A lost laptop or a pulled server disk is a data breach unless the storage is unreadable without a key the finder does not have. D3-DENCR Disk Encryption is the MITRE D3FEND countermeasure for that case: D3FEND defines it as "Encrypting a hard disk partition to prevent cleartext access to a file system." It sits in the Harden tactic under Platform Hardening, and D3FEND models it as a technique that encrypts Storage. This card covers what that relation does and does not protect, the single ATT&CK technique D3FEND relates to it, unlock and key choices, how to prove encryption is really in force across a fleet, and the gaps attackers use. It is written for endpoint, infrastructure and compliance teams. For product rollout detail, see the Disk Encryption Guide: BitLocker and FileVault, which this page does not repeat.
Key takeaways
- Disk encryption protects data at rest, on a powered-off device. Once the volume is unlocked, malware and logged-in users read cleartext like any other process.
- The unlock method is the real control. TPM-only unlock is transparent and protects against disk removal; pre-boot PIN or key adds protection against an attacker holding the whole device.
- Recovery keys are high-value secrets. Escrow them centrally, restrict who can read them and log every retrieval.
- D3FEND's ATT&CK link is thin and inferred. It relates D3-DENCR only to T1564.005 Hidden File System, through the shared Storage artefact.
- Prove it with device state, not policy assignment. Report encryption status, protector type and key escrow per device, and alert on suspended or decrypted volumes.
D3-DENCR at a glance
| Field | D3-DENCR Disk Encryption |
|---|---|
| D3FEND ID | D3-DENCR |
| Tactic | Harden |
| Parent technique | Platform Hardening (siblings include Bootloader Authentication, Driver Load Integrity Checking, File Encryption, Software Update and TPM Boot Integrity) |
| Digital artefact | Storage (D3FEND: Disk Encryption "encrypts" Storage) |
| What it changes | Data on a partition or volume is stored encrypted; reading it requires the volume key, released only after the configured unlock |
| Typical implementation points | Operating system volume encryption, self-encrypting drives, hypervisor and cloud volume encryption, key escrow in directory or device management |
| Verification data | Per-device encryption status, protector types, recovery key escrow records, recovery key access logs |
| Related ATT&CK mitigation | M1041 Encrypt Sensitive Information (D3FEND links M1041 to D3-DENCR) |
| Main limitation | No protection for a running, unlocked system |
How it works
The D3FEND entry is short: its definition, the "encrypts Storage" relation and one reference, the LUKS1 on-disk format specification. The design pattern behind all mainstream implementations is a two-layer key hierarchy:
- Volume key: a random key encrypts the data, usually with AES in XTS mode. It never changes in normal use, so the disk does not need re-encrypting when a password changes.
- Protectors or key slots: the volume key is wrapped by one or more unlock methods: a TPM sealed to boot measurements, a PIN or passphrase, a hardware token, a recovery key. Each protector can be added or removed independently.
This is why the protector configuration, not the cipher, decides most real-world outcomes. NIST SP 800-111 groups storage encryption into full disk, volume and virtual disk, and file and folder encryption, and notes that the right choice depends on the storage, the environment and the threats. D3-DENCR covers the first two; file-level protection is its sibling D3-FE File Encryption.
ATT&CK techniques D3FEND relates to D3-DENCR
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-DENCR; the row below is inferred through the shared Storage artefact (checked November 2026).
| ATT&CK ID | Technique (v20 tactic) | D3FEND relation | What disk encryption changes (NHI Mgmt Group assessment) |
|---|---|---|---|
| T1564.005 | Hidden File System (Stealth) | Inferred via Storage | Little: the technique is about an adversary hiding its own data in storage; volume encryption does not stop malware running on the unlocked host from doing so |
The D3FEND site also shows an inferred link to Cloud Storage Object Discovery without an ID; in ATT&CK v20 that technique is T1619, and disk encryption has no practical effect on it. In NHI Mgmt Group's view, the threats disk encryption actually counters are offline ones that ATT&CK models only partly: theft or loss of a device or drive, improper disposal, and direct reading of a disk removed from a host. Related ATT&CK pages: MITRE ATT&CK T1006 Direct Volume Access (an online technique that encryption does not stop on a running host) and MITRE ATT&CK T1200 Hardware Additions (where pre-boot authentication and DMA controls matter). See also the M1041 Encrypt Sensitive Information page.
Where it is implemented
Platforms are listed alphabetically.
| Implementation | Unlock options (from vendor or project docs) | Recovery and escrow | Status check |
|---|---|---|---|
| BitLocker (Windows) | TPM only (default), TPM + PIN, TPM + startup key, TPM + startup key + PIN; Network Unlock for wired devices | Recovery key backed up to Microsoft Entra ID or AD DS (with policy) | manage-bde -status or Get-BitLockerVolume |
| FileVault (macOS) | User password combined with the hardware UID in the Secure Enclave on Apple silicon and T2 Macs | Personal recovery key, or institutional escrow through device management | fdesetup status or device management inventory |
| LUKS (Linux, cryptsetup) | Passphrase key slots; with systemd-cryptenroll also TPM2 (optionally with PIN), FIDO2, PKCS#11 and recovery key | Recovery key slot; header backup with luksHeaderBackup | cryptsetup status, isLuks, luksDump |
- BitLocker: Microsoft documents TPM only as the default and most convenient protector, and recommends TPM with a PIN, standby disabled and shutdown or hibernate for devices facing a skilled attacker with lengthy physical access. Automatic device encryption begins with a clear key that is removed only after the TPM protector is created and the recovery key is backed up. Availability: automatic device encryption has hardware prerequisites; on devices that use only local accounts Microsoft notes the data is encrypted but not yet protected, so turn on a protector and escrow explicitly.
- FileVault: Apple documents that internal storage on Apple silicon and T2 Macs is always encrypted, protected only by the hardware UID until FileVault is turned on; turning it on binds the key encryption key to the user's password, and credentials are then required at start-up. Removable drives do not use the Secure Enclave. Erasing the media key, for example through a device management remote command, makes the volume cryptographically inaccessible.
- LUKS: the cryptsetup manual states LUKS2 is the default format and warns that a damaged header means permanent data loss without a header backup. systemd-cryptenroll binds to no PCRs by default; its documentation suggests PCR 7 (with 11 and 14 where relevant) over firmware PCRs 0 and 2, which change with updates, and notes that
--tpm2-with-pin=yeshardens the PIN so a compromised TPM alone does not expose the key.
Product deep dives: BitLocker and LUKS Disk Encryption Guide; FileVault is covered in the Disk Encryption Guide: BitLocker and FileVault and the macOS Security Guide for Enterprises.
Choosing the unlock model
| Situation | Suggested unlock model (NHI Mgmt Group view) | Trade-off |
|---|---|---|
| General office laptops | TPM-backed transparent unlock plus strong sign-in and short screen lock | Protects removed disks; relies on the OS sign-in for a stolen, powered-on device |
| Privileged and high-risk users, travel devices | TPM plus pre-boot PIN, hibernate instead of sleep | A prompt at each boot; PIN resets need the recovery process |
| Unattended servers in your own facility | TPM bound to boot measurements, or network-based unlock | No human at boot; physical security of the site carries more weight |
| Cloud and virtual machine volumes | Provider or hypervisor volume encryption with keys in a managed key service | Protects media and snapshots at the provider; key access policy becomes the control |
Where identity fits
Recovery keys, TPM-sealed keys and network unlock credentials are machine secrets. Whoever can read the escrow store can decrypt any device in it, so treat recovery key read rights as privileged access, review who and which service accounts hold them, and alert on bulk retrieval. See the Cryptographic Key Management Guide.
Implementation steps
- Set the standard: which device classes must be encrypted, the cipher strength, the protector per class (table above) and where recovery keys are escrowed. On Windows, set the encryption method by policy before encryption starts; Microsoft notes an encrypted drive must be decrypted to change it.
- Prepare the platform: UEFI with Secure Boot, TPM 2.0 enabled, firmware password where supported. Pre-boot integrity depends on these.
- Pilot: deploy to a ring that includes each hardware model, test recovery key retrieval end to end and test firmware and OS updates for unexpected recovery prompts.
- Enforce escrow before trust: require a recovery key in escrow before a device is marked compliant. For LUKS, take a header backup and store it with the recovery material.
- Roll out by ring: watch recovery prompt rates and helpdesk tickets; pause a ring if a firmware or driver update triggers mass recovery.
- Plan rollback: suspending protection is a supported temporary step for updates, but set it to resume automatically and alert on volumes left suspended.
- Close the life cycle: at disposal, use cryptographic erase or disk erasure; see D3-DKE Disk Erasure.
How to verify it works
| Check | Source | Expected result |
|---|---|---|
| Volume encrypted and protection on | Device management compliance or local status command | Fully encrypted, protection on, not suspended |
| Correct protector | Protector list per volume | Matches the device class standard (for example TPM plus PIN on privileged devices) |
| Recovery key escrowed | Directory or device management record | One current key per volume; old keys rotated after use |
| Recovery key access | Audit log of key retrieval | Every retrieval tied to a ticket and an authorised role |
| Offline test | Boot a sample device from external media or attach its disk to another host | Data unreadable without the recovery key |
Example metrics (examples, not standards): percentage of in-scope devices encrypted with protection on, percentage with recovery key in escrow, volumes suspended for more than a set period, recovery key retrievals per month and the share without a ticket, and median time to encrypt new devices.
Limits, bypasses and failure patterns
- Unlocked means unprotected: ransomware, infostealers and insiders on a running host see cleartext. Disk encryption is not a control against them.
- Sleep keeps keys in memory: Microsoft notes that resuming from sleep needs no PIN or startup key and recommends hibernate for stronger protection, along with protecting DMA ports.
- Transparent unlock on a stolen, powered-off device: TPM-only unlock boots to the sign-in screen, so OS sign-in strength and pre-boot DMA protection carry the load.
- Clear keys and suspended volumes: a volume that is encrypted but still has a clear key or suspended protection reports as encrypted in some views while offering no protection.
- Lost recovery material: missing escrow or a damaged LUKS header without backup turns a hardware fault into permanent data loss.
- Over-broad escrow access: the escrow store becomes a single place to decrypt the fleet.
Framework mapping
| Framework | Reference | Relationship to D3-DENCR |
|---|---|---|
| MITRE ATT&CK | M1041 Encrypt Sensitive Information | The ATT&CK mitigation D3FEND links to D3-DENCR |
| NIST SP 800-53 Rev 5 | SC-28, SC-28(1) | Protection of information at rest, cryptographic protection |
| NIST CSF 2.0 | PR.DS-01 | Data at rest is protected |
| NIST SP 800-111 | Full disk and volume encryption | Guidance on choosing and deploying storage encryption for end user devices |
| ISO/IEC 27001:2022 | Annex A 8.24 Use of cryptography; 7.10 Storage media | NHI Mgmt Group mapping |
Related countermeasures
- Same parent: D3-FE File Encryption protects files after the volume is unlocked; D3-TBI TPM Boot Integrity and D3-BA Bootloader Authentication protect the boot chain that releases the key.
- End of life: D3-DKE Disk Erasure.
- Response: the Lost or Stolen Device Response Checklist and Remote lock and wipe for lost phones and laptops.
For how D3FEND is organised, see the MITRE D3FEND Guide.
Practitioner checklist
- Define in-scope devices, cipher and protector per device class.
- Enable Secure Boot and TPM 2.0 before encrypting.
- Require recovery key escrow before a device counts as compliant.
- Use pre-boot PIN and hibernate for privileged and high-risk devices.
- Restrict and log recovery key reads; alert on bulk retrieval.
- Back up LUKS headers alongside recovery keys.
- Alert on suspended, decrypted or clear-key volumes.
- Pair with file encryption, endpoint detection and erasure at disposal.
Standards and references
- MITRE D3FEND: Disk Encryption (D3-DENCR)
- NIST: SP 800-111 Guide to Storage Encryption Technologies for End User Devices
- Clemens Fruhwirth: LUKS1 On-Disk Format Specification Version 1.2.3
- Microsoft: BitLocker overview
- Microsoft: BitLocker countermeasures
- Apple: Volume encryption with FileVault in macOS
- cryptsetup: cryptsetup(8) manual
- systemd: systemd-cryptenroll
Related NHI Mgmt Group resources: Disk Encryption Guide: BitLocker and FileVault · LUKS Disk Encryption Guide · M1041 Encrypt Sensitive Information · MITRE D3FEND Guide