This blog will show you how we could still open protected data with Personal Data Encryption (PDE) even when logging in with a Password, even when Microsoft’s documentation tells us otherwise.
Introduction
Personal Data Encryption (PDE) is a security feature in Windows 11 designed to protect a user’s personal data, specifically from being accessed by anyone other than the intended user, such as other local administrators. Its purpose is to ensure that files in key user folders (Desktop, Documents, Pictures) are only accessible after the user who is the owner of the data authenticates securely using Windows Hello for Business (WHfB).
The protection is tied not just to who you are, but how you sign in. According to Microsoft, PDE content is only accessible after a WHfB sign-in, typically a PIN or biometric gesture. If you use a password or FIDO2 security key, access to those protected files should be blocked.
“If you sign in with a password or a FIDO2 security key, you can’t access Personal Data Encryption protected content.” It sounds strict. But what actually happens when you try to sign in with a password? That’s where things get interesting.
Microsoft’s Documented Behavior on PDE’s Protected Data
Microsoft’s official documentation clearly outlines the expectations around Personal Data Encryption. One of the clearest illustrations of this enforcement model is found in their feature comparison table for PDE.
As we could notice above, Microsoft’s documentation explicitly states: Protected data is accessible when signing with Windows password instead of Windows Hello for Business: No (Level 1 and Level 2)
This entry makes it clear that signing in with a password should never allow access to PDE-protected files. Whether you’re operating at Level 1 or Level 2 protection, the answer is still “No” …. password-based access is not supposed to work.
This is further reinforced both in the interface and written documentation, I showed you earlier: “If you sign in with a password or a FIDO2 security key, you can’t access Personal Data Encryption protected content.”
And when users attempt to sign in using a fallback method, the lock screen provides this warning:
“You need to sign in with Windows Hello to access files your organization has encrypted on this device. Only use the current sign-in option if you need to recover your Windows Hello PIN.”
The message is unambiguous: access is supposed to be tied to WHfB authentication. No PIN or biometric, no access.
Protected Data Test Setup
To validate whether PDE works as promised, I prepared a test environment:
- PDE policy enabled for known folders (Desktop, Documents, Pictures)
- OneDrive Known Folder Move (KFM) is active to redirect user folders
- I also performed the same test without OneDrive / Onedrive KFM active (same issue)
- Windows Hello for Business is fully configured with PIN
To confirm that the folder was indeed protected, I verified the registry values at:
HKCU\Software\Microsoft\Windows NT\CurrentVersion\EFS\PDE
Here, the protected data folders: ProtectDesktop, ProtectDocuments, and ProtectPictures were all set to 1, confirming that PDE protection was enforced for those folders.
After signing in with the PIN, I created a test file on the Desktop. The Yellow lock icon shows me that PDE indeed protects the data, but you can never be too sure.
So, I looked at the properties of the file and also ran cipher /c to confirm that the file was PDE-protected:
- Compatibility Level: Personal Data Encryption
- Protection Status: On
- File availability: Any time after signing in
At this point, everything appeared to be protected exactly as expected.
What Should Happen with the Protected Data
Based on Microsoft’s documentation, PDE protection should prevent file access to the protected data if the user does not sign in using WHfB. This means:
- Signing in with a password should block access
- Using a FIDO2 key should block access
- Access by any other user, including local administrators, should also be denied
In other words, the encryption is supposed to be tightly bound to WHfB credentials.
What Actually Happened
After signing out of my WHfB session, I signed back in using a password only. Then I opened the same test file, and it just opened? The file opened without any issue. No error message, no access denial…. Nothing… it just opened.
To confirm this wasn’t a fluke, I repeated the test using a different local admin account. This time, as expected, access was denied. That confirmed the file was encrypted and PDE was technically active.
Which means Windows still considers the file PDE-protected, yet allows access with a password sign-in.
Is This a Bug or a Design Gap?
This raises a key question: is PDE enforcing access control based on the authentication method (as documented), or merely on the user identity? From my testing, it’s clear that PDE only restricts access based on who is signed in…not how they signed in.
If you’re signed in with the same account, even using a password, PDE will still allow access to the protected data. This makes it less of a WHfB-enforced feature and more of a per-user encryption mechanism.
Whether this is an intentional design decision or an oversight is unclear. But it directly contradicts the behavior described in Microsoft’s documentation.
Video Walkthrough
To show this behavior step-by-step, I recorded a walkthrough of the test process. You can watch it here:
A Small Note: With an additional reboot instead of only logging off, I am also still able to access the protected data when logging in with a Password.And the same flow and behavior when we are not using OneDrive. We can create a new Document on the desktop which gets protected with PDE and after a reboot and signing in with a Password we can still open it.
Implications
If you’re relying on PDE to enforce strict post-logon isolation via WHfB, this behavior creates a gap in protection. Administrators expecting that password sign-ins would block access to sensitive content are in for a surprise.
This weakens PDE’s position as a WHfB enforcement tool and may give organizations a false sense of security.
Microsoft should clarify:
- Is Password fallback intended for same-user scenarios?
- Can this fallback behavior be disabled or hardened?
- Why does the documentation make a claim that the actual product behavior does not uphold?
Until these questions are answered, PDE should be viewed with caution in high-assurance environments.
Conclusion
PDE adds value by protecting files from access by other users, but its enforcement based on sign-in method is inconsistent with Microsoft’s own documentation.
As long as the user identity matches, Windows appears to allow access to PDE-protected data, even when logging in with a password. This makes PDE a user-bound protection layer, not a WHfB-enforced one.
Hopefully, Microsoft either clarifies this behavior or adds stricter enforcement mechanisms.