What Is BitLocker Network Unlock?

BitLocker Drive Encryption protects data on Windows machines by encrypting the OS volume. By default, when a machine with BitLocker enabled and a TPM+PIN protector boots, it stops and waits for the user to enter a PIN before the OS loads. In large enterprise environments with hundreds or thousands of workstations, this creates a significant operational burden — remote reboots, automated patch cycles, and overnight maintenance windows all get blocked waiting for manual PIN entry at physical consoles.

BitLocker Network Unlock solves this problem. When a managed domain machine boots while connected to the corporate network, Network Unlock automatically provides the BitLocker key over the network, allowing the OS to boot without any user interaction. If the machine is off-network — for example, a laptop taken home — the normal TPM+PIN or TPM+password fallback applies, maintaining security. This gives you the best of both worlds: frictionless automated reboots on the corporate LAN, and full protection outside it.

Network Unlock works by leveraging the UEFI DHCP boot process. During pre-OS startup, the machine’s UEFI network stack sends a special DHCP request containing an encrypted session key. A WDS (Windows Deployment Services) server on the network processes this request and returns the BitLocker unlock key material, encrypted with the machine’s Network Unlock certificate. The TPM decrypts the session key, then uses it to unseal the BitLocker volume master key.

Requirements for BitLocker Network Unlock

Before configuring Network Unlock, verify the following prerequisites are met across your environment:

Client machines: UEFI firmware (not legacy BIOS), TPM 1.2 or 2.0 chip, UEFI network stack capable of DHCP (most enterprise hardware from 2012 onwards qualifies), and Windows 8/Windows Server 2012 or later. The UEFI must support IPv4 PXE boot capability, even if you do not actually PXE-boot the machines.

Server infrastructure: A Windows Server 2022 (or 2019/2016) server running Windows Deployment Services (WDS). The WDS server does not need to be actively deploying operating systems — it just needs the WDS role installed and the Network Unlock provider configured. A DHCP server must be accessible on the same subnet, or a DHCP relay agent must forward requests to a DHCP server. Active Directory domain membership is required for Group Policy delivery of the Network Unlock certificate.

BitLocker protectors: The client drive must have both a TPM protector and a Network Unlock protector. The Network Unlock protector is added automatically when Group Policy deploys the certificate and the machine successfully contacts the WDS server during a boot cycle. A TPM+PIN or TPM+StartupKey protector must also exist as a fallback.

Generating the Network Unlock Certificate

Network Unlock requires an X.509 certificate with a 2048-bit (or larger) RSA key and the Key Encipherment extended key usage. You can use your enterprise CA or generate a self-signed certificate. The recommended approach in a domain is to use an enterprise CA so that revocation is managed centrally.

To create a self-signed certificate for testing on your WDS server:

$cert = New-SelfSignedCertificate `
    -Subject "CN=BitLocker Network Unlock CA" `
    -CertStoreLocation "Cert:LocalMachineMy" `
    -KeyUsage KeyEncipherment `
    -KeyLength 2048 `
    -KeyExportPolicy Exportable `
    -NotAfter (Get-Date).AddYears(10)

$cert.Thumbprint

Export the certificate with its private key for import into WDS, and export the public certificate separately for GPO deployment to clients:

# Export with private key (for WDS server)
$pwd = ConvertTo-SecureString -String "YourExportPassword123!" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath "C:BitLockerNetworkUnlock.pfx" -Password $pwd

# Export public cert only (for GPO)
Export-Certificate -Cert $cert -FilePath "C:BitLockerNetworkUnlock.cer" -Type CERT

If you are using an enterprise CA, create a custom certificate template with Key Encipherment usage and the OID 1.3.6.1.4.1.311.67.1.1 for the BitLocker Network Unlock Application Policy. Enroll the WDS server against this template.

Deploying the Certificate via Group Policy

The public portion of the Network Unlock certificate must be deployed to all BitLocker-protected client machines via Group Policy so that their UEFI can encrypt the session key against it.

Open Group Policy Management Console (gpmc.msc) and edit the appropriate GPO (typically the one that also configures BitLocker settings, applied to the OU containing your managed workstations). Navigate to:

Computer Configuration
  > Windows Settings
    > Security Settings
      > Public Key Policies
        > BitLocker Drive Encryption Network Unlock Certificate

Right-click the BitLocker Drive Encryption Network Unlock Certificate store and choose Add Certificate. Browse to and import the BitLockerNetworkUnlock.cer file you exported earlier. The certificate will appear in the store. After the next Group Policy refresh on client machines (gpupdate /force), the certificate is present in their local machine certificate store under the BitLocker Network Unlock Certificate folder.

Verify the certificate landed on a client:

Get-ChildItem -Path "Cert:LocalMachineFVE" | Format-List Subject, Thumbprint, NotAfter

The certificate store Cert:LocalMachineFVE is the dedicated BitLocker FVE (Full Volume Encryption) store where Network Unlock certificates reside.

Configuring WDS for Network Unlock

Install WDS on your server if not already installed:

Install-WindowsFeature -Name WDS -IncludeManagementTools

Initialize WDS. If you are not using WDS for OS deployment, configure it in standalone mode pointing to a local folder:

wdsutil /initialize-server /remInst:"C:RemoteInstall" /standalone

Now import the Network Unlock certificate (with private key) into the WDS server’s certificate store:

$pwd = ConvertTo-SecureString -String "YourExportPassword123!" -Force -AsPlainText
Import-PfxCertificate -FilePath "C:BitLockerNetworkUnlock.pfx" `
    -CertStoreLocation "Cert:LocalMachineFVE" `
    -Password $pwd

Enable the Network Unlock feature in WDS using the wdsutil command:

wdsutil /Set-Server /EnableBitlockerNetworkUnlock:Yes

Verify the WDS Network Unlock provider is registered and active:

wdsutil /Get-Server /Show:Config | Select-String "Bitlocker"

Restart the WDS service to apply changes:

Restart-Service WDSServer

The WDS server listens on UDP port 4011 for Network Unlock DHCP requests. Ensure your firewall allows this traffic from the client subnets. If clients are on a different subnet than the WDS server, configure your DHCP relay agent (IP helper) to also forward UDP 4011 traffic, or use a dedicated Network Unlock subnet with the WDS server directly reachable.

On the DHCP server, no special scopes are needed for Network Unlock itself. The standard DHCP lease process is used; Network Unlock piggybacks on the DHCP discover/offer exchange with vendor-specific option 250 in the response.

Enabling Network Unlock Protector on Clients

Once the GPO certificate is deployed and WDS is configured, the Network Unlock protector is added automatically on the next boot when the machine is on-network and BitLocker is already active with a TPM protector. You can also add it manually:

# Check current BitLocker protectors
manage-bde -protectors -get C:

# Add Network Unlock protector manually if needed
manage-bde -protectors -add C: -NetworkUnlock

After the next successful Network Unlock boot, verify the protector is present:

Get-BitLockerVolume -MountPoint "C:" | Select-Object -ExpandProperty KeyProtector | 
    Where-Object { $_.KeyProtectorType -eq "NetworkUnlock" }

Testing Network Unlock

To test Network Unlock, reboot a client machine while it is connected to the corporate network on the same subnet (or properly relay-forwarded subnet) as the WDS server. The machine should boot completely into Windows without prompting for a PIN or password.

Monitor the WDS event log on the server during the boot attempt:

Get-WinEvent -LogName "Microsoft-Windows-Deployment-Services-Diagnostics/Debug" -MaxEvents 50 |
    Where-Object { $_.Message -like "*NetworkUnlock*" -or $_.Message -like "*BitLocker*" } |
    Format-List TimeCreated, Message

On the client, after a successful Network Unlock boot, check the System event log for BitLocker events:

Get-WinEvent -LogName System | 
    Where-Object { $_.ProviderName -like "*BitLocker*" } |
    Select-Object -First 10 TimeCreated, Message

Event ID 24577 in the Microsoft-Windows-BitLocker log indicates successful volume unlock. If Network Unlock was specifically used, you will see the Network Unlock key protector referenced.

Troubleshooting Network Unlock Failures

Machine prompts for PIN instead of unlocking automatically: This indicates Network Unlock did not complete. The most common causes are: the machine’s UEFI does not support IPv4 PXE stack, DHCP/UDP 4011 traffic is not reaching the WDS server, the certificate in Cert:LocalMachineFVE on the WDS server does not have its private key, or the GPO certificate has not yet propagated to the client. Check connectivity from the affected subnet to the WDS server on UDP 4011 using a packet capture during boot.

WDS service fails to start: Verify the Network Unlock certificate private key permissions. The WDS service account (Network Service) needs read access to the private key:

$cert = Get-ChildItem "Cert:LocalMachineFVE" | Where-Object { $_.Subject -like "*NetworkUnlock*" }
$keyPath = ($cert.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName)
icacls "$env:ProgramDataMicrosoftCryptoRSAMachineKeys$keyPath" /grant "NETWORK SERVICE:(R)"

Certificate mismatch: The thumbprint of the certificate in the GPO must exactly match the certificate with the private key in the WDS server’s FVE store. Export both and compare thumbprints:

# On WDS server
Get-ChildItem "Cert:LocalMachineFVE" | Format-List Subject, Thumbprint, HasPrivateKey

UEFI secure boot and PXE: Some UEFI configurations require Secure Boot to be enabled for Network Unlock to work. Others require it disabled for PXE. Test with Secure Boot both enabled and disabled to identify your hardware’s requirements.

Network Unlock not working after certificate renewal: When you renew the Network Unlock certificate, you must update the GPO with the new public certificate, re-import the new PFX on the WDS server, and wait for GPO to propagate. Old Network Unlock protectors on clients referencing the old certificate thumbprint will stop working on the next boot after GPO updates. Use manage-bde -protectors -get C: to confirm the new protector thumbprint matches.

Fallback to TPM+PIN

If Network Unlock fails for any reason (machine is off-network, WDS is unreachable, certificate expired), BitLocker automatically falls back to the next available protector in the protector list. For laptops and mobile devices, this is typically TPM+PIN. Ensure a TPM+PIN protector is always present alongside the Network Unlock protector:

# Verify protector types present
manage-bde -protectors -get C:

# Add TPM+PIN if missing (prompts for PIN)
manage-bde -protectors -add C: -TPMAndPIN

For server machines that should never require manual PIN input (even off-network), consider using a recovery key escrowed to Active Directory via BitLocker MBAM or the built-in AD escrow policy. Configure AD escrow via GPO at:

Computer Configuration > Administrative Templates > Windows Components > 
BitLocker Drive Encryption > Operating System Drives > 
"Choose how BitLocker-protected operating system drives can be recovered"

Enable the option to store recovery passwords in AD DS and require AD DS backup before BitLocker is enabled. This ensures that if Network Unlock fails and no one is available to enter a PIN, the recovery key can be retrieved from Active Directory to complete the boot.