What this check looks at
Checks whether people can read the BitLocker recovery keys of devices they own from their account page.
When a Windows device encrypts its disk with BitLocker, the recovery key is backed up to Microsoft Entra ID. By default the device’s owner can read that key themselves by signing in to their account page (https://myaccount.microsoft.com, Devices) with their work account. The setting Restrict users from recovering the BitLocker key(s) for their owned devices turns that off.
The check reads the default user permissions in the tenant’s authorisation policy. It fails when people can read the BitLocker keys of their own devices and passes when they cannot, so recovery goes through the service desk.
BitLocker protects the data on a lost or stolen laptop because the thief cannot read the disk; the recovery key undoes that protection. If the key can be read with nothing more than the owner’s account, an attacker who has phished that account and stolen or found the laptop can recover everything on it, and an insider can do the same with a colleague’s device and password.
Why it matters
A BitLocker recovery key unlocks the whole disk. If a stolen password is enough to read it, a stolen laptop and a phished password together give up everything on the device. Recovery through the service desk keeps a check in place.
Consider a laptop stolen from a car, belonging to someone whose password was reused on a breached site. With self-service key recovery, a thief who buys the password can unlock the disk and read cached email, OneDrive files and saved browser passwords. Without it, the disk stays encrypted and the loss is a hardware cost rather than a data breach.
Under UK GDPR, losing a device whose data is encrypted, with the key kept safe, is usually not a reportable breach; losing one whose key anyone with the user’s password can read may well be. Routing recovery through the service desk adds an identity check, and the occasional recovery call takes a few minutes.
The CIS Microsoft 365 Foundations Benchmark (5.1.4.6) asks for users to be stopped from recovering their own BitLocker keys, and NCSC device security guidance treats disk encryption with properly protected recovery keys as a baseline for laptops. The rule maps to NIST CSF 2.0 PR.DS-01.
How to fix it
Where: Entra admin centre → Devices → Device settings
Before you start
- Make sure the service desk can read recovery keys (Helpdesk or Cloud Device Administrator role) and knows the process for a locked-out laptop.
Step by step
- Make sure the service desk can recover keys. Check the support team holds a role that can read BitLocker keys, such as Helpdesk Administrator, Cloud Device Administrator or Intune Administrator, and has a written process: verify the caller’s identity, find the device in Entra ID > Devices > All devices, show its BitLocker keys, and read out only the key whose ID matches the one on the person’s screen.
- Change the setting. In the Microsoft Entra admin centre, go to Entra ID > Devices > Device settings. Under Other settings, set Restrict users from recovering the BitLocker key(s) for their owned devices to Yes and select Save.
- Or make the change in PowerShell. In Microsoft Graph PowerShell: Connect-MgGraph -Scopes Policy.ReadWrite.Authorization, then Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions @{ AllowedToReadBitlockerKeysForOwnedDevice = $false }.
- Tell staff. Tell staff that if their laptop asks for a BitLocker recovery key, they should call the service desk, which will check who they are before giving the key.
- Confirm. Reload Device settings and check the option shows Yes. Signed in as an ordinary test user at https://myaccount.microsoft.com, the Devices page should no longer offer BitLocker keys. Re-run the assessment to confirm.
What users will notice
People can no longer read the BitLocker recovery key for their own device from their account page; they call the service desk instead.
How to confirm it worked
Entra admin centre, Devices, Device settings: "Restrict users from recovering the BitLocker key(s) for their owned devices" is Yes.
Frameworks and controls
This check maps to controls in 13 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | B3.d Mobile data |
| DSPT | Standard 9: IT protection |
| NIS2 | Art. 21(2)(h) Cryptography and encryption |
| Microsoft Cloud Security Benchmark | DP-4 Enable data at rest encryption by default |
| Zero Trust | EndpointsData |
| SOC 2 | CC6.1 Logical access security software, infrastructure and architectures |
| NIST SP 800-171 | 3.13.16 Protect the confidentiality of CUI at rest |
| CMMC Level 2 | SC.L2-3.13.16 Data at Rest |
| ISO 27001:2022 | A.8.24 Use of cryptographyA.5.17 Authentication information |
| CIS M365 | 5.1.4.6 Ensure users are restricted from recovering BitLocker keys |
| CIS Controls v8.1 | 3.6 Encrypt data on end-user devices (IG1) |
| NIST CSF 2.0 | PR.DS-01: The confidentiality, integrity, and availability of data-at-rest are protected |
| NCSC 10 Steps | Data security |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Device settings (Microsoft Learn)