MFA Is Not a Checkbox: Understanding Authenticator Assurance Levels

A sign-in page may ask for two codes and report that multi-factor authentication is complete. But the number of prompts alone says little about independence or resistance. Good policy begins with the properties of the credential, not the number of boxes checked.

Two accounts compared, both showing multi-factor authentication enabled: one with a passkey and a security key, the other with two factors both delivered to the same mailbox. — Both show two factors. Only one has two failures.

Distinguish factor type from protocol name

Knowledge, possession and inherence describe broad factor types. A protocol such as email OTP, TOTP, a password or WebAuthn has particular characteristics, but its assurance depends on implementation and the signals the verifier can trust. Two credentials that look different in the interface may still rely on the same factor type.

WebFrolic documents configurable assurance requirements and administrator-defined authenticator characteristics where the protocol does not provide enough server-verifiable signal. Such configuration needs care: labelling a method “strong” does not make it strong.

Match assurance to the action

Reading a low-risk page, changing a recovery method and granting an administrator role are different decisions. Define assurance by operation and determine when step-up authentication is needed. Requiring the strongest method for every action can create needless friction; using the same threshold everywhere can be unsafe.

Apply policy consistently across dashboards, applications and role assumptions. A previous strong sign-in should not automatically authorise every later change if the session context or operation requires renewed proof.

Understand the limits of labels

The WebFrolic security paper describes levels including AAL1, AAL1_Strong, AAL2, AAL2_strong and AAL3. The “strong” intermediate levels are product extensions; do not present them as identical to formal standard-defined levels. Explain the accepted factor combinations and the actual requirements.

Two possession authenticators may offer more protection than one, but they do not automatically become two distinct factor types. Phishing resistance and device binding introduce further distinctions. A clear policy says what was proved instead of relying on a label alone.

Test policy at the boundaries

Test enrollment, sign-in, step-up, role assumption, recovery and credential changes under each relevant level. Include negative cases: the wrong authenticator combination, a newly enrolled factor, a stale session or a flow that has not completed all required checks.

Review the user experience as well as the control. If a user cannot update a credential because a stronger requirement applies, provide a documented recovery or administrator-assisted route that does not quietly bypass the requirement.

The point

Map each authenticator to verifiable factor characteristics. Then: map each authenticator to verifiable factor characteristics; set assurance requirements by operation and identity class; distinguish product-specific levels from standard-defined levels.

Implementation guide

Turn an assurance label into an enforceable policy

A dashboard badge that says “MFA enabled” tells you little about the risk of a sensitive operation. Were the factors genuinely distinct? Is one phishing-resistant? Was the user asked to prove an already-enrolled factor before adding a new one? Does the assurance requirement apply to the change itself, or only to the original login?

Start with factor properties, not marketing names

Classify authenticators by the security properties they actually provide: knowledge, possession, inherence, phishing resistance, device binding and user verification where those properties can be verified. Do not assume that two different product names represent two independent factors. Two possession factors may add resilience but are not automatically equivalent to two distinct factor types under a standards-defined assurance model.

NIST SP 800-63B-4 defines assurance levels and requirements for its scope. WebFrolic's product materials describe configurable levels, including product-specific intermediate labels. Keep those two things distinct: a WebFrolic label should not be presented as a NIST conformance claim unless the complete requirement set has been assessed.

Example: bind the requirement to the action

# Illustrative policy model — not a WebFrolic configuration format
policies:
  view_own_profile:
    minimum_assurance: "standard-login"
  export_tenant_members:
    minimum_assurance: "two-distinct-factor-types"
  change_authenticators:
    require_existing_factor: true
    re_evaluate_assurance: true
  grant_platform_admin:
    minimum_assurance: "phishing-resistant"
    require_audit_reason: true

The names above are descriptive placeholders, not NIST AAL labels or product configuration keys. The important choice is that different actions can require different evidence, and credential changes cannot silently weaken the requirement.

Authenticator change should not bypass assurance

Verify existing evidence
Enroll new authenticator
Re-evaluate required assurance
Record and notify

Watch for the enrollment trap

Suppose a session has enough proof to change a low-risk profile field but not enough to change a privileged recovery factor. If the system permits enrollment of a new factor without a fresh check, the user may satisfy the new requirement using a factor that was just added by someone who already hijacked the session. The policy must protect the credential-change operation itself.

Test the policy

Assurance test checklist

✓Each authenticator has documented factor and phishing-resistance characteristics.
✓Two credentials of the same factor type are not automatically treated as two distinct factors.
✓High-risk actions and authenticator changes re-evaluate the required evidence at the time of action.
✓Recovery does not become an undocumented shortcut around the assurance policy.
✓Tests cover enrollment, removal, replacement, lost factors, stale sessions and administrator-assisted recovery.