At Ignite 2024, Microsoft (re)introduced some exciting security features for Windows 11, including Local Administrator Protection and Windows 11 Hotpatching and Personal Data Encryption. We already wrote some stuff about two of them, so why not dive into Personal Data Encryption (PDE) next?
PDE is a shiny new Windows feature designed to protect your personal files by tying encryption directly to your user session. In this blog, we’ll explore how it works, how to set it up, and test real-world scenarios like SYSTEM and administrator access to see just how secure it really is. If you’ve ever wondered how to keep your files safe, even from elevated accounts, this is the blog for you!
Introduction
If you’ve ever been concerned about someone gaining access to your files, whether it’s another user on your device or even a local administrator, Microsoft’s Personal Data Encryption (PDE) is here to help. PDE protects your files by tying encryption directly to your user session, making them completely inaccessible to anyone else on your device, even users with admin privileges.
The core purpose of Personal Data Encryption (PDE) is to prevent other users (local administrators), from accessing a user its personal data on the device. Normally, a local administrator could access all personal user data, but with PDE, those files become inaccessible to anyone without the user’s credentials.
This blog will explain how PDE works, how to set it up, and how it performs under different conditions. We’ll test it against various scenarios and uncover some interesting details about how encryption behaves by looking at some funny DLLs
1. What Is Personal Data Encryption (PDE)?
Personal Data Encryption (PDE) is a Windows feature designed to keep your files safe from unauthorized access. It protects files by encrypting them in a way that:
- Only you can access the files while you are logged in.
- If you log out, the encryption keys are erased, and no one, including SYSTEM or other administrators, can decrypt the files.
- Windows Hello for Business is required, so signing in with your PIN, fingerprint, or facial recognition ensures the encryption keys are unlocked.
Why Is Personal Data Encryption (PDE) Different?
Unlike traditional encryption systems like Encrypting File System (EFS), PDE does not rely on certificates or recovery agents. Instead, it depends on your current user session and your Windows Hello credentials. Once you log off, the encryption keys are gone, and the files stay locked. With the files being locked, no other user (administrators) has access to it !
2. Requirements
Before using PDE, ensure the following are set up on your system:
- Windows 11: PDE is available on newer versions of Windows 11 (22h2 and up).
- Windows Hello for Business: You must use Windows Hello (PIN, fingerprint, or facial recognition) to enable encryption keys for your session.(Security keys such as Fido aren’t supported)
- Entra Joined: Devices needs to be Entra joined. Hybrid is not supported
- Folders to Protect: PDE allows encryption of the known (onedrive)folders, such as your Desktop or Documents.
- Enterprise:PDE doen’t work on Windows Pro… You will need Education or Enterprise to activate it.. Which is weird if you ask me, as it feels like a pro feature also
3. How to Set Up Personal Data Encryption Using Intune
Configuring Personal Data Encryption in Intune is pretty simple. To configure PDE, we only need to configure a new disk encryption policy.
Step 1: Create a Configuration Profile
- Open the Intune portal and go to Endpoint Security > Disk Encryption
- Create a new configuration profile and select Personal Data Encryption
Step 2: Configure the Personal Data Encryption Settings
In the configuration profile:
- Enable PDE encryption: Set the feature to Enable mode to enforce session-based personal data encryption.
- Specify the known folders to encrypt: Ensure the Pictures/Documents and Desktop folder are enabled for PDE.
Step 3: Assign and Apply
- Assign the profile to the appropriate user or device group.
- Once the policy is applied, users will see files in specified folders automatically encrypted with a lock icon.(more in this later on)
Step 4: Ensure OneDrive KFM Is Active (optional)
OneDrive isn’t a hard requirement for Personal Data Encryption, but having a backup is strongly recommended to protect against key loss. If the encryption keys are lost, access to protected files may be permanently gone. So, ensure you configured the silently move Windows Known folders to OneDrive.
4. How Personal Data Encryption Works
Let’s break down how PDE handles your files in a simple few steps before diving in and decompiling the code:
File Encryption During Creation
- When you create or save a file in a protected folder, Personal Data Encryption (PDE) immediately encrypts it.
- This process happens seamlessly in the background, requiring no manual intervention (unless you’re experimenting with it, like I do).
Session-Specific Encryption Keys
PDE ties encryption keys to your active login session.
- These keys remain in “memory” while you’re signed in and decrypt files as needed.
- When you log out, the keys are securely wiped from “memory”, leaving encrypted files inaccessible.
Windows Hello Integration
- PDE integrates with Windows Hello for Business, ensuring encryption keys are only accessible through Hello credentials, such as PIN, fingerprint, or facial recognition. Logging in via Hello loads the necessary encryption keys.
File Access and Locking
- Once you log out, your files are locked and encrypted.
- Even if another user, an administrator, or the SYSTEM account tries to access them, they remain securely protected.
Easy does it, right? Let’s check out how it looks on the device itself once it is activated
5.Checking Personal Data Encryption on Your Device
Here’s how you can confirm PDE is active on your devices:
- Logging in to the Device
- When selecting “other user” and trying to log in to the device, will prompt you that you need to sign in with Windows Hello to access files your organization has encrypted on this device.
- Desktop Icons
- Files in protected folders like Desktop or Documents will show a lock icon aka Padlock, indicating they are PDE-encrypted.
When taking a closer look at the properties of a document and asking for the Attributes (1) Encryption details (2) we can indeed spot it has been encrypted with Personal Data Encryption.
- Registry Settings
- Go to HKEY_USERS\<SID>\Software\Microsoft\Windows NT\CurrentVersion\EFS\PDE.
- You’ll see PathsProtected, which lists the folders that PDE is protecting.
More on these wonderful PDE keys later on, as they are not tamper-protected or read-only. I guess the EdpCredentials key needs more attention, so I will write an additional blog about them.
- Task Scheduler
- PDE is maintained by the PDE Conversion Maintenance Task, which does amazing things when you manually kick it off. I am going to zoom in to this later on.
6. Taking a look at a Protected File
To examine the encrypted Personal Data file, we can use the cipher tool. A single command will reveal both the compatibility level and the file’s protection status.
When the user is still logged in, it’s clear that personal data encryption is disabled. However, reviewing the file’s key details below shows that AES-256 encryption has been applied.
7. Checking the Event Logs
When your files are being protected or maybe decrypted you may want to check out the event log if you want to know what’s happening. To do so, you need to check out the EFS event log
For example, if you added some folders to PDE to encrypt, you may want to look out for EFS event 4434. As shown below it will show us that personal data encryption conversion is completed.
Besides showing some informational stuff, you may want to keep an eye out for event 4432! This one will inform you that a different user attempted to access the user personal encrypted data and was denied access!
8. PDE vs. EFS: Key Differences
Before diving into PDE further, first, a small overview of EFS vs PDE to make the difference between them a bit more clear.
| Feature | Personal Data Encryption (PDE) | Encrypting File System (EFS) |
| Encryption Key | Session-based, tied to user’s session | Certificate-based, stored permanently |
| Access Control | Only active user session can access files | Admins can decrypt with recovery keys |
| Key Lifetime | Keys are “erased” upon logoff | Keys remain until revoked manually |
| Use Case | Protecting personal files in real-time | General file-level encryption |
So EFS is not PDE, but it has some close interactions with it as we also noticed with the EFS event log
9. Real-World Testing
We tested PDE in different scenarios to understand its behavior. Why I did so? Well as I was wondering if it was possible for other local administrators to access or decrypt the data when the user was still logged on and/or logged off!
Here’s what we found:
Scenario 1: SYSTEM Account with Protected User Logged Off
Test:
- Ran cipher /c on a PDE-protected file from the SYSTEM account while the user was logged off
Result
- Output: “Key information cannot be retrieved.” And the specified file could not be decrypted
- The SYSTEM account could not access or decrypt the file because the session keys were not available in memory.
Conclusion:
- Without the user session keys, the file could not be decrypted or accessed even not from the system account when the user was not logged in.
Scenario 2: SYSTEM Account with Protected User Logged In
Test:
- Ran cipher /c on a PDE-protected file from the SYSTEM account while the user was logged in.
Result:
- The SYSTEM account successfully retrieved the key information.
- The SYSTEM account could read the file because the session keys were loaded in memory.
Conclusion:
- If the user is logged in, SYSTEM can temporarily access the file by leveraging the session’s loaded encryption keys.
Scenario 3: Local Administrator Access with Protected User Logged In
Test:
- Attempted to access and decrypt the PDE-protected file using a local administrator account while the user was logged in.
Result:
- The local administrator could not access the file.
- Decrypting the file failed, even though the user was logged in
Conclusion:
- PDE enforces strict session-based access, ensuring that only the user who encrypted the file can decrypt it. Other administrators are blocked.
Scenario 4: SYSTEM Account After Protected User Logoff
Test:
- Ran cipher /d on a PDE-protected file from the *SYSTEM account after the user logged off.
*Psexec required, which requires local Administrator privileges
Result:
- The SYSTEM account was unable to decrypt or access the file, as the PDE keys had been erased from memory.
Conclusion:
- Once the user logs off, all access is blocked—even for SYSTEM. PDE’s design ensures that encryption keys are session-bound and discarded when the user logs out.
Scenario 5: SYSTEM Decryption with Protected User Logged In
Test:
- Attempted to decrypt the PDE-protected file from the SYSTEM account while the user was logged in.
Before looking at the results, let’s look at the official MSFT documentation:
It mentions that other users on the device who aren’t owners of the content will be denied access to the file: Shall we look at the results then?
Result:
- Surprisingly, the SYSTEM account was able to decrypt the file.
- However, the cipher /c output indicated that only the original user (MMSMOARudy) should have been able to decrypt it.
- Once the user logged out, SYSTEM could no longer access or decrypt the file.
Conclusion:
- This unexpected behavior suggests that SYSTEM can sometimes leverage the active session keys to perform decryption while the user is logged in. However, this access is revoked as soon as the user logs off. So ensure you have the ASR rule in place to block PSEXEC.
Scenario 6: Sharing the Document
Test:
Sharing the document encrypted with PDE with someone else out of your organization
Result:
The encryption of the document “lives” on the device itself so people are still able to open it. Let me explain a bit more. When you are sharing the file, you are in fact sharing the file that got uploaded to SharePoint. The personal date encryption happens on the device and not on the file that is uploaded to Sharepoint.
Scenario 7: Altering and deleting the file
Test:
Trying to delete and change the file protected with personal data encryption from the additional logged in local administrator.
Result:
As shown below I could change the file name of the protected file.
Besides changing the file name, we could also delete the file.
10. Adding More Folders to Personal Data Encryption
After doing some testing, I was curious if we could add more folders to the Personal Data encryption. As always, I started reading the documentation. When looking at the official MSFT Personal Data Encryption documentation, we will notice that it mentions the fact that: we could use the personal data encryption APIs to specify which content to protect. (Level 2 PDE)
Well…. That makes sense. Looking at the Personal Data encryption code, showed me a couple of fun things. PathsinPolicy and PathsProtected.
When reading through the test, it seems that these registry keys are being used to enable personal data encryption on those selected folders. Well… let’s try it ourselves then!
Updating the PathsInpolicy registry keys inside the EFSPDE folder.
You need to add a PIPE to both of the registry values as shown below. For example I added the c:temp folder.
Please Note: You only need to change the PathsInpolicy registry value, the PathsProtected will be updated accordingly.
2. But how are we going to encrypt or ensure that PDE is aware of this folder?
As shown above, we can’t manually encrypt those files… Well, let’s first look at what the files in the c: temp folder looks like after performing my magic trick.
As shown above, the files in the c:\temp now also show the padlock and are protected. How did we kick off this encryption? Let’s find out, shall we?
11. Encrypting Files Manually with PDE
Before showing you how to do so, let’s take a look at another important note, Microsoft added to the Personal Data Encryption documentation. It mentions that once a user selects to manually decrypt a file, the user won’t be able to manually protect the file again using PDE.
Remember, I am the weird one that looks at code… and while looking at the efsutil.dll I noticed something funny.
It mentions the task scheduled folder PDE… and how it creates that maintenance schedule if necessary.
If we look closer to the schedule itself, we will notice that it will trigger the efsui.exe and the /efs /pdeconvert maintenance parameters (which are also mentioned in the code)
Let’s take a look at what happens when we have decrypted a file and kick off that schedule by looking at a YouTube video.
Exactly !!! after running the PDE maintenance task manually, those decrypted files are being encrypted on the fly!! isn’t that wonderful?
Known Issues with Personal Data Encryption
If you’re encountering error 0x80070043 when trying to launch an executable on a device with Personal Data Encryption (PDE) enabled, chances are you’ve also implemented Local Administrator Protection on that same device.
Here’s the issue: Personal Data Encryption and Local Administrator Protection don’t always play nicely together when it comes to running executables. Why? Because Local Administrator Protection relies on a virtual account for elevation, and guess what that virtual account doesn’t have access to? Exactly.
Want to know more? Read the full blog below!
Please Note: Endpoint Privilege Management will also give you the same error when trying to elevate an executable when it’s protected with Personal Data Encryption
Conclusion
Personal Data Encryption is a significant step forward in securing personal user files on Windows devices. By tying encryption to the user session and Windows Hello, PDE ensures that files remain private and secure, even in environments where multiple users or admins have access.
I had fun digging into the inner workings of PDE…. one thing is for sure! once you log off, those files are locked tighter than ever.