Passkeys to PRT: The Next Evolution in Authentication

Jonas Bøgvad
Jonas Bøgvad

Table of Contents

Over the past few weeks, I’ve had a lot of conversations about how different platforms handle authentication, security, and token management in the Microsoft Entra ID ecosystem. It’s a complex topic with many moving parts, so I created a four-part comparative guide to make it easier to explain and understand.

The framework looks at:

  1. Platform Security Foundation - The OS and hardware features that protect credentials and ensure system integrity.
  2. Entra ID Integration - How the device connects to Microsoft Entra ID and receives trust.
  3. Authentication - The ways users sign in and how tokens are bound to devices.
  4. Session Management - How tokens are stored, refreshed, and used for single sign-on, including Proof-of-Possession.

By mapping each platform across these four areas, the discussion becomes clearer, more structured, and much easier to follow.

Let's begin

If you're an IT architect or security admin managing a mix of Windows, macOS, and mobile devices in a Microsoft ecosystem, you've probably felt it: the dizzying confusion of modern authentication.

I have asked the questions:

  • "What's the real difference between a Passkey and a Primary Refresh Token (PRT)?"
  • "Microsoft supports the FIDO2 standard, so why don't iCloud Keychain passkeys 'just work' with Entra ID?"

The documentation can feel like a labyrinth, with one page seemingly contradicting another. After a deep dive of questioning, research, and validation, I'm here to give you the map. This isn't just theory, this is a validated framework you can use to build your security strategy.

The First Mistake: Lumping Everything Together

Our initial impulse is to create a simple table comparing features. We might start with something that looks right on the surface but is full of subtle (and dangerous) inaccuracies. We treat login and session as the same thing and assume standards-compliance means universal support. This is where the confusion begins.

Let's cut through the noise. The key is to separate the authentication journey into stages.

"Aha!" Moment #1: The Login is Not the Session

This is the most critical concept to internalize. The act of logging in and the SSO session that follows are two different things, powered by two different technologies.

  • Authentication (The Login): This is the front door. Its job is to prove you are who you say you are at a single moment in time. The modern, phishing-resistant tool for this is the Passkey.
  • Session Management (The SSO): This is the all-access wristband you get after you're inside. Its job is to give you seamless access to all other apps and services without making you prove your identity again. The technology for this in the Entra ID world is the Primary Refresh Token (PRT).

The Passkey gets you a PRT. The PRT gives you SSO. They are a cause-and-effect pair.

"Aha!" Moment #2: The Passkey Bombshell (This Changes Everything)

Here is where reality collides with the logical approach of open standards.

What the FIDO2 Standard suggests: Any FIDO2-compliant passkey provider (like iCloud Keychain or Google Password Manager) should work with any FIDO2-compliant service (like Entra ID).

What the official Microsoft Entra ID Support Matrix actually says:

"Microsoft Entra ID currently supports only device-bound passkeys stored on FIDO2 security keys or in Microsoft Authenticator. Microsoft... plans to support synced passkeys for Microsoft Entra ID."

This is the ground truth. As of today, for an officially supported enterprise deployment, you cannot rely on roaming passkeys from iCloud Keychain or Google Password Manager for Entra ID. Microsoft's support is currently limited to:

  1. Hardware Security Keys (like YubiKeys).
  2. Device-bound passkeys from Windows Hello for Windows and now Platform SSO for macOS.
  3. The "new" device-bound passkey stored inside the Microsoft Authenticator app on iOS and Android, which can be used across all devices.

This single fact is the source of immense confusion and is essential for building a realistic deployment plan.

The Final, Framework

After peeling back these layers, we can build a table that reflects reality. This framework is structured from the ground up: from the platform's foundation to the user's SSO session.

A few Takeaways

  1. Separate your understanding for Login and Session: A policy for passkeys is not the same as a policy for protecting the SSO token. (Who said Token protection?)
  2. Build your passkey strategy on what Entra ID supports today: Hardware keys across all platforms and Microsoft Authenticator. Plan for future support of synced passkeys.
  3. Trust, but verify: Always check the official Microsoft support matrixes. The pace of change is incredible, and what's true today might be different in six months.

Resources

Microsoft

Understanding Tokens in Microsoft Entra ID - Microsoft Entra ID
To protect against token theft and replay attacks, explore the types of tokens used in Microsoft Entra, their role in authentication, and strategies.

This is the blueprint for the PRT. It explains what it is, how it's issued, and how it's protected at a conceptual level. It's the foundational document for Section 4.

What is device identity in Microsoft Entra ID? - Microsoft Entra ID
Device identities and their use cases

This page defines the different device states: Entra Joined, Entra Hybrid Joined, and Entra Registered. It's the official source for the terminology used in Section 2.

https://learn.microsoft.com/en-us/entra/identity/authentication/fido2-compatibility-matrix (It contains the critical note stating that Entra ID currently only supports device-bound passkeys from hardware keys and Microsoft Authenticator, and that support for "synced passkeys" (iCloud/Google) is planned for the future. This document is the final word that validates Section 3.

Enable passkeys in Authenticator for Microsoft Entra ID - Microsoft Entra ID
Learn about how to enable passkeys in Microsoft Authenticator for Microsoft Entra ID.

This document explains the new capability for the Authenticator app to act as its own passkey provider on iOS and Android. It provides the AAGUIDs that prove this is a distinct, Microsoft-provided option.

Microsoft Entra Conditional Access token protection explained - Microsoft Entra ID
Learn how to secure your environment with token protection in Microsoft Entra Conditional Access policies.

This is the definitive document for the Proof-of-Possession capability. The "Supported clients" table on this page is the primary evidence that macOS is not currently supported, which validates the final row of our table.

https://learn.microsoft.com/en-us/entra/identity/devices/device-join-macos-platform-single-sign-on (This explains the modern "join-like" experience on Mac. It confirms that the device gets a PRT and has a seamless SSO experience, but a careful reading shows it proves by omission that this does not enable Proof-of-Possession, as the feature is never mentioned

Apple

Hardware security overview
Apple devices with iOS, iPadOS, macOS, tvOS, watchOS, and visionOS have hardware security capabilities designed into silicon.

This is the bible for Apple security. It's a comprehensive, book-length guide that details the architecture of their hardware and software.

Android

Android Security | Android Open Source Project

 As Android is open source, this is the official engineering and architectural documentation for the platform's security model.

FIDO Alliance

How Passkeys Work | Passkey Central
FIDO’s user authentication standards leverage public key cryptography techniques to provide user-friendly, phishing-resistant authentication that allows users to sign in with passkeys.

This explains the FIDO2/WebAuthn standard itself the common language that Apple, Google, and Microsoft have all agreed to speak. Apple's documentation explains how they speak FIDO; Microsoft's documentation explains how they listen for FIDO.