Independent MFA

Independent multi-factor authentication (MFA) allows you to enforce MFA requirements directly in Access without relying on your identity provider (IdP). Users authenticate with their IdP as usual, and Access prompts for an additional authentication method before granting access to the application.

Because you can configure MFA at the application and policy level, you can enforce stricter authentication methods like hardware security keys on sensitive applications without requiring them across your entire organization. This allows you to add additional security where it matters most while avoiding MFA fatigue for your broader user population.

Supported MFA methods

MFA method	Description
Authenticator application	Time-based one-time passwords (TOTP) generated by apps such as Google Authenticator, Microsoft Authenticator, or Authy. Access supports one TOTP authenticator per user at a time.
Security key	YubiKeys and hardware security keys that support the WebAuthn ↗ standard. Users can enroll multiple security keys.
Biometrics	Built-in device authenticators that use WebAuthn ↗, including Apple Touch ID, Apple Face ID, and Windows Hello. Users can enroll multiple biometrics.

Turn on independent MFA

Before you can enforce independent MFA on applications and policies, you must turn on independent MFA at the organization level.

Dashboard

1. In the Cloudflare dashboard ↗, go to Zero Trust > Access controls > Access settings.
2. Under Allow multi-factor authentication (MFA), select the MFA methods you want to allow in your organization.
3. Set an Authentication duration. This determines how long a user can log in to Access without being prompted for MFA again. If the user does not have an active MFA session for the required authenticator method, they must complete MFA in addition to IdP authentication.
4. (Optional) To avoid double prompting a user for MFA, you can enable Use identity provider MFA. This will check the AMR value passed from the identity provider at the time of authentication, if that AMR value passes an allowed MFA method, the user will not be prompted for MFA for the duration configured.
5. (Optional) To apply your MFA methods and authentication duration to all Access applications, select Apply global MFA settings by default. You can override the global MFA settings for individual applications and policies.

   Note

   The App Launcher is exempt from the global MFA requirement. Users must be able to access the App Launcher without MFA to enroll their authenticators.

6. Select Save.

API

1. Get your existing Zero Trust organization configuration:

   Required API token permissions

   At least one of the following token permissions is required:

   • Access: Organizations, Identity Providers, and Groups Revoke
   • Access: Organizations, Identity Providers, and Groups Write
   • Access: Organizations, Identity Providers, and Groups Read

   Get your Zero Trust organization

   curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/organizations" \
     --request GET \
     --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

2. Send a PUT request to update your organization's MFA settings. To avoid overwriting your existing configuration, the PUT request body should contain all fields returned by the previous GET request.

   Required API token permissions

   At least one of the following token permissions is required:

   • Access: Organizations, Identity Providers, and Groups Write

   Update your Zero Trust organization

   curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/organizations" \
     --request PUT \
     --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
     --json '{
       "auth_domain": "your-team-name.cloudflareaccess.com",
       "name": "Your Team Name",
       "mfa_config": {
           "allowed_authenticators": [
               "totp",
               "biometrics",
               "security_key"
           ],
           "session_duration": "24h"
       },
       "mfa_required_for_all_apps": false
     }'

   Set allowed_authenticators to an array containing one or more of:

   • totp — Authenticator application (time-based one-time passwords).
   • biometrics — Biometrics (Touch ID, Face ID, Windows Hello).
   • security_key — Security keys (YubiKeys).

   Set session_duration to a duration string (for example, 30m, 1h, 24h). To require MFA on every access, use 0m.

After you turn on independent MFA, users can enroll authenticators through the App Launcher.

Restrict authenticators by AAGUID

An AAGUID ↗ (Authenticator Attestation GUID) is a 128-bit identifier that indicates the make and model of a WebAuthn ↗ authenticator. By restricting enrollment to a specific set of AAGUIDs, you can require that users only enroll approved hardware, such as FIPS-validated security keys or company-issued devices.

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.

Warning

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 ↗.

1. Create an AAGUID list

AAGUIDs are managed using Lists. Create a list of type AAGUID, then reference the list in your organization's MFA configuration.

Dashboard

1. In the Cloudflare dashboard ↗, go to Zero Trust > Resources > Lists.
2. Select Create new list.
3. Enter a List name (for example, Approved security keys) and an optional description.
4. Set List type to MFA AAGUIDs.
5. Add one or more AAGUID entries:
   • To add predefined AAGUIDs, select authenticators from the Known authenticators list.
   • To add a custom AAGUID, fill out the following fields:
     • MFA AAGUIDs — The AAGUID of the authenticator, in 32-character hexadecimal format without dashes (for example, 8c39ee867f9a4a959ba3f6b097e5c2ee).
     • Description — An optional label such as the authenticator's name and model.
6. Select Save.

API

Send a POST request to create the list:

Create Zero Trust list

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/lists" \
  --request POST \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{
    "name": "Approved security keys",
    "description": "AAGUIDs for MFA enrollment",
    "type": "AAGUID",
    "items": [
        {
            "value": "8c39ee867f9a4a959ba3f6b097e5c2ee",
            "description": "YubiKey Bio Series - FIDO Edition (Enterprise Profile)"
        }
    ]
  }'

The response contains an id (UUID) for the list. Use this ID when you assign the list to your organization's MFA configuration.

Tip

You can look up AAGUIDs for common authenticators in the FIDO Alliance Metadata Service ↗. Most vendors also publish AAGUIDs for their hardware on their support sites.

2. Assign an AAGUID list to your organization

Dashboard

1. In the Cloudflare dashboard ↗, go to Zero Trust > Access controls > Access settings.
2. Under Allow multi-factor authentication (MFA), go to Limit MFA to specific authentication methods.
3. Select an existing AAGUID list.
4. Select Save.

After you save, only authenticators whose AAGUIDs appear in the list can be enrolled. Users with previously enrolled authenticators outside the list can continue to use them until they are deleted by an administrator.

API

1. Get your existing Zero Trust organization configuration:

   Required API token permissions

   At least one of the following token permissions is required:

   • Access: Organizations, Identity Providers, and Groups Revoke
   • Access: Organizations, Identity Providers, and Groups Write
   • Access: Organizations, Identity Providers, and Groups Read

   Get your Zero Trust organization

   curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/organizations" \
     --request GET \
     --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

2. Send a PUT request to assign the list. To avoid overwriting your existing configuration, the PUT request body should contain all fields returned by the previous GET request. Set mfa_config.required_aaguids to the ID of your AAGUID list.

   Required API token permissions

   At least one of the following token permissions is required:

   • Access: Organizations, Identity Providers, and Groups Write

   Update your Zero Trust organization

   curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/organizations" \
     --request PUT \
     --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
     --json '{
       "auth_domain": "your-team-name.cloudflareaccess.com",
       "name": "Your Team Name",
       "mfa_config": {
           "allowed_authenticators": [
               "security_key",
               "totp",
               "biometrics"
           ],
           "session_duration": "24h",
           "required_aaguids": "05ddacda-5131-41ab-9eeb-6763f8dce3be"
       }
     }'

   To remove the restriction, set required_aaguids to null.

Note

AAGUID requirements and AMR matching 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.

Use identity provider MFA

If your identity provider already prompts users for MFA, you can configure Access to accept that MFA instead of prompting again. Access checks the Authentication Method Reference (AMR) claim returned by the IdP, as defined in RFC 8176 ↗. If the AMR value matches an allowed authenticator type for the application or policy, Access skips the independent MFA prompt.

Supported AMR values

AMR value	Matches Access authenticator type	Description
hwk	Security key	Proof-of-possession of a hardware key
swk	Security key	Proof-of-possession of a software key
otp	Authenticator application	One-time password
face	Biometrics	Facial recognition
fpt	Biometrics	Fingerprint
iris	Biometrics	Iris scan
retina	Biometrics	Retina scan
vbm	Biometrics	Voice biometric

Access ignores AMR values that do not map to a supported authenticator type (for example, pwd, sms, tel, geo, kba, sc, pin, user, mca, rba, wia).

Turn on AMR matching

Dashboard

1. In the Cloudflare dashboard ↗, go to Zero Trust > Access controls > Access settings.
2. Under Allow multi-factor authentication (MFA), turn on Use identity provider MFA.
3. Under Authentication Method Reference (AMR) matching duration, set how long a successful IdP MFA remains valid. During this period, users can log in to Access without an additional MFA prompt. You can set a custom duration (default 24 hours) or check for a valid AMR value on every login.
4. Select Save.

API

1. Get your existing Zero Trust organization configuration:

   Required API token permissions

   At least one of the following token permissions is required:

   • Access: Organizations, Identity Providers, and Groups Revoke
   • Access: Organizations, Identity Providers, and Groups Write
   • Access: Organizations, Identity Providers, and Groups Read

   Get your Zero Trust organization

   curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/organizations" \
     --request GET \
     --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

2. Send a PUT request to update your organization's AMR matching settings. To avoid overwriting your existing configuration, the PUT request body should contain all fields returned by the previous GET request.

   Required API token permissions

   At least one of the following token permissions is required:

   • Access: Organizations, Identity Providers, and Groups Write

   Update your Zero Trust organization

   curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/organizations" \
     --request PUT \
     --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
     --json '{
       "auth_domain": "your-team-name.cloudflareaccess.com",
       "name": "Your Team Name",
       "mfa_config": {
           "allowed_authenticators": [
               "totp",
               "biometrics",
               "security_key"
           ],
           "session_duration": "24h",
           "amr_matching_enabled": true,
           "amr_session_duration": "1h"
       }
     }'

When AMR matching is skipped

Access does not apply AMR matching in the following cases:

• AAGUID requirements 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 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.

In these cases, Access falls back to checking for existing MFA sessions. If there are no valid MFA sessions, Access prompts the user to complete independent MFA.

Note

Identity providers differ in how they populate the amr claim. Some providers, including Okta, may return provider-specific values such as pop that are not part of RFC 8176. Test the behavior with your IdP before relying on AMR matching for production applications.

Turn off independent MFA

Warning

Turning off independent MFA removes MFA protection on all Access applications. Before turning off independent MFA, verify that your Access policies provide adequate coverage. Remove custom MFA settings from any applications and policies that use it, then turn off independent MFA at the organization level.

To turn off independent MFA for the organization:

Dashboard

1. In the Cloudflare dashboard ↗, go to Zero Trust > Access controls > Access settings.
2. Under Allow multi-factor authentication (MFA), turn off Apply global MFA settings by default.
3. Turn off all MFA methods (Biometrics, Security key, and Authenticator application).

If you get an error updating MFA settings, ensure that you have removed custom MFA settings from all applications and policies.

API

1. Get your existing Zero Trust organization configuration:

   Required API token permissions

   At least one of the following token permissions is required:

   • Access: Organizations, Identity Providers, and Groups Revoke
   • Access: Organizations, Identity Providers, and Groups Write
   • Access: Organizations, Identity Providers, and Groups Read

   Get your Zero Trust organization

   curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/organizations" \
     --request GET \
     --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

2. Send a PUT request with an empty allowed_authenticators array. To avoid overwriting your existing configuration, the PUT request body should contain all fields returned by the previous GET request.

   Required API token permissions

   At least one of the following token permissions is required:

   • Access: Organizations, Identity Providers, and Groups Write

   Update your Zero Trust organization

   curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/organizations" \
     --request PUT \
     --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
     --json '{
       "auth_domain": "your-team-name.cloudflareaccess.com",
       "name": "Your Team Name",
       "mfa_config": {
           "allowed_authenticators": []
       }
     }'

Enroll authenticators

Users enroll authenticators through the App Launcher.

If a user already has at least one authenticator enrolled, Access requires them to verify with an existing MFA method before they can add a new authenticator.

To enroll an authenticator:

1. Go to your organization's App Launcher at <your-team-name>.cloudflareaccess.com.

2. Log in with your identity provider or with a one-time PIN (OTP).

3. Go to Account > MFA devices > Add an MFA device.

   Note

   Administrators can also share a direct enrollment link to help onboard users: <your-team-name>.cloudflareaccess.com/AddMfaDevice

4. If you already have an MFA device enrolled, complete the MFA verification prompt.

5. Select the authenticator type you want to enroll and follow the on-screen instructions.

   Authenticator application

   1. Select Authenticator application.
   2. Scan the QR code with your authenticator app (for example, Google Authenticator, Microsoft Authenticator, or Authy). Alternatively, you can manually enter the setup key into your authenticator app. Use SHA1 as the hash function and set the time-step size to 30 seconds.
   3. Enter the 6-digit time-based one-time password (TOTP) generated by your authenticator app to verify enrollment.

   Note

   You can only have one TOTP authenticator enrolled at a time. If you use multiple devices, scan the same QR code on each device during enrollment. To replace an existing TOTP authenticator, delete it first and then enroll a new one.

   Security key

   1. Select Security key.
   2. When your browser prompts you, insert your security key and follow the on-screen instructions.
   3. After your browser confirms the registration, the security key is enrolled.

   You can enroll multiple security keys for backup purposes.

   Biometrics

   1. Select Biometrics > Register biometrics.
   2. You will be prompted to enroll with an authenticator type that is available on your device (for example, Add macOS Touch ID or Add Windows Hello).
   3. After your browser confirms the registration, the platform authenticator is enrolled.

You can now use these authenticators to log in to your organization's applications.

Delete an authenticator

Users can delete their own authenticators from the App Launcher. If the user has at least one authenticator enrolled, Access requires them to verify with an existing MFA method before they can remove a device.

1. Go to your organization's App Launcher at <your-team-name>.cloudflareaccess.com.
2. Go to Account > MFA devices.
3. Select the 3-dot menu next to the MFA device, then select Remove MFA device.
4. If you have other MFA devices enrolled, complete the MFA verification prompt.

Administrators can also delete authenticators on behalf of users.

MFA verification for authenticator changes

When a user has at least one authenticator enrolled, Access requires MFA verification before the user can add or remove an authenticator from the App Launcher. This verification step is separate from the IdP login and uses the user's existing independent MFA device.

After the user completes MFA verification, they have 10 minutes to add or remove authenticators without additional prompts. This window is tied to the current device. After 10 minutes, or if the user switches to a different device, Access requires MFA verification again.

This prevents an attacker with compromised IdP credentials from modifying a user's enrolled authenticators. Even if an attacker gains access to the user's IdP session, they cannot bypass the independent MFA verification step without also possessing the user's enrolled authenticator. If a user loses their only authenticator and cannot verify, an administrator can delete it to allow re-enrollment. Refer to Manage user authenticators.

Note

MFA verification is not required when a user enrolls their first authenticator, since they do not yet have an MFA device to verify with.

Manage user authenticators

Administrators can view and delete authenticators enrolled by users. This is useful for resolving lockouts or responding to security events.

View user authenticators

To view a user's enrolled authenticators:

1. In the Cloudflare dashboard ↗, go to Zero Trust > Team & Resources > Users.
2. Select a user.
3. Go to MFA devices. Each entry shows the authenticator's ID, its user-configured name, and the MFA method.

Delete a user authenticator

If a user is locked out or you need to revoke an authenticator for security reasons, you can delete it from the dashboard or API.

Dashboard

1. In the Cloudflare dashboard ↗, go to Zero Trust > Team & Resources > Users.
2. Select the user whose authenticator you want to delete.
3. Under MFA devices, find the authenticator and select Delete.

The user will need to enroll a new authenticator the next time they access an application that requires MFA.

API

Send a DELETE request to remove a specific authenticator:

Delete a user's MFA device

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/users/$USER_ID/mfa_authenticators/$AUTHENTICATOR_ID" \
  --request DELETE \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

Parameters:

• user_id — The UUID of the user. You can find this in the user details under Team & Resources > Users.
• authenticator_id — The unique identifier for the authenticator.

Lockout recovery

If a user loses access to all of their enrolled authenticators:

1. Delete the user's authenticators.
2. The user can then access a protected application and will be provided a link to enroll a new authenticator.
3. Alternatively, share the direct enrollment link with the user: <your-team-name>.cloudflareaccess.com/AddMfaDevice.

Tip

To prevent lockouts, users should enroll multiple authenticators (for example, a security key and an authenticator application) when available.

Related links

• Enforce MFA on applications and policies