Phishing-Resistant by Strength

What “phishing-resistant” actually means

An authenticator is phishing-resistant when the credential itself refuses to work at the wrong site — the protocol cryptographically binds the authentication to the origin, so a pixel-perfect fake login page gets nothing usable. Two families qualify: PIV/smartcard certificate authentication (the federal workhorse) and FIDO2/WebAuthn — which in 2026 means passkeys, device-bound (hardware keys, platform authenticators) or synced. What does not qualify, ever: SMS, voice calls, emailed links, TOTP codes, and bare push approvals — everything a tired human can be talked into relaying. Number-matching push is the accepted middle tier: better, still not resistant.

The 2026 standards note that matters (in one sentence, current per the finalized digital-identity guidelines): syncable passkeys rate AAL2, device-bound passkeys and PIV can reach AAL3 — so “we use passkeys” now spans two assurance levels, and which one you’re getting is a deployment decision, not a vendor default.

Enforce by strength, not by “MFA”

The mechanism from Lesson 2.1 gets specific here. A legacy “require MFA” grant is satisfied by any registered method — deploy passkeys everywhere and a phished user’s SMS fallback still lets the attacker in. The modern construct is the authentication strength: a named set of acceptable methods attached to a CA policy. The rollout that works, tier by tier:

Tier 1 (now):      admins + break-glass-adjacent roles => strength:
                   "phishing-resistant only" - no fallback satisfies CA02
Tier 2 (quarter):  high-risk sign-ins => step-up to phishing-resistant
Tier 3 (rolling):  everyone - passkey enrollment campaigns, phishable
                   methods REMOVED from each user as their passkey verifies

That last clause is the one programs skip: enrollment without removal changes nothing. As long as the phishable method remains registered, the attacker just requests it — the downgrade attack. Phishing resistance is achieved on the day the weak method is gone, and the removal wave is where helpdesk load actually lands (recovery flows, below).

The AAL trap: assurance is a system property

The subtlest failure, taken from a real implementation guide’s sharpest section: assurance level belongs to the authentication system, not the authenticator. A smartcard deployment silently downgrades to AAL2 when the verifier side is misconfigured — the two classic traps: certificate revocation not actually checked (a revoked card keeps working), and the federation assertion not carrying/requiring the strength claim (so the app can’t tell a smartcard session from an SMS one). Your hardware is AAL3; your system is whatever your weakest verifier check says. Audit the verifier, not the token drawer.

Prompt first

Design the authentication-strength rollout for this estate: (1) the custom
strength definitions (phishing-resistant-only; phishing-resistant-or-numbermatch
as the migration tier), (2) which CA policies from our baseline get which
strength, per role tier, (3) the enrollment-then-REMOVAL sequence per
population with helpdesk load estimates, (4) the verifier-side checklist -
revocation checking, strength claims in assertions, federation gaps - as
testable assertions, and (5) the recovery story: lost-passkey and
lost-smartcard flows that do not reintroduce a phishable path (temporary
access pass + identity verification, never "fall back to SMS").

Point (5) is where designs quietly fail. A recovery flow that hands a locked-out user an SMS code has reintroduced the exact hole the program closed — the attacker just calls the helpdesk crying. The pattern that holds: verified-identity ceremony → time-boxed temporary access pass → enroll new strong authenticator → TAP expires. (Vendor names for the time-boxed credential vary; the pattern — a short-lived enrollment pass that is itself useless for ordinary access — does not.) (Helpdesk verification itself got harder in 2025-26 — voice-cloning made “sounds like Bob” worthless; real shops moved to callback-plus-manager-confirmation or in-person for privileged accounts.)

Teaching it: the eighteen-panel trick

You now own the technical story — but the field techs, the finance team, and the board don’t want authentication-strength policy. A format proven in a real federal MFA rollout: an ASCII graphic novel, eighteen panels, zero jargon until a closing glossary. The arc: show the old way failing before introducing the fix, decompose one factor per page, and teach phishing resistance without the word “phishing” — the credential refuses the fake door, not the user:

## 10.                                    ## 11.

    (•_•)                                       ┌────┐
    <)   )      ┌──────────┐                    │CARD│  ─→   ✗ ✗ ✗
     / \        │  fake    │                    └────┘
                │  door    │
                │   ▓▓▓    │                      NO.
                │  click!  │
                └──────────┘
                                            The card knows.
The bad one sends a trick door.

Recovery gets dramatized inside the happy path (“The Helper gives a tiny pass”) — because users who know recovery exists don’t hoard forbidden fallbacks. The closing glossary maps story-objects to real terms (the card the Guard can’t be tricked by = phishing-resistant MFA; the tiny one-day pass = temporary access pass; the hidden spare key = break-glass). Steal the format: the deferred-vocabulary structure outperforms every acronym-first deck you’ve ever sat through.

Key takeaway

Phishing resistance = the credential refuses the wrong origin: PIV and passkeys qualify, everything relayable doesn’t. Enforce it as an authentication strength (never bare “MFA”), tier the rollout admins-first, and remember the two silent killers: fallback methods left registered, and verifier-side misconfigurations that downgrade AAL3 hardware to AAL2 reality. Then teach it in panels, not acronyms. Next: the privilege that shouldn’t be standing at all.