Frequently Asked Questions About Okta Passkey FIDO Metadata Service Validation
Last Updated:
Overview
Okta provides specific administrative controls for validating passkey authenticators against the Fast IDentity Online (FIDO) Metadata Service (MDS). Administrators often have questions regarding how Okta handles FIDO MDS validation during enrollment and authentication, enforces security actions, and manages compromised authenticators.
Applies To
- Okta Identity Engine (OIE)
- Okta Classic Engine
- Passkeys (FIDO2 WebAuthn)
Solution
Does Okta validate passkey authenticators against FIDO MDS during enrollment and authentication?
Okta validates passkeys for specific administrator-configured checks rather than automatically by default. Under the Passkeys (FIDO2 WebAuthn) access controls, administrators can enable Required characteristics, which apply to both enrollment and authentication. These characteristics are sourced from the FIDO MDS Authenticator Attestation Globally Unique Identifier (AAGUID) list or from a custom AAGUID entry if an administrator overrides it. Administrators can enforce validation during enrollment and authentication by enabling the required characteristics for certificate-based attestation, hardware protection, and Federal Information Processing Standards (FIPS) compliance.
- Certificate-based attestation validation, checked against the associated certificate in the FIDO MDS or a custom AAGUID validation certificate uploaded by the administrator.
- Hardware protection requirements, such as Trusted Platform Module (TPM) or Secure Enclave.
- FIPS-compliant requirement.
NOTE: Separately, Okta provides a Block synced passkeys toggle. This toggle does not perform an attestation or MDS-based check. Instead, Okta blocks known syncable-passkey providers, such as Google Password Manager, iCloud Keychain, and 1Password, by category, independent of MDS.
Okta Enforces Security Actions Based on Administrative Settings Rather Than Dynamic MDS Data
Okta enforces security based on administrative settings rather than dynamic MDS status changes. Okta blocks any authenticator absent from the AAGUID allowlist. The Required characteristics settings act as enforcement. Okta blocks an authenticator at enrollment and authentication if it does not meet the enabled requirements, such as FIPS compliance, hardware-backed protection, or a valid attestation certificate. Administrators can also maintain a custom AAGUID list that overrides FIDO MDS entries for the entire organization.
How does Okta handle authenticators identified as insecure or revoked?
If an authenticator is compromised, Okta does not automatically disable it. Administrators must take manual administrative action to secure the environment. Administrators must secure the environment against compromised authenticators by removing the compromised AAGUID from the allowlist and manually deleting the WebAuthn factor from affected user profiles.
- Remove the compromised AAGUID from the allowlist to block new enrollments.
- Manually delete the WebAuthn factor from the profiles of users who previously enrolled the compromised device.
