Implementing Multi-Factor Authentication in Zero Trust Frameworks

Multi-factor authentication (MFA) is an access control that requires a user to present two or more independent authenticators, drawn from different categories, before access is granted. Inside a zero trust program, MFA stops being a one-time login event and becomes a per-resource verification signal that the access decision engine can re-evaluate continuously.

The zero trust principle of “never trust, always verify” is defined in NIST SP 800-207, Zero Trust Architecture. The authenticator categories used below come from NIST SP 800-63B-4, Digital Identity Guidelines (Revision 4), which superseded the earlier upd2 revision on July 31, 2025 and reorganised authenticator types around syncable authenticators and passkeys. For an implementation-maturity reference, see CISA’s Zero Trust Maturity Model, which sets explicit expectations for MFA strength across the Identity pillar (Traditional, Initial, Advanced, Optimal).

Why MFA matters more in zero trust

NIST states the principle directly in SP 800-207: “Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location” (NIST SP 800-207, Zero Trust Architecture). That is the sentence that does the work. Once implicit trust is gone, every access request needs a fresh authentication signal, and MFA is one of the strongest such signals available.

Perimeter security treated identity as a one-shot decision at login. Zero trust treats identity as a signal that feeds every access decision: per-request, per-resource, and across the session lifetime. That shift changes the MFA picture in two specific ways.

First, MFA becomes a continuous control, not a daily ceremony. Step-up authentication kicks in when the access decision engine sees a risk signal: new device, unfamiliar geo, sensitive resource, anomalous behaviour. The user authenticated at 9am does not get the same trust budget at 4pm if context drifts.

Second, the strength of the factor matters. A password plus SMS does not survive a SIM-swap attack, and SMS-based one-time codes were the cracked layer in the 0ktapus campaign of August 2022 that breached Twilio, Cloudflare, and over a hundred other organisations through SMS-relayed phishing (CISA: Implementing Phishing-Resistant MFA). A phishing-resistant authenticator (FIDO2 hardware key, platform passkey, smartcard) does survive, because the cryptographic challenge is bound to the relying party and cannot be replayed by a proxy site.

The four authenticator categories (NIST 800-63B)

NIST 800-63B groups authenticators by what they prove about the user:

1. Something you know (memorized secret): passwords, PINs. Weakest factor on its own; vulnerable to phishing, credential stuffing, and reuse.
2. Something you have (possession): a phone running an authenticator app, a hardware security key, a smartcard. Strength depends entirely on the implementation. SMS is weakest; FIDO2 hardware keys are strongest.
3. Something you are (biometric): fingerprint, face, voice. Used in 800-63B as an authenticator activation factor, typically paired with a possession factor (the phone or token that holds the cryptographic material).
4. Out-of-band channels - an authenticator that uses a separate communication channel (push notification to an enrolled device). 800-63B requires that the channel be distinct from the primary one and that no shared secret traverses both.

“Something you are” is not a standalone authenticator in 800-63B. The biometric unlocks a possession factor; the possession factor is what the relying party verifies. This distinction matters when you are mapping vendor claims to AAL levels.

NIST AAL levels: what they actually require

NIST 800-63B defines three Authenticator Assurance Levels.

AAL1 permits single-factor authentication, including memorized secret alone. Acceptable for low-sensitivity access. Not appropriate for any system holding regulated data, controlled goods information, CUI, or financial credentials.

AAL2 requires two distinct authenticator categories, with the possession factor proving possession of the authenticator at the time of authentication. Most modern enterprise SaaS targets AAL2. TOTP, push notifications with number matching, and hardware keys all qualify.

AAL3 requires a hardware-based authenticator that is also a verifier-impersonation-resistant (phishing-resistant) factor with a non-exportable key. The current path to AAL3 is a FIDO2 hardware security key, a smartcard with PIV/CAC credentials, or a device-bound platform passkey backed by a hardware-protected, non-syncable credential. NIST SP 800-63B-4 explicitly excludes syncable authenticators from AAL3, so cloud-synced consumer passkeys do not qualify. AAL3 is the right design target for high-sensitivity systems, privileged accounts, and remote access to controlled environments.

A program that targets AAL2 broadly and AAL3 for privileged accounts is the right shape for most regulated organisations. For CMMC Level 2 (currently assessed against NIST SP 800-171 Rev 2 under 32 CFR Part 170), the MFA control IA.L2-3.5.3 requires multi-factor authentication for local and network access to privileged accounts and network access to non-privileged accounts, but does not by default mandate AAL3-strength authenticators. AAL3 or phishing-resistant MFA is the appropriate design target for privileged administration, remote access, and high-risk systems, and may be required by a specific contract, agency overlay, or assessor instruction. The same risk-based posture applies to CPCSC Level 2 readiness against ITSP.10.171.

Phishing-Resistant MFA: what counts and what does not

The phrase “phishing-resistant MFA” has a specific meaning in current US federal guidance and a near-identical Canadian counterpart. Phishing-resistant means the authenticator cryptographically binds the authentication to the relying party’s domain, so a proxy phishing site cannot relay the credential.

What qualifies:

• FIDO2 hardware security keys (YubiKey, Titan, Feitian) using WebAuthn
• Device-bound platform passkeys on managed devices (Apple, Microsoft, Google) backed by hardware-protected, non-syncable credentials (cloud-synced consumer passkeys do not qualify for AAL3)
• Smartcards with PIV / CAC credentials

What does not qualify:

• SMS one-time codes
• Voice-call one-time codes
• TOTP apps (Authenticator, Authy) on their own
• Push notifications without number matching or device-bound assertion

TOTP is a meaningful improvement over passwords, and push-with-number-matching is meaningful over plain push, but neither survives a determined adversary-in-the-middle attack against a high-value target. For executive and privileged accounts, the calculus is simple: deploy FIDO2 first, accept the procurement and onboarding friction, and treat TOTP as a fallback during transition.

A rollout sequence that actually works

The single biggest cause of failed MFA programs is rolling out to everyone at once. Plan in tiers.

1. inventory every authentication surface

SSO covers most apps; the long tail is what bites. Marketing-tool admin consoles, the bookkeeper’s accounting login, the CAD vendor portal, the prime contractor’s sharing site. Map every account that touches sensitive data, with the actual login URL, before announcing a deadline.

2. pilot on privileged accounts first

Domain admins, cloud root and break-glass, finance approval roles. These are the smallest user populations and the highest-blast-radius accounts. Deploy FIDO2 to them before touching general staff.

3. set the MFA policy and the exception process in writing

Who can be exempt, for how long, with what compensating control, and who signs off. An exception register that is empty after 90 days is the goal; an exception register that quietly grows is the early warning of program drift.

4. roll out to general staff in cohorts

Department by department, with a short hand-off window per cohort. Provide self-service enrolment and a clear path for recovery (a published help-desk channel, backup codes issued at enrolment).

5. decommission the weaker factors

Once general staff have a working AAL2 setup, remove SMS as an option. Do not leave it as an emergency fallback; it is the path the attacker will use.

6. add step-up to high-risk actions

Once baseline MFA is universal, add a second prompt at the actions that actually matter: wire transfers, key rotations, role changes, data exports. The friction of a single re-auth at the moment of an irreversible action is far smaller than the cost of getting one wrong.

Pitfalls that quietly erode the program

Watch for these patterns. They show up in environment after environment.

Authenticator app sprawl. Users end up with TOTP seeds in Authy on one phone, Google Authenticator on another, Microsoft Authenticator for a third tenant, and lose them all the next time a phone replaces. Standardise on one authenticator app per organisation, document the recovery path, and test it.

SMS fallback that never gets removed. “Just in case” SMS fallback for a small population becomes “everyone uses SMS when push fails.” Audit who actually uses SMS in any given month; if the number is not declining, the fallback is not a fallback.

MFA bombing. Push-based MFA without number matching is vulnerable to authenticator bombardment. Microsoft, Okta, and Duo have all shipped number-matching defaults; verify the setting is enforced and audited.

Service accounts and API keys outside MFA. A service account with a long-lived API key in an environment file is the single most common bypass on otherwise-MFA-clean environments. Treat service accounts as a separate access path, with rotation and just-in-time elevation.

Recovery flows that are weaker than the front door. Help desk staff who can reset MFA without re-verifying identity are the new attack surface. The recovery flow should require at least the same factor strength as the original login.

Where to spend your effort first

If you only have time to make three changes this quarter:

• Deploy FIDO2 to every privileged account and remove SMS from those accounts.
• Enforce number matching on every push-based MFA prompt.
• Build a real account inventory and confirm MFA coverage on every SaaS that touches sensitive data.

Those three moves close the highest-value gaps that show up in incident reports. Everything else is refinement.

How pilotcore helps

Pilotcore runs MFA rollouts inside zero trust programs for regulated Canadian organisations, including defence suppliers preparing for CPCSC Level 1 and Level 2, and US contractors working through CMMC. Nelson Ford, principal at Pilotcore and based in Ottawa, is a CISSP and CMMC Certified Professional, and works with technical teams on the rollout sequence above plus the policy and evidence work that goes with it. For the broader zero trust architectural context, see our companion posts on zero trust micro-segmentation and AI and machine learning in zero trust. Book a zero trust readiness conversation.

Frequently asked questions

What is multi-factor authentication (MFA) in zero trust?

MFA is an access control that requires a user to present two or more independent authenticators from different categories before access is granted. Inside zero trust, MFA stops being a one-time login event and becomes a per-resource verification signal that the access decision engine can re-evaluate continuously.

What are the NIST AAL levels?

NIST SP 800-63B defines three Authenticator Assurance Levels. AAL1 permits single-factor authentication. AAL2 requires two distinct authenticator categories and is the right target for most enterprise SaaS. AAL3 requires a hardware-based phishing-resistant authenticator and is required for privileged accounts and high-sensitivity remote access.

What is phishing-resistant MFA?

Phishing-resistant means the authenticator cryptographically binds the authentication to the relying party's domain, so a proxy phishing site cannot relay the credential. FIDO2 hardware keys, smartcards with PIV/CAC credentials, and verifier-resistant platform passkeys qualify. SMS, voice, plain TOTP, and push notifications without number matching do not.

Is SMS-based MFA still acceptable?

SMS one-time codes are a meaningful improvement over passwords alone, but they do not survive a SIM-swap attack or an adversary-in-the-middle phishing kit. Treat SMS as a transition fallback only, not as the destination state for any account that touches sensitive data.

Where should an MFA rollout start?

Start with privileged accounts. Domain administrators, cloud root and break-glass accounts, finance approval roles, and security operations accounts are the smallest user populations and the highest-blast-radius accounts. Deploy FIDO2 to those accounts before touching general staff, then expand in cohorts.

What is MFA bombing and how do you stop it?

MFA bombing is when an attacker who has a valid password issues repeated push-notification prompts until the user approves one by accident or fatigue. The defence is number matching, where the user must type a number shown on the requesting device into the authenticator. Microsoft, Okta, and Duo have all shipped number-matching defaults; verify the setting is enforced and audited.