Threat modeling full disk encryption, and what I missed

TL;DR - Full disk encryption is not one product. "The drive is unreadable outside this machine" is true in a state the device is almost never in and false in the state it spends most of its life in. Part one of this post is the honest, compressed account of how a real threat model gets produced: a pitch, a design doc, an intuition-led review that found the one finding that mattered most and missed eight others, and a mechanical STRIDE pass that caught what intuition could not. Part two is the thing that review process should have produced and did not get shown in the first cut of this post: an actual threat model report, with a scope statement, an asset register, trust boundaries, an attacker capability ladder, a 26 row threat register, attack trees, residual risk, an assumptions register, and a validation plan. Then the reveal: this is BitLocker, and every derived weakness has a real, documented, still-live counterpart.

This is the third entry in a series about threat modeling everyday technology. The first modeled the macOS Trusted Computing Base from the outside in. The second derived a threat model from a single hardware pattern before checking it against Apple's Secure Enclave. This one is shaped differently again: it follows one feature, full disk encryption, through the process that actually produces a threat model, then writes up the result the way a reviewer would actually expect to receive it. The product under review is called DDP throughout, on purpose, until part one reaches the point where it stops needing a fake name.

Part one: how this model was produced. This half is compressed on purpose. It is the narrative, kept honest about the misses, in roughly half the space it took the first time. Part two, starting after the reveal, is the report itself.

1. The pitch

A product team walks in with a pitch: full disk encryption, on by default, on every device that ships, no password prompt at boot. The volume key is held by a platform security processor and released automatically when the machine boots into a configuration it recognizes as normal. We will call it DDP for now. The pitch's closing line is always some version of the same sentence: the drive is never readable outside this machine, and the user never has to think about it.

Nobody threat models that sentence directly. A five-minute pitch is not a system, and the first real conversation only produces a list of questions the design has to answer: which states is this protecting, what proves the requesting machine is the provisioned one, what happens the day the key does not release. The team returns later with a written design, and the model gets built jointly against that document, because a model written by security alone gets filed and ignored, and one written by the product team alone misses whole categories it never had reason to visit.

Two things about this are worth saying plainly. By the time a design document exists, a decision like "no password at boot" already has a business case and a release date behind it; the model does not get to reopen that decision, only to document what it costs. And the most dangerous weaknesses tend to live on the seam between two teams who each modeled their own half correctly, not inside either half.

2. The four questions

Which state are you protecting? Powered off, hibernated, asleep, at the lock screen, and unlocked are five different products wearing one sentence, and a key released automatically at boot says nothing about four of them: the measurements already matched, and the key is already sitting in memory. Laptops get stolen asleep, not powered off, and a lock screen is a user interface decision, not a cryptographic boundary.

Who authenticates? No pre-boot secret means possession is the credential, which converts what sounds like a cryptography problem into a boot integrity problem in its entirety. Unlocking the disk and signing into the account are separate events, and the attacker only wants the first one. With no secret to get wrong there is also nothing to rate limit, so an attacker with the device on a bench gets unlimited attempts. A pre-boot PIN's real value is giving the chip something to count.

What is measured? A chain, extend only, compared once at release. Sealing to a signing authority rather than a specific binary means a genuine, correctly signed, obsolete component satisfies the policy, because the policy proves provenance, not safety, and revocation has to be a separate mechanism that in practice lags for compatibility. Usability pressure keeps pushing that binding looser, and looser binding is exactly what an attacker needs.

What happens on recovery? Lockouts are inevitable, so there has to be a recovery key that bypasses everything else unconditionally. Users will not retain it, so it gets escrowed, and that one choice quietly redefines the whole feature: the strength of the disk encryption becomes the strength of whatever protects the escrow copy. The attacker does not attack AES. They attack a password reset.

3. The design doc

The team returns with version 0.9 of a written design, and it exhibits, almost point for point, the failure modes documents like this one characteristically exhibit: non-goals that quietly exclude the states that matter (sleep is never addressed until it resurfaces as an open question deferred to another team); an assumptions section carrying more risk than the threats table (one assumption states that devices are powered off when lost or stolen, close to the opposite of how they are actually stolen); a threats table listing five rows, every one an attack the design already defeats; the single most important component, recovery key escrow, marked out of scope with retrieval UX left as a literal "TBD"; and a deadline requesting sign-off within two weeks, explicitly to avoid holding the release train.

None of this is unusual, and none of it is written in bad faith. It is what a design document produced under real organizational pressure looks like almost every time, which is exactly why a review process has to expect it rather than be surprised by it.

4. The first pass

The first pass is intuition led, and three findings from it matter enough to block sign-off. The recovery key unwraps the volume key unconditionally, bypassing the platform security processor, the measurements, and the boot chain entirely, and the design escrows it automatically while declaring its handling out of scope. Sealing to a signing authority rather than a binary is a defensible response to a real operational problem, but the document never states that it silently depends on prompt revocation. And sleep is never addressed as its own state, even though the volume key sits resident in DRAM exactly like an unlocked machine, which is the state a laptop is actually in when it goes missing.

Of the three, the escrow finding is the one that invalidates the rest. Tighten the sealing policy, specify the sleep state, and both fixes are still protecting a door while the wall next to it stays open.

5. What it missed

The honest part comes next, and it does not get softened. The first pass missed eight things, and several of them are worse than what it caught.

No integrity protection for data at rest: the cipher is length preserving and unauthenticated, so ciphertext is malleable and offline tampering goes undetected.
Used space only encryption on existing drives leaves plaintext remnants that wear leveling makes unreliable to overwrite.
A suspension window during firmware updates places the key on disk in the clear.
Hibernation and page files write memory, including keys, outside the encryption model's coverage.
The boot partition stays unencrypted and holds attacker-writable configuration.
Crypto erase does not revoke an already escrowed key, so a wiped or resold device leaves a valid key with the previous holder.
On a managed fleet, one directory administrator can read every recovery key in the organization.
Availability was never modeled: a forced measurement mismatch locks people out at scale, all at once.

6. The mechanical pass

Intuition finds what it already recognizes and is blind to categories it never thought to visit. STRIDE does not depend on recognition: it forces every element and interaction through six fixed questions regardless of whether any of them feel relevant walking in. Asking the tampering question specifically at data at rest is what surfaces the missing integrity check. Asking the denial of service question near the measurement policy is what surfaces mass lockout. Asking the repudiation question at key retrieval is what surfaces the missing audit trail.

The mechanical pass produced findings judgment never reached on its own: the platform security processor is never itself authenticated; the escrow upload endpoint at provisioning is unauthenticated; the device signs into the same account that holds its own recovery key, so malware already running as the signed in user can retrieve the key for the disk it is running on, and that key survives a reimage; escrow is a single point of availability failure on its own terms; deliberate chip lockout is a usable denial of service that pushes a targeted user into recovery; activation telemetry is, structurally, a queryable list of unencrypted devices; three separate repudiation gaps exist around measurement, escrow, and key retrieval; and on-device access control for the recovery key is left entirely unspecified.

Neither approach was sufficient alone. Structure buys coverage: every category gets asked about, whether or not it looks interesting. Judgment buys depth, and more importantly it buys prioritization, because a checklist has no opinion about which finding actually blocks a release. A mechanical pass alone would never have identified escrow-out-of-scope as the finding that invalidates the rest of the document. Judgment alone left holes a junior reviewer with nothing but a template would have filled in an afternoon.

7. The reveal

DDP is BitLocker, and every weakness derived above has a documented, named, still relevant counterpart.

The unauthenticated bus finding is discrete TPM sniffing. On systems where the platform security processor is a separate chip, the boot manager talks to it in the clear over LPC or SPI, and a logic analyzer clipped onto that bus during boot captures the volume master key as it is released. The technique has been public for years, and it is still live enough in 2026 that HP shipped dedicated hardware, HP TPM Guard, specifically to cryptographically bind a discrete TPM to its host processor and close the gap. Pulse Security's writeup on TPM sniffing and HP's TPM Guard announcement cover both sides of that timeline.

The "signed but obsolete" finding is Bitpixie, CVE-2023-21563. The Windows boot manager fails to wipe the volume master key from memory across a PXE soft reboot, so an attacker forces that reboot path and then boots their own environment to read the key straight out of memory, no hardware required, software only, and it works precisely because the boot manager involved is genuinely, validly signed. Microsoft's mitigation is a Secure Boot certificate rotation, the Windows UEFI CA 2023 certificate replacing the Windows Production PCA 2011 certificate through the DBX revocation list, and as of May 2026 that rotation had still not been enforced across the fleet, with the old, vulnerable certificate not set to expire on its own until October 2026. See the MSRC advisory for CVE-2023-21563 and Microsoft's own enterprise guidance for the certificate rotation.

The sleeping machine finding is cold boot and DMA, bounded rather than solved. Kernel DMA Protection blocks unauthorized device access over Thunderbolt and PCIe, but only for the period after the operating system has already loaded. The pre-boot window, and any port not covered by that protection, is left entirely to the firmware, and a machine asleep with the key resident in DRAM is exactly the target that class of attack was built for. Microsoft documents the boundary directly in its own Kernel DMA Protection guidance.

And the escrow finding is not a corner case. Since Windows 11 24H2, a clean install where the user signs in with a Microsoft account silently turns on device encryption and uploads the recovery key to that same account, no separate prompt, no separate notice. Enterprise devices escrow the equivalent key to Entra ID or Active Directory through the standard managed-device flow. The finding that a first-pass reviewer would be tempted to treat as a worst case, the recovery key sitting behind the very account the device signs into, is the default configuration on a very large number of machines running today. Microsoft's own documentation on device encryption in Windows describes exactly this flow.

Part two: the threat model report. Everything above is the process. What follows is the artifact that process should have produced: scope, architecture, assets, trust boundaries, attacker capabilities, the full threat register, attack trees, invariants, residual risk, assumptions, and a validation plan. It refers to the system as DDP throughout, matching the design and review documents it is drawn from.

8. Scope and system description

Field	Value
System	DDP (Device Data Protection), default-on full disk encryption
Design document reviewed	v0.9, draft, pre-implementation
Design document owner	Platform Storage team
Reviewers	Platform Security (lead), with Firmware and Identity as named reviewers
Sign-off target (as requested by the design doc)	Within two weeks, to hold the release train
This report compiled	Aug 6, 2026

In scope for this review (expanded from the original design doc by the review process itself): volume key generation, sealing to the platform security processor, and release logic; boot chain measurement across firmware, boot manager, and OS loader, and the sealing policy that governs it; recovery key generation and its full escrow path, including which account it lands in; default-on activation behavior during setup; and behavior across the states the device actually occupies over its working life, which the original design doc did not treat as in scope until this review put it there.

Out of scope, as stated in the original design document's non-goals: protecting data while a user is signed in and the system is running normally; defending against malware running on an already-unlocked system; protecting individual files from other authenticated users on the same device; and attackers with sustained physical access and laboratory equipment. The last exclusion is revisited in the attacker capability ladder and residual risk sections below, because parts of it still matter more than the original document assumed.

9. Architecture summary

The diagram below is the working model for this report: the boot chain running left to right from firmware through the boot manager to the OS loader, the platform security processor holding the sealed volume key, the encrypted volume it releases into, the recovery key sitting in escrow inside a cloud account, and the device's own sign-in pointed at that same account, which is the loop that makes the escrow finding what it is. Device states are laid out with the key marked present or absent in memory for each one, and the physical attack surfaces sit on the buses and ports around the whole system.

Threat model sketch: gold arrows are flows the design still governs. Red-brown arrows mark where that control runs out, including the loop from the device's own sign-in back to the account holding its recovery key.

Step	Flow	Trust boundary crossed
1	Firmware measures itself and platform configuration into the PSP	Boot / manufacturing root
2	Firmware measures the boot manager, then transfers control to it	Code integrity boundary
3	Boot manager measures boot configuration and the OS loader	Code integrity boundary
4	Boot manager requests the volume key from the PSP	Main processor to PSP bus
5	PSP compares accumulated measurements to sealed policy, releases the key on match	Main processor to PSP bus
6	Boot manager unlocks the volume and hands off to the OS	Boot to OS handoff
7	OS presents the sign-in screen, downstream of key release	Disk unlock to account authentication
8	At provisioning, the recovery key is generated and uploaded to escrow	Device to cloud account or directory
9	At sign-in, the device authenticates into the same cloud account that holds its recovery key	Device to identity provider (the loop)
10	On lockout, the recovery key unwraps the volume key directly, bypassing steps 1 through 6	Recovery bypass boundary

10. Asset register

Asset	Where it lives	Security goals	Impact if lost
Volume key (VK)	Sealed inside the PSP; transiently in DRAM after release	Confidentiality, integrity	Full plaintext disclosure of the volume
Recovery key (RK)	Generated at provisioning; escrowed to a cloud account or directory	Confidentiality, authenticity of retrieval	Equivalent to the VK; unconditional bypass of every other control
Boot measurements and sealing policy	PSP, extend-only registers	Integrity	A falsified or loosely bound policy releases the VK to an unauthorized boot state
PSP identity and attestation	Silicon, boot ROM rooted	Authenticity	An unauthenticated PSP cannot be trusted to be the provisioned chip
Encrypted user data (the volume)	Fixed storage	Confidentiality (stated); integrity (not currently promised)	Confidentiality breach on VK compromise; undetected tampering regardless
Escrow record	Cloud account or organizational directory	Confidentiality, availability, auditability	Deletion or account loss means permanent data loss; unaudited access is undetectable compromise
Boot partition and configuration	Unencrypted fixed storage	Integrity	Attacker-writable with physical access alone
Activation telemetry	Metrics and backend systems	Confidentiality	Aggregated, becomes a targeting list of unencrypted devices
Sign-in account credentials	Identity provider	Confidentiality, authenticity	Compromise of this account now also compromises the disk

11. Trust boundary table

Boundary	What crosses it	What enforces it	What is assumed
Main processor to PSP (bus)	Measurement submissions, key release requests and responses	Physical bus protocol (LPC or SPI)	Bus is not observable, false for discrete parts
Boot manager to PSP (logical)	Sealing policy comparison	PSP firmware logic	Firmware correctly measures what it claims to measure
Firmware and boot manager to signing authority	Code signatures	Signature verification against embedded trust roots	Signing authority is not compromised; revocation propagates promptly
Device to escrow account	Recovery key upload at provisioning, retrieval at recovery	Account authentication on the identity provider side	Provisioning endpoint is authenticated (it is not); account recovery flow is adequate (unexamined)
Device sign-in to escrow account	Session authentication	Whatever authenticates the signed-in OS session	The signing-in account is a different trust domain from the account holding the key (it is not)
Physical enclosure to a possessing attacker	Power state, exposed ports and buses	Sleep and hibernate policy; Kernel DMA Protection, post-boot only	Device is powered off when lost or stolen
Directory to fleet devices	Managed key escrow	Directory access control	Access to escrowed keys is scoped per device, not organization-wide

12. Attacker capability ladder

Level	Capabilities	In scope
L0	Remote attacker, no code execution, no physical access	Not addressed, not contradicted
L1	Malicious or compromised app running as the already signed-in user	Yes, this review's finding
L2	Possession of a powered-off device, no credentials	Yes, the design doc's core claim
L3	Possession of a sleeping or locked device, no credentials	Yes per this review; excluded by the design doc's implicit assumption
L4	Bench access with hardware tools: logic analyzer, cold boot rig	Explicitly out of scope in the design doc; flagged as residual risk here
L5	Insider or administrator with directory or support-desk access	Partially, only the escrow path is examined
L6	Attacker who compromises the account recovery flow directly: phishing, support-desk social engineering, password reset	Yes, this is the attacker the escrow finding actually describes

13. Threat register

Twenty-six findings: five originally flagged blocking, twenty-one significant. This is the centerpiece of the report and it stays a table rather than being summarized into prose, split in two so it stays legible on a narrow screen: identification first, then assessment and disposition. Match rows by ID.

13.1 Identification

ID	Threat	STRIDE category	Affected element / boundary	Attack path
B1	Recovery key escrow left out of scope; unwrapping the VK via escrow bypasses every other control	Elevation of privilege	Escrow record; recovery key	Attacker reaches the account recovery flow (phish, reset, support) and pulls the RK directly
B2	Device signs into the same account that holds its own recovery key	Elevation of privilege	Escrow record; sign-in session	Malware running as the signed-in user calls the account API and retrieves its own disk's RK; survives reimage
B3	Sealing to signing authority admits genuine, signed, obsolete boot components	Tampering	Boot manager; sealing policy	Attacker supplies an old, validly signed, vulnerable boot component; PSP releases the VK anyway
B4	No integrity protection for data at rest	Tampering	Encrypted volume	Attacker with offline access flips ciphertext bits; the change is undetectable, plaintext corrupts silently
B5	Sleep state unaddressed; VK resident in DRAM	Information disclosure	Volume key; DRAM	Device is taken while asleep, the common theft state; key is live in memory the whole time
S1	"PSP interface not observable" is an assumption, false for discrete parts	Information disclosure	Main processor to PSP bus	Logic analyzer on the bus during boot captures the VK in the clear
S2	PSP itself is never authenticated	Spoofing	PSP identity	Nothing proves the responding chip is the provisioned one; a substitute could answer requests
S3	No pre-boot secret means no rate limiting	Elevation of privilege	Boot path	Unlimited offline attempts against the boot path, at leisure, no lockout, no signal
S4	Suspension window during firmware update places the key on disk unprotected	Information disclosure	Volume key; firmware update path	Attacker triggers an update, catches the key during the unprotected window
S5	Escrow upload endpoint unauthenticated at provisioning	Spoofing	Provisioning endpoint	RK may be uploaded to an attacker-controlled endpoint at first boot
S6	Escrow is a single point of availability failure	Denial of service	Escrow record	Account closure, suspension, or record deletion destroys the only recovery path, permanently
S7	Silent activation; setup notice cut	Privacy, adjacent to information disclosure	User consent and notice	User never learns encryption is on or that a key copy left the device, so cannot protect the account holding it
S8	Recovery key is static, never rotates	Elevation of privilege	Recovery key	Anyone who ever legitimately held the RK, technician or prior owner, holds it permanently
S9	Retrieval security requirements undefined, "TBD"	Multiple	Recovery flow	No specified re-authentication, delay, notification, rate limit, or audit on the most sensitive operation in the system
S10	Hibernation and page files write memory, including keys, outside encryption coverage	Information disclosure	Hibernation file; page file	Offline read of the hibernation or page file recovers key material never covered by the volume's own encryption
S11	Unencrypted boot partition holds attacker-writable configuration	Tampering	Boot partition	Physical access lets an attacker rewrite boot configuration directly, no encryption in the way
S12	Used space only encryption leaves plaintext remnants; wear leveling makes overwrite unreliable	Information disclosure	Flash storage	Forensic read of "unused" flash blocks recovers pre-encryption plaintext
S13	Crypto erase does not revoke an escrowed key	Elevation of privilege	Recovery key; escrow record	Device is wiped or resold; the escrowed key remains valid and held by the previous owner
S14	A single directory administrator can read every recovery key in the organization	Elevation of privilege	Directory; escrow record	One compromised or malicious admin account exposes the entire fleet's keys
S15	Forced measurement mismatch enables mass lockout	Denial of service	Sealing policy	Attacker, or a bad update, triggers mismatch across many devices at once, pushing all of them into recovery simultaneously
S16	Activation telemetry is, structurally, a list of unencrypted devices	Information disclosure	Telemetry pipeline	Metrics data doubles as a targeting list for exactly the devices this feature has not yet reached
S17	No audit trail: measurements used, escrow success, or non-retrieval cannot be proven	Repudiation	Measurement log; escrow log; retrieval log	Compromise via escrow, or a disputed retrieval, leaves no record either side can point to
S18	On-device access control for the recovery key is unspecified	Elevation of privilege	Recovery key, local	Unclear whether a standard user or its processes can request the RK locally
S19	Local account path undefined	Multiple	Activation logic	Device ships silently unencrypted, or encrypted with an unrecoverable key; design picks neither
S20	Port and DMA exposure while sleeping not considered	Information disclosure	Exposed ports; DRAM	Cable-connected attacker reaches a sleeping device's memory before Kernel DMA Protection's post-boot coverage applies
S21	Threats table lists only defeated attacks; assumptions carry more risk than the threats table	Process	Design document itself	A reviewer reading only the threats table concludes the design is fully examined; it is not

13.2 Assessment and disposition

ID	Likelihood	Impact	Severity	Mitigation	Residual risk	Owner	Status
B1	High	Critical	Critical	Bring escrow retrieval fully into scope; require re-authentication, delay, notification, audit; stop treating account recovery as pre-approved	Even a hardened flow is only as strong as its own recovery path	Storage + Identity	Open, blocks sign-off
B2	Medium-High	Critical	Critical	Stop escrowing the RK to the account the device signs into; use a distinct credential, a factor the device cannot supply, or split-key escrow	A separated credential is itself a target needing its own reset flow	Storage + Identity	Open, blocks sign-off
B3	Medium	High	High	Name revocation as a dependency with an owner and a propagation SLA; consider tighter binding for high-risk device classes	Revocation always lags a disclosed break by some window	Storage + Firmware	Open, blocks sign-off
B4	Medium	High	High	Add authenticated encryption; if infeasible short term, state explicitly that only confidentiality is promised	Retrofitting integrity does not protect data already at rest under the old scheme	Storage	Open, blocks sign-off
B5	High	High	High	Hibernate or evict the key on lid close; otherwise remove the "protects stolen laptops" claim from the goals	Hibernate has its own exposure, see S10	Storage + Power	Open, blocks sign-off
S1	Low-Medium	Critical	High	Require an integrated PSP, or document residual risk per configuration for discrete parts	Physical attacks against one targeted individual remain possible regardless	Storage + Hardware	Open, tracked
S2	Low	High	High	Authenticate the PSP's identity as part of the release protocol	Adds complexity to a path that must stay reliable at scale	Firmware	Open, tracked
S3	High	Medium	Medium	Promote the optional pre-boot PIN to a supported, encouraged configuration so there is something to rate limit	Optional means many devices remain unprotected by it	Storage	Open, tracked
S4	Low-Medium	High	Medium	Close the suspension window; treat firmware updates as part of the same threat model as boot	Update mechanisms are an inherently privileged, complex path	Storage + Firmware	Open, tracked
S5	Medium	Critical	High	Authenticate the provisioning endpoint	First-boot provisioning is an inherently trust-on-first-use moment	Identity	Open, tracked
S6	Medium	High	High	Define a secondary escrow or export path; define account-closure handling explicitly	Any single-account escrow model retains some availability dependency	Identity	Open, tracked
S7	High	Medium	Medium	Reinstate the setup notice; get Legal and Privacy sign-off in writing	Ordinary consent fatigue, once notice is restored	Storage + Legal	Open, blocks setup-flow ship pending Legal/Privacy
S8	Medium	Medium-High	Medium	Rotate the key after every retrieval and after any suspected exposure	Rotation only helps once implemented; past exposures are unaffected	Storage	Open, tracked
S9	High	High	High	Specify re-authentication strength, delay, notification, rate limiting, audit logging as requirements, not UX decisions	None if fully specified and implemented; today's risk is entirely the gap	Identity	Open, tracked
S10	Medium	High	Medium	Bring hibernation and page files into the same encryption coverage as the volume	Historical hibernation files predate the fix	Storage + Power	Open, tracked
S11	Low-Medium	Medium	Medium	Sign or authenticate boot configuration even if the partition itself stays unencrypted	Full protection would need encrypting boot config, which conflicts with reading it pre-key-release	Storage	Open, tracked
S12	Medium	Medium	Medium	Encrypt full volumes at provisioning rather than used space only; document residual risk for retrofit encryption	Cannot be fully closed for drives already encrypted in place	Storage	Open, tracked
S13	Medium	High	High	Invalidate escrow on crypto erase as part of the wipe procedure	Requires escrow and device state to stay synchronized, not guaranteed offline	Storage + Identity	Open, tracked
S14	Medium	Critical	High	Scope key-read access per device with its own audit trail, not a standing organization-wide grant	Some concentration of trust in directory administration is close to irreducible	Identity	Open, tracked
S15	Low-Medium	High	Medium	Treat lockout-at-scale as a denial of service class, not only a security feature; stage measurement policy changes	Any fail-closed design retains this trade-off by construction	Storage	Open, tracked
S16	High	Medium	Medium	Stop emitting device-level unencrypted-status telemetry, or restrict and audit its access tightly	Aggregate metrics still say something about fleet posture	Storage + Privacy	Open, tracked
S17	High	Medium	Medium	Log measurement values used at release, escrow upload confirmation, and retrieval events, independently auditable	Logging after the fact cannot undo an already-unrecorded past event	Storage + Identity	Open, tracked
S18	Unknown, unspecified today	High if unrestricted	Medium	Specify and enforce local access control on the RK, at least as strong as other secret material	Depends entirely on the eventual specification	Storage	Open, tracked
S19	Medium	Medium	Medium	Decide and document one of the two outcomes explicitly rather than leaving both possible	Whichever is chosen carries a real trade-off	Storage	Open, tracked
S20	Low-Medium	High	Medium	Document port and DMA exposure explicitly; consider port lockdown while asleep	Pre-boot and pre-OS windows stay outside typical DMA protections	Storage	Open, tracked
S21	High	Low directly, high indirectly	Medium	Require at least one unresolved row per major component in any threats table submitted for review	A process fix, not a technical one; recurrence is a management problem	Storage	Open, tracked

14. Attack trees

Goal: read plaintext from an encrypted volume, or write undetected changes to it
|
|-- Extract the volume key from hardware
|   |-- Sniff a discrete PSP's bus in the clear, LPC or SPI [S1]
|   |-- Cold boot or DMA the key out of DRAM while the device sleeps [B5, S20]
|   +-- Fault or probe an integrated PSP (higher cost, still bounded)
|
|-- Bypass release without extracting the key
|   |-- Present a genuine, signed, obsolete boot component, revocation lag [B3]
|   |-- Exploit an unwiped key across a soft reboot, Bitpixie class bug
|   |-- Spoof the PSP's identity to a caller expecting attestation [S2]
|   +-- Roll the measurement policy back to a permissive configuration
|
|-- Go around the boot chain entirely
|   |-- Retrieve the recovery key from its escrow account
|   |   |-- Phish or reset the account holding it [B1]
|   |   |-- Run as the already signed in user and read it out [B2]
|   |   +-- Compel or compromise the escrow holder: directory admin, support [S14]
|   +-- Exploit an unauthenticated escrow upload endpoint at provisioning [S5]
|
|-- Force the system around its own protections
|   |-- Trigger repeated measurement mismatch to force lockout [S15]
|   |-- Trigger a firmware-update suspension window [S4]
|   +-- Exhaust or corrupt state to push the user into the recovery path
|
|-- Skip the key entirely and attack the ciphertext or its neighbors
|   |-- Modify ciphertext offline with no integrity check to catch it [B4]
|   |-- Read plaintext remnants left by used space only encryption [S12]
|   +-- Read the unencrypted boot partition's attacker-writable configuration [S11]
|
+-- Undermine accountability rather than the cryptography
    |-- Exploit the missing audit trail to act without a provable trace [S17]
    |-- Harvest activation telemetry as a list of unencrypted targets [S16]
    +-- Hold a key past its useful life: static RK, no rotation after exposure [S8, S13]

15. Security invariants

State and scope

The design states explicitly which power and session states it protects, and which it does not.
Sleep and hibernate are treated as first class states in the model, not deferred as another team's open question.
The lock screen is documented as a user interface control, never represented as a cryptographic boundary.

Authentication and possession

Where no pre-boot secret exists, the document states plainly that possession is the credential and that rate limiting does not apply.
A pre-boot PIN, where supported, is a documented, supported configuration, not an unlisted concession.
Signing into the account and unlocking the disk are documented as separate events with no implicit dependency between them.

Measurement and revocation

The sealing policy states what is not measured, in addition to what is.
Revocation is named as a dependency with a named owner and a defined propagation time.
Anti-rollback prevents replay of an old sealed state or an old, validly signed firmware measurement.
The platform security processor's own identity is authenticated, not merely assumed from its responses.

Data at rest

The document states whether it promises integrity, confidentiality, or both, and does not let one stand in silently for the other.
Full volume encryption is used at provisioning, or the plaintext remnants left by used-space-only encryption are documented as residual risk.
The boot partition's exposure to attacker-writable configuration is documented, not left implicit.

Recovery and escrow

The recovery key is not escrowed to the same account the device signs into.
The escrow upload endpoint is authenticated at provisioning time.
Retrieval requires re-authentication, a delay, notification to the account owner, rate limiting, and an audit record.
The key rotates after every retrieval and after any suspected exposure.
Device wipe or crypto erase is documented as not revoking an already escrowed key, or escrow is explicitly invalidated as part of that process.

Fleet and availability

No single directory administrator can read every recovery key in an organization without that access itself being audited.
Deliberate lockout through a forced measurement mismatch is treated as a denial of service path, not only as a security feature.
Activation telemetry is not a queryable list of which devices remain unencrypted.

16. Residual risk register

Risk	Why it cannot be fully mitigated	Accepted by	Review date
Possession remains the credential wherever the pre-boot PIN is off	The PIN is an available mitigation, not a universal one; default configuration leaves this open	Storage engineering director (named owner recommended per security review)	Next major release cycle
Revocation always lags a disclosed break	Detection, decision, and propagation take real time across a real fleet	Storage and Firmware directors	Continuous, reviewed per major disclosure
A separated retrieval credential is itself a target	Any secret needs its own reset flow; this shrinks the problem, it does not remove it	Identity director	12 months post-launch
Retrofitting integrity does not protect already-shipped drives	Cannot rewrite history for volumes already encrypted under the old scheme	Storage director	At next full-disk re-provisioning
Narrowing fleet key visibility reduces, but does not remove, concentrated trust	Some administrative access to a directory is structurally necessary	Identity director	Annual access review
Physical possession plus unlimited time still favors a targeted attacker	No purely software control defeats an attacker holding the device with lab tools	Accepted at product level (Storage VP)	Revisit if hardware generation changes

17. Assumptions register

Six assumptions in the original design document, and at least three of them are load bearing. The table below separates the ones that were really requirements in disguise from the one that was really an accepted risk, and names the finding each one turned into.

Assumption as written	Really a...	Why	Related finding
The PSP is trustworthy and its interface to the platform is not observable	Requirement (hardware)	Only true for an integrated PSP; a discrete part fails this on the bus	S1
Firmware correctly measures what it claims to measure	Requirement	A precondition for the entire sealing model, not a safe default to assume	B3
Secure boot is enabled and functioning on supported hardware	Requirement	Should be a stated hardware and configuration requirement, not an assumption	B3, S1
The signing authority for boot components is not compromised	Accepted risk (organizational)	Key custody and insider risk at the signing authority is a standing exposure engineering cannot assume away	B3
The account recovery flow protecting escrowed keys is adequate	The load-bearing one: was an assumption, is actually the whole finding	Nothing in the document examines this flow; the review found it does not hold	B1, B2, S5, S6
Devices are powered off when lost or stolen	False, and should never have been an assumption	Contradicted by how devices are actually stolen	B5

The fifth row is the one worth sitting with. An assumption that was never verified turned out to be the entire finding that invalidates the rest of the document. A threats table with no unresolved rows is not a threat model, and an assumptions section is where the unexamined risk actually lives.

18. Validation and assurance plan

Check	Method	Expected result
Whether your own recovery key is escrowed, and to which account	Inspect account recovery-key storage or directory console	Escrow target identified; a match to the sign-in account flags B1/B2 exposure
Whether the device sleeps or hibernates on lid close	Inspect power configuration	Hibernate confirmed, or B5 exposure accepted explicitly
Whether the platform security processor is discrete or integrated	Inspect hardware specification or TPM properties	Integrated confirmed, or S1 residual risk documented
Whether a pre-boot PIN is available and enabled	Inspect boot security configuration	PIN available and on, or S3 residual risk documented
Who can read recovery keys in the directory, for fleet owners	Audit directory role assignments	Access scoped per device with logging, not standing org-wide read
Whether the PSP can be spoofed from software	Protocol-level test against the release request and response path	Request rejected, or challenge fails, without genuine hardware
Whether the provisioning endpoint accepts unauthenticated uploads	Endpoint security test at provisioning time	Request rejected without valid device credentials
Whether offline ciphertext tampering is detected	Modify volume ciphertext offline, then remount	Modification detected and blocked
Whether the key is exposed during a firmware update	Instrumented update test through the suspension window	No plaintext or unprotected key material observed on disk
Whether retrieval is properly gated and logged	Request a recovery key retrieval, then review logs	Re-authentication, delay, notification, and an audit record are all present
Whether crypto erase actually revokes the escrowed key	Wipe a previously escrowed device, then attempt retrieval of its old key	Old escrowed key is invalidated
Whether the threats table has any unresolved rows	Documentation review, applied to this and future revisions	At least one open, unresolved risk per major component

19. Findings summary

Severity	Count
Critical	2
High	10
Medium	14
Total	26

All five originally blocking findings, B1 through B5, must be resolved or formally accepted before sign-off. B1 requires a joint session with Identity and cannot be closed by Storage alone. S7 additionally blocks the setup flow specifically, pending a written answer from Legal and Privacy. The remaining twenty findings can proceed in parallel with implementation.

Recommendation: resolve B1 through B5 before sign-off. If the release train genuinely cannot accommodate that, the correct action is to record the gap as an explicitly accepted risk with a named director as owner, not to ship it as an unexamined assumption. That is the difference between this report and the document it reviews: every risk here is either mitigated, or named, dated, and owned.

20. Final verdict

Several of the mitigations above reintroduce exactly the friction the original design existed to remove: a distinct recovery credential is one more thing to lose, a mandatory delay on retrieval is one more thing standing between a locked-out user and their data, a setup notice is one more click in a flow that was being actively shortened. That tension does not resolve on its own. It gets decided, on the record, by someone with the authority to accept the cost, which is the entire point of writing any of this down.

The broader lesson sits underneath the specific findings. The encryption was never really the product. Key management was the product, and across most of this design, it had been quietly outsourced to the identity system, one decision at a time, none of them wrong in isolation, all of them adding up to a disk whose real protection was only ever as strong as a password reset flow nobody on the storage team had been asked to review. Structure found the seams a reviewer did not think to look for. Judgment decided which of those seams actually mattered enough to block a ship date. Neither one alone would have produced this report.