Encryption Evidence at Scale: Automating BitLocker Governance for Audit Readiness

BitLocker Key Rotation: Automating Encryption Evidence for Auditors

Full-disk encryption is a foundational security control that appears in virtually every compliance framework. ISO 27001 A.8.24 (Use of Cryptography), Cyber Essentials Plus, DORA, NIS2, and SOC 2 all require demonstrable evidence that endpoint storage is encrypted. For Windows devices managed by Microsoft Intune, BitLocker is the encryption mechanism - but the gap between "BitLocker is turned on" and "we can prove to an auditor that BitLocker is consistently enforced, keys are rotated, and recovery is possible" is significant.

Why Auditors Ask for Encryption Evidence

Auditors are not interested in whether your policy document says "all devices shall be encrypted." They want evidence that:

1. Every in-scope device is currently encrypted: Not "most" - every single one. A single unencrypted device in a compliance sample is a finding.
2. Encryption was active during the audit period: Not just today. If a device was unencrypted for a week last quarter, that is a gap.
3. Recovery keys are securely stored: If a device is encrypted but the recovery key is lost, the data is effectively destroyed - which may violate data retention requirements.
4. Key rotation occurs: Stale encryption keys increase the risk window if a key is compromised. Regular rotation demonstrates active management.

Intune BitLocker Configuration

Navigate to Microsoft Intune admin centre > Endpoint security > Disk encryption > Create policy > Windows 10 and later > BitLocker.

Base settings:

• Require device encryption: Yes
• Allow warning for other disk encryption: No (this prevents the prompt asking users if they want to enable a third-party encryption tool, which confuses users and delays encryption)
• Allow standard users to enable encryption during Autopilot: Yes (critical for Autopilot-provisioned devices where the user completes setup)
• Configure encryption methods: XTS-AES 256-bit for OS drives and fixed data drives. AES-CBC 256-bit for removable drives.

OS Drive settings:

• OS drive recovery: Enable
• Recovery key escrow to Entra ID: Required. This is the single most important setting. Without it, recovery keys exist only on the local device and are lost if the device fails.
• Save BitLocker recovery information to Entra ID: Yes
• Configure pre-boot recovery message: Custom URL pointing to your IT support portal
• Require additional authentication at startup: Configured per organisational requirement. For devices with TPM 2.0 (which should be all modern devices), TPM-only authentication provides silent encryption without user interaction.

Fixed data drive settings:

• Fixed drive recovery: Enable
• Recovery key escrow: Required
• Block write access to fixed data drives not protected by BitLocker: Yes

Removable data drive settings:

• Control use of BitLocker on removable drives: Yes
• Block write access to removable drives not protected by BitLocker: Yes (prevents writing unencrypted data to USB drives)

Automatic Key Rotation Policies

BitLocker key rotation is a feature that generates a new recovery key and escrows it to Entra ID, either on a schedule or after the recovery key is used. This is critical for:

• Post-incident security: If a recovery key is disclosed during a support interaction, it should be rotated immediately to prevent reuse
• Compliance evidence: Regular rotation demonstrates active cryptographic management
• Reducing key exposure window: If a key is compromised, rotation limits the period of vulnerability

Configure key rotation under Endpoint security > Disk encryption in the BitLocker policy:

• Client-driven recovery key rotation: Enable, for both Entra ID-joined and hybrid-joined devices
• Rotation trigger: After recovery key is used (this ensures that any key disclosed during support is immediately replaced)

For scheduled rotation (not triggered by use), deploy a Proactive Remediation (now called Remediations) script:

Detection script:

$keyProtectors = (Get-BitLockerVolume -MountPoint C:).KeyProtector
$recoveryPassword = $keyProtectors | Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' }
$keyAge = (Get-Date) - $recoveryPassword.KeyProtectorId.CreationTime
if ($keyAge.Days -gt 90) { exit 1 } else { exit 0 }

Remediation script:

$BLV = Get-BitLockerVolume -MountPoint C:
$existingRP = $BLV.KeyProtector | Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' }
Remove-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $existingRP.KeyProtectorId
Add-BitLockerKeyProtector -MountPoint C: -RecoveryPasswordProtector
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId (Get-BitLockerVolume -MountPoint C:).KeyProtector[-1].KeyProtectorId

Schedule this remediation to run daily on all devices. It detects keys older than 90 days and rotates them automatically.

Recovery Key Escrow and Management

Recovery keys escrowed to Entra ID are viewable under Entra ID > Devices > [device] > BitLocker keys or via the Intune admin centre > Devices > [device] > Recovery keys. Access to recovery keys should be restricted:

• Helpdesk role: Configure Entra ID custom roles or use the built-in "Cloud Device Administrator" role to limit who can view recovery keys
• Audit trail: Every recovery key view is logged in the Entra ID audit log. Export these logs to demonstrate to auditors that key access is controlled and monitored
• Self-service recovery: Configure the Windows Recovery screen to display a custom message directing users to https://myaccount.microsoft.com/device-list where they can retrieve their own recovery key after authenticating with MFA. This reduces helpdesk load and provides an audit trail of self-service access.

Compliance Reporting for Auditors

Generate audit-ready encryption evidence:

Report 1: Device encryption status Navigate to Intune > Reports > Device compliance > Setting compliance. Filter for BitLocker settings. Export as CSV showing every device and its encryption compliance state. This is your primary evidence artifact.

Report 2: Encryption policy assignment Under Endpoint security > Disk encryption, select your BitLocker policy and view the Device status tab. Export the full list showing policy assignment, compliance state, and last check-in time for every targeted device.

Report 3: Recovery key escrow verification Use Microsoft Graph API to programmatically verify that every device has a recovery key in Entra ID:

$devices = Get-MgDevice -All
foreach ($device in $devices) {
    $keys = Get-MgInformationProtectionBitlockerRecoveryKey -Filter "deviceId eq '$($device.DeviceId)'"
    if (-not $keys) {
        Write-Warning "No recovery key for: $($device.DisplayName)"
    }
}

Devices without escrowed recovery keys must be investigated, they may be encrypted with a locally stored key or may not be encrypted at all.

Report 4: Key rotation evidence Export the Entra ID audit log filtered for "Update device" events related to BitLocker key updates. This demonstrates that key rotation is occurring per policy.

ISO 27001 A.8.24 Mapping

For ISO 27001 certification, the auditor will assess A.8.24 (Use of Cryptography). Your evidence package should include:

• Cryptographic policy: Document specifying AES-256, key rotation schedule, recovery procedures
• Technical evidence: Intune compliance reports showing comprehensive encryption across in-scope devices
• Key management evidence: Entra ID audit logs showing recovery key escrow and rotation
• Access control evidence: Custom role assignments limiting recovery key visibility

This package, extracted programmatically from Intune and Entra ID, provides the auditor with verifiable, timestamped evidence that encryption is not just a policy statement but an enforced technical control with active key management.