Many are questioning why keys are saved in the clear ahead of sign-in
Microsoft’s design choices when it comes to the management of BitLocker encryption keys have been questioned online.
This month, a Twitter and StackOverflow debate has been taking place over how BitLocker encryption keys are stored before users sign in with a Microsoft account.
In a Twitter thread started by user @atomicthumbs, the question was why, when an installation of Microsoft Windows 11 with a local account takes place, the drive will still be encrypted with BitLocker – “but it keeps the key on the drive... in clear text... until you sign in with a Microsoft account”.
Consultant and software developer Stephen Schmidt chimed in with his opinion on why keys are stored in this way.
According to Schmidt, while there is a “small amount of exposure”, you would still need access to take advantage of this step in the process – so, in theory, you could simply swipe the data stored on a target machine.
When a Microsoft account is used, a recovery key is then uploaded to the account in the cloud. As explained by the developer, if only a local account is used, then “there is no place to store the recovery key”.
The feature is not new and was introduced by design and existed before Windows 11.
Windows machines can only enable BitLocker if they contain a Trusted Platform Module (TMP) and UEFI Secure Boot, Platform Secure Boot, and Direct memory access (DMA) protection are enabled.
BitLocker encryption begins out of the box, but protection is suspended until a machine is linked to a Microsoft account or an Azure Active Directory account. Microsoft has ensured this is the case to prevent data loss caused by hardware problems.
Once a user signs in, a recovery password is generated and uploaded to their cloud account which can be used in the event of hardware failure.
“BitLocker automatic device encryption is not enabled with local accounts, in which case BitLocker can be manually enabled using the BitLocker Control Panel,” Microsoft says.