Skip to content

[Cloudflare One] Clarify AAGUID/AMR incompatibility in independent MFA docs #30805

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kennyj42 wants to merge 2 commits into
base: production
Choose a base branch
from
Open

[Cloudflare One] Clarify AAGUID/AMR incompatibility in independent MFA docs #30805

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
edac200
[Cloudflare One] Move AAGUID/AMR incompatibility explanation to AAGUI…
kennyj42 May 13, 2026
7adeb3c
[Cloudflare One] Fix AAGUID/AMR docs per eng feedback
kennyj42 May 13, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 2 additions & 8 deletions ...content/docs/cloudflare-one/access-controls/access-settings/independent-mfa.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -86,12 +86,7 @@ An [AAGUID](https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-registry-v
AAGUID restrictions apply at enrollment time only. Access verifies the AAGUID when a user registers an authenticator, not when they authenticate. As a result, AAGUID restrictions are configured at the organization level.

:::caution
Some authenticators do not send an AAGUID during WebAuthn registration, including:

- Apple devices using iCloud Keychain passkeys.
- YubiKey 4 and earlier models using U2F (CTAP1).

Users cannot enroll these authenticators when AAGUID restrictions are turned on. Before turning on AAGUID restrictions, confirm that your required authenticators are in the [FIDO Alliance Metadata Service](https://fidoalliance.org/metadata/).
Some authenticators do not send an AAGUID during WebAuthn registration, such as YubiKey 4 and earlier models using U2F (CTAP1). Users cannot enroll these authenticators when AAGUID restrictions are turned on. Before turning on AAGUID restrictions, confirm that your required authenticators are in the [FIDO Alliance Metadata Service](https://fidoalliance.org/metadata/).
:::

### 1. Create an AAGUID list
Expand Down Expand Up @@ -187,7 +182,7 @@ After you save, only authenticators whose AAGUIDs appear in the list can be enro
</Tabs>

:::note
AAGUID requirements and [AMR matching](#use-identity-provider-mfa) cannot both be turned on at the organization level. If AAGUID requirements are turned on, Access skips AMR matching even when the identity provider returns a matching AMR value.
AAGUID restrictions and [AMR matching](#use-identity-provider-mfa) can both be turned on, but AMR matching is more permissive than independent MFA when AAGUID restrictions are configured. Most identity providers do not include AAGUID information in their AMR claims, so Access cannot verify that the authenticator used for IdP MFA is in the list of approved AAGUIDs. If the IdP returns a matching AMR value, Access will skip the independent MFA prompt regardless of which authenticator the user used at the IdP.
Copy link
Copy Markdown

@sha-e-512 sha-e-512 May 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: 'can both be turned on simultaneously'.

:::

## Use identity provider MFA
Expand Down Expand Up @@ -254,7 +249,6 @@ Access ignores AMR values that do not map to a supported authenticator type (for

Access does not apply AMR matching in the following cases:

- [AAGUID requirements](#restrict-authenticators-by-aaguid) are turned on at the organization level. AAGUID information is not present in the IdP's AMR claim, so Access cannot verify that the IdP's MFA came from an approved device.
- The IdP does not return an `amr` claim.
- The IdP returns only AMR values that do not map to an [allowed authenticator type](#supported-mfa-methods) for the application or policy.
- The user's AMR matching session has expired because they last performed MFA via their IdP longer ago than the configured AMR matching duration.
Expand Down