Entra ID Passkey Profiles: Granular FIDO2 Controls in Public Preview

Microsoft’s Entra ID will let administrators create multiple, group‑scoped passkey profiles — a move that shifts passkey (FIDO2) controls from a single tenant‑wide setting to a flexible, profile-based model and introduces a broader acceptance of attestation formats when Enforce attestation is turned off. The change arrives as a public preview beginning in early November 2025 and is intended to give organizations finer control over which passkey types and providers are allowed for different user groups, while also raising important implementation and security trade‑offs that IT teams must address before the rollout.

Background / Overview​

Microsoft Entra ID currently exposes passkey (FIDO2) registration and enforcement as tenant‑wide settings within the Authentication methods policy. That model works well for organizations that want one uniform posture for passkeys, but it lacks the granularity many enterprises need to align authentication controls with role, risk profile, or regulatory segmentation.
Beginning in public preview in November 2025, Entra ID will support multiple passkey profiles per tenant, enabling administrators to scope different FIDO2/passkey behaviors to distinct groups. This is a scheduled preview rollout that Microsoft will phase across worldwide and government clouds, and the new UX and schema are being delivered first to the Microsoft 365 admin center.
Two technical clarifications:

• Microsoft states tenants can create multiple passkey profiles (reporting shows up to ten profiles per tenant in the preview model). This is a hard limit for the preview stage and may be revised later.
• When a tenant opts into the new schema, existing tenant‑wide settings are migrated into a Default passkey profile automatically to preserve behavior until admins explicitly modify or add profiles.

---

What’s changing: passkey profiles and attestation acceptance​

The new passkey profile model​

Under the new model administrators will be able to:

• Create distinct passkey profiles and assign them to security groups, allowing different authentication rules per group.
• Control which passkey types and FIDO2 security key models are allowed or blocked per profile.
• Maintain a Default profile migrated from existing tenant settings so current behavior doesn’t immediately break after the preview begins.

Practical examples:

• A “C‑suite” profile that allows only corporate‑issued hardware keys and Microsoft Authenticator passkeys, while enforcing attestation and key‑restriction by AAGUID.
• A “general staff” profile that permits a wider set of passkeys, including cross‑device passkeys stored in third‑party managers for desktop‑first users.
• A “contractors” profile with stricter or more permissive controls depending on the organization’s trust model.

Expanded attestation acceptance when “Enforce attestation” is off​

One of the most consequential changes is the acceptance of a wider set of attestation statements when the policy setting Enforce attestation is set to No. Microsoft forecasts that during the preview Entra ID will begin accepting WebAuthn‑compliant passkeys and security keys that report attestation statements such as:

• "none"
• "tpm"
• "packed" (AttCA type only)
• Custom attestation formats up to 32 characters

The effect is that if a given profile (or the Default profile after migration) has attestation enforcement disabled, Entra ID will accept a broader variety of passkeys from more vendors or un‑attested providers at registration and authentication. This will make registration easier for users and increase compatibility, but it reduces the ability to limit sign‑ins to specifically vetted hardware models.

---

Why Microsoft is doing this: benefits and administrative control​

Benefits for administrators and users​

• Granular policy alignment: Profiles let administrators tailor passkey options to departmental needs, regulatory zones, or user risk levels without one size fitting all.
• Reduced friction for mixed estates: Organizations that combine corporate hardware keys, mobile passkeys, and third‑party password managers gain flexibility to permit appropriate providers by group.
• Easier staged rollouts: IT can pilot passkey types with a limited group and expand consistent configurations as confidence and telemetry grow.
• Better business continuity: The Default profile migration preserves existing behavior so rollouts are less likely to cause immediate sign‑in failures during preview.

Administrative UX and API notes​

• The new settings are exposed first in the Microsoft 365 admin center under Home > Security > Authentication methods > Passkey (FIDO2) settings. Admins who edit passkey settings in the new admin UX will see the schema change immediately in preview.
• Microsoft warns that tenants continuing to manage passkeys via Graph API or third‑party tooling will not see the schema change until General Availability (GA). That temporal mismatch means automated management scripts may need updates when APIs catch up.

---

Security implications and operational trade‑offs​

The headline benefits carry clear trade‑offs. The following are the most important security implications and recommendations.

1) Attestation enforcement vs compatibility​

• When Enforce attestation = Yes, Entra ID requires vendor metadata and validated attestation — a strong guarantee that registered keys are genuine models that passed the FIDO metadata and Microsoft’s vetting. This is how organizations traditionally restrict allowed key models using AAGUIDs.
• When Enforce attestation = No, Entra ID accepts broader attestation statements (including "none"), increasing compatibility with consumer or third‑party passkey providers that don’t provide vendor‑verified attestations. That convenience can also allow weaker or unvetted authenticators to register — potentially increasing exposure if device hygiene or supply‑chain trust is a concern.

Recommendation: Plan to enforce attestation in profiles that protect high‑value accounts (executives, privileged admins, critical infrastructure roles) while carefully evaluating safer, more flexible settings for lower‑risk groups.

2) AAGUID‑based key restrictions can be weakened​

Enterprises often rely on AAGUIDs to whitelist specific key models. Under the preview schema the newly accepted attestation statements and custom formats can make it harder to enforce strict AAGUID whitelisting unless administrators explicitly enable Enforce attestation and Key restrictions in those profiles.
Recommendation: Audit existing AAGUID whitelists and identify which groups depend on strict model enforcement. For high‑assurance groups, create profiles with both attestation enforcement and key restrictions active to preserve device‑level guarantees.

3) The migration risk: Default profile and silent exposure​

When a tenant migrates to the new schema automatically, the tenant’s prior top‑level passkey settings become the Default profile. If that setting had Enforce attestation disabled (a common choice during early adoption), the Default profile will permit the wider set of attestation statements — potentially exposing many users to less stringent registration rules without administrators noticing.
Recommendation: Before the preview begins, inventory current passkey settings and use targeted communication. When the preview hits your tenant, immediately review the Default profile and adjust attestation and AAGUID lists where required. Microsoft specifically recommends reviewing passkey configuration and notifying admins ahead of the rollout.

4) Operational and tooling gaps (APIs and automation)​

Because Graph API and many automation workflows will not adopt the new schema until GA, organizations that rely on scripted provisioning, auditing, or compliance tools might see inconsistent behavior between the admin center UI and API‑driven workflows.
Recommendation:

• Map which automation scripts touch the Authentication methods policy.
• Pause non‑essential changes via automated flows during preview or prepare to update scripts when Microsoft publishes API changes.
• Use the preview admin UX for the tasks that require the new profile schema until APIs are updated.

---

Preparing for the rollout — concrete steps for administrators​

• Review tenant‑wide passkey settings and document the current state (Enforce attestation, Key restrictions, allowed AAGUIDs).
• Identify high‑risk groups (privileged accounts, executives, IT) and plan profiles that enforce attestation and key restrictions for those groups.
• Plan pilots: choose a small test group to create and validate a passkey profile before broad assignment.
• Update runbooks and support scripts to handle the new Default profile behavior, and audit Graph‑API‑based tools for compatibility gaps.
• Communicate to helpdesk and user training channels: explain the change, how to register passkeys, and how recovery/SSPR flows work if devices are lost.
• Monitor registration telemetry closely after the preview begins to detect any unexpected uptick in unverified passkey registrations.

---

What enterprise risk teams should measure post‑rollout​

• Rate of registrations with none or other low‑assurance attestation strings in Default and non‑enforced profiles.
• Authentication failure and recovery incidents tied to cross‑device passkeys or third‑party passkey providers.
• Helpdesk call volume related to account recovery and passkey migration.
• Inventory mismatches between allowed AAGUID lists and actual registered key AAGUIDs.

These telemetry signals will indicate whether the organization’s risk posture has weakened in practice and whether additional hardening is required.

---

Vendor and ecosystem considerations​

• Third‑party password managers and passkey providers will be affected positively by broader attestation acceptance because registration friction for cross‑device and non‑hardware keys will be reduced.
• Hardware key vendors that rely on attestation metadata and the FIDO Alliance Metadata Service should verify their metadata is current and that their models appear in Microsoft’s approved lists. If you rely on specific hardware models, keep vendor metadata and AAGUID lists updated.
• Organizations using lifecycle management services for FIDO keys (e.g., provisioning and retirement tooling) should watch for API updates and plan to validate workflows when GA happens, because API schema changes may require tool updates.

---

Community context and early analysis​

Microsoft’s passkey direction is part of a broader industry trend toward passwordless authentication and passkey adoption across major platforms. Community and industry reporting highlight the speed of feature releases and the friction that can arise when management APIs lag behind admin UX updates. IT and security communities have already been discussing practical passkey issues — for example, how Android Work Profile passkeys interact with cross‑device flows, passkey recovery, and device provisioning — which reinforces the need for thorough testing in mixed device estates.

---

Strengths of the change​

• Practical flexibility: Profiles let organizations adopt real‑world segmentation of authentication policy — a major operational win for large enterprises.
• Better user experience for mixed environments: Permitting appropriate third‑party passkeys for less‑sensitive groups lowers adoption barriers.
• Staged rollout and Default profile migration: Microsoft’s approach reduces the risk of a sudden, organization‑wide outage by preserving current behavior until admins act.

---

Key risks and how to mitigate them​

• Risk: Silent weakening of attestation guarantees. If the Default profile has attestation disabled, a tenant could unintentionally begin accepting weakly attested passkeys for many users.
  Mitigation: Verify Default profile attestation immediately after preview arrives and set Enforce attestation = Yes where high assurance is required.
• Risk: Breaks between UI and API automation. Scripts that assume the old schema may behave unexpectedly.
  Mitigation: Freeze or review automation touching the Authentication methods policy; plan script updates for GA.
• Risk: Increased helpdesk load from misconfigured cross‑device or work‑profile passkeys. Mobile work profile distinctions (Android) can generate confusion and recovery requests.
  Mitigation: Update helpdesk playbooks and training, and build guided user documentation for passkey registration and recovery.
• Risk: Supply chain or vendor trust exposure. Accepting "none" or custom attestation formats can permit unvetted devices.
  Mitigation: Use profile scoping to restrict critical users to vetted, attested models and require AAGUID whitelisting for those profiles.

---

Practical admin checklist (quick reference)​

• Inventory current passkey settings (Enforce attestation, Key restrictions, AAGUID lists).
• Map groups that need strict device control and plan profiles accordingly.
• Pilot a profile with strict attestation and key restrictions for a small privileged cohort.
• Validate SSPR and recovery flows for passkey users to prevent lockouts.
• Monitor registration telemetry within the first 30 days of preview activation.
• Coordinate with vendors to ensure attestation metadata is available for your preferred hardware keys.

---

Final assessment​

Microsoft’s passkey profiles deliver an overdue and necessary layer of policy granularity for organizations moving aggressively into passwordless authentication. For enterprises that need to tailor authentication to business roles and risk zones, profiles represent a substantial operational improvement.
However, the relaxed attestation acceptance when Enforce attestation is disabled introduces a tangible security trade‑off that must be managed carefully. The most sensible approach for large organizations is a hybrid one: use profile scoping and enforce attestation for high‑value accounts while allowing broader passkey acceptance for low‑risk groups to accelerate adoption and reduce user friction.
The preview rollout in early November 2025 gives IT teams a practical window to test, adjust automation, and assemble the governance and telemetry needed to keep assurance high as passkeys become the enterprise standard. Administrators who prepare now — inventorying settings, segmenting users by risk, and updating automation — will turn this change into an operational advantage rather than a surprise exposure.

---

Conclusion
The Entra ID passkey profile update is a pragmatic step forward for enterprise passwordless adoption: it balances flexibility and manageability, but it also places the onus on administrators to preserve attestation and AAGUID protections where they matter most. The preview release is the time to test and harden controls, so organizations should move from awareness to action — inventory, pilot, and enforce. Doing so will let teams reap the usability gains of passkeys while keeping the rigorous device assurance required by mature security programs.

---

Source: Petri IT Knowledgebase Microsoft Entra ID to Add Granular Passkey Profiles for Better Authentication