File-Level Encryption
Granular encryption of individual files with unique keys, enabling classification-based protection that persists regardless of storage location or transmission method.
Continue your mission
Granular encryption of individual files with unique keys, enabling classification-based protection that persists regardless of storage location or transmission method.
# File-Level Encryption
File-level encryption (FLE) is a data protection method that applies cryptographic controls to individual files or directories rather than to an entire storage volume or disk. It exists because organizations need precision in their data protection posture: not every file carries the same sensitivity, not every user requires the same access, and not every storage location can be trusted equally. FLE solves the problem of data exposure when files leave a controlled environment, whether through cloud sync, email attachment, USB transfer, or unauthorized access to a shared storage system. By binding the encryption policy directly to the file rather than to the container holding it, FLE ensures that protection travels with the data, not with the infrastructure.
---
File-level encryption refers to the application of symmetric or asymmetric cryptographic algorithms to individual files, producing ciphertext that cannot be read without possession of the appropriate decryption key. The encryption boundary is the file itself, not the block device, volume, or partition that contains it.
FLE is distinct from full-disk encryption (FDE), which encrypts all data on a storage medium uniformly. FDE protects against physical theft of a device but offers no protection once the disk is unlocked and mounted. An attacker with operating system access sees all files in plaintext. FLE, by contrast, maintains per-file or per-directory key controls independent of whether the disk is mounted or the OS is running.
FLE is also distinct from transport encryption (TLS), which protects data in transit but leaves it exposed at rest at both endpoints. It differs from database-level encryption, which protects structured records within a database engine but does not extend protection to file exports, backups, or attachments derived from that data.
The most significant operational characteristic of FLE is that the encryption travels with the file. When an FLE-protected file is copied to a USB drive, uploaded to cloud storage, or sent as an email attachment, it remains encrypted regardless of the destination environment's security posture. This makes FLE the preferred control for scenarios where data must cross trust boundaries or where the security of the destination storage cannot be guaranteed.
---
FLE follows a consistent cryptographic architecture regardless of the platform implementing it. Understanding the mechanics precisely is essential to evaluating any FLE implementation.
Key Hierarchy and Management
FLE relies on a two-tier or three-tier key hierarchy. At the bottom is the Data Encryption Key (DEK), a symmetric key (typically AES-256) used to encrypt the file contents directly. The DEK is never stored in plaintext anywhere on the system. It is wrapped (encrypted) by a Key Encryption Key (KEK), which is tied to a user, group, role, or device identity. The KEK is managed by a Key Management Service (KMS), a Hardware Security Module (HSM), or a PKI infrastructure. Some implementations add a third tier: a master key or tenant root key that wraps all KEKs, allowing administrators to revoke or rotate access at scale.
This hierarchy enables two critical capabilities. First, it allows granular access control without managing symmetric keys for every user-file combination, which would be mathematically impossible at scale. Second, it enables key rotation without re-encrypting every file: rotating a KEK invalidates access for all files wrapped with it, while DEK rotation can be performed selectively based on sensitivity or age.
Encryption Process at Write Time
When a user saves a file in an FLE-enabled system, the following sequence occurs:
The result is a file that appears normal to the filesystem but contains only encrypted content plus metadata necessary for authorized decryption.
Decryption Process at Read Time
When a user requests access to an encrypted file:
Implementation Variants
Per-file encryption assigns each file its own unique DEK. This provides maximum granularity and security isolation but creates the highest key management overhead. Per-directory encryption uses a shared DEK for all files within a directory, simplifying key management while reducing granularity.
Object-level encryption is FLE applied in cloud storage systems like AWS S3 or Azure Blob Storage, where each object receives its own encryption key managed by a customer-controlled KMS. This enables client-side encryption where files are encrypted before transmission to the cloud provider.
Rights-managed encryption embeds policies directly with the encrypted file, defining not just who can decrypt it but what actions they can perform (view only, print, copy, forward). Microsoft Information Protection and Adobe Document Security represent this approach.
Real-World Implementation: Law Firm Document Protection
A law firm implements FLE to protect client communications and case files. Files in the "Privileged" directory are automatically encrypted with DEKs wrapped by KEKs tied to the specific case team. When an associate emails a protected file to opposing counsel, the file remains encrypted during transmission and storage. The recipient cannot decrypt it because their identity does not map to an authorized KEK for that case. Only case team members with valid authentication to the firm's KMS can decrypt the file, regardless of where it physically resides.
When the case closes, the firm revokes the case-specific KEK. All files protected with that KEK become permanently unreadable, even if copies exist on personal devices, cloud accounts, or backup systems outside the firm's control. This ensures that confidential case information cannot be accessed after the professional relationship ends.
---
The security value of FLE is measured not by what it prevents during normal operations but by what it limits during a breach, misconfiguration, or insider threat event. FLE serves as a control that fails securely: when other protections fail, encrypted files remain protected by the cryptographic properties of the implementation.
Protection Beyond Infrastructure Boundaries
Traditional perimeter security assumes that data stays within controlled environments. This assumption fails regularly in modern business operations. Employees email sensitive files to personal accounts, sync them to unauthorized cloud services, and copy them to portable devices. Remote work has accelerated these behaviors. FLE maintains protection in all these scenarios because the encryption policy is bound to the file, not to the network or device containing it.
For regulated industries, this capability changes breach notification obligations substantially. Under HIPAA, the disclosure of encrypted PHI using NIST-validated algorithms with properly managed keys may not constitute a breach requiring notification. Similar provisions exist in state privacy laws and international frameworks. FLE transforms a potential compliance violation into a technical finding.
Limiting Ransomware Extortion
Modern ransomware operations follow a double-extortion model: exfiltrate sensitive data before encrypting systems, then threaten to publish the stolen data if ransom demands are not met. This model has proven more effective than pure destruction because organizations can often restore from backups but cannot recall data that has been stolen and published.
FLE disrupts this model when properly implemented. If sensitive files are protected with customer-controlled keys managed in HSMs, exfiltrated files remain unreadable to attackers. The disruption component of the ransomware attack (encrypting systems) may still succeed, but the extortion component (threatening to publish data) loses its leverage. Organizations that can credibly demonstrate that exfiltrated files were encrypted with keys the attackers cannot access face a fundamentally different risk calculation.
Cloud Storage Misconfiguration Protection
Cloud storage misconfigurations represent one of the most common causes of data exposure incidents. AWS reports that over 70% of S3 buckets have at least one misconfiguration that could lead to unauthorized access. Azure and Google Cloud report similar statistics. These misconfigurations typically involve overly permissive access policies, disabled encryption, or improperly configured authentication.
FLE with customer-managed keys serves as a backstop control against storage misconfigurations. A misconfigured bucket that allows public read access will expose files to unauthorized parties, but if those files are encrypted with keys controlled by the organization rather than the cloud provider, unauthorized access yields only ciphertext. The root cause (misconfigured access controls) still requires remediation, but the data exposure impact is contained.
Common Implementation Failures
Many organizations implement FLE incorrectly, creating a false sense of security. The most common failure is using provider-managed keys in cloud environments. When a cloud provider manages both the data and the keys, provider account compromise, legal compulsion, or insider access can break protection entirely. True FLE requires customer-controlled key management.
Another common failure is inconsistent coverage. Organizations often encrypt obviously sensitive files while leaving supporting documentation, metadata, or derived files unprotected. Attackers can reconstruct sensitive information from unprotected supporting files, making partial FLE implementation less effective than expected.
---
CDA approaches file-level encryption through the Planetary Defense Model (PDM) under the Data Protection and Sovereignty (DPS) domain. The governing methodology is the Sovereign Data Protocol (SDP), which establishes a non-negotiable principle: your data lives where you decide, period. FLE is the technical mechanism that makes that principle enforceable rather than aspirational.
Within the SDP framework, CDA rejects shared-key arrangements with cloud providers, SaaS vendors, or managed service providers as insufficient. Provider-managed encryption, where a third party controls both the data and the keys, creates a single point of failure. A compromised provider account, a compelled legal disclosure, or an insider at the provider can break protection entirely. CDA-aligned FLE implementations require customer-controlled keys, managed in HSMs that the organization owns or operates under dedicated tenancy with hardware attestation.
CDA's operational approach to FLE includes four specific requirements that differentiate it from conventional implementations:
First, classification-driven encryption policies must be defined before deployment. Files are tagged at creation time based on content inspection, directory policy, or user-applied labels. These tags determine which KEK wraps the file's DEK, which groups have access, and what actions are permitted on decrypted content. Classification drives the technical implementation rather than being retrofit afterward.
Second, key access must generate immutable audit records stored outside administrative control. Every DEK unwrap event must be logged to a SIEM or append-only log store that cannot be modified by any single administrator. This supports both compliance reporting and forensic investigation. The audit trail must survive the compromise of the primary environment.
Third, key revocation capabilities must be tested quarterly in non-production environments. The ability to revoke a KEK and render files unreadable to a terminated employee, compromised device, or departing vendor is only reliable if the procedure has been exercised and validated. Untested revocation procedures fail under operational pressure when they are most needed.
Fourth, client-side encryption is strongly preferred for any data destined for third-party storage. CDA does not accept server-side encryption with provider-managed keys as satisfying the SDP requirements. The encryption must occur on an endpoint or system the organization controls before data crosses the trust boundary. This ensures that the organization maintains cryptographic control over its data regardless of the security posture of external storage providers.
---
---
---
CDA Theater missions that address topics covered in this article.
Cryptographic technique that encrypts data while preserving its original format and length, enabling protection without breaking legacy system compatibility.
Guide to HTTP/2 security covering binary framing, HPACK compression attacks, rapid reset vulnerability, stream multiplexing risks, and mitigation strategies.
Explanation of Certificate Transparency framework, covering log servers, Signed Certificate Timestamps, monitoring capabilities, and detection of fraudulent certificates.
Written by CDA Editorial
Found an issue? Help improve this article.