Zero trust is no longer a buzzword. It's a security architecture that major enterprises, government agencies, and increasingly mid-market organizations are actively implementing. At the center of every zero trust architecture is identity — and at the center of identity security is multi-factor authentication.
This guide explains zero trust, its authentication requirements, and what IT teams need to do to align their MFA practices with zero trust principles.
What Zero Trust Actually Means
Zero trust is based on a single principle: never trust, always verify.
Traditional network security assumed that anything inside the network perimeter was trustworthy. VPN access meant "you're in, you're trusted." This model broke down when:
- Work moved to the cloud (resources are no longer inside the perimeter)
- Remote work became standard (users are no longer inside the perimeter)
- Attackers learned to establish footholds inside networks (the perimeter was breached)
Zero trust abandons the notion of a trusted perimeter. Instead, every access request — regardless of origin — is:
- Authenticated: who is this user?
- Authorized: is this user allowed to access this resource?
- Verified: is this device in a good security state?
- Logged: what did they do?
This happens for every request, not just at the moment of initial login.
Why MFA Is Central to Zero Trust
In a zero trust architecture, identity is the new perimeter. If identity verification fails — if an attacker can authenticate as a legitimate user — the entire model fails.
This is why MFA is non-negotiable in zero trust:
- Passwords alone are insufficient: phishing, credential stuffing, and data breaches make single-factor authentication unreliable
- Context is not enough: knowing a user's IP or device profile is not sufficient to establish identity
- MFA establishes verifiable identity: the combination of something you know and something you have is significantly harder to bypass than either alone
NIST's zero trust framework (SP 800-207) explicitly identifies identity verification — including MFA — as a foundational component.
Zero Trust MFA Requirements
Not all MFA is equally strong in a zero trust context. The zero trust standard is phishing-resistant MFA:
TOTP (Time-based OTP) — Good
Rolling 6-digit codes from an authenticator app. Significantly stronger than SMS. However, TOTP is technically phishable: a sophisticated phishing page can capture a TOTP code in real time and replay it immediately. In practice, this requires targeted, real-time attacks rather than mass phishing.
For most organizations, TOTP is a sufficient second factor for most systems.
FIDO2/WebAuthn — Preferred for Zero Trust
Hardware security keys (YubiKey, Google Titan) or platform authenticators (Touch ID, Windows Hello) that use public-key cryptography. The key differentiator: FIDO2 is phishing-proof by design. The authentication is bound to the specific domain — a phishing site at examp1e.com cannot receive a valid FIDO2 response for example.com.
For high-value access (production infrastructure, financial systems, admin consoles), FIDO2 is the appropriate second factor in a zero trust architecture.
SMS OTP — Insufficient for Zero Trust
SMS-based OTP is vulnerable to SIM-swapping and real-time phishing. In a zero trust context, SMS OTP does not meet the bar for strong authentication. If you're still using SMS OTP for any privileged access, replacing it is a priority.
Authentication Factors in Zero Trust Context
Zero trust adds additional signals beyond the authentication factors themselves:
Device posture: is the device managed, encrypted, and compliant with security policy? A valid authentication from an unmanaged device should receive lower trust than the same authentication from a managed, compliant device.
Risk signals: is this login from an unusual location? An unusual time? A new device? Risk-based authentication adjusts requirements based on context — requiring step-up authentication for suspicious signals.
Continuous verification: zero trust architectures re-verify authentication throughout a session, not just at login. A session that was authenticated an hour ago may need re-verification before accessing a sensitive resource.
This is why zero trust is often implemented through an identity provider (IdP) like Okta, Azure AD, or Google Workspace — these platforms provide the policy engine for combining authentication, device posture, and risk signals.
Managing MFA Codes in a Zero Trust Architecture
Zero trust doesn't just change how authentication works — it changes the requirements for how MFA codes are managed.
In a zero trust context, MFA code management must be:
Organizational, not personal: OTP secrets for shared accounts must be in organizational control — a team vault — not on personal phones. Personal devices are not subject to organizational security controls.
Access-controlled: who can generate an OTP for a given account should be explicitly controlled by policy, not implicit through account sharing.
Auditable: every authentication event should be logged. Zero trust requires logging of "who accessed what, when, from where" for all access — including MFA-protected access.
Centrally revocable: when a user leaves, all their access — including access to shared MFA codes — should be revocable immediately from a central point.
A team MFA vault like Gatera provides this organizational layer: centralized storage, role-based access, full audit logging, and instant revocation.
Implementing Zero Trust MFA — A Phased Approach
Phase 1: Foundation
- Ensure MFA is enabled for all admin and privileged accounts
- Replace SMS OTP with TOTP where possible
- Move shared OTP codes from personal phones to a team vault
- Establish audit logging for authentication events
Phase 2: Strengthen
- Migrate high-value admin access to FIDO2/WebAuthn
- Implement device posture checks in your IdP
- Enable risk-based authentication (step-up auth for unusual signals)
- Integrate authentication logs into your SIEM
Phase 3: Mature
- Implement continuous verification within sessions
- Add network-level zero trust (VPN replacement with ZTNA)
- Establish per-application access policies through an identity-aware proxy
- Regular red team exercises targeting authentication bypass
Common Zero Trust MFA Mistakes
Treating MFA as "done": enabling MFA is the beginning, not the end. The management layer — token storage, access control, audit logging, revocation — is where most organizations have gaps.
Inconsistent enforcement: zero trust with exceptions isn't zero trust. Every privileged access point must require strong MFA.
Weak second factors: using SMS OTP in a zero trust context undermines the entire model. Strong second factors (TOTP minimum, FIDO2 preferred) are required.
No device verification: MFA establishes who a user is, but not the security state of their device. A compromised device can successfully complete MFA. Device posture is the additional layer zero trust adds.
Long session lifetimes: a 30-day "remember this device" session is not compatible with zero trust. Sessions should be short-lived and continuously re-verified for sensitive access.
Conclusion
Zero trust elevates MFA from an optional control to a foundational requirement. But it also raises the bar for how MFA is managed — organizational token storage, access control, audit logging, and instant revocation are all part of what zero trust-aligned MFA management looks like.
For IT teams starting their zero trust journey, authentication is the right place to start. It has the most impact, and it's where most organizations have the most room to improve.
Explore Gatera → — team MFA management aligned with zero trust principles.