Correction and Context
In a recent follow-up video, Peter Rising [MVP] corrected an earlier demo and clarified a key distinction in passkey behavior within Microsoft Entra. He explained that his original video showed Device‑Bound Passkeys rather than the cloud-synced experience he intended to demonstrate. Consequently, this short update walks viewers step by step through how Synced Passkeys actually operate so administrators and users understand the difference. Moreover, Rising thanked the community for feedback that helped surface the mistake and improve the guidance.
Defining Synced and Device‑Bound Passkeys
Synced Passkeys store the private credential in a cloud-based passkey vault such as native platform managers or third-party password managers, which allows the key to travel with the user across devices. In contrast, Device‑Bound Passkeys keep the private key anchored to the originating device and rely on local hardware attestation for a stronger cryptographic claim. Therefore, while device-bound keys can offer higher assurance because of attestation, they make recovery harder when a device is lost or replaced. Conversely, synced keys improve continuity but depend on the security and trust model of the chosen cloud provider.
Rising emphasized that both approaches use the FIDO2 standards for authentication, yet their operational models differ significantly for end users and administrators. For example, synced credentials reduce the need for re-registration after device replacement, which eases support overhead and improves user experience. However, administrators must consider attestation policies and whether they require hardware-backed proofs for certain roles. As a result, choosing between the two types requires weighing convenience against the strongest possible device assurances.
Policy Updates and Rollout Implications
Starting March 2026, Microsoft will automatically enable passkey profiles for tenants, and these profiles introduce a new property to distinguish between synced and device-bound options. Consequently, organizations can apply more granular controls by assigning profiles to groups instead of relying on tenant-wide toggles. Moreover, existing FIDO2 settings will migrate into a default profile during the rollout, which reduces manual configuration but calls for administrators to review settings proactively.
Additionally, the update changes registration campaigns to favor passkey-first strategies, potentially increasing adoption rates while simplifying enrollment workflows. Nonetheless, admins who prefer gradual adoption can still adjust targeting and opt out of specific automatic behaviors during the migration window. Therefore, planning a phased rollout with targeted user groups remains a practical approach to balance operational risk and user disruption.
Tradeoffs: Security, Usability, and Administrative Control
The tradeoffs between synced and device-bound passkeys center on security assurances versus user convenience, and Rising highlighted these differences clearly in his correction. On one hand, device-bound keys provide stronger attestation and reduce the attack surface tied to cloud synchronization, which benefits high-risk or privileged accounts. On the other hand, synced passkeys limit account lockouts and recovery friction, which reduces helpdesk load and improves end-user satisfaction.
Moreover, administrators face additional complexities such as which third-party providers to trust for syncing and how to enforce attestation where it matters most. For example, enforcing hardware attestation for administrators and sensitive roles while allowing synced passkeys for general staff can strike a balance, though it increases policy complexity. Consequently, organizations must consider threat models, compliance needs, and user experience goals when designing their passkey strategy.
Practical Guidance for IT Teams and Users
Rising’s correction leaves practical takeaways: first, validate whether your tenant’s default profile permits the passkey type you expect and update group-level profiles as needed. Next, test sign-in flows for both synced and device-bound scenarios so helpdesk teams can respond quickly to device loss or synchronization issues. Additionally, document recovery procedures and communicate them to users to minimize confusion and downtime.
Finally, organizations should monitor vendor support for synced passkeys across platforms and password managers, and plan training to set expectations for end users. In this way, teams can take advantage of improved usability without sacrificing the controls necessary for sensitive accounts. Overall, Rising’s clarification serves as a useful reminder that small differences in implementation can change both security posture and user experience, and that careful planning is essential when adopting passkeys at scale.
