Microsoft BitLocker, Windows Hello for Business and Personal Data Encryption: Working Together to Protect User Data

Still using a BitLocker PIN? That’s approaching ancient history. Discover how Windows disk encryption, data encryption, and a passwordless strategy are redefining security – making access seamless and data breaches almost obsolete.

Microsoft BitLocker and Personal Data Encryption (PDE) are complementary security features in Windows 11 that work in tandem to protect sensitive data from unauthorized access. BitLocker provides full disk encryption at the device level, while PDE adds an additional layer of file-level encryption tied to strong user authentication. This report provides a detailed overview of each technology, how they integrate, the role of the PDE API for extending protection to applications, and the importance of Windows Hello for Business (WHfB) in enabling a secure, password-less sign-in experience.

Overview of Microsoft BitLocker

Introduced as a fundamental, cornerstone feature, aptly codenamed “Cornerstone,” of Windows Vista, BitLocker has been available since 2007. Although Windows Vista had its criticisms, BitLocker remains a robust tool. It is likely that you have already encountered, implemented, and benefited from it over the years. Nevertheless, let me provide a brief overview to bring you up to speed.

BitLocker is a full-volume encryption feature built into Windows that protects data at rest on a device. It encrypts entire disk volumes (such as the operating system drive or data drives) using strong encryption algorithms, rendering data inaccessible without proper hardware authentication. The primary goal of BitLocker is to mitigate the risk of data theft or exposure if a device is lost, stolen, or improperly decommissioned. Although BitLocker doesn’t require a Trusted Platform Module (TPM) to work, for the purpose of this article I will assume you have devices with TPM.

Key aspects of BitLocker include:

• Full Disk Encryption: BitLocker encrypts all data on a volume using AES encryption (commonly AES in XTS mode) so that the data cannot be read by mounting the drive on another system or running offline attacks. This ensures that if someone removes the hard drive or boots from alternate media, the stored data remains scrambled and unreadable without the decryption key.
• TPM Integration for Security: BitLocker works closely with the computer’s TPM (a secure crypto-processor) to enhance security. The TPM verifies the integrity of the boot process and will only release the decryption key if it detects the system hasn’t been tampered with. By default, BitLocker can automatically unlock the drive at boot after confirming the system’s integrity. This protects against attackers who might try to alter boot files or firmware to capture the encryption key.
• Multi-Factor Authentication (Startup PIN): For additional protection, BitLocker supports requiring a user to input a startup PIN before the OS boots. In this configuration, even if an attacker steals the device, they cannot boot and decrypt the drive without knowing the PIN. This TPM + PIN approach is a form of multi-factor authentication at boot (something you have – the TPM-bound key, and something you know – the PIN). It prevents “automatic” decryption; the correct PIN must be provided on startup, otherwise the disk stays encrypted. (More about why this isn’t necessarily a good idea later in this article)
• Data Protection for Lost Devices: Once BitLocker is enabled and the drive is encrypted, the data is safe from offline attacks. For example, if a laptop gets stolen, the thief cannot read the disk contents by connecting it to another computer or booting to an alternate OS, because the volumes remain encrypted without the BitLocker key. This protects sensitive files from exposure in common theft scenarios. BitLocker also helps securely decommission PCs; when retiring or repurposing a drive, administrators can cryptographically “wipe” access to data by deleting the keys (since encrypted data without keys is irrecoverable). The data isn’t technically removed but as the keys are removed, no one can recover the data, not even an Administrator.
• Transparent Operation: With a TPM (and no startup PIN), BitLocker can operate transparently — the user simply logs in normally and may not even realize the disk is encrypted. The decryption key release is handled by TPM if all checks pass, allowing a seamless boot. Once the OS is running and the user is authenticated, data access is normal (the encryption/decryption happens behind the scenes). Administrators can choose between convenience (TPM-only, auto-unlock) and security (TPM+PIN) based on their risk tolerance.

In summary, BitLocker’s role in data protection is to secure the entire storage volume from unauthorized access, especially when the device is powered off or in an untrusted state. It addresses threats like an attacker attempting to read data by booting to another OS or removing the drive. However, once an authorized user has booted the PC and signed in, the BitLocker-protected volume is unlocked, and at that point the data is in plaintext for legitimate use. Notice the “an authorized user” part, it doesn’t matter who logs on to the device, the volume will be available and access is governed only by file system Access Control Lists. This is where Personal Data Encryption comes in – adding encryption that persists even when the system is on and the BitLocker volume is unlocked, until the right user signs in.

Overview of Microsoft Personal Data Encryption (PDE)

Personal Data Encryption (PDE) is a Windows 11 security feature that provides file-level encryption tied to the user’s credentials. Introduced in Windows 11 version 22H2 for Enterprise and Education editions, PDE is designed to complement BitLocker by protecting individual files and ensuring they remain encrypted until and unless the rightful user signs in with Windows Hello for Business (WHfB). Here are key features and characteristics of PDE:

• File-Based Encryption Linked to User Login: Unlike BitLocker (volume encryption), PDE encrypts individual files (such as documents, pictures, emails, and other user data). The encryption keys for those files are protected by the user’s WHfB credentials (PIN or biometric). When the user signs in via WHfB, the PDE decryption keys are released from the TPM and the protected files become accessible. If the user signs out or the device locks, those keys are discarded and the files return to an encrypted, inaccessible state. This means sensitive data stays encrypted even while the machine is running but the user is not actively signed in, offering protection “under lock” or before login that BitLocker alone doesn’t cover.
• Complements BitLocker: Microsoft emphasizes that PDE is not a replacement for BitLocker but an additional layer. BitLocker still provides baseline full-disk encryption, and using both together yields better security than either alone. BitLocker protects data-at-rest (when a device is powered off or the disk is removed), whereas PDE protects data in scenarios where the device is powered on but not yet unlocked by the user. If BitLocker is enabled without PDE, once the OS boots and reaches the login screen, the disk is decrypted and an attacker with physical access might attempt to get at data (via ports or malicious tools). PDE closes that gap by keeping user files encrypted until after authenticating using WHfB. Conversely, if PDE were used without BitLocker, an attacker could still remove the drive and read sectors directly; so Microsoft recommends enabling BitLocker alongside PDE for comprehensive protection.
• WHfB Requirement: PDE requires that users sign in with Windows Hello for Business rather than a traditional password. In fact, if a user signs in with a password on a PDE-protected system, they will not get access to the encrypted files. The content stays locked because PDE specifically ties decryption to the presence of the WHfB credentials. This ensures that the added security of PDE is only active in a password-less authentication scenario. Organizations planning to use PDE must therefore deploy Windows Hello for Business for their users, eliminating password-based sign-in on those devices. (If you’re new to WHfB, we will discuss it in depth later in this article.)
• Protected Folders and Known Folders: Starting with Windows 11 version 24H2, PDE can be enabled using “Personal Data Encryption for known folders,” which automatically protects common user folders like Desktop, Documents, and Pictures. Once PDE is turned on via policy, those folders and their contents are transparently encrypted by the OS. The user sees a padlock icon on files that are PDE-protected. If someone else logs onto the machine (a different user) or if the files are viewed remotely from another OS instance, the files remain encrypted and inaccessible (even with the owning user’s credentials). Even an administrator on the device cannot read a user’s PDE-protected files without that user’s sign-in – a zero trust approach at the file level. (Notably, PDE-protected files also cannot be opened over network shares or by remote access; the user must be interactively signed in on the device to access them.)
• Encryption Strength and Levels: PDE uses AES-CBC with a 256-bit key for encrypting files. It offers two protection levels: Level 1 (L1) – “After First Unlock”: Data protected at L1 becomes available after the first successful WHfB sign-in following a reboot. Essentially, L1 covers the period from system start-up until the user first unlocks the device. Once unlocked, L1 data remains available even if the device is locked again, until the user signs out. This level is meant to protect data before login (early boot). In practice, L1 ensures that on a freshly booted device, the user’s files stay encrypted until the user signs in via WHfB. Level 2 (L2) – “While Unlocked”: Data protected at L2 is only accessible while the device is actively unlocked. The moment the device is locked (e.g. Windows lock screen due to user away or timeout), L2-protected data becomes inaccessible, and it remains encrypted until the user unlocks the device again with Hello. This provides even stricter protection, covering scenarios where the user is logged in but steps away and locks their PC. Even if an attacker gains physical access to a logged-in but locked device, L2 data would be safe. Typically, L2 protection is applied to more sensitive content that should be shielded whenever the session is not active. By default, the known folders protection uses L1 since logoff is the bigger gap, but app developers can choose L2 for certain data.

Together, these levels mean PDE can secure data both before login (boot stage) and during lock screen periods. Administrators can configure which level to use for different data via policy or choose to apply both levels as needed.

• Availability and Prerequisites: PDE is currently supported on Windows 11 Enterprise and Education editions (it’s not available on Home or standard Pro editions). The devices must be Entra ID joined or hybrid (please don’t do hybrid…) joined; traditional on-prem AD alone isn’t supported for PDE. As mentioned, Windows Hello for Business is mandatory for sign-in. These requirements mean PDE is geared towards enterprise-managed devices with modern authentication. IT admins can deploy and configure PDE via Intune by creating a Disk Encryption policy that enables Personal Data Encryption for target users or devices. Once configured, PDE runs in the background – users just continue using WHfB to sign in, and their files are protected automatically.
• Data Recovery Considerations: Because PDE encryption keys are tied to user credentials (which are stored securely in the TPM and are not recoverable like BitLocker recovery keys), losing access to those credentials can mean losing the data. For instance, if a user performs a destructive PIN reset or the TPM is reset, the PDE keys for that user are lost and any files encrypted with those keys become permanently inaccessible. Regular backups of important files (e.g. via OneDrive) are strongly recommended when using PDE. This way, if a user’s PDE keys are lost, the files can be restored from backup. Administrators are advised to educate users and have backup solutions in place, because unlike BitLocker (which has recovery mechanisms), PDE-protected files cannot be recovered without the original credentials by design.

In essence, Personal Data Encryption adds another safeguard: it keeps user data encrypted and safe not just when the device is off, but even when it is on and potentially vulnerable, up until the moment the legitimate user authenticates. This provides defense against sophisticated attacks that BitLocker alone may not stop, and it streamlines user access by leveraging the same WHfB login for both device unlock and data decryption.

Integration of BitLocker and PDE

BitLocker and Personal Data Encryption are designed to work in unison, providing “defense in depth” for data protection. Using both together addresses different stages of device use and threat scenarios, ensuring data remains secure at rest, in transit through boot, and even when a device is powered on but locked. Microsoft explicitly recommends enabling BitLocker drive encryption and Personal Data Encryption together for the most robust protection.

To understand their integration, it’s helpful to compare how each functions across the device lifecycle:

As shown above, BitLocker secures the “offline” state and early boot, whereas PDE secures the post-boot, pre-login and locked state. The combination means that from the device is resting (powered off) in your backpack, through the moment a device turns on to the moment an authorized user is logged on to it, the data is always actively encrypted by one or both of the mechanisms:

• When the device is off or just booting, BitLocker’s full disk encryption is in effect – an attacker can’t read the drive without the BitLocker key. (If configured with a startup PIN, an attacker can’t even boot the OS without that PIN.)
• When the device has booted but no user is logged in yet (or if it’s at the lock screen), PDE ensures the user’s sensitive files remain encrypted. Even though BitLocker has unlocked the drive to allow the OS to boot, the files themselves are still encrypted with keys that won’t be released until the user provides their WHfB credentials. So if an attacker tries a direct memory access attack or uses a specialty port (like Thunderbolt/PCIe) to read memory or disk data while the machine is locked, they’ll find the critical files are gibberish without the user’s PIN/biometric to release keys.
• When the user is actively signed in and working, the PDE-protected files are decrypted for that user’s access, and BitLocker is also transparently in effect (but it doesn’t impede authorized use). At this stage, normal OS security applies (file permissions, etc.). If the user locks the screen or signs out, PDE will promptly re-encrypt or lock access to those files again.

Real-world example of their synergy: Consider an attacker stealing a laptop that is powered on and logged in, or one that is on but locked. BitLocker (TPM only) would not stop the attacker from resuming the session or using hardware attacks because the disk is technically unlocked. This is where PDE shines – if the device was locked (or at the login screen), the attacker cannot access the encrypted files without the WHfB PIN or biometric. If the device is stolen while in sleep/standby, upon waking it will demand WHfB authentication for PDE-protected content, effectively similar to requiring a BitLocker PIN but at the login stage. Conversely, if the laptop was fully shut down, BitLocker’s protection would require the TPM (and possibly PIN) to unlock the disk at next boot, preventing access. Thus, between the two, the data remains protected in both scenarios: device off (BitLocker) and device on but locked (PDE).

Some specific attack vectors mitigated by using BitLocker + PDE together: sniffing the TPM bus (on systems without BitLocker PIN) or performing Direct Memory Access (DMA) attacks via ports to grab data from memory are defeated because PDE keeps user data encrypted until proper login, essentially blocking access during that vulnerable pre-login or locked state. In the past, requiring a BitLocker PIN helped protect against some of these attacks (by not auto-unlocking the disk at boot), but now PDE can handle that protection in a more user-friendly way.

Finally, using both BitLocker and PDE does mean two layers of encryption are technically applied to certain data (e.g., a file in Documents is encrypted by PDE and that encrypted file sits on a BitLocker-encrypted volume). This layered approach doesn’t hinder the user experience; it is managed by the system automatically. The performance impact is minimal on modern CPUs with hardware acceleration for AES encryption. Administrators should still enable BitLocker as the foundation, and add PDE via policy for users who need that extra security. If a user or app ever needs to work with extremely sensitive data even while logged in, they can leverage PDE’s Level 2 (through the PDE API) to keep it encrypted whenever the device is locked.

PDE API

Consider a Line of Business application that stores data across various locations on the hard drive, not adhering to Microsoft Development Guidelines. This approach makes it challenging for the OS to distinguish between application data and user data. Therefore, the application must either organize its data storage more efficiently or utilize the PDE API.

The availability of the PDE API for developers, allowing any application to take advantage of this encryption mechanism for its own data (unless it’s already stored in a well-known location covered by the default policy). The PDE API is a set of Windows Runtime APIs that let apps encrypt and decrypt content (files, folders, or even arbitrary data buffers) using the same user-bound encryption keys that Windows uses for PDE. In other words, an application can extend PDE protection beyond the default “known folders” and apply it to any data it manages – thereby ensuring that its sensitive files are only accessible when the user is signed in with WHfB.

Key capabilities of the PDE API:

• Low-Level Encryption Functions: The PDE API provides low-level functions to protect or unprotect data. Developers can encrypt files or folders by calling these functions, and the underlying system will use the user’s WHfB credentials to secure the data. The encryption keys are never directly handled by the app; Windows manages them and ties their availability to the user’s session. From a developer’s perspective, using the API is similar to calling any file encryption library, except that the key management (storage and release on unlock) is automatically linked to the user’s WHfB login.
• Two Protection Levels (L1 and L2): Apps can choose the level of protection when encrypting content via the API. The API exposes an enumeration for “UserDataAvailability” which corresponds to AfterFirstUnlock (L1) or WhileUnlocked (L2). For example, an email client could mark its local cache of emails as L1 protected (accessible after first login, remaining available while the user session is active), whereas a password manager application might protect its vault files with L2, making them accessible only while the desktop is unlocked, for maximum security. By offering both levels, the PDE API lets app developers tailor the security vs. convenience tradeoff for their specific scenario.
• Applicability to Various Data Types: The PDE API isn’t limited to files on disk. It can also encrypt in-memory content or arbitrary data buffers if needed. This means an application could even use PDE to protect data it is processing on the fly, though common usage is to protect stored data. Typical use cases include: securing application configuration files, confidential documents created by the app, cached data, or any content that should remain private to the user. For instance, a note-taking app could ensure its notes are PDE-protected files, or a finance application could protect its local database using PDE.
• Enterprise Control and Enablement: By default, applications can only use the PDE API on devices where PDE is enabled by policy. IT admins control PDE via Intune or CSP settings, and that includes enabling the API usage for apps. If a developer calls the PDE API on a system that doesn’t support PDE (for example, a non-Enterprise edition, or PDE not enabled by admin), the calls will fail gracefully. This is indicated by the API returning null or an error when trying to obtain the User Data Protection manager if the feature isn’t available. Thus, organizations can choose which users or groups have PDE (and by extension which apps can utilize it) by deploying the policy.
• Example and Tools: Microsoft has provided sample code and even a sample application to demonstrate use of the PDE API. In the sample, an app walks through selecting a folder, protecting it (and optionally all files within it), and then unprotecting as needed. The file on disk is then marked such that Windows knows it requires WHfB authentication to open in the future. The API also allows checking if a storage item is already protected and what level, etc., through provided classes.

By following the API recommendations, any application can extend PDE’s protections to its own data, meaning that even if a malicious actor gains access to the device or the raw files, without the user’s WHfB credentails, the content remains secure. This is especially useful for apps handling highly sensitive information (financial data, personal notes, corporate intellectual property, etc.) because it adds a safeguard beyond normal file permissions. Even an admin or attacker running code as SYSTEM cannot bypass PDE encryption to read another user’s protected files.

Eliminating the Need for a BitLocker PIN

One of the motivations for introducing PDE was to improve security without burdening users with additional credentials. Historically, organizations concerned about sophisticated attacks would enable a BitLocker startup PIN so that even if an attacker had physical access to a device, they couldn’t boot it and automatically decrypt the drive. This however meant users had to remember and enter a second secret (the PIN) on each boot, in addition to their Windows logon. Personal Data Encryption mitigates the same attack vectors that the BitLocker PIN was designed to address, thereby making a separate startup PIN optional or unnecessary when PDE is in use.

PDE covers the attack vectors of a BitLocker PIN: A BitLocker PIN primarily protects against an attacker who might:

• Steal a laptop and power it on, hoping it will boot to the login screen with the disk unlocked (which would happen if BitLocker is TPM-only).
• Attempt to bypass the Windows logon (for example, by using specialized hardware to read memory or by moving the drive to a machine that skips OS boot security).
• Use hardware attacks like sniffing the TPM-to-CPU communication to extract keys, or DMA attacks via ports to dump memory while the system is awaiting login.

With PDE enabled, even if an attacker does manage to boot the stolen device, the sensitive user files remain encrypted and inaccessible without the user’s PIN/biometric login. For instance, PDE specifically thwarts DMA-based “drive-by” attacks that try to access data on a locked machine – because the data is still encrypted under the hood. It also counteracts TPM bus sniffing: even if someone could tap the hardware bus, the BitLocker key that unlocked the OS at boot doesn’t grant access to PDE files; their keys won’t be released until user sign-in. Thus, PDE provides a layer of protection during the period after boot but before user authentication, much like what requiring a BitLocker PIN would achieve (preventing silent decryption).

Simplified sign-in – one credential instead of two: From the user and IT perspective, eliminating the BitLocker PIN is a usability win. With PDE, the user only needs to sign in via WHfB, and that single action both unlocks the OS and decrypts user data. In the old model without PDE, if an admin enforced a BitLocker PIN, the user had to input (1) the PIN at boot, and then (2) their password or WHfB PIN at the login screen. That’s two separate authentications. PDE allows organizations to drop the pre-boot PIN requirement because the security goals are met in another way.

It’s worth noting that some extremely security-conscious environments might still choose to use both BitLocker PIN and PDE for defense-in-depth (since these protect slightly different stages). However, many organizations will find that PDE’s protection is sufficient such that the inconvenience of a startup PIN isn’t justified. PDE ensures that until the rightful user is present, the data remains encrypted – effectively achieving the same result as “authenticating before boot” but instead “authenticating right after boot” with equivalent security. As long as an attacker cannot bypass WHfB (which is designed to be very resistant, especially with biometrics and anti-hammering), the data is safe. Therefore, deploying PDE with Windows Hello for Business is seen as a modern, user-friendly alternative to the old BitLocker PIN approach, aligning with a passwordless strategy while still mitigating cold-boot and live attack scenarios.

If you are already familiar with Windows Hello for Business and understand its functionality, you may proceed directly to the conclusion at the end of the article. However, for those who have not yet embraced a passwordless Windows experience, here is a brief overview of what you might have missed:

Windows Hello for Business (WHfB)

Windows Hello for Business is Microsoft’s password-less authentication method for Windows, using biometrics or PIN backed by cryptographic keys instead of traditional passwords. It is a cornerstone of modern Windows security and directly enables technologies like PDE. In a WHfB setup, users no longer log in with a username/password. Instead, they set up WHfB on their device (which might involve facial recognition, fingerprint, or simply a PIN code). This is not just a local convenience feature; for business environments, it links to Entra ID or Active Directory to prove the user’s identity to the organization without sending a password.

Key points about WHfB:

• Asymmetric Key Pair (Password-less Authentication): When WHfB is configured, the system generates a pair of cryptographic keys – a private key that is stored securely in the device’s TPM chip and a public key that is associated with the user’s account in Entra ID/AD or on a certificate. Authentication works by the user unlocking the private key (with a PIN or biometric) and the system using that key to authenticate to the domain or cloud – no password transmitted. In effect, Windows Hello for Business replaces the single-factor password with a two-factor cryptographic authentication: something you have (the device with the private key) and something you know or are (the PIN or your biometric). For example, when you sign into Windows or an Office 365 app with WHfB, the system uses a cryptographic challenge/response with your key, which proves your identity to the server without ever sending a secret that a hacker could intercept. This design addresses the major weaknesses of passwords (phishing, replay, server breaches) by never sharing the actual credential.
• Device-Bound Credentials: A hallmark of WHfB is that the credentials are tied to the specific device. The PIN or biometric you set up is only a method to unlock the key on that one device. If you go to a different PC, your PIN there will be different because it unlocks a different private key. This means if an attacker somehow got hold of your PIN, it’s useless to them unless they also have your device. In contrast, if an attacker steals (shoulder surfs) your password, they could potentially use it from anywhere to log into your account. With WHfB, shoulder surfing just the PIN alone will not let them into your account from another machine. This device-specific nature of the WHfB credential greatly limits the scope of damage from any credential compromise.
• Two-Factor and Tamper-Resistant: Windows Hello for Business inherently provides multi-factor auth: the private key serves as something you have (it resides in hardware on your PC), and the PIN/biometric is something you know/are. The private key is typically stored in the TPM. The TPM hardware protects the private key and will not release it without the correct PIN or biometric, and it has anti-hammering protections to prevent brute-force attempts on the PIN. If too many wrong PIN guesses occur, the TPM will lock out further attempts or even require a recovery, making brute-force impractical. The biometric options (face, fingerprint) also offer convenience with security – they are tied to the device as well and never send your fingerprint image (it’s not even your image but a hash of the image) anywhere; it’s just used locally to unlock the key. The combination of these factors means an attacker needs to both steal your physical device and break your PIN or biometric (which is very difficult thanks to TPM protections) to impersonate you. Simply tricking you into typing a password on a fake site (a common phishing tactic) won’t work, because there is no password to type – the PIN is only entered on the real/physical device and never leaves it.
• Phishing Resistance and Improved Security: WHfB is a great path to a password-less environment because it eliminates the most vulnerable link: passwords. Passwords can be reused, leaked in data breaches, captured via phishing emails or keyloggers, etc. WHfB doesn’t transmit a secret that can be phished; the PIN unlocks a cryptographic operation within the TPM. The actual authentication to online services is done with a signed challenge using your private key, which the server verifies with your public key. This means if an attacker tricked you with a fake login page, even if you entered your PIN there, it wouldn’t give them anything—they can’t use that PIN on their device to authenticate as you. Moreover, the server never stores your PIN or biometric; it only holds your public key (which is useless to attackers). Thus, even if the server’s user database is compromised, the attackers get no passwords – because none were stored – and your biometric/PIN remain safe on your device. This model of authentication is often described as “passwordless, two-factor by default, and phishing-resistant” which is exactly what modern cybersecurity guidelines recommend.
• User Experience and Adoption: From the user’s perspective, WHfB can actually be more convenient than passwords. They might use a short PIN or just look at their webcam for facial recognition – it’s quick and easy. Yet, behind the scenes, this is more secure than typing a long password. Microsoft’s push for WHfB is part of its broader passwordless initiative, which includes other solutions like FIDO2 security keys

In context of this article, Windows Hello for Business is critical because PDE relies on it and because it transforms the security model that BitLocker and PDE operate in. BitLocker with a PIN was essentially trying to bolt on a second factor to a password-based system. WHfB with PDE achieves security by design with one strong, phishing-resistant factor (well, two combined factors, but one user action). As more companies adopt WHfB, features like PDE become natural extensions of that trust: since the user has a trusted key on the device, we can encrypt their data knowing it will be safe until that key is unlocked by them.

To summarize, Windows Hello for Business enables a passwordless Windows environment by using device-bound keys and PIN/biometrics, offering stronger security than traditional passwords. It’s the foundation that allows features like PDE to function and removes the need for things like BitLocker PINs. Users get a fast, easy login experience, and organizations get assurance that a stolen password won’t cause a breach.

Bonus section because you read all the way to here: In the next section, we will delve deeper into the often-asked question: Why is a Windows Hello PIN considered more secure than a password, even though both might look like a “string of characters”?

WHfB PIN vs. Password – Why the PIN is More Secure

At first glance, a Windows Hello PIN might seem similar to a password – after all, both are secrets a user remembers and types in. It’s common for people to question: “If a PIN is usually digits and shorter than a password, how can it be more secure?” The answer lies in the context and implementation. A WHfB PIN is fundamentally different from a password in how and where it works, making it more secure despite potentially being shorter or simpler. Let’s break down the differences and dispel a few misconceptions:

• Local Device Scope vs. Global Scope: A password is typically a universal credential – for example, your Entra ID password can be used on any device to sign in to that account. If a bad actor obtains your password, they can potentially use it from anywhere on the internet to access your account. A WHfB PIN, by contrast, is local to one device. It unlocks the key on that specific machine’s TPM. If someone somehow learned your PIN, it would be useless to them unless they had your physical device. They can’t go to another computer and use that PIN to log in as you, because the PIN isn’t the actual authenticator – it’s just unlocking the actual secret (private key) which never leaves your machine. This device-tied nature means the impact of a PIN compromise is far more limited than a password compromise.
• Never Transmitted Over Network: When you enter a username and password to log into a service, that password (in some form) goes over the network to be verified (hopefully encrypted in transit, but nonetheless it leaves your machine). There are multiple points where it could be intercepted or stolen – malware on your machine could grab it as you type, a phishing site could trick you into sending it to an attacker, or a breach on the server side could leak a database of (hashed) passwords. With WHfB PIN, the PIN is never sent to a server or anywhere else – it is only used locally to verify with the TPM and unlock your credential. The authentication to the server is then done with a key or token. This means there’s no opportunity for an attacker to phish your PIN by posing as a website or service, because the PIN is not something you ever enter into a website or remote login prompt. Even malware that logs keystrokes won’t directly grant access to online accounts, because capturing the PIN alone doesn’t bypass WHfB security without the TPM. In summary, passwords are vulnerable to theft during transmission and in storage; PINs are not transmitted or stored on servers, removing those attack vectors.
• Backed by Secure Hardware (TPM): A PIN on WHfB is backed by the device’s TPM module. The TPM ensures that guessing attacks against the PIN are thwarted – if multiple wrong PIN attempts are made, the TPM will invoke anti-hammering logic to delay or lock out, making brute force impractical. Additionally, the TPM releases the key only when presented with the correct PIN (or biometric) using a secure check that cannot be bypassed via software. A password, on the other hand, typically relies on the server to rate-limit or lockout on wrong attempts, and if stolen hash databases are involved, attackers can try millions of guesses offline without any device to stop them. So a PIN is considered stronger than a local password because the TPM hardware is actively defending it. If someone steals your device, they can’t extract the PIN from the TPM; and they can’t brute force it either before the TPM locks them out. The TPM effectively transforms even a short PIN into a strong credential by limiting attempts and protecting the secret key inside it.
• It’s Not Just a PIN – It Unlocks an Asymmetric Key: When we say “PIN vs. password” it’s important to realize the WHfB PIN is not the sole factor protecting your login. The real authentication is done by the cryptographic key pair. The PIN is just one element of a multi-factor design (device + PIN) and is an “unlock key” for the TPM-held private key. In contrast, a password is the primary secret that verifies your identity in a single factor scenario. With WHfB, even knowing the PIN isn’t enough for an attacker – they’d need the TPM (device) and the PIN. And if the device is compromised at hardware level, the TPM will lock after a few attempts, so it’s not like an attacker can just try all 10,000 possible 4-digit PINs easily; the TPM will stop them long before that (typically after a handful of wrong guesses, there’s a significant delay or required reset). The strength of WHfB PIN should not be measured purely by its length or complexity like a password, because the security comes from the architecture (TPM + key) not just the secret entropy. As a proof point: even a 6-digit PIN (1 million combinations) in a TPM is far more secure against cracking than a 8-character password (which has trillions of combos) stored on a server, because the latter could be attacked offline with unlimited guesses if stolen, whereas the former cannot.
• No Server-Side Store of Secrets: When using WHfB, there’s no server database with your PIN or biometric that could be leaked. The server only holds a public key, which is useless for impersonation. In contrast, password systems have to store either the password or a hash of it on a server. If that server is breached, attackers might obtain hashes and run brute-force to recover passwords (which is typically what happens in breaches reported in the trade press). With WHfB, even if an attacker breached Entra ID, your actual login secrets (your private key and PIN) aren’t there to steal. They’d have to compromise your device individually.

Addressing common misconception: “A PIN is just a short password, so it must be less secure.” – By now it’s clear that’s not true due to the reasons above. To put it succinctly: a PIN is different from a password because of how it’s used and confined. An online password is a single factor that, if compromised, can be reused anywhere; a PIN is one factor in a multi-factor system and is useless outside its native device. Additionally, organizations can require complex PINs (they’re not limited to 4 digits; they can be longer and include letters if policy requires), but in most cases, they don’t need to be as complex as passwords because of the aforementioned protections.

Another misconception is thinking “Well, if someone steals my laptop, they could somehow extract the PIN or the key.” In practice, to compromise a WHfB credential on a stolen device, an attacker would need to overcome multiple hurdles: steal the physical device, bypass hardware protections (possibly needing to decapsulate the TPM chip or exploit a flaw in it, which is highly sophisticated), or successfully spoof a biometric, and do all this before the TPM locks up from failed attempts. This is a much higher bar than stealing a sticky note with a password or tricking someone into divulging it.

In summary, the Windows Hello PIN is more secure than a traditional password because it is bound to dedicated hardware, never travels over the network, cannot be used on other devices, and serves as part of a multi-factor authentication scheme rather than the sole secret. On the surface they’re both “a string you type,” but their context is entirely different. The PIN’s simplicity is deceiving; behind it is a robust framework of TPM-backed encryption and device-specific keys. This is why moving to Windows Hello for Business, which utilizes the PIN as one element (ideally you never use your PIN, you show your face or finger!), is recommended for organizations: it both improves user experience (no more complex passwords to remember or rotate) and significantly boosts security (resistant to phishing, replay, and many forms of credential theft).

Conclusion

By combining BitLocker and Personal Data Encryption, and leveraging Windows Hello for Business, Windows provides a comprehensive security model that protects data at all times. BitLocker secures the data on disk when a device is lost or turned off, PDE secures user files during runtime whenever the user isn’t authenticated, and Windows Hello for Business secures the authentication process itself by eliminating passwords and using device-bound keys. For technical professionals, the integration of these technologies means you can achieve strong data protection without sacrificing usability: users sign in with a convenient PIN or biometric, and behind the scenes their device is fully encrypted and their sensitive files are doubly protected until that sign-in occurs. The PDE API further extends these benefits to proprietary application data, making the protection ecosystem extensible. Adopting Windows Hello for Business paves the way for a password-less environment where old risks like stolen passwords or required boot PINs are replaced with modern, hardware-backed security. Together, BitLocker + PDE + WHfB address threats comprehensively – from stolen device scenarios to sophisticated hardware attacks – ensuring that user data remains safe and only accessible to the rightful owner in any situation.