Microsoft's decision to make passkeys the default authentication method for Entra ID creates a compliance planning problem you can't ignore. By February 1, 2027, Microsoft-provided SMS and voice authentication will be phased out. This timeline forces a governance question: how do you implement passkeys without breaking your control environment?
This isn't just a technology upgrade. It's a shift in how you demonstrate authentication controls to auditors, manage user lifecycle requirements, and maintain operational continuity. Most organizations will run a hybrid authentication model for years, mixing passkeys with legacy methods. Your audit readiness depends on documenting that hybrid state clearly and proving you've addressed the governance gaps it creates.
Checklist Overview
This checklist helps you evaluate whether your passkey implementation meets the control objectives in ISO/IEC 27001:2022 Annex A 5.17 (Authentication Information), A 5.18 (Access Rights), and SOC 2 CC6.1 (Logical and Physical Access Controls). It focuses on the governance challenges that hybrid authentication introduces: recovery processes, device lifecycle management, ecosystem dependencies, and control over authentication methods you don't directly operate.
Prerequisites
Before you use this checklist, confirm you have:
- Current authentication policy documentation that defines acceptable authentication methods and their risk classification.
- Access to your identity provider configuration (Entra ID, Okta, Ping Identity, or equivalent).
- Inventory of applications with their supported authentication methods documented.
- User lifecycle procedures covering onboarding, role changes, and offboarding.
- Incident response procedures for account compromise and recovery scenarios.
Passkey Governance Checklist
1. Classify passkeys within your authentication policy framework.
Document where passkeys fit in your risk-based authentication hierarchy. Define when passkeys are required, optional, or when legacy methods remain acceptable. A policy matrix should map authentication methods to application sensitivity tiers, with explicit criteria for each tier and board-approved exceptions for legacy systems.
2. Document the recovery process for users who lose passkey access.
Define how users regain access when they lose a device, change roles, or leave the organization. Specify who can authorize recovery, what evidence is required, and how you prevent social engineering attacks during recovery. Reference ISO/IEC 27001:2022 A 5.17 requirement that authentication information be protected during issuance and revocation. A recovery procedure should require manager approval plus identity verification through a separate channel, with all recovery events logged to your SIEM.
3. Identify applications that cannot support passkeys and document compensating controls.
Inventory legacy applications, on-premise systems, and third-party services that don't support FIDO2/WebAuthn standards. Document the alternative authentication method and why it's justified. A risk register entry should show the residual risk, compensating controls (such as hardware tokens or certificate-based authentication), and a target migration date.
4. Address ecosystem dependency risk in your vendor risk management program.
Passkeys rely on Apple, Google, or Microsoft ecosystems for key storage and sync. Document which ecosystem(s) your organization uses, how keys are synced across devices, and what happens if a user loses access to their personal account. Reference SOC 2 CC6.1 requirement for logical access restrictions. A vendor risk assessment should cover key recovery, data residency, and termination procedures, with contractual terms reviewed by legal.
5. Test cross-platform passkey portability for your user base.
Verify that users can authenticate across the devices they actually use. Test scenarios where a user generates a passkey on an iPhone and needs to use it from a Windows desktop. Document which workflows are seamless and which require workarounds. Test results should show successful authentication across all supported device combinations, with documented procedures for edge cases and a help desk script for common failures.
6. Define metrics for passkey adoption and authentication failures.
Establish how you'll measure rollout progress and detect implementation problems. Track passkey enrollment rates, authentication success rates, and recovery request volume. Reference ISO/IEC 27001:2022 Clause 9.1 requirement for monitoring and measurement. A dashboard should show weekly enrollment by department, authentication failure rates by application, and recovery requests by reason code, with defined thresholds that trigger investigation.
7. Update your user lifecycle procedures to include passkey provisioning and revocation.
Modify onboarding procedures to include passkey enrollment. Update offboarding procedures to revoke passkey access and document the revocation in your access review evidence. Onboarding checklist items should include passkey enrollment with completion timestamps, and offboarding automation should trigger passkey revocation within 24 hours of termination notice.
8. Document how you'll demonstrate Segregation of Duties with passkey-based access.
Define how you'll prove that users with conflicting roles don't have simultaneous access to incompatible systems. Passkeys don't change the SOD requirement, but they do change how you demonstrate it. Access review reports should show user-to-role assignments and flag SOD conflicts, with passkey enrollment status included so auditors can verify that privileged access uses stronger authentication.
9. Test account recovery under your incident response plan.
Simulate scenarios where multiple users lose device access simultaneously (device refresh, security incident, natural disaster). Verify that your recovery process scales and doesn't create a single point of failure. Tabletop exercise documentation should show that IT can recover 50 users within 4 hours without bypassing authentication controls, with lessons learned incorporated into the recovery procedure.
10. Prepare audit evidence showing that passkey implementation doesn't weaken existing controls.
Collect evidence that passkeys meet or exceed the security of your previous authentication methods. For SOC 2 Type II or ISO/IEC 27001 surveillance audits, you'll need to show that control effectiveness didn't degrade during the transition. A control effectiveness memo should compare phishing resistance, credential reuse risk, and authentication assurance levels before and after passkey deployment, with supporting evidence from authentication logs.
Common Mistakes
Treating passkeys as a drop-in password replacement. Passkeys change your recovery model, device dependency, and vendor relationships. You can't just enable them and assume your existing procedures still work.
Failing to document the hybrid state. Auditors need to understand why some systems still use passwords and when you plan to migrate them. Undocumented exceptions look like control failures.
Ignoring the personal device problem. When corporate authentication depends on a user's personal Apple ID or Google account, you've created a recovery dependency you don't control. Document how you'll handle that scenario before it becomes an emergency.
Skipping the cross-platform testing. Assuming passkeys work seamlessly across all devices is how you create help desk chaos during rollout. Test the actual device combinations your users have.
Next Steps
Start with a pilot group that represents your device diversity. Enroll 20-50 users across different roles, devices, and applications. Collect evidence of what works and what breaks. Use that evidence to refine your procedures before you scale.
Update your Risk Treatment Plan to include passkey-related risks: ecosystem lock-in, recovery process failures, and legacy system persistence. Define risk owners and target treatment dates.
Schedule a pre-audit walkthrough with your external auditor or certification body. Show them your hybrid model, recovery procedures, and compensating controls for legacy systems. Get their feedback before your next assurance engagement, not during it.
The February 1, 2027 deadline isn't the finish line. It's when Microsoft stops providing one legacy option. Your governance challenge is proving you controlled the transition and maintained operational resilience throughout.
