Full-Disk and Container Encryption
Storage encryption is not one uniform boundary. The protected storage scope, availability before and after unlock, recovery-password custody, and technical ability to decrypt are separate questions. This page covers neither backup-copy encryption nor compelled-passcode and border-search rules.
Not legal advice. This page is research, not compliance guidance.
What does each storage-encryption layer cover?
Storage encryption restricts access to stored information through encryption and authentication, while full-disk encryption, volume or virtual-disk encryption, and file or folder encryption protect different storage boundaries.
The National Institute of Standards and Technology distinguishes three storage-encryption categories: full-disk encryption, volume or virtual-disk encryption, and file or folder encryption. Each category applies protection at a different storage boundary rather than making every encrypted system equivalent.
Choosing the relevant boundary depends primarily on the type of storage, the amount of information to protect, the environment where the storage will be located, and the threats to address. Those factors define the scope of the storage problem; they do not rank products or prescribe setup steps.
The phrase container-like can help describe the volume or virtual-disk layer, but it is explanatory framing rather than the agency's category name. It does not establish a product-specific container design or implementation.
- Full-disk encryption: one of the three storage-encryption categories.
- Volume or virtual-disk encryption: the category that can be described as container-like for explanation, not as an official category name.
- File or folder encryption: protection scoped to files or folders rather than the other listed storage boundaries.
- Selection factors: storage type, information scope, environment, and threat.
Figure 1. Full-disk and container layers compare locked, unlocked, backup and recovery states beside a coercion-and-legal-process limits boundary.
Source: none (concept)
How does availability change between locked and unlocked states?
In one documented platform-specific model, credential-encrypted storage becomes available only after user unlock, while device-encrypted storage is available after boot before the first unlock and remains available afterward.
The example separates two encrypted storage classes by availability. Credential-encrypted storage is available only after the user unlocks the device. Device-encrypted storage is available after boot before the first unlock and after the user has unlocked the device.
Encrypted therefore does not mean that every byte has the same locked-state availability. The encryption label and the availability state answer different questions: one concerns protected storage, while the other concerns when a particular encrypted storage class can be used.
This is a platform-specific example, not a universal device model. It does not establish that every platform uses these storage classes, exposes the same data before unlock, or behaves the same way after boot.
- Credential-encrypted storage in the documented model: available only after user unlock.
- Device-encrypted storage in the documented model: available after boot before the first unlock and afterward.
- Interpretation limit: encrypted storage can have different availability states.
- Scope limit: the documented model does not establish behavior across every platform or device.
What access does a recovery password create?
Possession of a recovery password permits a holder to unlock the protected volume and access all of its data, so the recovery material should be stored securely and separately from the device it protects.
A recovery password is an alternate access path to a protected volume. The documented recovery boundary is direct: a holder with the recovery password can unlock that volume and access all of its data. Recovery material therefore requires protection of its own.
Secure, separate storage keeps the recovery password apart from the protected device. This page makes no claim about how a named cloud, account, escrow service, or backup system stores or releases recovery material.
Recovery-password custody is separate from backup-copy encryption. For backup-copy exposure and encryption, see 3-2-1 Backups and Border Crossings.
- Access path: possession of the recovery password permits unlocking the protected volume.
- Data boundary: the holder can access all data on that volume.
- Custody: store recovery material securely and separately from the protected device.
- Outside this page's scope: named cloud or escrow flows and backup-copy encryption.
Does legal authorization guarantee technical access?
The Department of Justice reports one instance in which a lawfully issued warrant did not enable law enforcement to bypass a phone's encryption and access its content; that single account is not a general rule about legal authority and decryption.
The reported instance separates two questions. Law enforcement had legal authorization through a warrant, yet the agency reports that it could not bypass the phone's encryption and access the content. In that example, authorization did not supply technical decryption capability.
One agency account of one instance is not a statute, legal holding, success-rate claim, or general rule about compelled decryption. Its scope is the reported warrant and failed bypass, not compelled-passcode or border-search rules. This page offers no legal advice.
Questions about authentication and passcodes are covered in Passkeys and Second-Factor Location. The warrant example remains a narrow technical distinction between authorization and decryption capability.
- Documented example: a lawfully issued warrant did not enable bypass of the phone's encryption or access to its content.
- Technical boundary: legal authorization and technical decryption capability were separate in that instance.
- Scope: one agency account of one warrant and a failed encryption bypass.
- Related subject: Border Device Search covers border-specific search and access limits.