Replay-Resistant vs. Phishing-Resistant Authentication

Why this distinction matters

Walk into almost any defense-contractor security meeting and you’ll hear “we have MFA, so we’re covered.” That statement hides a trap. Not all MFA is created equal, and the two properties in this article are exactly where the quality line gets drawn.

The confusion is understandable. Both terms describe resistance to a credential-theft attack. Both show up in NIST guidance. Both are satisfied by “using MFA.” So people treat them as synonyms — and then implement a form of MFA that technically checks the compliance box while leaving the front door open to the single most common attack of the last three years: adversary-in-the-middle (AiTM) phishing.

Getting this right is not academic. Your authentication choice determines whether a phished employee is a near-miss or a full account takeover — and, for CUI environments, whether an assessor’s finding is “met” or “not met.”

What each term actually means

Replay-resistant authentication

An authentication process is replay-resistant when it is impractical to authenticate successfully by recording and replaying a previous authentication message.

The classic replay attack: an attacker captures network traffic (or a hashed credential, or a one-time code) during a legitimate login, then re-transmits that same captured data later to impersonate the user. Replay resistance defeats this by making every authentication exchange unique and non-reusable.

Techniques that provide replay resistance include:

• Time-synchronous one-time passwords (TOTP — e.g., Google Authenticator, RSA tokens)
• Challenge-response protocols that use a nonce (a one-time random value)
• Kerberos (built-in replay protection via timestamps and tickets)
• TLS (session-level protection against replay)
• PKI / smart cards and FIDO2 tokens

The key idea: a captured login is worthless a moment later because the code has expired, the nonce won’t match, or the session token is stale.

Phishing-resistant authentication

An authentication method is phishing-resistant when it cannot be tricked out of the user by a fake verifier — a counterfeit login page standing in for the real one. NIST’s technical term for this property is verifier impersonation resistance, defined in NIST SP 800-63B.

Phishing-resistant authenticators work by cryptographically binding the authentication to the real relying party’s origin (the actual website’s domain). If the login isn’t happening on the genuine site, the cryptographic signature simply won’t validate — so a phishing site captures nothing it can use.

There are essentially two widely available phishing-resistant mechanisms today:

1. PIV / CAC smart cards — public-key authentication over client-authenticated TLS; the federal government standard.
2. FIDO2 / WebAuthn — modern security keys (YubiKey and similar) and passkeys built into phones and laptops.

Everything else — passwords, SMS codes, TOTP apps, and push-approval prompts — is not phishing-resistant.

The critical difference, in one example

Here is the distinction that matters most, and it surprises people every time:

A TOTP code from an authenticator app is replay-resistant, but it is not phishing-resistant.

How can both be true?

• Replay-resistant: If an attacker records that 6-digit code and tries to reuse it two minutes later, it’s expired and useless. Replay defeated.
• Not phishing-resistant: If an attacker stands up a fake login page (using an AiTM toolkit like Evilginx), the victim types their username, password, and the live TOTP code into the counterfeit site. The attacker’s proxy relays all three to the real site in real time, within the code’s validity window — and steals the resulting session cookie. This isn’t “replay later.” It’s real-time relay plus session hijack, and TOTP does nothing to stop it because the code was never bound to the real destination.

A FIDO2 passkey or a PIV card breaks that attack cold: the authentication is bound to the genuine domain, so when the browser is pointed at the phishing site, there is no valid signature to relay. The attacker gets an empty hand.

Where each requirement actually lives

This is where the popular “Rev 2 vs. Rev 3” shorthand falls apart. Here is what the source documents actually say:

Two corrections fall out of this table:

1. Replay resistance did not disappear in Rev 3. It carries forward as control 03.05.04. If anything, Rev 3 strengthened it by replacing “network access” with plain “access,” which pulls local/console logins into scope.
2. “Phishing-resistant” is not a numbered 800-171 requirement — not in Rev 2, and not in the Rev 3 base controls. The term and its technical definition come from NIST SP 800-63B. The mandate to use it comes from OMB Memorandum M-22-09, which requires phishing-resistant MFA across federal agencies, and it is heavily promoted by CISA. For higher-assurance environments, phishing-resistant authentication also appears in NIST SP 800-172, the enhanced-security companion to 800-171.

So the accurate way to describe the evolution is: 800-171’s enforceable bar is still MFA (03.05.03) plus replay resistance (03.05.04) — while the surrounding federal ecosystem has moved decisively toward phishing-resistant MFA as the expected standard of care.

What this means for CMMC and CUI

If you’re a defense contractor, here’s how to translate all of this into action.

Know which revision your contract invokes. CMMC Level 2 is built on NIST SP 800-171, and the control you are assessed against for replay resistance is IA.L2-3.5.4 (Rev 2). The DoD’s move from Rev 2 to Rev 3 is a phased matter tied to updates in the DFARS 252.204-7012 clause — verify which revision your specific contract cites before you scope an assessment, because the control text and numbering differ between revisions.

Meet the letter of the requirement — then aim higher. Replay-resistant MFA satisfies the control. But assessors increasingly expect to see that you understand modern threats, and your cyber-insurance carrier and prime contractors may ask for phishing-resistant MFA outright. Implementing phishing-resistant methods satisfies the replay-resistant control and closes the AiTM gap in one move.

Prioritize by blast radius. You do not have to convert the entire workforce overnight. Deploy phishing-resistant authentication where a compromise hurts most, first:

1. Privileged / administrator accounts — highest priority, no exceptions.
2. Remote access (VPN, remote desktop, cloud admin consoles).
3. Anyone who touches CUI.
4. The general workforce, as a rollout.

Common mistakes to avoid

• Treating “we have MFA” as the finish line. SMS and push-approval MFA are the weakest tiers and phishable.
• Assuming TOTP is phishing-resistant. It is replay-resistant only — the single most common misconception on this topic.
• Leaving legacy authentication protocols enabled, which lets attackers bypass MFA entirely.
• Enrolling users but not enforcing the policy — an unenforced control is a not-met finding.
• Forgetting break-glass accounts and recovery paths when you roll out hardware-bound authenticators.
• Assuming your CUI cloud supports the same features as commercial. In GCC High and other government clouds, confirm phishing-resistant options are provisioned before you design around them.

How to get it right

For most defense contractors, the practical path is:

1. Inventory every account, starting with admins and remote access.
2. Turn on phishing-resistant methods your platform supports — FIDO2 security keys, passkeys, or certificate-based authentication (CAC/PIV).
3. Enforce those methods for privileged and remote users first, then expand.
4. Disable legacy authentication that bypasses MFA.
5. Document the policy, the enforcement configuration, and your recovery procedures — that documentation is your evidence at assessment time.

This is precisely the work behind the DoW “Brilliant at the Basics” IT-01 priority: Phishing-Resistant Multi-Factor Authentication — the recommended first move in any resource-constrained program, because it turns a phished password from a catastrophe into a dead end.

Key takeaways

• Replay-resistant ≠ phishing-resistant. Replay resistance stops credential reuse over time; phishing resistance stops real-time interception at a fake site. Phishing-resistant is strictly stronger.
• Replay resistance is in both revisions of 800-171 — §3.5.4 (Rev 2) and §03.05.04 (Rev 3) — not just Rev 2.
• “Phishing-resistant” is not a numbered 800-171 base control. It’s defined in NIST SP 800-63B, mandated federally by OMB M-22-09, and pushed by CISA and NIST SP 800-172.
• TOTP is the trap: replay-resistant, but not phishing-resistant. Only FIDO2/WebAuthn and PIV/CAC deliver true phishing resistance today.
• For CUI/CMMC: meet the replay-resistant control you’re assessed against, verify which 800-171 revision your contract cites, and deploy phishing-resistant MFA where a breach would hurt most — admins and remote access first.