Microsoft says Surface “deprecated UEFI” can brick via a single packet, after 90-day patch

For the last 90 days, Microsoft has been quietly repairing a firmware flaw across Surface devices that could render hardware inoperable with a single crafted interaction. The company’s spokesperson says the underlying trigger is a “deprecated UEFI interface” that can cause a boot loop on some devices. The catch is that exploitation requires administrator privileges and requires users to have already disabled Secure Boot, or disabled Secure Core and Secure Boot, depending on the scenario described by the researcher.

The twist that made this story unavoidable: Microsoft Copilot helped find it. Jack Darcy, an Australia-based security researcher, told The Register that Copilot generated and executed a Python script during a probe to adjust backlight settings on a Surface. Darcy says Copilot autonomously created and executed four progressively aggressive Python scripts, which sent raw SSAM ioctl commands (SSAM_CDEV_REQUEST = 0xC028A501) through the SAM software path to the SAM microcontroller. SSAM (or SAM) is the embedded controller responsible for low-level functions in Surface devices, and according to Darcy, Microsoft’s controller implementation lacked defense against arbitrary write values when Secure Core and Secure Boot were disabled.

Here is the mechanics, in plain English, and why this matters to executives who worry about “theoretical” vulnerabilities. Darcy explains that the probing led the embedded controller to process write-like operations without the usual safety checks. The Python script iterated over target category and specific Command ID (CID) pairs, sending empty or null payloads to WRITE commands. The outcome, Darcy said, was that SET Feature Report and Output Report calls were made with null payloads, while other CIDs were hit by SET commands that wrote garbage data.

Microsoft frames the impact as a boot-loop trigger. Darcy frames the outcome as potentially permanent bricking. He says devices that become inoperable via SAM access are permanently bricked: no USB recovery, no factory reset, and no access to BIOS or UEFI. He also claims this can mean hundreds of dollars in repairs for a new motherboard. The Register notes it cannot independently verify whether other reported boot failures are attributable to this specific bug, and Microsoft’s own position is narrower: “There is no realistic attack scenario with this issue,” a spokesperson told The Register. To exploit it, an attacker would need to interact with specific drivers and send commands to a hardware interface, which requires administrator privileges and disabling Secure Boot.

There is another detail executives should not gloss over: the bricking problem shows up specifically across a reboot boundary. Darcy explains that while the SAM is already initialized and running in RAM, so devices may keep operating during the initial probing, the trouble comes when the SAM reloads from corrupted non-volatile storage. Upon reboot, it fails to initialize and the system cannot complete Power-On Self-Test (POST). That makes this less like a normal software crash and more like the firmware equivalent of corrupting the one thing that boots everything else.

Microsoft says it investigated and released updates for “most impacted devices.” The company’s statement says the user must have administrator privileges and must have disabled the Secure Boot security feature to trigger the boot loop. Microsoft also says it released updates that address the issue for most impacted devices, and that managed devices are not at risk because those systems should receive updates via Windows Update. Microsoft added that the issue did not meet the bar for a CVE. If you have not received the update, the Register reports potential exposure still applies for users on Linux, users who disabled Secure Core and Secure Boot for gaming, users using custom Windows drivers, and users with USB boot enabled. Microsoft also indicates that managed devices are not at risk; the unresolved question for ops teams is how many endpoints fall into “not managed,” “not updated,” or “configured in a non-standard way.”

Even if the direct flaw is now patched, the second-order story is bigger than one bug. During coordinated disclosure, The Register says it delayed publication for 90 days to allow repairs after it coordinated a conversation between Darcy and Madeline Eckert, a senior program manager with MSRC. Microsoft’s investigation found a deprecated UEFI interface could trigger a boot loop, and it released updates accordingly.

The longer arc is about how Surface security architecture is being rebuilt. The Register reports Microsoft is moving the Surface stack toward Rust. David Abzarian, chief architect for Microsoft Surface, said Microsoft is building embedded controller firmware from the ground up in Rust using and contributing to the Open Device Partnership, and also rewriting UEFI DXE Core in Rust as “Project Patina.” Abzarian also said some drivers are being written in Rust and that Microsoft is co-developing “Windows Drivers in Rust (WDR)” to help partners adopt the model, with an emphasis on open-source transparency.

For boards and security leaders, the stakes are not just “will we patch.” It is how quickly a chain of components can turn a low-level command path into catastrophic outcomes, and how access controls interact with disabled security features. Surface is a prime example because it combines embedded controller firmware, UEFI interfaces, and driver paths that can be partially bypassed or destabilized when hardening is switched off. And for every organization watching the endpoint security market, this is a reminder that AI tooling can accelerate discovery, but it can also push probes harder than humans would typically do. That is why patch velocity, endpoint configuration hygiene, and secure-by-default posture are still the real governance levers, even when the vulnerability itself is “not a realistic attack scenario.”