Why Disk Encryption Is Non-Negotiable in Zero Trust
Disk encryption protects data at rest against physical access threats: stolen laptops, lost devices, decommissioned drives that bypass secure disposal, and insider threats with physical access to hardware. In a Zero Trust model where devices routinely access sensitive resources from any location, the probability of physical device loss is significantly higher than in traditional office-bound environments. A single unencrypted laptop left in a taxi or stolen from a coffee shop can expose credentials cached in browser profiles, VPN certificates, OAuth tokens stored in application data, and locally synced files containing sensitive data.
Regulatory frameworks reinforce this requirement. HIPAA’s breach notification safe harbor exempts organizations from reporting data breaches when the compromised data was encrypted with NIST-approved algorithms. GDPR considers encryption a key technical measure under Article 32. PCI DSS Requirement 3.4 mandates that stored cardholder data be rendered unreadable. For organizations subject to these regulations, enforcing disk encryption is not just a security best practice; it is a compliance obligation that directly impacts breach notification requirements and potential penalties.
Encryption Technologies by Platform
Windows: BitLocker
BitLocker Drive Encryption, available in Windows Pro, Enterprise, and Education editions, provides full-volume encryption using AES-128 or AES-256 in XTS mode. For Zero Trust enforcement, the policy should require AES-256-XTS on all fixed drives, not just the OS volume. BitLocker can operate in several modes: TPM-only (transparent to the user), TPM+PIN (requires a pre-boot PIN), and TPM+USB (requires a USB startup key). The TPM+PIN configuration provides the strongest protection against cold boot attacks and DMA attacks via Thunderbolt or FireWire ports, though it adds friction to the user experience.
Recovery key escrow is critical for enterprise deployment. BitLocker recovery keys should be automatically backed up to Active Directory or Azure AD during encryption. The posture agent should verify not only that BitLocker is enabled but that the recovery key has been successfully escrowed. A device with BitLocker enabled but no escrowed recovery key represents a data loss risk if the TPM fails or the user forgets their PIN.
macOS: FileVault 2
FileVault 2 uses XTS-AES-128 encryption on the entire startup volume. On Macs with the Apple T2 or M-series chips, the hardware provides always-on encryption at the storage controller level; FileVault adds a layer by protecting the volume encryption key with the user’s password. The posture agent verifies FileVault status using fdesetup status and confirms that the institutional recovery key has been escrowed to the MDM platform. Jamf Pro and other macOS MDM solutions can enforce FileVault enablement during enrollment and automatically escrow the recovery key.
Linux: LUKS
Linux Unified Key Setup (LUKS) provides disk encryption for Linux endpoints. LUKS2, the current version, supports multiple encryption algorithms and key slots, allowing both a user passphrase and an organizational recovery key. The posture agent on Linux checks for LUKS encryption by examining block device metadata through cryptsetup luksDump and verifying that all partitions containing user or application data are encrypted. For enterprise Linux deployments, Network-Bound Disk Encryption (NBDE) using Clevis and Tang allows automated decryption when the device is connected to the corporate network, with manual passphrase entry required when off-network.
Enforcing Encryption Through the Policy Engine
The encryption enforcement policy should be implemented as a mandatory posture check in the Zero Trust policy engine. The posture agent reports encryption status as part of the device health attestation, and the PDP evaluates it against the encryption policy before issuing access tokens.
The policy should check multiple attributes beyond simple on/off status. A comprehensive encryption posture check verifies the following conditions:
- Encryption State: All fixed volumes must be fully encrypted. Volumes in the process of encrypting (BitLocker reports “Encryption In Progress”) should be treated as compliant with a time-limited exception, as initial encryption of a large drive can take several hours.
- Algorithm Strength: The encryption algorithm must meet the organizational minimum. AES-256 is recommended. Devices using deprecated algorithms like 3DES or AES-128 in non-XTS modes should be flagged for re-encryption.
- Protector Configuration: On Windows, BitLocker must use TPM as a protector. Software-only encryption without TPM backing is vulnerable to key extraction from memory dumps. The policy should require TPM 2.0 as the minimum TPM version.
- Recovery Key Escrow: The recovery key must be present in the organization’s key management system. This ensures recoverability and confirms that the device was encrypted through the managed process rather than independently by the user.
- Removable Media Policy: If the organization permits USB storage, BitLocker To Go should be enforced on removable drives. The posture check should verify that the Group Policy for removable media encryption is applied.
Deployment and Remediation Strategies
Enabling disk encryption fleet-wide requires careful planning to avoid data loss and user disruption. The deployment should proceed in phases, beginning with an assessment of the current encryption landscape. MDM platforms like Intune, Jamf, and Workspace ONE provide encryption status reporting that reveals how many devices are already encrypted and which devices lack encryption.
For devices that lack encryption, the MDM platform can push an encryption configuration profile that silently enables encryption. On Windows, Intune’s endpoint protection profile can configure BitLocker settings including encryption method, recovery key rotation, and startup authentication requirements. On macOS, a FileVault configuration profile triggers encryption at the next logout, with the recovery key automatically escrowed to the MDM server.
Devices that fail the encryption posture check should be directed to a self-service remediation portal. The portal should detect the device platform and provide platform-specific instructions. For a Windows device without BitLocker, the portal might offer a one-click remediation that triggers encryption through a PowerShell script delivered via the MDM agent. For a personal device in a BYOD program, the portal should provide clear instructions for enabling the platform’s native encryption and warn that access will remain restricted until encryption is confirmed.
Hardware Security Module Integration
Modern endpoints include hardware security modules, specifically TPM 2.0 on Windows and the Secure Enclave on Apple devices, that provide tamper-resistant key storage for disk encryption keys. The Zero Trust policy engine should verify not only that encryption is active but that it is backed by hardware key storage.
On Windows, the posture agent can query TPM status through the Win32_Tpm WMI class, verifying that the TPM is present, activated, owned, and running firmware version 2.0 or later. BitLocker’s TPM protector ensures that the volume master key is sealed to the TPM’s Platform Configuration Registers (PCRs), which means the key is only released when the boot chain is intact. Any modification to the boot loader, boot manager, or early boot drivers changes the PCR values, preventing the TPM from releasing the key and halting the boot process until the BitLocker recovery key is provided.
This hardware-backed encryption provides strong protection against offline attacks. Even if an attacker removes the drive and connects it to another machine, the encryption key is bound to the original device’s TPM and cannot be extracted. This level of protection is essential for Zero Trust environments where devices frequently operate outside physically secured facilities.
Operational Monitoring and Key Rotation
Ongoing encryption management includes monitoring for compliance drift, rotating recovery keys, and responding to encryption-related incidents. The MDM platform should generate alerts when a device’s encryption status changes, for example, when BitLocker is suspended during a BIOS update and not automatically resumed. The posture check catches these transient states and restricts access until encryption is fully active again.
Recovery key rotation is an often-overlooked operational requirement. When a recovery key is used, such as after a TPM firmware update or a help desk recovery scenario, the key should be rotated immediately. Intune supports automatic BitLocker key rotation after use. The organization should also rotate keys on a scheduled basis, typically annually, to limit the window of exposure if a key is compromised. Each rotation generates a new recovery key that is escrowed to the management platform, and the previous key is invalidated.
Disk encryption enforcement is one of the most impactful and least disruptive posture checks in a Zero Trust deployment. Modern operating systems include robust, hardware-backed encryption capabilities that operate transparently to users. By making encryption a mandatory access requirement, organizations close one of the most significant physical security gaps in distributed work environments.