Apple Secure Enclave vs Microsoft Pluton: Two Roads to Hardware Root of Trust

1. The bus that taught everyone a lesson#

In 2021, a researcher at Pulse Security wired a forty-dollar FPGA to the LPC bus of a Microsoft Surface Pro 3 and a Lenovo laptop, captured a handful of bytes as the machines powered on, and pulled the BitLocker Volume Master Key out of the air. Then they decrypted the drives. They wrote the whole thing up, with photos of the soldering and an open-source sniffer named lpc_sniffer_tpm (Pulse Security: Sniff, there leaks my BitLocker key).

The hardware was working exactly as designed.

That is what makes the story interesting. The Trusted Platform Module released the disk-encryption key the moment the boot configuration matched its sealed policy. It then handed the key, in cleartext, to the CPU over a physical wire on the motherboard. Anyone who could touch that wire could read the key. The chip, the spec, the OS -- all of them did precisely what the standard required. The threat model just never accounted for somebody putting probes on a laptop.

This is the problem hardware-rooted security has spent twenty years trying to dig itself out of. If you trust software, malware wins. If you trust software-plus-discrete-TPM, the bus wins. If you trust software-plus-firmware-TPM, the host operating system's privileged-mode bugs win. Every layer you add closes one class of attack and opens another.

Hardware roots of trust exist because no purely software-defined boundary can survive an attacker who runs code at the same privilege level you do. The only way out is to put the secrets somewhere your main CPU literally cannot read.

Apple and Microsoft both reached the same conclusion roughly a decade apart, and built almost opposite answers. Apple shipped the Secure Enclave Processor (SEP) with the A7 chip in the iPhone 5s in September 2013 -- a dedicated ARM core inside the application SoC, running its own microkernel, talking to the rest of the phone through a hardware mailbox. Microsoft announced Pluton in November 2020, but had been shipping Pluton-class silicon since the original Xbox One in 2013; the Windows version is an on-die security subsystem that pretends to be a TPM 2.0 chip and accepts firmware updates over Windows Update.

Both companies looked at the same threat -- a curious adversary with a screwdriver, an OS-level rootkit, or a $40 logic analyzer -- and decided the answer was to move the keys off the bus. They just disagreed about where to put them.

This article is the comparison nobody quite writes, partly because both vendors prefer to talk about themselves and partly because the technologies look superficially similar. They are not. The architectures differ. The threat models differ. The patch channels differ. The developer APIs differ enough that the same security goal -- "store this key so nothing but the user's biometric can use it" -- produces wildly different code on each side. By the end of this you should know which one is in your device, why it is there, what it actually defends against, and where the academic literature has already poked holes.

flowchart LR
subgraph Discrete["Discrete TPM (sniffable bus)"]
CPU1[CPU] -- LPC/SPI --> TPM[Discrete TPM chip]
end
subgraph SEP["Apple SEP (separate core)"]
AP[Application Processor] -- mailbox --> SEPCore[SEP core + sepOS]
end
subgraph Pluton["Microsoft Pluton (on-die subsystem)"]
CPU2[CPU] -- on-die fabric --> PlutonSub[Pluton subsystem]
end

The journey from "trust the OS" to "trust the silicon that even the OS cannot read" is the story of the last fifteen years of platform security. The Surface Pro 3 attack is what happens when you do half of it. Apple's and Microsoft's answers are what it looks like when you do all of it -- in two opposite ways.

2. Apple's answer: a small computer inside your phone#

The Apple Secure Enclave Processor is a separate physical CPU core, on the same die as the application processor, with its own memory, its own boot ROM, its own operating system, and its own random number generator. Apple's own framing in the Platform Security Guide is that the SEP "provides the foundation for the secure generation and storage of the keys necessary for encrypting data at rest." That is what it does. How it does it is what is interesting.

2.1 What sits on the die#

Inside an A-series or M-series SoC, the SEP is a distinct cluster. According to Apple's published architecture, it includes (Apple Platform Security: Secure Enclave):

• A dedicated processor core (not a SMT thread, not a shared core) running at a lower clock than the application cores.
• A Memory Protection Engine (MPE) that encrypts every cache line going to or from SEP-owned DRAM.
• A True Random Number Generator (TRNG) seeded by silicon noise.
• A hardware AES engine and a Public Key Accelerator (PKA) for ECC and RSA.
• A boot ROM masked in silicon at fabrication time.
• From A13 onward, a relationship with an external Secure Storage Component (SSC) that provides monotonic counters and replay-protected non-volatile storage.

The lower clock speed is not an accident. Apple explicitly notes that the SEP "is designed to operate efficiently at a lower clock speed that helps to protect it against clock and power attacks" (Apple Platform Security). Side-channel-resistance starts at the timing budget.

2.2 The boot chain, in order#

When you press the power button, two CPUs come up at once. The application processor begins executing its boot ROM, and the SEP begins executing its own. They are independent boot processes that meet later, after both sides have verified their own firmware.

sequenceDiagram
participant AP as Application Processor
participant SEP as Secure Enclave Processor
participant ROM as SEP Boot ROM (mask)
participant Flash as System Storage
Note over AP,SEP: Reset
AP->>AP: Execute AP Boot ROM
SEP->>ROM: Execute SEP Boot ROM
ROM->>Flash: Load sepOS image
ROM->>ROM: Verify signature against Apple root key
alt Signature valid
ROM->>SEP: Launch sepOS
SEP->>SEP: Initialize MPE, derive UID-tangled keys
else Signature invalid
ROM->>SEP: Halt
end
AP-->>SEP: Mailbox handshake
SEP-->>AP: Available services advertised

The SEP boot ROM is mask ROM. That phrase carries weight. It means the bits were etched into the silicon at fabrication and cannot be rewritten. Apple cannot patch the SEP boot ROM with a software update, even if Apple wants to. This is a feature -- nobody else can patch it either -- and a liability. We will return to it when we discuss checkm8.

After the SEP boot ROM verifies and launches sepOS, the SEP holds two values fused into the silicon at manufacture: a Unique ID (UID) and a Group ID (GID). The UID is per-device. The GID is per-product-family. Both are kept inside the SEP and never appear outside it. Keys derived from the UID are tangled to the specific piece of silicon; you cannot lift the wrapped key, move it to another phone, and unwrap it. The chip is physically the wrap-and-unwrap oracle. The UID is also why factory-reset really does erase your data. The data-protection key hierarchy roots at a key derived from the UID and a per-file random; rotate the right intermediate and every wrapped file becomes unrecoverable noise.

2.3 The Memory Protection Engine#

The SEP's RAM is, physically, in the same DRAM module as everything else. A naive design would let the application processor read it. The MPE prevents that. Every cache line bound for SEP memory is encrypted with AES in XEX mode (a tweakable mode similar to disk-encryption XTS) and authenticated with a CMAC tag. The tweak includes the physical address, so an attacker cannot relocate ciphertext to a different location and have it still verify (Apple Platform Security: Secure Enclave).

Starting with the A11 SoC, the MPE added an anti-replay value per protected block, with the anti-replay tree rooted in dedicated on-die SRAM. The threat that introduces is: an attacker who can capture the encrypted DRAM contents at time T1 and overwrite the DRAM with that snapshot at time T2 -- a "store, rewind, replay" attack. Tree-rooted anti-replay defeats it because the root in SRAM does not match the old leaves the attacker re-injected.

From the A14 and M1 generation onward, the MPE handles two ephemeral keys: one for SEP-private data and one for data shared with the Secure Neural Engine (used during Face ID matching). The keys are regenerated at every reset, so even capturing the DRAM ciphertext across a reboot leaks nothing.

2.4 The Secure Storage Component#

Anti-hammering -- the property that a passcode-guessing attacker is rate-limited and eventually locked out -- requires reliable monotonic state that the attacker cannot rewind. Mask ROM and on-die SRAM are not enough on their own because power loss erases SRAM. From the A13 SoC onward, Apple solves this by adding a separate chip on the logic board: the Secure Storage Component (SSC).

The SSC is small, tamper-resistant, and only the SEP can talk to it. It stores monotonic counters and entropy values that the SEP uses to bind authenticated storage to wall-clock state. If you steal the phone, dump the encrypted blobs, "rewind" by overwriting the flash with an earlier copy, and try to brute-force the passcode again, the SSC's counters no longer match. Anti-hammering survives the rewind.

2.5 The mailbox API#

Userspace apps never touch the SEP directly. The application processor reaches it through a hardware mailbox -- a small ring of registers and shared memory that defines the entire API surface from AP to SEP. The kernel exposes higher-level services on top: Touch ID and Face ID matching, Keychain entries flagged with kSecAttrTokenIDSecureEnclave, Data Protection class keys, App Attest signing, and so on.

The constraint is severe. The SEP exposes a fixed set of operations. No app, and no part of the OS, can ask the SEP to do something the firmware did not already implement. Compromise of the AP-side kernel does not produce an arbitrary-code-execution primitive on the SEP. It produces, at most, the ability to call SEP services from a hostile place -- and those services still require user authentication (FaceID, TouchID, passcode) before they release sensitive operations.

If you had to summarize what Apple built in one sentence: they put a second computer in the phone, gave it the keys, gave it a lock on its own door, and left a slot for messages to slide through. That is the design.

3. Microsoft's answer: kill the bus, keep the standard#

Apple had the luxury of designing the application processor and the security processor together. Microsoft does not. Microsoft sells software that runs on AMD, Intel, and Qualcomm silicon, on chassis from Dell, HP, Lenovo, Acer, Asus, Microsoft itself, and a long tail of others. The discrete TPM 2.0 standard fixes a contract between Windows and a piece of trusted hardware that any vendor can implement. Pluton's job was to keep that contract while removing the parts that did not survive contact with reality.

The first part of reality Pluton kills is the bus.

3.1 The Xbox lineage#

Microsoft did not invent Pluton for Windows. The architecture started in the original Xbox One, shipping in 2013, where it served as the security subsystem that prevented modchipping and verified the boot chain. The same architecture was extended to the Azure Sphere MT3620 microcontroller in 2018, aimed at IoT devices. The Windows variant -- the one most people mean when they say "Pluton" -- was announced in November 2020.

The first shipping Windows silicon containing Pluton was the AMD Ryzen 6000 series ("Rembrandt") in January 2022. Qualcomm Snapdragon 8cx Gen 3 and the Snapdragon X family followed in 2023-2024. Intel's first Pluton-bearing CPU was Core Ultra Series 2 ("Lunar Lake") in late 2024. As of the current Microsoft documentation, the supported matrix is "AMD Ryzen 6000/7000/8000/9000 and Ryzen AI Series; Intel Core Ultra 200V Series, Ultra Series 3; Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series" (Microsoft Pluton Security Processor, Microsoft Learn).

3.2 What sits on the die#

Pluton is a security subsystem placed inside the SoC, not on a separate chip on the motherboard. That single architectural decision eliminates the LPC/SPI bus that defeats discrete TPMs. Microsoft's framing in the announcement post: the design targets attacks "where an attacker can steal or temporarily gain physical access to a PC ... on the communication channel between the CPU and TPM" (Microsoft Security Blog).

Inside the die, Pluton runs its own small processor (the vendors do not publish the ISA in customer-facing docs), with its own ROM, on-die RAM, hardware crypto engines, and a hardware-confined key store. It exchanges messages with the host through a mailbox interface analogous to SEP's, but the higher-level wire protocol it speaks back to the host is TPM 2.0.

3.3 TPM 2.0 as the personality, not the limit#

Pluton implements the TPM 2.0 command set. That means BitLocker, Windows Hello, Credential Guard, System Guard, Measured Boot, and Device Health Attestation all work against Pluton with no modifications -- they think they are talking to a TPM 2.0 chip, and they are (Microsoft Pluton as TPM, Microsoft Learn).

TPM 2.0 compatibility is the compromise that buys Microsoft adoption. The entire Windows security stack was already designed against the TCG TPM 2.0 wire protocol. Forcing it onto a new API would have required years of platform engineering. Forcing it onto a new API and getting OEMs to adopt the new chip would have required forever.

flowchart TD
subgraph Windows["Windows OS"]
BL[BitLocker]
WH[Windows Hello]
CG[Credential Guard]
DHA[Device Health Attestation]
end
subgraph Pluton["Pluton subsystem on SoC"]
TPMpers["TPM 2.0 personality — (PCRs, EK, AK, Quote, Seal)"]
MSrooted["Microsoft-rooted services — (Pluton credentials, MS-signed firmware)"]
end
BL --> TPMpers
WH --> TPMpers
CG --> TPMpers
DHA --> TPMpers
DHA --> MSrooted
WH --> MSrooted

3.4 The patch channel#

This is the design feature Microsoft most emphasizes and where the philosophical break with Apple is most visible. Pluton firmware can be updated through two paths (Microsoft Pluton Security Processor, Microsoft Learn):

1. UEFI capsule update. The Pluton firmware lives on the system's SPI flash and is loaded during early boot. A capsule update -- delivered via the same UEFI mechanism that updates BIOS -- can replace it.
2. Dynamic loading via Windows Update. Microsoft can ship a new Pluton firmware blob through Windows Update; the OS loader picks it up the next time the subsystem comes online.

Apple's update model is essentially the first path with a different label. The SEP firmware ships inside the iOS/macOS image bundle, signed by Apple, and is loaded at boot. There is no Windows-Update-style ambient channel separate from the OS image.

Patchable. By Microsoft. Through the channel users already trust. This is the single biggest practical advantage Pluton has over discrete TPMs, and the single biggest political problem.

The structure of this difference is what makes the Apple-vs-Microsoft comparison sharp. Apple controls the entire silicon, OS, and update channel. The patch path is fast because everything is one vendor. Microsoft does not control the silicon -- AMD, Intel, and Qualcomm do -- but they wrote the firmware, signed it, and route it through Windows Update. The patch path is fast because Microsoft has been delivering OS-level updates to a billion machines for a quarter century.

3.5 Rust as the firmware base#

In 2024 Microsoft began shipping Pluton firmware on AMD and Intel with what the documentation calls "a Rust-based firmware foundation given the importance of memory safety" (Microsoft Pluton Security Processor, Microsoft Learn). This is, as far as we can tell from primary sources, the most prominent shipping production use of Rust inside an x86 platform security subsystem. It addresses the most common class of TPM firmware bugs, which historically have been C memory-safety issues -- bounds errors, use-after-frees, integer overflows.

If the SEP's design philosophy is "small fixed-purpose computer," the Pluton design philosophy is "in-die TPM 2.0 we can actually patch, written carefully enough that we will not have to patch it often." Two different bets about which property mattered most.

4. The tightly-coupled vs SoC-integrated trade-off#

So far we have two architectures: SEP as a separate physical core, Pluton as an on-die subsystem. They sound different. They are different. But "separate core" and "on-die subsystem" both refuse the discrete-TPM design where the security chip is off the SoC and reachable over a motherboard bus. Why did both vendors converge there, and what is the trade-off between SEP-style and Pluton-style integration?

4.1 What both reject#

The discrete TPM 2.0 model is the baseline. A separate chip, often a Nuvoton, Infineon, or ST device on the motherboard, connected to the platform via LPC, SPI, or I²C. The TCG spec it implements is excellent. The physical placement is the problem.

Pulse Security's attack is the canonical demonstration. With lpc_sniffer_tpm on a $40 FPGA, they probed the LPC bus of a Surface Pro 3 as it booted, captured the bytes the TPM returned for the unsealed Volume Master Key, and used those bytes to decrypt the disk (Pulse Security: TPM Sniffing). The TPM was working correctly. The bus was the problem. There is a mitigation -- pre-boot PIN or USB key, so the VMK is bound to something not on the wire -- but the default BitLocker configuration on most enterprise hardware does not enable it.

Both SEP and Pluton refuse to expose that bus. The keys never appear on an external wire. That is the structural property both architectures buy by being on the SoC.

4.2 Tightly-coupled (SEP) vs subsystem-on-die (Pluton)#

After agreeing on "no external bus," the two diverge sharply on what "on the SoC" should look like.

flowchart TD
subgraph SEPDie["Apple SoC (A14, M1, M2, etc.)"]
SEPCore["SEP core — own voltage — own clock — own ROM"]
MPE["Memory Protection Engine"]
APCore["Application processor cores"]
SEPCore -- mailbox --> APCore
SEPCore --> MPE
end
subgraph PlutonDie["AMD/Intel/Qualcomm SoC"]
PSub["Pluton subsystem — (may share voltage rail — with security die area)"]
PSP["Vendor security subsystem — (AMD PSP / Intel CSME)"]
Cores["Application cores"]
PSub -- on-die fabric --> Cores
PSub -.runs on top of.-> PSP
end

The SEP is a separate physical core with its own clock, its own voltage rail, and crucially no shared microarchitecture with the application processor. That last point matters because the family of cross-thread, cross-core, and frequency-scaling side channels -- Meltdown, Spectre, Foreshadow, Hertzbleed, and their cousins -- generally requires the attacker code to be co-resident on the same physical pipeline or share a microarchitectural resource. The SEP simply does not share execution resources with potentially hostile code on the application cores (Apple Platform Security: Secure Enclave Processor).

Pluton-on-AMD is implemented inside the AMD Platform Security Processor environment. Pluton-on-Intel is implemented inside Intel's Converged Security and Management Engine. These are pre-existing vendor security subsystems Microsoft layered Pluton atop. The Pluton subsystem is logically separate, with its own firmware and its own key store. Whether it has a fully separate physical voltage rail and clock domain from the application cores is not something the public documentation states clearly, and the answer almost certainly varies by silicon partner.

4.3 The SGX cautionary tale#

There is a third design point worth flagging because both vendors implicitly chose against it: putting the trusted execution environment inside the application CPU cores themselves. Intel SGX, introduced in 2015, did exactly that. Enclaves were memory regions with hardware access control inside the same cores running ordinary software.

SGX was a beautiful idea and an academic catastrophe. Foreshadow, ZombieLoad, SgxPectre, Plundervolt, and a long sequence of related attacks reused the side-channel-rich microarchitecture of modern Intel cores to leak enclave contents. Intel deprecated SGX on most consumer processors in 2022, retaining it on server SKUs for confidential computing scenarios where the threat model is different.

The lesson is something both Apple and Microsoft seem to have absorbed: a trusted execution environment that shares any microarchitectural state with the workloads it must protect from is structurally compromised, because microarchitecture is too rich and too leaky to perfectly isolate. The SEP rejects this by living on its own core. Pluton rejects it by living in a separate subsystem.

4.4 The trade-off in one sentence#

A dedicated core (SEP) maximises side-channel resistance and minimises attack surface, at the cost of vendor proprietary lock-in and zero portability. An on-die subsystem (Pluton) preserves the TPM 2.0 standard, ships on three silicon vendors, and inherits the security guarantees of the underlying vendor security subsystem -- whose history, as we will see, is less reassuring than Apple's monopoly on its own silicon.

SEP wins on isolation. Pluton wins on portability. Neither wins on both. The choice you make at the SoC level constrains every API, every patch path, and every threat-model claim downstream.

5. The APIs developers actually call#

Architectures are interesting. What ships in production code is what determines whether developers use these things correctly. The API surfaces are wildly different, and the difference matters.

5.1 Apple: SecKey, App Attest, LocalAuthentication#

On Apple platforms, the SEP is exposed through a handful of frameworks. The most common entry point is SecKey in the Security framework, with key attributes that bind the key to the SEP:

• kSecAttrTokenIDSecureEnclave makes the key SEP-resident.
• kSecAttrAccessControl with LAContext adds biometric or passcode gating.
• kSecAttrIsPermanent puts it in the Keychain.

The key itself never leaves the SEP. The application receives an opaque handle. Asking the framework to sign a message turns into a mailbox call to the SEP, which evaluates the access-control policy (e.g., "the user must FaceID-authenticate within the last five seconds") and either signs or refuses.

// This is a conceptual model of what happens when iOS code asks the SEP
// to sign a message with a key whose private half lives inside the SEP.
// The real code is Swift + Security.framework; this JS captures the logic.

function generateSEPKey(accessControl) {
// SEP generates the keypair internally
const priv = sepRandomBytes(32);            // never leaves SEP
const pub  = ecP256ScalarMul(priv, BASE_G);
const blob = aesKeyWrap(sepUIDDerivedKey, priv);
return { publicKey: pub, handle: opaque(blob), policy: accessControl };
}

function sign(handle, message) {
const policy = lookupPolicy(handle);
// SEP enforces the access control: must the user have authenticated recently?
if (!policy.satisfied(LAContext.current)) {
  return { error: "user authentication required" };
}
const blob = lookup(handle);
const priv = aesKeyUnwrap(sepUIDDerivedKey, blob);
return ecdsaP256Sign(priv, sha256(message));
}

const k = generateSEPKey({ requireBiometric: true });
console.log("Public key returned to the app:", k.publicKey);
console.log("Private key location: inside SEP, never accessible to app code");

Beyond SecKey, the SEP underpins:

• LocalAuthentication -- Face ID / Touch ID matching happens inside the SEP. The biometric template never leaves the SEP, and the application is only told yes/no.
• DeviceCheck and App Attest -- documented in the Apple Platform Security Guide. App Attest gives each app installation a SEP-rooted asymmetric key whose certificate chains to Apple's CA, letting servers verify that a sign-up came from a genuine app on a genuine Apple device.
• Data Protection / FileVault -- per-file class keys are wrapped under SEP-held intermediate keys.
• Apple Pay -- payment credentials are SEP-resident and gated on biometric/passcode authentication.

5.2 Microsoft: TBS, NCrypt, Pluton-rooted credentials#

On Windows, the TPM 2.0 personality means Pluton is reached through the same APIs as any TPM:

• TPM Base Services (TBS) -- the low-level Win32 API for sending TPM 2.0 commands.
• CNG (Cryptography Next Generation) with NCrypt and the Microsoft Platform Crypto Provider -- the higher-level key API that asks "store this key in the TPM, gated on the user's PIN."
• BCryptDecrypt / BCryptSignHash as the in-process crypto API on top.

The DPAPI key-protection model -- file/blob protection rooted in user logon credentials -- has a CNG variant documented as CNG DPAPI that integrates with TPM-rooted hierarchies. Above that sit the consumer-facing systems: BitLocker for disk encryption, Windows Hello for credential storage, Credential Guard for isolating LSA secrets in a virtualization-based security enclave, and Microsoft Entra ID conditional access for cloud sign-in.

flowchart LR
subgraph Apple["Apple application stack"]
App[App] --> Sec["Security.framework — (SecKey, SecAccessControl)"]
App --> LA["LocalAuthentication — (LAContext)"]
App --> DC["DeviceCheck / App Attest"]
Sec --> Mailbox[SEP mailbox]
LA --> Mailbox
DC --> Mailbox
Mailbox --> SEPSvc[SEP services]
end
subgraph MS["Windows application stack"]
WApp[App] --> NCrypt["CNG / NCrypt"]
WApp --> Hello["Windows Hello"]
WApp --> Entra["Entra ID / Health Attestation"]
NCrypt --> TBS["TPM Base Services"]
Hello --> TBS
Entra --> TBS
TBS --> Pluton["Pluton (TPM 2.0 personality)"]
Entra --> PlutonMS["Pluton MS-rooted services"]
end

5.3 What the API shape tells you#

The SEP API forces every call into the small set of operations the SEP firmware implements. There is no TPM2_PolicyLocality(2) equivalent or TPM2_PolicyOR combinator on the SEP. You ask for a key, you ask for a signature, you ask for a biometric match, and that is mostly the surface. From a developer's point of view, the SEP feels like a very small set of well-defined building blocks.

The TPM 2.0 API, by contrast, is enormous. There are several hundred commands. The TPM has policy expressions, sessions, hierarchies (storage, endorsement, platform, owner), and a half-dozen attestation primitives. This expressiveness was the right call for an open standard -- the TCG had to accommodate every conceivable use case across two decades. It also means that "wrote TPM 2.0 code correctly" is a measurable engineering skill rather than a default.

5.4 A note on what is not exposed#

Neither platform exposes the device's per-silicon root key to applications. On Apple, the UID is sealed inside the SEP; on Microsoft, the Pluton Endorsement Key is unique per chip but applications interact only with the AKs (Attestation Keys) derived from it. This is deliberate: per-device permanent keys, if exposed, enable cross-service tracking. The exposed primitives are either per-app/per-installation (App Attest), per-session (TPM2_Quote with a fresh AK), or ephemeral (a freshly-generated SEP key).

That choice maps to a privacy property we will pick up in the next section: how each platform answers "prove this is a real device" without becoming "track this specific user across every service."

6. Identity, attestation, and the privacy problem#

The deepest difference between Apple and Microsoft is not architectural. It is the answer each one gives to a question that sounds simple: what does it mean to prove a device is real?

6.1 Why attestation is hard#

A naive answer is: burn a unique identifier into every chip and have the chip sign messages with the corresponding private key. That works for proof. It also creates a per-device pseudonym that every service can recognise and correlate. The naive answer is a surveillance disaster.

A better answer keeps the unforgeability of "this signature came from a real device" and adds an unlinkability property: the signature does not identify which device, only that it is genuine. This is what cryptographers call anonymous attestation, and the canonical construction is DAA.

The mathematics of DAA rests on group signatures with selective linkability. A device runs the join protocol once with a group issuer (the "Privacy CA" or analogous authority) and receives a credential. It can then prove, via a Camenisch-Lysyanskaya-style signature of knowledge, that it holds such a credential without revealing which one. With ECDAA, the join and signing operations are roughly the cost of a couple of elliptic-curve multiplications.

The privacy property comes with caveats. Verifiers can opt into "basename" linkability, where signatures from the same device addressed to the same service are linkable -- letting a service recognise a returning user without letting it correlate across services. The math has been deployed in TPM 2.0 since the 2014 spec.

6.2 The Microsoft path: TPM 2.0 attestation plus Microsoft-rooted services#

Pluton inherits TPM 2.0's attestation primitives. The standard flow:

1. Generate an Attestation Key (AK) inside the TPM, with a private half that never leaves.
2. Certify the AK to a Privacy CA (or via ECDAA) using the Endorsement Key.
3. Hash the boot configuration into Platform Configuration Registers (PCRs) during measured boot.
4. Have the relying party send a fresh nonce.
5. Issue TPM2_Quote(AK, PCR_mask, qualifying_data=nonce).
6. Send the quote, the AK certificate, and the boot event log to the relying party.
7. The relying party replays the event log, checks that the replayed PCRs match the quoted ones, validates the AK certificate chain, and validates the signature.

attest(nonce, pcr_mask):
    AK = TPM2_Create(parent=EK, type=signing)
    AK_cert = privacy_CA.certify(AK_pub, EK_cert)    # or ECDAA group sig
    quote = TPM2_Quote(AK, pcr_mask, qualifying_data=nonce)
    return (quote, AK_cert, event_log)

verify(quote, AK_cert, event_log, expected_pcrs):
    assert privacy_CA.verify(AK_cert)
    assert ECDSA_verify(AK_cert.pub, quote.sig, quote.body)
    assert quote.qualifying_data == nonce
    assert replay_log(event_log) == quote.pcrs == expected_pcrs

That covers raw TPM 2.0. Microsoft layers on top a service called Device Health Attestation that does the verifier work as a cloud service, supplying Reference Integrity Manifests for known-good Microsoft-signed boot states. Microsoft Entra ID conditional access policies can then refuse sign-in to devices whose Pluton-signed health attestation does not match an expected baseline (Microsoft Pluton Security Processor, Microsoft Learn).

6.3 The Apple path: rooted in Apple's CA, scoped per app#

Apple's DeviceCheck and App Attest take a different approach. App Attest gives each installation of each app a unique SEP-resident key. The corresponding attestation certificate chains to Apple's CA. Apps prove integrity to their own back-end servers by having the server send a nonce, the SEP signing the nonce with the per-install key, and Apple's CA chain validating that the key was issued on a genuine Apple device.

The privacy property is scoped differently from DAA. The key is per-installation, which means uninstalling and reinstalling the app generates a new key with no link to the old one. Across different apps on the same device, the keys are independent -- so two apps cannot collude with their respective back-ends to detect they are on the same phone. The trade-off: there is no formal anonymity within a group; the key is identifiable to its single installation, but that installation is fresh each install.

DeviceCheck is older and weaker. It gives an app a two-bit value the developer can set per device, retrievable on future runs. It is fraud-signal infrastructure, not cryptographic proof.

6.4 Where the two converge: FIDO2/WebAuthn#

Both platforms expose their hardware-backed credentials through a single cross-platform standard: FIDO2/WebAuthn. When a browser asks "create a credential bound to this origin, hardware-resident if possible," the underlying operating system asks SEP or Pluton to generate the key. The resulting public-key credential, signed by the device's attestation key, is what the relying party verifies (FIDO Alliance).

sequenceDiagram
participant Browser
participant OS as OS Authenticator
participant HW as SEP or Pluton
participant RP as Relying Party
RP->>Browser: Challenge nonce, RP ID
Browser->>OS: navigator.credentials.create()
OS->>HW: Generate key bound to RP ID + user gesture
HW-->>OS: Public key + attestation
OS-->>Browser: Public key + signed attestation
Browser->>RP: Registration response
Note over RP: Stores public key
RP->>Browser: Authentication challenge
Browser->>OS: navigator.credentials.get()
OS->>HW: Sign challenge (user gesture)
HW-->>OS: Signature
OS-->>Browser: Assertion
Browser->>RP: Authentication response
RP->>RP: Verify signature with stored pubkey

FIDO2/WebAuthn is the most boring and most important fact about modern hardware roots of trust: from the application's point of view, you no longer need to know whether you are talking to SEP or Pluton or a discrete TPM. The same JavaScript runs on all of them. We will return to FIDO2 in Section 8.

7. What has actually broken#

Architecture is a story you tell about a system. Attacks are the system's reply. Both SEP and Pluton have a public attack history; reading it carefully is the fastest way to understand the real threat model rather than the marketing one.

7.1 checkm8 and the unpatchable boot ROM#

In late 2019, the researcher axi0mX published ipwndfu, an exploit against a use-after-free in the SecureROM USB DFU stack of Apple SoCs from A5 through A11. The advisory carries CVE-2019-8900 and CERT/CC VU#941987. Because SecureROM is mask ROM -- etched into the silicon, immutable -- Apple cannot patch it. The only mitigation was new silicon. A12 and later are immune; earlier devices are permanently affected.

What checkm8 buys an attacker is application-processor code execution at boot time, on a device they have physical access to. That is significant. It enables forensically sound extraction tooling -- the Elcomsoft writeup walks through exactly which iPhone models and iOS versions are supported. It also covers the Apple T2 chip used in 2018-2020 Intel Macs, which is built on the same A10-family silicon.

But checkm8 does not, by itself, break SEP secrets. The SEP is still gated by the device passcode and the data-protection class keys. An attacker with checkm8 can run code on the AP, but they still need the passcode to unlock the user's protected data (CERT/CC VU#941987). The forensic value of checkm8 comes from being able to brute-force passcodes more effectively, capture keyboard state, and access classes of data not bound to a passcode -- not from extracting SEP-held keys directly.

7.2 LPC sniffing and discrete TPMs#

We opened with this attack and it deserves a second pass in the context of Pluton's design. The Pulse Security writeup demonstrates extraction of the BitLocker Volume Master Key from a Microsoft Surface Pro 3 (TPM 2.0) and a Lenovo laptop (TPM 1.2) using a $40 FPGA on the LPC bus. The attack requires physical access for under an hour and modest soldering skill.

This is the textbook case where Pluton is structurally better than discrete TPMs: there is no external bus to sniff because the security subsystem lives on the SoC die. The same attack against a Pluton-enabled CPU is not just hard, it is geometrically impossible. There is no bus to attach probes to.

That is not the same as "Pluton is unattackable" -- it just means this specific attack class is closed.

7.3 faulTPM and the AMD PSP#

The most consequential publication on Pluton-adjacent silicon is Werling, Buhren, Jacob, and Seifert's 2023 USENIX WOOT paper "faulTPM". The attack: voltage fault injection against AMD's Platform Security Processor (PSP), the TEE on which AMD's fTPM runs, on Zen 2 and Zen 3 CPUs. The result: full extraction of the fTPM key derivation seed. With that seed, the attackers decrypted all sealed objects regardless of PCR policy or anti-hammering, and recovered the BitLocker VMK on a Lenovo Ideapad. The reproducible attack code is PSPReverse/ftpm_attack on GitHub.

Several careful observations:

• The published attack targets non-Pluton AMD fTPM. Pluton-on-AMD is a separate code path; faulTPM as published does not directly extract Pluton state.
• Pluton-on-AMD runs in the PSP environment. The underlying TEE that faulTPM compromises is the same TEE Pluton-on-AMD rides on. Whether the additional hardening Pluton adds is sufficient to defeat fault injection at the PSP level is an open empirical question.
• There is no published voltage-glitch attack against Microsoft Pluton specifically as of May 2026 in the verified sources surveyed. Absence of evidence is not evidence of absence; serious researchers are reportedly working on it.

7.4 What is not known to be broken#

Modern SEP (A14+/M-series) has no publicly disclosed extraction attack as of the May 2026 verified sources reviewed. The combination of dedicated core, MPE with anti-replay, lower clock, and SSC-backed replay protection has held up. This is consistent with -- but does not prove -- the architectural claim that the dedicated-core design closes the side-channel and co-execution attack surface.

Pluton with the 2024+ Rust firmware foundation has no publicly disclosed direct extraction attack. The faulTPM family of attacks remains an open concern at the PSP layer; the LPC bus class is closed by design; firmware bugs are reduced (not eliminated) by the move to memory-safe code.

flowchart TD
A["Attack class"] --> B&#123,"Discrete TPM"&#125,
A --> C&#123,"AMD fTPM"&#125,
A --> D&#123,"Pluton"&#125,
A --> E&#123,"Apple SEP A14+"&#125,
B --> B1["LPC sniffing: yes (Pulse Security)"]
B --> B2["Firmware bug: rare patches"]
C --> C1["faulTPM: full extraction"]
C --> C2["Patches: BIOS only"]
D --> D1["LPC sniffing: not applicable"]
D --> D2["faulTPM-like on PSP: open"]
D --> D3["Patches: Windows Update + capsule"]
E --> E1["checkm8 on A5-A11: AP code exec"]
E --> E2["Direct SEP extraction A14+: none public"]
E --> E3["Patches: iOS/macOS update, mask ROM never"]

The honest summary is that as you move from discrete TPMs to fTPMs to Pluton to SEP, the attack surface shrinks but the residual attacks get more expensive rather than disappearing. The faulTPM line is still the academic state of the art in showing this.

8. Cross-platform standards: the layer where the divide gets papered over#

If you are a web developer in 2026 and a user asks "how do I sign into your site with my Touch ID or my Windows Hello fingerprint?" the answer is the same in either case: WebAuthn. The standard does not care which hardware root of trust the OS happens to expose underneath.

8.1 FIDO2/WebAuthn as the lingua franca#

The FIDO Alliance defines the protocols. WebAuthn is the W3C JavaScript API; CTAP (Client to Authenticator Protocol) is the underlying transport between the browser/OS and the authenticator. The authenticator can be a USB security key, a phone, a built-in platform authenticator backed by SEP or Pluton, or something else entirely. The relying party sees the same registration and authentication ceremony in all cases.

The handful of properties WebAuthn guarantees -- origin binding, user gesture, fresh signature per challenge -- are independent of the silicon underneath. The handful of properties it does not try to guarantee -- "is this device freshly compromised by a kernel rootkit" -- are not fixable at the protocol layer either; that is what attestation extensions are for.

8.2 Where attestation extensions vary#

WebAuthn defines optional attestation extensions that let a relying party request a hardware-backed proof that the authenticator is genuine. Apple's attestation through WebAuthn rides on App Attest infrastructure; Microsoft's rides on TPM 2.0 attestation. The receipts differ in format and certificate chain, but the higher-level question "does the public key come from genuine hardware" gets answered on both platforms.

For most relying parties, the cross-platform truth is simpler than the underlying mechanics: ask for a hardware-backed credential, accept the WebAuthn response, validate the signature, and let the platform handle what kind of silicon was involved.

8.3 TPM 2.0 as the other lingua franca#

TPM 2.0 itself plays this role in non-web contexts. Enterprise tools that need to attest a device's boot state -- Microsoft Entra ID conditional access, MDM compliance evaluators, Linux remote attestation frameworks -- speak TPM 2.0. Pluton exposes the TPM 2.0 wire protocol, so these tools work unchanged (Microsoft Pluton as TPM, Microsoft Learn).

Linux on Apple Silicon (Asahi) currently cannot use SEP for analogous attestation; Apple does not expose the SEP to non-Apple operating systems, and there is no TPM 2.0 emulation. This is a real gap for users who want Apple hardware with a non-Apple OS.

8.4 The Android third corner#

This article is about Apple vs Microsoft, but a complete picture must mention that Android has its own hardware root of trust story rooted in Trusty/TEE-style designs on ARM TrustZone plus discrete StrongBox elements on Pixel-class hardware. Cross-platform mobile development frequently abstracts SEP and Android StrongBox under a common interface (e.g., React Native's keychain modules), and the privacy and attestation properties of the two systems are not identical but rhyme. Google Play Integrity API plays the role App Attest plays on iOS.

9. Deployment dynamics: who ships what, where, when#

The two industries have different shapes, and that shapes the deployment story.

9.1 Apple: vertical integration, total reach#

Every shipping Apple device since the iPhone 5s contains a SEP, by virtue of every shipping Apple SoC containing one. That includes (Apple Platform Security: Secure Enclave):

• iPhone 5s and later (A7+)
• iPad Air and later
• Apple Watch Series 1 and later
• Apple TV HD and later
• HomePod and HomePod mini
• Apple Vision Pro
• All Apple Silicon Macs (M1, M2, M3, M4 families)
• All Intel Macs from 2018 to 2020 (via the T2 chip)

There is no SKU differentiation. There is no "Pro vs Air" split on whether security hardware is present. You buy a current-generation Apple device, you get the SEP. This is the upside of vertical integration: deployment by default.

The downside is that nothing else gets the SEP. Linux on Apple Silicon -- the Asahi Linux project -- cannot use the SEP for keychain operations, FileVault wrapping, or attestation. Apple does not expose the SEP outside of macOS, iOS, iPadOS, watchOS, tvOS, and visionOS. The hardware is universal in Apple's product line and absent everywhere else.

9.2 Microsoft: open multivendor, opt-in adoption#

Pluton ships in silicon Microsoft does not make. That changes the deployment story in two ways:

1. Vendor availability. As of the current Microsoft documentation, Pluton is present in AMD Ryzen 6000 and later, Intel Core Ultra Series 2 and later, and Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series. Anything older still uses discrete TPM 2.0 or vendor fTPM.
2. OEM enablement. The chip can be physically present and disabled in UEFI. Microsoft has been pushing OEMs to ship Pluton enabled by default on Copilot+ PCs, but the universe of laptops is heterogeneous, and the practitioner answer is "check tpm.msc to see what manufacturer ID is reported."

Default-enabled-on-shipping-hardware is documented for Surface Laptop 7 and Surface Pro 11 Copilot+ PCs. Various Lenovo ThinkPad Z, Dell Latitude, and HP EliteBook configurations follow (Microsoft Pluton Security Processor, Microsoft Learn). On other devices Pluton may be present but disabled in firmware, falling back to discrete TPM or vendor fTPM.

9.3 The patch-channel difference, made concrete#

Apple ships SEP firmware inside its OS update. When the user installs iOS 19.4 or macOS 16.2, the bundle includes a new sepOS image; the device verifies and loads it during the next boot (Apple Platform Security).

Microsoft ships Pluton firmware through Windows Update and UEFI capsules. The OS-driven path lets Microsoft push a firmware refresh to billions of machines without OEM cooperation. The capsule path covers the case where the firmware is needed during early boot before Windows itself is in control.

Discrete TPMs occupy the third position: firmware updates exist but require an OEM-issued utility that few users ever run. This is why most enterprise TPMs in the field run firmware from 2020 or earlier.

9.4 The economic and political layer#

Apple controls every step from sand to support page. The benefit is consistency. The cost is that Apple decides what the SEP can and cannot do, with no externally visible audit, and the customer cannot verify the firmware. For the Apple-customer market, that has not been a deal-breaker.

Microsoft controls the Pluton firmware. The benefit is that one team's engineering effort propagates across three silicon vendors and thousands of OEM SKUs. The cost is that the OS update channel and the security update channel collapse into one Microsoft-controlled flow. Critics describe this as platform lock-in; supporters describe it as the only way to actually patch the silicon at scale. Both readings have evidence behind them.

The same patch channel that protects users from unpatched silicon bugs is the patch channel a hypothetical compelled-update scenario would use. There is no commodity product that gives the device owner an independent veto on root-of-trust firmware updates.

This is a real open problem, not a fictional one. The Trusted Computing Group has a notion of "owner-authorized" TPM hierarchies; Azure Sphere uses a three-key model in which device owner, vendor, and Microsoft all hold signing capabilities for different scopes. Nothing in the commodity consumer space has yet shipped a model where the device owner can veto a vendor-signed firmware update on the security subsystem.

10. Where this goes next#

The honest answer is that the immediate future is more of the same with three new pressures.

10.1 Post-quantum migration#

The cryptographic primitives currently rooted in both platforms -- ECDSA P-256 in the SEP, RSA-2048 and ECDSA in TPM 2.0 -- are not post-quantum-safe. NIST standardized ML-KEM and ML-DSA in FIPS 203 and FIPS 204 in 2024 (the NIST publication URLs are outside our verified-source set, so this paragraph states the timeline at the policy level only). Migrating hardware-fused attestation roots to post-quantum schemes is genuinely hard because the silicon-burned UID-equivalent keys are baked at fabrication time and cannot easily be replaced.

The likely path: hardware retains agility at the wrapping layer (the unique chip key) while the attestation key types evolve. TPM 2.0 already supports algorithm agility in the spec, which is the kind of foresight you only appreciate a decade after it was added. SEP's key wrapping is bespoke; Apple has not published a PQC migration plan in the verified sources reviewed.

This is a place where the comparison gets uncertain. Both vendors will need to migrate. Neither has shipped a primary post-quantum-rooted attestation flow in their public 2026 documentation as far as we can verify.

10.2 Confidential computing convergence#

The same silicon technologies that build SEP and Pluton are now powering confidential computing -- AMD SEV-SNP, Intel TDX, ARM CCA. These extend the "untrusted host kernel" threat model from disk encryption and credential storage to entire virtual machines. The trust roots of confidential computing currently live in the same chips' security subsystems: AMD's PSP holds SEV-SNP attestation keys; Intel's CSME, working with TDX, holds equivalent keys.

Pluton-on-Intel and Pluton-on-AMD will likely inherit responsibilities here as Microsoft consolidates more of the security subsystem under the Pluton name. Apple has not publicly signaled equivalent ambitions for SEP on the server -- Apple's server presence is mostly internal.

10.3 The AI agent identity problem#

This is the next decade's question. When your laptop runs an autonomous AI agent that signs cloud API requests on your behalf, what attests to the agent's identity? The current architectures attest to the device and to user gestures, not to the agent. There is no shipping primitive in either SEP or Pluton that says "this signature came from agent X running on device Y, gated by user policy Z that the user actually consented to."

A defensible reading is that both vendors are moving slowly toward agent-bound credentials, but neither has published a clean primitive. This is an open design space. We mark it as a place to watch rather than a place where shipping products have answers.

10.4 The convergence that probably will not happen#

People periodically suggest that Apple should expose the SEP via TPM 2.0 for cross-platform compatibility, or that Microsoft should ship a dedicated security core like SEP. Neither is likely. Apple's value proposition rests on vertical integration; opening the SEP to non-Apple operating systems would dilute it. Microsoft's value proposition rests on multi-vendor compatibility; mandating a SEP-style dedicated core would fragment their silicon partner relationships.

The structural diversity is here to stay. FIDO2/WebAuthn and TPM 2.0 are how the two systems will continue to interoperate without converging on a single hardware architecture. That is fine. It is even, arguably, good -- a monoculture would be worse for security than a duopoly with different threat-model trade-offs.

The interesting question for the next decade is not whether Apple or Microsoft picks a different silicon strategy. It is whether the cross-platform standards layer -- WebAuthn, TPM 2.0, FIDO2 -- evolves fast enough to expose new security primitives (post-quantum attestation, agent identity, owner-vetoable updates) before any one vendor ships proprietary equivalents.

11. Frequently asked questions#

12. Closing observation#

There is a temptation, when comparing two designs as deeply considered as SEP and Pluton, to declare one the winner. Resist that temptation. The two architectures answer different questions for different markets, and the differences are exactly where each one shines. SEP is what you build when you own the silicon, the OS, and the patch channel. Pluton is what you build when you control the OS and the patch channel but need to ride on three other companies' silicon.

The closing observation worth keeping is the one Pulse Security demonstrated by accident: most hardware security failures are not failures of the math. They are failures of the physical placement and the patch flow. SEP and Pluton both close the historical bus-sniffing attack class. They both retain a slow channel for fault-injection research to chip away at. They both depend on the device owner trusting the vendor's signing infrastructure. The next big shift -- if it comes -- will probably be in who controls the patch channel, not in the silicon itself.

That is the bet to watch.