An agency security architect completes a Zero Trust readiness review. Authentication: checked. MFA: deployed across the workforce. Then the follow-up lands: “Is it phishing-resistant?”

That question now has a policy answer, and for a significant share of organizations running OTP or TOTP, the answer is no.

The Compliance Floor Moved

OMB Memorandum M-22-09 set a hard requirement for federal agencies: phishing-resistant MFA for all staff accessing federal systems, with deadlines that most agencies have already passed. CISA’s guidance is equally specific. Only two method categories qualify as phishing-resistant under federal policy: FIDO2/WebAuthn and PKI-based authentication, including CAC and PIV smart cards. OTP and TOTP, time-based one-time passwords, including those generated by authenticator apps, are explicitly excluded.

This is not a matter of interpretation. CISA’s Phishing-Resistant MFA Fact Sheet names the exclusions directly. For DoD environments, DISA’s Zero Trust Reference Architecture v2.0 reinforces CAC/PIV as the baseline identity assurance standard, with FIDO2 hardware tokens recognized as an approved supplement.

Organizations that have deployed OTP or TOTP and called their MFA requirement satisfied now have a rearchitecting problem. The earlier they recognize this, the less it costs.

What “Phishing-Resistant” Actually Means

The term has been diluted by overuse. The technical definition is precise.

Phishing-resistant MFA binds the authentication credential cryptographically to a specific origin. The authenticator, whether a smart card or a hardware security key, verifies not just the user’s identity but the legitimacy of the site or service requesting it. An adversary who intercepts the session gets nothing usable, because the credential cannot be replayed against a different origin.

OTP and TOTP don’t work this way. They authenticate the user. They don’t authenticate the origin. A sophisticated adversary who can intercept a session in real time can capture and replay a TOTP code within its validity window. Push bombing, SIM swapping, and SS7-based interception attacks all exploit this gap. These aren’t theoretical attack vectors. Credentials remain the most common initial access vector in enterprise breaches, appearing in more than 77% of web application incidents in recent years.

The line between phishing-resistant and merely compliant is where most authentication conversations now need to start.

Three Methods, Three Sets of Tradeoffs

For defense and federal environments, three phishing-resistant approaches define the decision space.

CAC/PIV. The Common Access Card remains the DoD baseline. It is hardware-backed PKI authentication: the private key lives on the card, cryptographic operations happen on the card, and nothing sensitive is exposed to the network. For environments where DoD identity assurance is the standard, CAC/PIV is the established answer.

The constraint is issuance. CAC requires in-person identity proofing and a sponsoring issuing authority with full credentialing infrastructure. Coalition partners, rapid-onboarding scenarios, and contractor environments outside the standard issuance pipeline all run into this. The authentication is strong. The logistics are the limiting factor.

FIDO2 hardware tokens. Physical security keys provide phishing-resistant authentication without the CAC issuance infrastructure. They use the same underlying principle - private keys never leave the device and authentication is bound to the registered origin - but can be provisioned without a credentialing authority. DISA recognizes them as an approved supplement where CAC issuance is impractical.

The deployment consideration for air-gapped and classified environments is authenticator management. FIDO2 infrastructure requires a considered approach to credential backup, recovery, and revocation, processes that assume some level of connected management infrastructure. In fully isolated environments, that infrastructure has to be replicated internally. This is a solvable problem, but it needs to be solved before deployment, not discovered during it.

Passkeys. Passkeys are FIDO2-based credentials stored in software, in a device’s secure enclave, synced through a platform account, or managed by a credential manager. They solve a real deployability problem for enterprise and consumer contexts. No physical hardware to provision or lose.

For classified and air-gapped environments, the calculus changes. Synced passkeys depend on a cloud account for credential continuity, an external dependency most high-security environments cannot accept. Device-bound passkeys avoid sync but reintroduce the hardware dependency passkeys were designed to eliminate. For defense and intelligence community deployments, passkeys are worth tracking as the standard matures and as vendors develop air-gap-compatible management architectures. But as a primary auth method in classified environments today, they introduce infrastructure dependencies that haven’t been resolved at scale.

Method Comparison

MethodPhishing-ResistantOffline CapabilityDoD/Gov CompatibleDeployment ComplexityCoalition Usability
OTP/TOTPNoYesPartialLowHigh
CAC/PIVYesYesPrimary standardHigh (issuance)Low
FIDO2 Hardware TokenYesYes (with prep)Approved supplementMediumMedium
Passkeys (synced)YesLimitedNot recommendedLowMedium
Passkeys (device-bound)YesYesEmergingMediumLow

Authentication Is Infrastructure

The method decision is not a security feature selection. It is an infrastructure decision, and it shapes everything downstream.

The choice of authentication method determines which devices can connect to sensitive channels, whether the system stays operational in DDIL conditions, whether a security review can produce a defensible audit record under CMMC or FedRAMP, and whether coalition partners operating under different identity frameworks can participate without being bottlenecked by issuance. An organization that selects CAC as its baseline and leaves the coalition authentication case unresolved ends up with federated workflows that exclude the people who need to be in them — often discovered mid-operation.

Getting this right requires working backward from operational requirements, not forward from deployment convenience. The organizations navigating this most cleanly are the ones who treat authentication architecture as a first-class design question rather than a deployment step.

Where Mattermost Fits

For organizations deploying Mattermost in high-security environments, the authentication architecture is a deployment decision built into the platform design.

Mattermost supports CAC/PIV authentication through SAML and LDAP integration. It deploys fully self-hosted — including in air-gapped and classified environments — so organizations retain complete control over identity provider (IDP) configuration, without a third-party SaaS layer inserted into the authentication chain. For multi-partner and coalition workflows, Mattermost federates identity across organizations using standards-based SAML/OIDC, supporting the interoperability cases that monolithic identity architectures can’t handle.

Mattermost addresses the Zero Trust User Management pillar by delegating the entire authentication flow to the existing IDP and the MFA option it supports. By avoiding a new auth flow, it simplifies the stack instead of adding to it.

The Compliance Date Is the Floor

Federal agencies and defense contractors now have a policy answer to the phishing-resistant question. The harder work is the operational one: which method holds up in your environment, survives DDIL conditions, scales to the partners who need access, and produces an audit record that satisfies your review authority?

Authentication is where Zero Trust compliance and operational continuity either converge or collide. Treating it as infrastructure from the start is what prevents the rearchitecting that happens when it’s treated as an afterthought.

Ready to design an authentication stack built for air-gapped and mission-critical environments? Talk to our team.