Full disk encryption stops someone reading a stolen drive, but once the machine is running and unlocked every file is plaintext to anything that can read it; file encryption is how you keep chosen files protected with their own keys. MITRE D3FEND names the countermeasure File Encryption (D3-FE) and defines it as "Encrypting a file using a cryptographic key." It sits under the Harden tactic as a child of Platform Hardening, with the relation encrypts File. This card explains what file-level encryption adds over volume encryption, how the operating system implementations work, how to prove files are actually encrypted and where the protection ends. It is written for endpoint, platform and data protection engineers. Platforms are listed alphabetically; the order is not a ranking.
Key takeaways
- Per-file keys, not one volume key. File encryption binds each file (or directory tree) to keys that can belong to a user, a class or an application, so access can be withdrawn while the system keeps running.
- Offline protection is the strong case. The Linux kernel documentation states fscrypt protects contents and filenames against "a single point-in-time permanent offline compromise of the block device content", and that it does not hide plaintext from other users on a running system.
- Metadata usually leaks. fscrypt "does not protect the confidentiality of non-filename metadata, e.g. file sizes"; permissions, timestamps and extended attributes stay readable too.
- The ATT&CK links are inferred and broad. D3FEND relates D3-FE to dozens of techniques through the File artefact. Real value is concentrated in collection, credential theft from files and offline data theft; for persistence and execution techniques the link is weak.
- Keys decide everything. D3FEND's own considerations are about keys: monitor that private keys are not compromised and move them between devices securely. Recovery keys and agents need the same care as the data.
D3-FE at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-FE (d3f:FileEncryption) |
| Tactic | Harden |
| Parent technique | Platform Hardening |
| Digital artefact | File (relation: encrypts) |
| Related ATT&CK mitigations listed by D3FEND | None (checked on D3FEND 1.6.0, November 2026) |
| D3FEND references | NIST SP 800-111 Guide to Storage Encryption Technologies for End User Devices; NIST ITL Bulletin August 2020 on exchanging files over the internet; a vendor article on file encryption |
| Main limitation | Protects data at rest and against users without the key; an attacker running as the key holder on an unlocked system reads plaintext |
How it works
D3FEND describes two models. In symmetric encryption "the same cryptographic key" encrypts and decrypts the file. In asymmetric encryption, typically with X.509 certificates, files are encrypted with a public key and decrypted with the matching private key; D3FEND notes it is "typically slower than symmetric encryption and not widely used for large file encryption, but is popular for key wrapping". Real systems combine both: a random symmetric key per file encrypts the contents, and that key is wrapped by a user, class or recovery key.
NIST SP 800-111 sets out the trade-off. Full disk encryption gives no protection once the device has booted, while file and folder encryption protects selected files until the user authenticates to them, and a file encrypted for a single user is generally protected from other users, in most cases including the device's administrators. It does not protect filenames (in NIST's general description), other metadata, or swap and hibernation files, and after the user has authenticated, malware running on the device can read the decrypted contents.
File encryption compared with neighbouring controls
| Control | Key scope | Protects against | Does not protect against |
|---|---|---|---|
| Disk or volume encryption (D3-DENCR) | One key per volume, unlocked at boot | Lost or stolen device, offline disk reads | Any process or user on the running, unlocked system |
| File encryption (D3-FE) | Per file or directory, wrapped by user, class or application keys | Offline reads, other users without the key, data copied off without its key | Malware running as the key holder while the key is loaded |
| Application or document encryption | Per document, enforced by the application or a rights service | Files that leave the managed device | Users who are authorised to open the document |
For the volume layer, see the Disk Encryption Guide: BitLocker and FileVault. For the cryptography itself, see the Encryption Guide and the Authenticated Encryption and Block Cipher Modes Guide.
Where it is implemented
Each major operating system has a built-in file-level mechanism. Platforms are listed alphabetically. These are customer-side settings: the organisation decides which files and keys use them.
| Platform | Feature | Key model | Default cipher (per vendor docs) |
|---|---|---|---|
| Apple (iPhone, iPad, Mac with Apple silicon and other Apple SoC devices) | Data Protection | A new 256-bit key per file, wrapped by a class key; four classes from Complete Protection to No Protection | AES-256 in XTS mode on A14 and M1 or later |
| Linux (ext4, F2FS, UBIFS, CephFS) | fscrypt | Master key per directory policy; v2 policies derive per-file keys | AES-256-XTS for contents, AES-256-CBC-CTS for filenames |
| Microsoft Windows (NTFS) | Encrypting File System (EFS) | Per-file key protected with the public keys of users granted access, plus optional recovery agent | Set by the current encryption driver |
Apple Data Protection
Apple states "Data Protection is controlled on a per-file basis by assigning each file to a class." Class A, Complete Protection, makes data inaccessible shortly after the device locks, and its class key is derived from the user passcode and the device UID. Class B, Protected Unless Open, lets files be written while locked. Class C, Protected Until First User Authentication, keeps the class key in memory after the first unlock and is "the default class for all third-party app data not otherwise assigned". Class D, No Protection, is protected only by the device UID. On a Mac with Apple silicon, Data Protection defaults to Class C and uses a volume key, and developers can opt in to a higher class. In practice: require app developers to set Class A for the most sensitive files, such as cached tokens and exported documents.
Linux fscrypt
fscrypt is built into ext4, F2FS, UBIFS and CephFS and encrypts contents and filenames per directory. The kernel documentation recommends v2 policies for new directories, "supported since Linux v5.4", because v1 policies do not verify keys and let one per-file key compromise expose the master key. Keys can be removed with FS_IOC_REMOVE_ENCRYPTION_KEY, which evicts cached inodes so files appear locked again; decrypted data in kernel caches is "freed but not wiped", which the init_on_free=1 boot option partly addresses. The kernel team recommends the fscrypt userspace tool over the raw API to reduce "the chance of introducing your own security bugs".
Microsoft Windows EFS
Microsoft describes EFS as "cryptographic protection of individual files on NTFS file system volumes using a public-key system", aimed at the case where "a laptop that contains sensitive data is lost or stolen". Compressed files, system files, system directories and root directories cannot be encrypted. The cipher command manages it: /e encrypts and marks directories so new files are encrypted, /c "Displays information on the encrypted file", /r generates a recovery agent key and certificate, /x backs up the user's EFS certificate and keys, and /rekey moves files to the currently configured key.
ATT&CK techniques D3FEND relates to D3-FE
D3FEND labels these relationships as inferred and experimental: they come from the shared File artefact, not from testing. The list is long and covers almost every technique that reads or writes a file. The table groups it by tactic with representative techniques and our assessment of real relevance. Where D3FEND still lists a revoked ATT&CK ID, the v20 successor is shown: Impair Command History Logging is now T1690 Prevent Command History Logging, and Clear Linux or Mac System Logs is now T1685.006. Launchd, which v20 marks deprecated, is omitted.
| Tactic | Representative techniques (ATT&CK v20) | Practical relevance of file encryption |
|---|---|---|
| Collection | T1005 Data from Local System; T1119 Automated Collection; T1074.001 Local Data Staging; T1114.001 Local Email Collection; T1560.001 Archive via Utility | Strong when the attacker has disk access but not the key, for example a different user or an offline copy. Weak against malware running as the key holder. |
| Credential Access | T1552.001 Credentials In Files; T1555.003 Credentials from Web Browsers; T1003.008 /etc/passwd and /etc/shadow | Useful for credential and token files of other users and for backups; does not help when the owning user's session is compromised. |
| Discovery | T1083 File and Directory Discovery | Partial. fscrypt encrypts filenames, so names in a locked directory are hidden; sizes and timestamps are not. |
| Impact | T1565.001 Stored Data Manipulation; T1565.003 Runtime Data Manipulation; T1486 Data Encrypted for Impact | Weak. Encryption without authentication does not stop tampering, and ransomware can encrypt already-encrypted files. Pair with backups. |
| Stealth | T1036.005 Match Legitimate Resource Name or Location; T1036.006 Space after Filename; T1070.004 File Deletion; T1027.002 Software Packing; T1564 Hide Artifacts | Little or none. |
| Persistence and Privilege Escalation | T1546 Event Triggered Execution; T1547 Boot or Logon Autostart Execution; T1543 Create or Modify System Process; T1037 Boot or Logon Initialization Scripts; T1505.003 Web Shell; T1548.003 Sudo and Sudo Caching | Little or none on a running system; these need integrity and permission controls. |
| Initial Access and Execution | T1566.001 Spearphishing Attachment; T1204.002 Malicious File; T1574.001 DLL; T1072 Software Deployment Tools | None in practice. |
| Defense Impairment | T1690 Prevent Command History Logging; T1685.006 Clear Linux or Mac System Logs | None in practice. |
The assessment column is NHI Mgmt Group's view. For the attacker side of the strongest fits, see MITRE ATT&CK T1005 Data from Local System and MITRE ATT&CK T1119 Automated Collection.
Implementation steps
- Decide what needs file-level keys: volume encryption should already be in place. Pick the data that must stay protected on a running system or across users: shared hosts, exported datasets, credential stores, backup staging areas and developer workstations holding production secrets.
- Design key ownership and recovery first: on Windows, create and publish an EFS recovery agent (cipher /r) and store its private key offline before encrypting anything. On Linux, decide how fscrypt protector keys are stored and recovered. On Apple devices, set protection classes in app code and rely on device management for recovery of the device itself.
- Choose current settings: fscrypt v2 policies with the default AES-256-XTS and AES-256-CBC-CTS pair (or Adiantum where AES is slow); Apple Class A for the most sensitive app files.
- Pilot: encrypt a test directory or app container, then exercise backup, restore, sync, antivirus scanning and indexing. EFS files copied through CopyFile rely on the EFS service in lsass.exe to keep their keys; check what your copy and sync tools do.
- Roll out by policy: mark directories (cipher /e on a directory, fscrypt policy on an empty directory) so new files inherit encryption, rather than encrypting files one by one.
- Back up keys: export EFS certificates (cipher /x) to protected storage and test that a recovery agent can open a sample file.
- Rollback: decrypt with the platform tool (cipher /d) or copy data out of an unlocked fscrypt directory before removing the policy. Never remove keys until a restore test has passed.
How to verify it works
- Windows: cipher /c shows encryption details for a file; cipher /u /n finds encrypted files on local drives without changing them. Report both coverage and the recovery agents present.
- Linux: the fscrypt userspace tool reports a directory's policy and whether it is locked. Remove the key, then confirm filenames in the directory show as encrypted names and contents cannot be read.
- Apple: verify in app code reviews and mobile security testing that sensitive files are written with the intended protection class, then test access while the device is locked.
- Offline test: image a test disk or directory and read it from another system without the key; contents and (for fscrypt) filenames should be unreadable.
- Key events: alert on new EFS recovery agent certificates, key exports and bulk decryption, which can indicate an attacker preparing to take data.
Metrics (examples, not standards)
| Metric | Source | Example target |
|---|---|---|
| In-scope directories with file encryption applied | cipher /u /n or fscrypt status reports | 100 per cent of the defined scope |
| Encrypted data with a tested recovery path | Quarterly restore test | 100 per cent |
| fscrypt directories still on v1 policies | Policy inventory | Zero for new data |
| Sensitive app files below Class A | Mobile app security testing | Zero without an approved reason |
| Unreviewed key export or recovery agent changes | SIEM alerts | Zero |
Limits, bypasses and failure patterns
- Malware runs as the key holder: on an unlocked session, the operating system decrypts on read for that user. The kernel documentation is explicit that with root or kernel code execution, in-use data is generally exposed.
- No integrity: fscrypt states that authenticated encryption modes are not supported, and offline tampering before access can break confidentiality and authenticity. Use integrity controls such as D3-FIM File Integrity Monitoring where tampering matters.
- Lost keys, lost data: encrypting before recovery is designed turns a reinstalled profile or a deleted certificate into permanent data loss.
- Plaintext copies: temporary files, caches, swap, sync clients and copies to file systems without file encryption can leave unencrypted versions. EFS protection belongs to NTFS volumes.
- Encryption mistaken for ransomware defence: encrypted files can be encrypted again by an attacker. See MITRE ATT&CK T1486 Data Encrypted for Impact and the Backup Security and Immutable Backup Guide.
- Metadata assumed private: sizes, timestamps and permissions remain readable, which can reveal what a file is.
Where identity fits
File encryption keys are identities in their own right: EFS keys sit behind user certificates, fscrypt protectors behind passphrases or keys held by services, and recovery agents are high-privilege credentials that can open everything. Service accounts that process encrypted files need their own keys, scoped to the directories they use, and their key material belongs in a secrets manager rather than in a script or a home directory. See the Cryptographic Key Management Guide.
Framework mapping
| Framework | Reference | Fit |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-28 Protection of Information at Rest; SC-28(1) Cryptographic Protection | Direct |
| NIST SP 800-53 Rev. 5 | SC-12 Cryptographic Key Establishment and Management; SC-13 Cryptographic Protection | Key design and approved algorithms |
| NIST CSF 2.0 | PR.DS-01 Data-at-rest protection | Direct |
| ATT&CK mitigation | M1041 Encrypt Sensitive Information | Closest mitigation; see the M1041 Encrypt Sensitive Information guide |
This mapping is NHI Mgmt Group's view; D3FEND lists no ATT&CK mitigation for D3-FE.
Practitioner checklist
- Keep volume encryption in place and use file encryption for data that must stay protected on running or shared systems.
- Design key ownership, backup and recovery before encrypting anything.
- Use fscrypt v2 policies and Apple Class A for the most sensitive data.
- Encrypt at directory level so new files inherit protection.
- Test restores from backup and recovery agents every quarter.
- Alert on recovery agent changes and key exports.
- Add integrity monitoring where tampering matters, because file encryption does not authenticate data.
- Scope service account keys to the directories they need.
Standards and references
- MITRE D3FEND: File Encryption (D3-FE)
- NIST: SP 800-111 Guide to Storage Encryption Technologies for End User Devices
- Apple Platform Security: Data Protection overview
- Apple Platform Security: Data Protection classes
- Linux kernel documentation: Filesystem-level encryption (fscrypt)
- Microsoft Learn: File Encryption
- Microsoft Learn: cipher
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-28)
Related NHI Mgmt Group resources: Disk Encryption Guide: BitLocker and FileVault · M1041 Encrypt Sensitive Information · Cryptographic Key Management Guide · MITRE D3FEND Guide