Endpoint Encryption: Full Disk, File-Level, and Removable Media

Endpoint encryption protects data stored on or transmitted from computing devices by rendering it unreadable without authorized credentials or keys. Three distinct implementation models — full disk encryption, file-level encryption, and removable media encryption — address different threat surfaces and compliance obligations. Regulatory frameworks including HIPAA, FISMA, and PCI DSS treat encryption as a baseline control for devices that store or process sensitive data, making the selection of the correct model a compliance and operational decision with direct consequences for breach liability and audit outcomes.

Definition and scope

Endpoint encryption is a data protection control applied at the device or storage layer to ensure that data-at-rest cannot be accessed by unauthorized parties, even when physical media is stolen, lost, or improperly decommissioned. The control operates independently of network-layer security and is distinct from transport encryption protocols such as TLS, which protect data-in-transit.

Three primary implementation models define the field:

1. Full Disk Encryption (FDE) — encrypts the entire storage volume, including the operating system, application files, swap space, and temporary files. Decryption occurs at boot via pre-boot authentication. Microsoft BitLocker and Apple FileVault are common platform-native implementations.
2. File-Level Encryption (FLE) — applies cryptographic protection to individual files or folders rather than the entire volume. Decryption is triggered when an authorized user or process accesses a specific file. This model is suited to shared systems where not all data requires equal protection.
3. Removable Media Encryption (RME) — enforces encryption on USB drives, external hard drives, SD cards, and optical media. Controls may be applied through endpoint management platforms that prevent unencrypted media from mounting or transferring data.

NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices, provides the authoritative federal taxonomy for these three categories and the threat models each addresses.

The regulatory scope is broad. The HIPAA Security Rule (45 CFR § 164.312(a)(2)(iv)) identifies encryption of electronic protected health information (ePHI) as an addressable implementation specification — meaning covered entities must implement it or document an equivalent alternative. PCI DSS Requirement 3.5 mandates encryption of stored cardholder data. FISMA-aligned systems follow NIST SP 800-53 Rev. 5 control SC-28, which requires protection of information at rest.

How it works

Full disk encryption operates through a volume-level cipher, most commonly AES-256, applied by either software or hardware. Hardware-based FDE uses a self-encrypting drive (SED) with an onboard cryptographic processor; software-based FDE (such as BitLocker or dm-crypt on Linux) uses the host CPU. The Trusted Platform Module (TPM) chip, standardized under TCG TPM Specification 2.0, stores the encryption key and validates platform integrity at boot, preventing decryption on unauthorized hardware.

The authentication and decryption sequence for FDE follows a defined phase structure:

1. Pre-boot authentication — the bootloader prompts for a PIN, password, or smart card credential before the OS loads.
2. Key release — the TPM releases the Volume Master Key (VMK) after verifying that measured boot values match stored Platform Configuration Register (PCR) values.
3. Volume unlock — the encryption driver decrypts sectors on-the-fly as they are read; the user experiences no performance-layer interruption under normal workloads.
4. Session termination — the key is revoked from memory upon hibernation or shutdown, leaving the drive encrypted at rest.

File-level encryption interrupts this flow differently. The encryption layer sits above the filesystem, not below it. Each file is encrypted with a unique File Encryption Key (FEK), which is itself wrapped by a user key or a domain key. The Microsoft Encrypting File System (EFS) follows this architecture. The critical operational difference from FDE: a logged-in session with an unlocked FDE volume exposes all files to processes running in that session, while FLE enforces per-file access control even within an authenticated session.

Removable media encryption typically enforces policy through endpoint management agents — products governed by standards such as NIST SP 800-124 Rev. 2 — that intercept device mount events and require encryption compliance before allowing data transfer.

Common scenarios

Endpoint encryption deployment varies by industry, device class, and data sensitivity classification. The following scenarios represent the dominant use contexts within the endpoint security service landscape:

Healthcare — laptop fleet protecting ePHI. A hospital system deploying BitLocker with TPM+PIN on all physician laptops satisfies the HIPAA addressable encryption specification and reduces breach notification exposure. Under the HITECH Act, encrypted data that is breached does not trigger the same notification requirements as unencrypted data — a material compliance distinction.

Financial services — portable media control. A broker-dealer subject to SEC and FINRA recordkeeping rules enforces RME policy through an endpoint management platform. USB ports are blocked by default; only AES-256-encrypted media provisioned through a corporate portal can mount.

Federal contractor — CMMC compliance. A defense contractor subject to CMMC Level 2 must implement NIST SP 800-171 control 3.13.16, which requires protection of CUI at rest. FDE on all workstations and servers processing Controlled Unclassified Information (CUI) satisfies this control, documented through a System Security Plan.

Mixed-sensitivity shared workstation. A university research lab shares workstations between public-use and restricted research data. FDE alone is insufficient because all users share an authenticated session context. FLE applied to the restricted research directories, combined with role-based key management, enforces access boundaries that FDE cannot provide in this configuration.

Decision boundaries

Selecting among FDE, FLE, and RME — or deploying them in combination — depends on four structurally distinct criteria:

Threat model alignment. FDE addresses physical theft of the device. FLE addresses unauthorized access by authenticated users or malware running in a user context. RME addresses exfiltration via portable media. These are non-overlapping threat vectors; a complete endpoint encryption posture typically requires addressing all three.

Regulatory mandate specificity. NIST SP 800-111 explicitly distinguishes between volume encryption and file encryption and notes that some compliance frameworks specify which type is required. Organizations reviewing the should map each regulatory requirement to its corresponding implementation layer before selecting tooling.

Performance and operational constraints. Hardware FDE via self-encrypting drives imposes near-zero performance overhead because the cryptographic operations occur on the drive controller. Software FDE consumes CPU cycles, with NIST SP 800-111 noting that modern AES-NI hardware acceleration has reduced this gap substantially on devices manufactured after 2010. FLE introduces higher per-access latency on large file operations due to per-file key retrieval overhead.

Key management complexity. FLE generates a larger key inventory than FDE because each protected file may carry a distinct FEK. Enterprise deployments require a key management infrastructure capable of recovery, revocation, and audit logging. The NIST Cryptographic Key Management Workshop guidance addresses key lifecycle requirements. Organizations using FDE alone carry a simpler key estate but accept that a stolen unlocked device exposes all data simultaneously.

The correct architecture for most regulated environments combines FDE as the baseline control with RME policy enforcement for all portable media, supplemented by FLE where role-segregated access to sensitive directories is required. Professionals assessing available services in this area can reference the endpoint security providers for qualified providers operating in these implementation domains.