Workforce Passkeys in Entra ID and Okta: Configuration

A workforce passkey policy is only as strong as the identity provider settings that decide which passkeys employees may register and where they may use them. Microsoft Entra ID and Okta both let administrators choose between synced and device-bound passkeys, restrict authenticators by AAGUID, require attestation and user verification, and enforce phishing-resistant sign-in per application. The setting names, scopes and side effects differ, and several of them only take effect at registration, which catches teams out when they tighten policy later. This guide walks through each platform's configuration in practical depth for identity engineers and IAM administrators, then covers rollout, monitoring and the mistakes that lock users out. Platforms are listed alphabetically; the order is not a ranking. Strategy across user populations is covered in the Passkey Rollout Guide.

Source note: settings below are summarised from the Microsoft Learn and Okta Help Center pages listed in the references, as checked in November 2026. Confirm against the official text before relying on it.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public Entra ID documentation and Okta's public Identity Engine documentation as of November 2026. It is not sponsored or reviewed by Microsoft or Okta. Product features change, so confirm settings against each vendor's current documentation.

Key takeaways

Decide passkey type per population first. Both platforms let you allow synced passkeys for general staff and require device-bound, attested passkeys for administrators; configure them as separate policies, not one compromise.
Attestation is what makes an AAGUID list a control. Without attestation the AAGUID is self-reported, so Microsoft describes AAGUID lists without attestation as a policy guide rather than a strict security control.
Some settings bite only at registration. In Entra ID, Enforce attestation applies at registration; users who registered earlier keep signing in. Plan a re-registration campaign when you tighten it.
Removing an AAGUID locks users out. In Entra ID, key restrictions apply at sign-in too, so removing an allowed AAGUID stops existing users of that authenticator immediately.
Registration is enforced by the access policy, sign-in by the app policy. Pair the authentication method settings with authentication strengths in Entra ID or app sign-in policy rules in Okta, or passkeys remain optional.

Configuration model at a glance

Each platform names its settings differently. This table maps the equivalent controls using each vendor's own terms, as documented in November 2026.

Control	Microsoft Entra ID	Okta Identity Engine
Where passkeys are configured	Entra ID > Authentication methods > Policies > Passkey (FIDO2)	Admin Console > Authenticators: Passkey (FIDO2 WebAuthn) authenticator, with user verification set separately for enrolment and authentication
Passkey type	Passkey types: Device-bound and/or Synced, per passkey profile	Block synced passkeys toggle, org-wide
Authenticator restriction	Enforce key restrictions with Behavior Allow or Block and a list of AAGUIDs	Authenticator groups (named sets of authenticators by name or AAGUID) used in enrolment and sign-in policies
Attestation	Enforce attestation (Yes or No), per profile	Required characteristics: Certificate-based attestation validation, against the FIDO MDS or an uploaded custom certificate
Hardware and compliance characteristics	Profiles targeting specific AAGUIDs of known hardware or apps	Required characteristics: Hardware protection and FIPS compliant
Targeting	Enable and target: All users or selected groups, each assigned profiles; up to three profiles including Default	Authenticator enrolment policies and app sign-in policy rules, by group
Enforcing passkey sign-in	Conditional Access with a built-in or custom authentication strength	App sign-in policy rules with phishing-resistant and other authenticator constraints

Microsoft Entra ID: passkey profiles and key restrictions

Microsoft documents passkeys (FIDO2) as available in all Entra ID editions, including Free, with no extra licence. Supported types are synced passkeys and device-bound passkeys on FIDO2 security keys and in Microsoft Authenticator. Configuring profiles requires the Authentication Policy Administrator role.

Passkey profiles

Opting in: Profiles are enabled from a banner on the Passkey (FIDO2) policy. Microsoft states you cannot opt out afterwards, and existing global settings move into a Default passkey profile.
Profile settings: each profile carries Enforce attestation, Passkey types (Device-bound, Synced or both), and Enforce key restrictions with an Allow or Block AAGUID list.
Limits: up to three profiles including the Default, and a 20 KB size limit for the whole Passkey (FIDO2) policy.
Evaluation: a group can be scoped to several profiles; registration and sign-in succeed if the passkey fully meets at least one, with no particular evaluation order. Members of an excluded group are blocked from registration and sign-in, and exclusion overrides inclusion.
Self-service: the global Allow self-service set up setting on the Configure tab, if set to No, stops registration through Security info even when the method is enabled.

Attestation and AAGUID behaviour

Enforce attestation = Yes: Entra ID verifies make and model against trusted metadata at registration. Microsoft states enforcement applies only at registration, so earlier unattested registrations keep working.
Enforce attestation = No: Microsoft states Entra ID cannot guarantee any attribute of the passkey, including whether it is synced or device-bound.
Synced passkeys: Microsoft notes they do not support attestation and should be treated as phishing-resistant with the same security posture as other unattested authenticators. Disabling Synced in a profile also blocks sign-in with synced passkeys already registered by targeted users.
Key restrictions: apply at both registration and authentication. To find a registered passkey's AAGUID, open the user's authentication method details.

Passkeys in Microsoft Authenticator

Microsoft documents device-bound passkeys in Authenticator on Android 14 or later and iOS 17 or later. The documented setup is a profile with Passkey types set to Device-bound and Target specific AAGUIDs set to Allow with the Microsoft Authenticator entry, then Enable and target. The published AAGUIDs are de1e552d-db1d-4423-a619-566b625cdc84 (Android) and 90a3ccdf-635c-4729-a248-9b709135078f (iOS).

Attestation sources: iOS uses the App Attest service; Android uses Play Integrity to verify the app and Android key attestation to verify the key is hardware-backed. Microsoft notes attestation-required registration is blocked while Apple or Google attestation services are unavailable.
Registration paths: on iOS, attested passkeys register only directly in the Authenticator app; on Android, in the app or through the cross-device flow.
Cross-device flows: need Bluetooth and internet on both devices, and endpoints cable.ua5v.com (Android) and cable.auth.com, app-site-association.cdn-apple.com, app-site-association.networking.apple (iOS) allowed through proxies.
Android work profiles: passkeys work only in the profile where they were created, so users with Work and Personal profiles register in each they use.
Graph: the tenant-level configuration is authenticationMethodsPolicy/authenticationMethodConfigurations/FIDO2 with isAttestationEnforced and keyRestrictions. Microsoft's sample PATCH notes that previously allowed AAGUIDs must be included in the aaGuids array or they may be removed.

Enforcing passkey sign-in

Use a built-in phishing-resistant authentication strength, or create a custom one under Authentication methods > Authentication strengths, selecting Passkeys (FIDO2) and optionally Advanced options > Add AAGUID to restrict models. Microsoft documents a registration loop: a policy on All resources requiring a passkey in Authenticator blocks users from adding that passkey. Its listed workarounds are filters for applications, splitting desktop and mobile policies with a Temporary Access Pass for mobile registration, and excluding the Microsoft Authenticator Credential Registration resource (app ID 6aa00308-ea33-4caa-90d6-ae905d8cb51b), which Microsoft lists as available from November 2026 after provisioning its service principal. Users must complete MFA within the past five minutes before registering a passkey. See the Conditional Access Guide and the Entra ID Security Guide.

Availability: Microsoft lists Graph-based provisioning of security keys on behalf of users as in preview, and states that passkey registration is not available for internal or external guest users, including B2B users in the resource tenant.

Okta: Passkey (FIDO2 WebAuthn) authenticator and access controls

In Okta Identity Engine, passkeys and security keys are managed through the Passkey (FIDO2 WebAuthn) authenticator. Okta classifies it as a possession factor plus a biometric or knowledge factor that meets phishing-resistant and user presence requirements, and that may meet device-bound and hardware-protected requirements depending on configuration.

Access controls

User verification: set separately for Enrollment and Authentication, each Required, Preferred (the default) or Discouraged. Okta notes app sign-in and Okta account management policy rules can also require it, and the most secure setting wins on conflict.
Block synced passkeys: blocks new enrolments of syncable passkeys across the org, targeting known syncing providers such as Google Password Manager, iCloud Keychain and 1Password. Okta states it is not an attestation check, and that passkeys in Chrome on macOS are device-bound and are not blocked.
Required characteristics: Certificate-based attestation validation (checks the authenticator's certificate against the FIDO MDS or an uploaded custom AAGUID validation certificate), Hardware protection (TPM or Secure Enclave) and FIPS compliant. All three apply to enrolment and authentication.

Authenticator groups and enrolment policy

Recognised authenticators: the authenticator settings list Okta-recognised authenticators from the FIDO Metadata Service, searchable by name or AAGUID, with type, FIPS and hardware protection status. Authenticators outside the list can be added as custom AAGUIDs.
Groups: Add authenticator group takes a group name and a set of authenticators by name or AAGUID. In the enrolment policy, choose Any WebAuthn authenticators or Authenticators from selected group list. A group cannot be deleted while a policy uses it.
Interaction with attestation: Okta documents that when the Early Access feature to match AAGUID groups on AAGUID alone is on, certificate-based attestation validation cannot be enabled while any group uses that matching. Prefer attestation-backed groups for administrator populations.

End-user experience and enforcement

Sign-in Widget settings: Show the "Sign in with a passkey" button, and Enable autofill UI, which shows enrolled passkeys when users click the username field. Okta notes autofill is not compatible with the password-first sign-in flow, and users can hold up to 10 passkey enrolments. When enrolment is required, Okta prompts users to enrol the next time they sign in. See Passkey Autofill and Conditional UI.
Okta FastPass: Okta describes FastPass as a phishing-resistant, passwordless authenticator delivered through Okta Verify on Android, iOS, Linux, macOS and Windows, signing responses with a proof-of-possession key issued at enrolment and evaluating device posture against device assurance policies. Okta's passkey documentation suggests FastPass or NFC or USB-C security keys for iPhone users when syncable passkeys are blocked.
Enforcement: add phishing-resistant constraints and required user verification to app sign-in policy rules for the apps that need them. See the Okta Security Hardening Guide.

Availability: Okta lists the authenticator as not supported on the MFA Credential Provider for Windows, documents that it works only on the org URL where it was added (add it to each custom URL), and states that security keys enrolled before 30 November 2022 must be re-enrolled. Okta asks for the latest Chrome version.

Designing policies per population

Population	Microsoft Entra ID configuration	Okta configuration
Administrators and privileged roles	Profile: Device-bound only, Enforce attestation Yes, Allow list of approved security key and Authenticator AAGUIDs; custom authentication strength on admin portals	Block synced passkeys on; Certificate-based attestation validation and Hardware protection; enrolment from an approved authenticator group; app sign-in rules requiring phishing-resistant and UV Required
General workforce on managed devices	Profile allowing Device-bound and Synced, or Authenticator passkeys only where phone-based passkeys are standard	Any WebAuthn authenticators or a broad group; UV Required for Authentication; FastPass on managed devices
Frontline and shared devices	Profile restricted to issued security key AAGUIDs, with Temporary Access Pass for first registration	Authenticator group of issued security keys; admin-initiated enrolment of FIDO2 security keys

Small organisations usually need one broad policy plus one strict administrator policy. Large and regulated organisations run separate policies per population and record why each AAGUID is approved. Where federal or AAL3 requirements apply, attested device-bound passkeys are the documented path; see Device-Bound Passkeys and the Hardware Security Keys Guide.

Rollout and rollback

Inventory current registrations. Export registered FIDO2 methods and their AAGUIDs (Entra ID user authentication method details; Okta enrolled authenticators) to see what a new allow list would break.
Build the strict policy first for a pilot group. In Entra ID, a new profile targeted at a pilot group; in Okta, an enrolment policy and app sign-in rule scoped to a pilot group.
Provide a bootstrap. Temporary Access Pass in Entra ID, or admin-initiated security key enrolment in Okta, so users can register without a weaker method. See the Account Recovery and Help Desk Security Guide.
Enforce at the app layer. Add the authentication strength or app sign-in rule for pilot apps; check sign-in logs for failures before widening.
Tighten registration rules, then re-register. Because attestation and synced-passkey blocks act on new registrations, run a campaign to replace older registrations, then remove unapproved credentials.
Roll back safely. Keep the previous profile or policy unassigned rather than deleted; reverting is a target change. In Entra ID, any Graph PATCH should carry the full AAGUID list.

Detection and measurement

Stream sign-in and audit logs to the SIEM and watch method changes as closely as sign-ins. See the Entra ID Sign-In and Audit Log Detection Guide and the Okta System Log Detection Guide.

Alert on: passkey registrations outside approved AAGUIDs or from new devices shortly after a help desk reset; changes to the Passkey (FIDO2) policy, profiles, authentication strengths, authenticator groups or the Block synced passkeys setting; Temporary Access Pass issuance spikes.
Phishing-resistant coverage: share of sign-ins to protected apps satisfied by passkeys or FastPass.
Administrator compliance: privileged users with only attested, device-bound credentials registered.
Legacy registrations remaining: credentials registered before attestation or synced blocks were enforced.
Registration failure rate: by platform and reason, to spot attestation service or Bluetooth issues.
Fallback use: sign-ins still completing with password, SMS or push on apps meant to be passkey-only.

Common failure patterns

Allow lists without attestation: an AAGUID list treated as proof of hardware when the AAGUID was self-reported.
Removing an AAGUID in production: in Entra ID, existing users of that authenticator lose sign-in at once; a partial Graph PATCH can remove every unlisted AAGUID.
Assuming tightened policy applies retroactively: attestation and synced-passkey blocks govern new registrations, so old credentials persist until replaced.
Registration loops: an All resources policy requiring the very passkey the user is trying to register.
Weak bootstrap and recovery: a strong passkey policy undone by help desk resets that issue a new factor on a phone call. Verify callers with checks that public information cannot defeat before any reset.
Methods left enabled beside passkeys: phishable methods still allowed by app policy remain the attacker's route. See the Phishing-Resistant MFA Guide.

Framework mapping

Framework	Reference	How the configuration supports it
NIST SP 800-53 Rev. 5	IA-2(1), IA-2(8), IA-5	Phishing-resistant MFA for privileged accounts, replay resistance, authenticator approval and lifecycle through AAGUID and attestation rules
NIST CSF 2.0	PR.AA-03	Users and hardware authenticated to policy
MITRE ATT&CK	T1111 Multi-Factor Authentication Interception, T1557 Adversary-in-the-Middle, T1556 Modify Authentication Process	Passkey enforcement counters interception; policy change monitoring detects tampering with authentication settings

Practitioner checklist

Inventory registered passkeys and AAGUIDs before changing any allow or block list.
Create a separate strict policy for administrators: device-bound, attested, approved authenticators only.
For administrators, require phishing-resistant authentication strengths in Entra ID and phishing-resistant, UV Required app sign-in rules in Okta.
Enforce passkeys per app with authentication strengths or app sign-in policy rules.
Use Temporary Access Pass or admin-initiated enrolment as the bootstrap, not SMS.
Plan re-registration after enabling attestation or blocking synced passkeys.
Always send the full AAGUID list in Graph PATCH calls and keep the previous policy for rollback.
Alert on passkey policy changes and on registrations of unapproved authenticators.

Standards and references

Related NHI Mgmt Group resources: Passkey Rollout Guide · Entra ID Security Guide · Okta Security Hardening Guide · Phishing-Resistant MFA Guide

Workforce Passkeys in Entra ID and Okta: Policies, AAGUID Allow Lists and Attestation Settings