What exactly is the requirement?
Before writing a line of code, be clear about the goal:
- Make sure every device's key is stored in Entra ID. This is the right requirement. The key sits on the device object, access is permission-based, and every view is logged.
- Collect all keys into a file or folder. Not recommended. It creates one place holding every encryption key in the organization, usually with no real access control.
Why do some devices have no key in Entra?
- Encryption was turned on before the device was managed by Intune, or manually by the user.
- The BitLocker policy was never applied to the device.
- The reason that's easiest to miss: the device is Microsoft Entra registered.
Entra registered devices won't get the policy
The Intune BitLocker profile is meant for Entra joined or Entra hybrid joined devices. Remediations also run only on Entra joined or hybrid joined devices, so on a registered device the key won't upload, no matter how many times you run the script.
The customer had quite a few devices in this state. What we did:
- An Intune filter: we applied the script only to joined or hybrid joined devices, so it doesn't run pointlessly on devices it can't fix.
- Registered devices: we recommend removing them from management and enrolling them again properly. If it's a personal device, take it out of BitLocker management scope.
The process: measure first, then fix
- Detection script only. Deploy through Intune Remediations a script that checks whether each device has a recovery key and whether it's stored in Entra. At this stage it changes nothing; it only shows the size of the problem. Remediations require Windows Enterprise E3/E5 (included in Microsoft 365 F3/E3/E5), Windows Education A3/A5 or Windows VDA per user, and Business Premium isn't on Microsoft's list. Without one of these licenses, deliver the same script another way, for example as an Intune platform script.
- Remediation script in a test environment. The script uploads the existing key to Entra with BackupToAAD-BitLockerKeyProtector. The command saves a recovery password protector, chosen by its ID, so the script has to find that protector (or add one) first. Test it on a test device first.
- Gradual rollout. Run the remediation only on the filtered devices, and check results after a week.
- Verify. Check the Intune encryption report and the device page in Entra for the key.
Field tips
- Always a test device first. The customer asked for it too, rightly.
- An old script isn't a tested script. We reworked the script we had before deploying it.
- Check who can see keys: the device owner and the Cloud Device Administrator, Helpdesk Administrator, Intune Administrator, Security Administrator and Security Reader roles can. Keep that list short, watch views in the audit log, and consider the Entra setting that stops non-admin users from recovering the key of their own device.
More on device security settings in Intune in our Intune Security Baselines guide. A recovery key is also part of getting a device back to work quickly, which we covered in restoring a device with Windows Backup for Organizations. We set up device management end to end in our Microsoft 365 security projects.
Where do I see a device's recovery key?
In Entra ID or Intune, on the device page. In Entra, open the device and select Show Recovery Key; every view is written to the audit log (KeyManagement category).
Why doesn't the script work on some devices?
They're probably Entra registered. Re-enroll them or take them out of scope.
Can we just export every key to a file?
Technically yes, but it creates a single point of risk. Better to make sure every key is stored in Entra.
What about Macs?
On a Mac, encryption is FileVault and the recovery key is stored in Intune. We wrote about it in FileVault key rotation.
Do you have encrypted devices with no key in the cloud? We'll check it with you.
Talk to us