# MFA and Authentication Standard Template

Source: https://startwithidentity.com/templates/mfa-authentication-standard/
Last updated: 2026-11-05
License: content by Start with Identity. Cite the source URL.

---

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](https://pages.nist.gov/800-63-4/sp800-63b.html) 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](https://startwithidentity.com/tools/mfa-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](https://startwithidentity.com/templates/identity-and-access-management-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](https://startwithidentity.com/standards/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](https://startwithidentity.com/glossary/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](https://startwithidentity.com/glossary/aal/), [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [phishable MFA](https://startwithidentity.com/glossary/phishable-mfa/).

## 2. Tiers by population

| Tier | Who | Target AAL | Phishing-resistant | Notes |
|------|-----|-----------|--------------------|-------|
| T0 Privileged | Domain, cloud and IdP admins; break-glass; CI/CD and secrets admins; `[others]` | AAL3 | Required **(NIST at AAL3)** | Device-bound keys only (no synced passkeys) |
| T1 Workforce | All employees and contractors | AAL2 | Required by `[date]`; until then strongly preferred | NIST: AAL2 verifiers must *offer* a phishing-resistant option, and federal agencies must *require* it for staff, contractors and partners |
| T2 Customers and partners with admin rights in our product | `[ ]` | AAL2 | Offered, admin-enforceable | |
| T3 Customers | End users of `[product]` | AAL1 or AAL2 by risk | Offered | Step up to AAL2 for `[payments, profile change, export]` |

> 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](https://startwithidentity.com/regulations/united-states/omb-m-22-09/) set the same direction for federal agencies.

## 3. Allowed factors by tier

| Factor | Phishing-resistant | T0 | T1 | T2 | T3 | Notes |
|--------|-------------------|----|----|----|----|-------|
| Device-bound passkey or FIDO2 security key | Yes | Allowed | Allowed | Allowed | Allowed | Preferred everywhere |
| Synced passkey | Yes | **Not allowed** | Allowed | Allowed | Allowed | Not permitted at AAL3 |
| Smart card / PIV / certificate-based authentication | Yes | Allowed | Allowed | `[ ]` | No | Needs PKI |
| Platform authenticator with device-bound key (e.g., Windows Hello for Business) | Yes | `[Allowed if device-bound and managed]` | Allowed | `[ ]` | `[ ]` | |
| Push approval with [number matching](https://startwithidentity.com/glossary/number-matching/) | No | No | Transitional until `[date]` | Allowed | Allowed | Reduces [MFA fatigue](https://startwithidentity.com/techniques/mfa-fatigue-push-bombing/), does not stop [AitM proxies](https://startwithidentity.com/techniques/aitm-phishing-proxy/) |
| TOTP app | No | No | Transitional until `[date]` | Allowed | Allowed | |
| SMS or voice OTP | No (restricted) | No | No | No | Fallback only, with a non-restricted alternative offered | |
| Email OTP or [magic link](https://startwithidentity.com/glossary/magic-link/) | No | No | No | No | `[Allowed for AAL1 only]` | |
| Password alone | No | No | No | No | AAL1 only | |

## 4. Sessions and reauthentication

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

| Level | Overall session limit | Inactivity limit |
|-------|----------------------|-----------------|
| AAL1 | SHOULD be no more than 30 days | MAY be applied, not required |
| AAL2 | SHOULD be no more than 24 hours | SHOULD be no more than 1 hour |
| AAL3 | SHALL be no more than 12 hours | SHOULD be no more than 15 minutes |

Our settings:

| Tier | Max session | Idle timeout | Reauthenticate for |
|------|-------------|--------------|--------------------|
| T0 | `[12 hours]` | `[15 minutes]` | Every privilege elevation |
| T1 | `[24 hours]` | `[1 hour, or device lock on managed devices]` | `[sensitive apps, admin portals]` |
| T2 | `[ ]` | `[ ]` | `[ ]` |
| T3 | `[ ]` | `[ ]` | `[step-up actions]` |

> 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](https://startwithidentity.com/glossary/device-bound-session-credentials/)) so a stolen cookie is not enough; see [session cookie theft](https://startwithidentity.com/techniques/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](https://startwithidentity.com/glossary/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](https://startwithidentity.com/breaches/incidents/2023-mgm-resorts-help-desk-ransomware/) and [Okta customer super admin takeovers](https://startwithidentity.com/breaches/incidents/2023-okta-customer-help-desk-super-admin-takeover/) began with help desk resets. See [account recovery](https://startwithidentity.com/glossary/account-recovery/) and [help desk social engineering](https://startwithidentity.com/techniques/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](https://startwithidentity.com/templates/service-account-non-human-identity-policy/), not this standard.

## 8. Metrics

| Metric | Target | Current |
|--------|--------|---------|
| T0 accounts using only phishing-resistant methods | 100% | `[ ]` |
| T1 users with a phishing-resistant method registered | `[ ]%` by `[date]` | `[ ]` |
| Sign-ins using phishing-resistant methods | `[ ]%` | `[ ]` |
| SMS/voice still registered (T1) | 0 by `[date]` | `[ ]` |
| Open MFA exceptions past expiry | 0 | `[ ]` |

## Control mapping

| Section | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A |
|---------|-----------------------|----------------------------|
| 2, 3 Tiers and factors | IA-2(1), IA-2(2) Multi-factor Authentication; IA-2(8) Access to Accounts: Replay Resistant | 8.5 Secure authentication |
| 4 Sessions | IA-11 Re-authentication; AC-11 Device Lock; AC-12 Session Termination | 8.5 |
| 5 Passwords | IA-5(1) Password-based Authentication | 5.17 Authentication information |
| 6 Recovery | IA-5 Authenticator Management; IA-12 Identity Proofing | 5.17 |
| 7 Exceptions | IA-2 | 5.15 Access control |

## Related

- [MFA implementation best practices](https://startwithidentity.com/guides/authentication/mfa-implementation-best-practices/)
- [MFA rollout guide](https://startwithidentity.com/guides/authentication/mfa-rollout/)
- [Implementing passkeys in the enterprise](https://startwithidentity.com/guides/authentication/implementing-passkeys-enterprise/)
- [Passkey rollout checklist](https://startwithidentity.com/templates/passkey-rollout-checklist/)
- [How to choose an MFA solution](https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-mfa-solution/)
- [NIST SP 800-63](https://startwithidentity.com/regulations/united-states/nist-sp-800-63/) and [Conditional access policy plan worksheet](https://startwithidentity.com/templates/conditional-access-policy-plan-worksheet/)