Microsoft has made passkeys the default authentication method for Entra ID as of September 1. By February 1, 2027, SMS and voice authentication will be phased out. If you're an IAM architect planning this transition, you need a rollout policy that balances security gains with operational realities.
This template provides a structured policy framework for introducing passkeys in a hybrid authentication environment. It covers phased implementation, governance boundaries, and the legacy systems that won't cooperate with FIDO2 for years to come.
Purpose of the Template
This policy template outlines how your organization will introduce passkeys for Entra ID authentication while maintaining support for systems that can't yet adopt FIDO2. It establishes:
- Which application categories get passkeys first
- How to handle device binding and recovery
- Governance controls for consumer ecosystem integration
- Fallback authentication paths for legacy infrastructure
The template assumes you're running Entra ID as your primary identity provider and need to support both cloud-native SaaS applications and on-premises systems during the transition.
Prerequisites
Before implementing this policy, ensure you have:
- Entra ID P1 or P2 licensing (passkey support requires premium features)
- Device management capability through Intune or equivalent MDM
- Identity governance tools for Certification Campaigns and access reviews
- A documented inventory of applications with their authentication protocols
- A recovery process for locked accounts that doesn't rely on SMS or voice
You'll also need executive sponsorship. This policy affects every employee's daily authentication experience and requires coordination across IT, security, and business units.
The Policy Template
PASSKEY ROLLOUT POLICY
Version: 1.0
Effective Date: [Insert Date]
Review Cycle: Quarterly
1. [SCOPE](/glossary/scope) AND OBJECTIVES
This policy governs the phased introduction of FIDO2 passkeys as the primary authentication method for Entra ID, replacing password-based authentication where technically feasible.
Objectives:
- Eliminate [phishing-resistant authentication](/glossary/phishing-resistant-authentication) gaps for cloud applications
- Reduce credential theft surface area
- Maintain operational continuity during multi-year transition
2. PHASED IMPLEMENTATION SCHEDULE
Phase 1 (Months 1-3): Cloud Application Pilot
- Target: Modern SaaS applications with native FIDO2 support
- Scope: IT and security teams (50-100 users)
- Success criteria: <5% helpdesk escalations, zero authentication outages
Phase 2 (Months 4-9): Cloud Application Expansion
- Target: All cloud-native applications accessed via Entra ID
- Scope: All employees with managed devices
- Exclusions: Documented in Section 4
Phase 3 (Months 10-24): Legacy System Bridge
- Target: Hybrid authentication for on-premises systems
- Approach: Maintain password + phishing-resistant MFA for legacy apps
- Exit criteria: Application modernization or retirement
3. APPLICATION CATEGORIZATION
Category A (Passkey-First):
- Cloud SaaS applications with FIDO2 support
- Microsoft 365 suite
- Web applications accessed via modern browsers
Authentication: Passkey required, password disabled
Category B (Hybrid):
- On-premises applications using [Kerberos](/glossary/kerberos)
- Custom internal applications without FIDO2 capability
- Third-party systems pending vendor updates
Authentication: Password + [Multi-Factor Cryptographic Device](/glossary/multi-factor-cryptographic-device) or TOTP
Category C (Exception):
- Industrial control systems
- Specialized business systems with vendor constraints
- Emergency access accounts
Authentication: Password + hardware token, documented exception required
4. DEVICE AND ECOSYSTEM GOVERNANCE
Approved Passkey Platforms:
- Windows 10/11 with Windows Hello for Business
- macOS with Touch ID or Face ID
- iOS/iPadOS devices enrolled in MDM
- Android devices meeting enterprise security baseline
Corporate Device Policy:
- Passkeys generated on corporate-managed devices remain under IT control
- Device lifecycle events (replacement, loss) trigger automated passkey revocation and re-[enrollment](/glossary/enrollment)
BYOD Policy:
- Personal devices may use platform authenticators (Apple ID, Google [Password Manager](/glossary/password-manager)) for Category A applications only
- Binding corporate credentials to consumer ecosystems requires:
* Documented risk acceptance from business unit owner
* Quarterly [Certification Campaign](/glossary/certification-campaign) review
* Capability to revoke access independent of consumer account
5. RECOVERY AND CONTINUITY
Primary Recovery Path:
- Temporary Access Pass issued by helpdesk after identity verification
- Valid for 8 hours, single use
- Requires manager approval for privileged accounts
Secondary Recovery Path:
- Pre-registered Multi-Factor Cryptographic Device (YubiKey, etc.)
- Stored in secure location, documented in asset management system
Prohibited Recovery Methods:
- SMS or voice authentication (deprecated Feb 1, 2027)
- Email-based password reset for passkey-protected accounts
- Security questions
6. COMPLIANCE AND AUDIT REQUIREMENTS
Monthly:
- Review passkey enrollment rates by department
- Analyze authentication failure patterns
- Validate recovery process usage
Quarterly:
- Certification Campaign for BYOD passkey bindings
- Exception review for Category C applications
- Vendor roadmap assessment for Category B applications
Annually:
- Full policy review and update
- Tabletop exercise for mass device loss scenario
- Cost-benefit analysis of legacy system modernization
7. ROLES AND RESPONSIBILITIES
IAM Team:
- Policy enforcement in Entra ID Conditional Access
- Passkey enrollment workflow management
- Recovery process execution
Security Operations:
- Monitor for passkey-related anomalies
- Investigate authentication bypass attempts
- Maintain threat intelligence on FIDO2 attack techniques
Application Owners:
- Categorize applications (A/B/C)
- Document technical constraints preventing passkey adoption
- Provide modernization timeline for Category B systems
Helpdesk:
- Execute recovery procedures
- Escalate unusual recovery requests
- Track user experience feedback
8. RISK ACKNOWLEDGMENTS
This policy accepts the following risks:
- Consumer ecosystem dependency for BYOD scenarios
- Cross-platform passkey portability limitations
- Recovery process complexity compared to password reset
- Extended timeline for full password elimination
Risk mitigations are documented in Section 5 (recovery paths) and Section 4 (governance controls).
Customizing the Template
Replace bracketed placeholders with your organization's specifics:
Timeline adjustments: If you have fewer than 500 employees, combine Phase 1 and Phase 2. If you're a large enterprise with complex legacy infrastructure, extend Phase 3 to 36 months.
Application inventory: Map your actual applications to Categories A, B, and C. Be strict about Category C exceptions. Every exception you grant today is technical debt you'll carry for years.
Device platform support: Remove platforms your organization doesn't use. If you're a Windows-only shop, strip out the macOS and mobile guidance. If you support Linux endpoints, add your approved FIDO2 authenticator requirements.
Recovery procedures: Adjust Temporary Access Pass validity windows based on your user population's timezone distribution. Global organizations may need longer validity periods.
Governance cadence: Monthly reviews work for organizations under 1,000 users. Scale to quarterly for larger deployments, but never extend Certification Campaigns beyond 90 days for BYOD bindings.
Validation Steps
Before you publish this policy:
Technical validation: Configure Entra ID Conditional Access policies that match your Category A, B, C definitions. Test with pilot users from each category. Verify that Category A blocks password authentication entirely.
Recovery testing: Execute your Temporary Access Pass workflow end-to-end. Time how long it takes from user report to restored access. Anything over 30 minutes will generate helpdesk backlogs.
Cross-platform verification: If you support multiple device platforms, test passkey enrollment and authentication on each. Document the user experience differences. iOS and Android users will see different prompts than Windows users.
Exception process: Walk through your Category C exception request workflow. Verify that exception requests require documented risk acceptance and have automatic expiration dates. Exceptions without expiration become permanent.
Compliance mapping: Review your policy against your organization's existing authentication and access control standards. Flag any conflicts with regulatory requirements before rollout.
After deployment, your first quarterly review will reveal whether your phase timelines were realistic. If Phase 1 pilot users report more than 5% authentication failures, pause Phase 2 expansion until you've resolved the root causes. Authentication is not the place to move fast and break things.
