Adversary-in-the-middle phishing has made one attack depressingly routine: steal a user's session token, replay it from your own infrastructure, and you're inside their mailbox without ever touching their password or their MFA. Bearer tokens are the soft underbelly — whoever holds the token is the user, as far as the resource is concerned.
Token protection is Microsoft's answer to that. The promise is simple to state and worth understanding precisely: a token becomes useless the moment it leaves the device it was issued to. This piece walks the whole mechanism — key generation, hardware sealing, the signing model, the session lifecycle — and clears up the specific points that trip people up, because most explanations skate over exactly the parts that matter.
01It starts at device registration
Two key pairs are born, and only half of each ever leaves the chip.
When a Windows device is Entra-joined or hybrid-joined, a background task generates its cryptographic identity. Two RSA 2048-bit key pairs are created, both rooted in the device's Trusted Platform Module (TPM):
The device key (dkpriv / dkpub) is the device's identity credential — it proves "I am this registered machine." The transport key (tkpriv / tkpub) has a narrower job: it exists so Entra can later hand back a secret that only this device can unwrap.
The split is the whole point. Each pair has a private half that is generated as non-exportable inside the TPM and a public half that is sent to Entra. The private keys never leave the silicon — not to the operating system, not across the network, not ever. The public keys are written to the device object in Entra (a common misconception is that they live on the user's profile — they don't; the binding is to the device, which is why one user across five machines has five separate device objects).
02Signing is not encryption
The single most common mix-up — and the one that makes everything else click once it's fixed.
People reach for the word "encrypt" here, and it sends the whole mental model sideways. Encryption and signing are different operations with opposite key directions:
Encryption is about secrecy. You encrypt with a public key and decrypt with a private key — anyone can lock a message, only the key-holder can open it. Signing is about proof of origin. You sign with a private key and verify with a public key — the contents aren't hidden at all; the signature just proves who produced it and that nothing was altered.
Token protection uses signing. There is no step where anything is "decrypted with the public key" — that operation doesn't exist. When a request reaches Entra, it doesn't unlock anything. It runs a verification check: given the request, the signature, and the public key, it confirms mathematically that only the holder of the matching private key could have produced that signature. The request was readable the entire time. The signature is a tamper-proof seal, not a lock.
The wax-seal model
A signet ring pressed into wax leaves an impression. The letter travels with the impression — the ring stays in your pocket. Anyone can confirm "only that ring could have made this mark," but you can't reconstruct the ring from the wax. Signing works the same way: the private key stamps the request and stays home; only the stamp travels.
03The daily flow: one key to bootstrap, another to run
What actually signs each request changes after login — and almost every summary gets this wrong.
When the user signs in, Entra issues a Primary Refresh Token (PRT) — a long-lived credential that powers single sign-on across Microsoft 365. Alongside the PRT, Entra sends down a session key: a proof-of-possession key, encrypted with tkpub so that only the TPM's tkpriv can unwrap it. (That step is genuine public-key encryption — the one place it appears.)
Now watch which key does the signing:
At that first sign-in, the device proves itself by signing with the asymmetric device key, dkpriv. But from then on, every ongoing token request is signed with the session key — not dkpriv. When Outlook wants an Exchange token, when Teams starts, when a short-lived access token expires an hour later and needs refreshing, the device presents its existing PRT and signs the request with its existing session key. dkpriv did its one job at login and isn't touched again.
Those access tokens are deliberately short-lived (around an hour). When one expires, the device does not get a new session key — it gets a new access token, produced by signing a refresh request with the same session key. The session key is the pen; the access token is the ticket. You use the same pen to sign for a new ticket; you don't get a new pen each time.
The session key only changes when the PRT itself rolls over — a longer lifecycle (on the order of two weeks, continuously renewed as the device stays in use). And that renewal is usually silent: Windows refreshes the PRT in the background using the still-sealed device key. Full interactive reauthentication is pulled in only when a policy demands it — a Conditional Access MFA requirement, a sign-in frequency limit, a risk detection, or the device having been offline long enough for the PRT to lapse.
04Why the replay dies
Everything above exists to make one specific attack fail.
With token protection enforced as a Conditional Access control, possessing the token is no longer sufficient. On each access to a protected resource, the client must also prove the session is still bound to its device — by producing a request signed with the session key. That's the trap the attacker can't escape:
05The confusions, laid out
Every one of these is a natural place to go wrong. Here's the correction.
The public key is stored on the user's profile.
It's on the device object. The binding is to the machine, not the person — one user across N devices means N device objects.
Entra sends the public key to the TPM to validate the request.
Keys never travel to meet each other. Signing is local to the device; verification is local to Entra. Only the signed request and the token cross the wire.
The request is encrypted with the private key, then decrypted with the public key.
It's signed, not encrypted. "Decrypt with a public key" isn't a real operation. Entra verifies a signature; nothing is unlocked.
Signing sends the private key to Entra.
Only the signature travels — a value the key computed. You can't recover the key from it. The private key is non-exportable and stays in the TPM.
dkpriv signs every token request.
dkpriv signs once at login to bootstrap the PRT. Every request after that is signed by the session key.
Each token refresh issues a new session key, and a new PRT means the user logs in again.
A refresh yields a new access token, same session key. PRT rollover brings a new session key but is usually a silent background renewal — interactive reauth only when policy forces it.
06Caveats worth carrying
Where the guarantee holds, and where it doesn't.
The TPM protects keys at rest, not in memory at runtime
Token protection defeats remote token replay cleanly. But once the OS derives the signing key and loads it into LSASS memory, a hands-on-keyboard attacker with local admin (à la Mimikatz) can read the derived key — the TPM doesn't guard live process memory. This is a different threat model, which is why Microsoft frames token protection as one layer of defense-in-depth, not a standalone control.
Hardware binding is the preferred path, not a guarantee
On a device with a broken, disabled, or absent TPM, registration can fall back to a software-protected key — same key names, no silicon seal, materially weaker. Confirming that eligible devices actually hold TPM-backed keys is part of scoping any enforcement rollout.
Scope is narrower than "everywhere"
It's a session control on resources like Exchange Online, SharePoint, Teams, Azure Virtual Desktop and Windows 365, and applies to Windows 10/11 (and Server 2019+) devices that are Entra joined, hybrid joined, or registered — because only those can issue a device-bound PRT. Browser sessions and other platforms have historically been out of scope, with coverage expanding over time. Check current support before you enforce.
The one-line model
The private key signs and stays home; the public key verifies and stays at Entra. Nothing crosses the wire but the signed request and the token — which is exactly why a stolen token can't be reused on a machine that doesn't hold the seal.
Sources & further reading
- How device registration works — Microsoft Learndevice key / transport key generation, DRS flow
- Understanding the Primary Refresh Token (PRT) — Microsoft LearnPRT issuance, session key, proof-of-possession
- Conditional Access: token protection — Microsoft Learnthe enforcement control and its scope
- TPM fundamentals — Microsoft Learnstorage root key, wrapping, the Platform Crypto Provider KSP
- Proof-of-possession (PoP) tokens — Microsoft LearnRFC 7800 model, dual signatures, nonce