MFA and Authentication Standard Template

An authentication standard turns the policy line "MFA is required" into decisions an engineer can configure: which factors are allowed for which users, which must be phishing-resistant, how long a session lasts, and how someone gets back in after losing a device. This template uses the authenticator assurance levels (AAL1 to AAL3) of NIST SP 800-63B-4 as its spine, because they are public, specific and widely accepted by auditors. Requirements quoted from NIST are marked (NIST); everything else is a recommended default you should adjust.

How to use this template

1. Assign every user population to a tier in section 2. Start with privileged users, because that tier has the least room for exceptions.
2. Mark each factor in section 3 as allowed or not for each tier in your environment. Check which factors your applications actually support: the Phishing-Resistant MFA Support Matrix shows that many SaaS apps support passkeys but few let an admin require them.
3. Set session values in section 4 and configure them in your IdP and in each app's own session settings.
4. Write the recovery procedure in section 6 before you enforce anything. Recovery is where attackers go once MFA is in place.
5. Have the standard approved under your IAM policy and review it every [12] months.

Owner: [Identity team lead] | Approved: [date] | Applies to: [workforce / customers / both]

1. Definitions

• Phishing-resistant: NIST recognizes two methods, channel binding and verifier name binding (Sec. 3.2.5). Authenticators that rely on the user typing or approving an output, including OTP codes and out-of-band push or SMS, "SHALL NOT be considered phishing-resistant" (NIST). In practice this means WebAuthn/FIDO2 passkeys and security keys, and smart card or certificate-based authentication.
• Syncable authenticator: a passkey whose private key can be copied to other devices through a sync service (synced passkey). Allowed at AAL2; "syncable authenticators SHALL NOT be used at AAL3" (NIST).
• Restricted authenticator: the only one NIST names is the public telephone network (SMS or voice) for out-of-band codes. If you offer it you must offer a non-restricted alternative, tell users about its risks, and plan for its removal (NIST, Sec. 3.2.9).

See also: AAL, phishing-resistant MFA, phishable MFA.

2. Tiers by population

Guidance: if you are not a US federal agency, the "require at AAL2" rule does not bind you, but it is the clearest benchmark to cite when arguing for phishing-resistant MFA across the workforce. OMB M-22-09 set the same direction for federal agencies.

3. Allowed factors by tier

4. Sessions and reauthentication

NIST SP 800-63B-4 sets these limits (Sec. 2):

Our settings:

Guidance: set the value in the IdP and in each application. A short IdP session does not end a long-lived app session or refresh token. Where you can, bind sessions to the device (see token protection and DBSC) so a stolen cookie is not enough; see session cookie theft.

5. Passwords (where still used)

These rules are from NIST SP 800-63B-4 Sec. 3.1.1:

• Minimum length 15 characters when the password is the only factor; minimum 8 when it is used only as part of MFA (NIST).
• No composition rules such as required mixtures of character types (NIST).
• No periodic forced change; force a change only on evidence of compromise (NIST).
• Check new passwords against a blocklist of commonly used, expected or compromised passwords (NIST).
• Allow password managers and paste. [Our maximum length: 64 or more].

6. Enrollment and account recovery

NIST SP 800-63B-4 Sec. 4.2 recognizes four recovery methods: saved recovery codes, issued recovery codes, recovery contacts, and repeated identity proofing. "In all cases, account recovery SHALL cause a notification to be sent to the subscriber or their designee" (NIST).

Our rules:

• Users enroll at least two phishing-resistant authenticators (for example, a security key plus a platform passkey) so losing one is not a recovery event.
• First enrollment uses [a Temporary Access Pass issued after identity verification / in-person check / existing strong session]; see temporary access pass.
• Help desk MFA resets for T0 and T1 require [live video ID check against HR photo / manager callback on a known number / in-person]. Knowledge questions and caller ID are not sufficient.
• Every recovery and every new authenticator registration notifies the user on a channel other than the one used to recover, and alerts the security team for T0.
• Registering a new MFA method requires an existing strong authentication or the recovery process above. Protect the registration page with the same conditions as sign-in.
• T0 recovery requires two people.

Guidance: the MGM Resorts and Okta customer super admin takeovers began with help desk resets. See account recovery and help desk social engineering.

7. Legacy protocols and exceptions

• Legacy authentication that cannot do MFA (basic auth, older IMAP/POP/SMTP clients) is blocked. Exceptions are listed in [register] with an end date.
• Accounts that cannot use MFA (shared kiosks, some service integrations) are listed with a compensating control (network restriction, device restriction, no admin rights) and reviewed [quarterly].
• Non-human identities follow the NHI policy, not this standard.

8. Metrics

Control mapping

Related

• MFA implementation best practices
• MFA rollout guide
• Implementing passkeys in the enterprise
• Passkey rollout checklist
• How to choose an MFA solution
• NIST SP 800-63 and Conditional access policy plan worksheet