WN10-00-000030 (WN11-00-000030 on Windows 11) is a CAT I DISA STIG check that fails when the operating system drive or any fixed data drive is not BitLocker-protected. To fix it, back up a recovery password to AD DS or Entra ID, enable BitLocker on all drives (C: and every fixed data drive), and confirm with manage-bde -status.
What the scanner is actually detecting
This is a configuration audit, not a missing patch: it fails if any internal volume is unencrypted or unprotected.
| Scanner | Finding title | Notes |
|---|---|---|
| Tenable Nessus compliance (DISA Microsoft Windows 10 STIG audit) | WN10-00-000030 – Windows 10 information systems must use BitLocker to encrypt all disks to protect the confidentiality and integrity of all information at rest. | CAT I, Rule SV-220702, PowerShell-based check |
| Tenable Nessus compliance (DISA Microsoft Windows 11 STIG audit) | WN11-00-000030 – Windows 11 information systems must use BitLocker to encrypt all disks to protect the confidentiality and integrity of all information at rest. | CAT I, Rule SV-253259 |
| Tenable (CIS Microsoft Windows 10/11 STIG audits) | 1.6 WN10-00-000030 or 1.6 WN11-00-000030 | Same requirement, CIS packaging |
| Microsoft Defender for Endpoint (Defender Vulnerability Management) | Encrypt all BitLocker supported drives | Security recommendation for the same gap |
The STIG check text asks you to confirm that the operating system drive and any fixed data drives are protected. If Control Panel still offers “Turn on BitLocker” for any of them, it is a finding. Tenable notes that Nessus includes the target output with the result, so read the collected output rather than only the status. Removable drives are out of scope for this item.
Real-world risk
BitLocker protects data at rest. Without it, anyone with physical access to a laptop or its disk can move the drive to another machine and read files directly, bypassing Windows permissions. That covers lost and stolen laptops, drives from retired machines, and hardware sent out for repair.
It is not a remotely exploitable flaw, and BitLocker does nothing against malware or an attacker on a running, unlocked machine. TPM-only protection stops disk removal attacks, but a stolen laptop still boots to the Windows sign-in screen, which is why the STIG pairs this item with a pre-boot PIN (WN10-00-000031 and WN10-00-000032). DISA rates it CAT I; on laptops it is often the only control between a theft and a data exposure. Disk encryption is one line in a wider baseline; for servers, see our Windows Server hardening checklist.
How to confirm it on the host
From an elevated prompt:
manage-bde -statusCheck every volume except removable ones. You want Conversion Status: Fully Encrypted (or Used Space Only Encrypted), Protection Status: Protection On, and at least one key protector listed. The PowerShell equivalent:
Get-BitLockerVolume |
Select-Object MountPoint, VolumeType, VolumeStatus, EncryptionPercentage,
ProtectionStatus, EncryptionMethod, KeyProtector
Get-Volume | Where-Object DriveType -eq 'Fixed'
Get-Tpm | Select-Object TpmPresent, TpmReadyFor scripts, manage-bde -status C: -protectionaserrorlevel returns exit code 0 when the volume is protected and 1 when it is not.
Watch for a volume that reports Fully Encrypted but Protection Off. When Windows device encryption starts automatically, the drive begins with a “clear key”, equivalent to suspended BitLocker, until the recovery key is backed up and a TPM protector is created. Devices that only use local accounts can stay that way indefinitely. The key sits on the disk in the clear, so treat it as a real finding.
How to fix it
Step 1: make recovery keys land somewhere first
Without an escrowed recovery password, a routine firmware update can become lost data. In Group Policy, under Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption:
- Choose drive encryption method and cipher strength: Enabled, XTS-AES 256-bit for operating system and fixed data drives. If not configured, BitLocker uses XTS-AES 128-bit.
- Operating System Drives > Choose how BitLocker-protected operating system drives can be recovered: Enabled, with Save BitLocker recovery information to Active Directory Domain Services and Do not enable BitLocker until recovery information is stored in AD DS for operating system drives selected.
- Fixed Data Drives > Choose how BitLocker-protected fixed drives can be recovered: the same two options for fixed data drives.
Microsoft’s documentation states that recovery passwords go to Entra ID on Microsoft Entra joined devices and to both AD DS and Entra ID on hybrid joined devices.
Step 2 (domain-joined or standalone): enable with PowerShell
Group Policy configures BitLocker but does not turn it on; the Require device encryption policy exists only as a CSP. Run the following elevated, from a startup script or your software deployment tool:
# Add a recovery password and escrow it before encrypting
Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector | Out-Null
$rp = (Get-BitLockerVolume -MountPoint "C:").KeyProtector |
Where-Object KeyProtectorType -eq 'RecoveryPassword' | Select-Object -Last 1
# AD DS joined:
Backup-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $rp.KeyProtectorId
# Microsoft Entra joined (use instead of the line above):
# BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $rp.KeyProtectorId
# Encrypt the OS drive with a TPM protector
Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -TpmProtectorOut-Null keeps the recovery password out of console transcripts. Continue only if the backup succeeds. Unless you pass -SkipHardwareTest, BitLocker runs a hardware test first, so encryption may start only after a restart.
If you follow the full STIG, use a PIN instead of TPM-only. This requires Require additional authentication at startup to be Enabled with a TPM startup PIN allowed (registry: UseAdvancedStartup = 1 and UseTPMPIN = 1 under HKLMSOFTWAREPoliciesMicrosoftFVE):
$pin = Read-Host -AsSecureString -Prompt "BitLocker startup PIN"
Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -TpmAndPinProtector -Pin $pinTPM protectors generally apply only to the operating system volume. For each fixed data drive, use a recovery password and auto-unlock, which relies on the OS drive being BitLocker-protected:
Enable-BitLocker -MountPoint "D:" -EncryptionMethod XtsAes256 -RecoveryPasswordProtector | Out-Null
Enable-BitLockerAutoUnlock -MountPoint "D:"
$rp = (Get-BitLockerVolume -MountPoint "D:").KeyProtector |
Where-Object KeyProtectorType -eq 'RecoveryPassword' | Select-Object -Last 1
Backup-BitLockerKeyProtector -MountPoint "D:" -KeyProtectorId $rp.KeyProtectorIdFor machines that are already encrypted but never escrowed a key, list the protector IDs and back them up with manage-bde (the -id parameter is required; use -aadbackup for Entra ID):
manage-bde -protectors -get C:
manage-bde -protectors -adbackup C: -id '{00000000-0000-0000-0000-000000000000}'Intune: silent encryption on Entra joined devices
In the Intune admin center go to Endpoint security > Disk encryption > Create Policy, platform Windows, profile BitLocker, and set:
- Require Device Encryption: Enabled
- Allow Warning For Other Disk Encryption: Disabled
- Allow Standard User Encryption: Enabled (needed when users are not local admins)
- Under Operating System Drives, Require additional authentication at startup: Enabled, with Configure TPM startup PIN, startup key, and startup key and PIN all set to Do not allow, and Configure TPM startup set to Allow TPM or Require TPM
- Encryption method XTS-AES 256 and recovery options for OS and fixed drives, with Store recovery information in Microsoft Entra ID before enabling BitLocker set to Required
Silent encryption requires Entra joined or hybrid joined devices, TPM 1.2 or later, native UEFI, Secure Boot, and a working WinRE. It cannot use a startup PIN, so it satisfies WN10-00-000030 but not the PIN items. With the warning disabled, BitLocker proceeds even when third-party encryption is present, which Microsoft warns can cause data loss, so remove other encryption products first.
How to verify the fix and rescan
manage-bde -status
manage-bde -status -computername HOST01Every OS and fixed data volume should show Protection On and 100 percent encrypted. Encryption runs in the background, so a scan taken mid-conversion will still fail. Confirm escrow as well: in Intune under Devices > All devices > (device) > Recovery keys, or in AD by checking the computer object for msFVE-RecoveryInformation child objects:
Get-ADObject -SearchBase (Get-ADComputer HOST01).DistinguishedName `
-Filter 'objectClass -eq "msFVE-RecoveryInformation"' -Properties whenCreatedThen rerun the credentialed Nessus compliance scan with the DISA STIG audit. Defender updates its recommendation after the device next reports in.
What can break and how to roll back
- Unexpected recovery prompts after BIOS or UEFI updates, TPM clears, Secure Boot or boot order changes. Suspend protection before firmware work with Suspend-BitLocker -MountPoint “C:” -RebootCount 1; data stays encrypted and protection resumes after the restart.
- Silent encryption stalls when a security baseline enables a TPM startup PIN or key, or when WinRE or Secure Boot is missing.
- Third-party disk encryption on the same volume can leave a machine unbootable.
- Changing the cipher later requires decrypting and re-encrypting the drive, so choose XTS-AES 128 or 256 before rollout.
- Deny write access to fixed drives not protected by BitLocker, if you enable it, mounts unencrypted fixed drives read-only and users get Access denied.
To roll back a volume, run Disable-BitLocker -MountPoint “D:”, which removes protectors and decrypts. On the OS drive, clear stored auto-unlock keys first with Clear-BitLockerAutoUnlock, or the cmdlet will not proceed. Rolling back reopens the finding, so record an exception.
Common false positive reasons
- Non-persistent VDI. The STIG marks the item not applicable for virtual desktops deleted or refreshed at logoff, and for Azure Virtual Desktop with no data at rest.
- Approved third-party full disk encryption. The STIG accepts an alternate product that does full disk encryption and meets the pre-boot authentication items, but a BitLocker-based check will still flag it. Document it.
- Encryption in progress when the scan ran.
- Volumes that are not real fixed drives, such as a mounted VHD, can appear in raw output. Compare against Get-Volume.
An encrypted volume with Protection Off is not a false positive: the key is readable on disk.
FAQ
Is a TPM-only protector enough to pass WN10-00-000030?
For this item, yes: it requires encryption of all disks. The same STIG requires a pre-boot PIN in WN10-00-000031 and WN10-00-000032, so a TPM-only fleet will still fail those.
Does enabling BitLocker require downtime or a reinstall?
No. Encryption happens in place while the machine is in use. Plan for a restart for the hardware test, and use -UsedSpaceOnly to shorten conversion on new machines.
Should I use XTS-AES 128 or 256?
Microsoft recommends XTS-AES for all drives and suggests 256-bit where hardware performance allows or regulators require it. The default is 128-bit.
Why does the finding persist on a machine that shows encrypted?
Usually a fixed data drive is still unencrypted or the OS drive is suspended. Check every volume in manage-bde -status, not just C:.
Tracking this finding across many hosts
This item tends to reappear on newly imaged laptops. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners, including Nessus results uploaded as .nessus files, and merges duplicates within each scanner. Its AI can write host-specific remediation scripts that run only after human approval through its Windows agents, and per-finding retest for Nessus results confirms closure after the fix.