4 MIN READ
Passwords died somewhere around 2022. The funeral for SMS one time passcodes happened in 2024, when the SIM swap attacks moved from the news section to the incident response binder. The 2026 survivors sit at three. Hardware keys, passkeys, certificate based auth. The choice between them runs as the choice the enterprise has been postponing for three years, and the postponement has cost enough breaches to retire the debate.
The term “phishing resistant” matters here. Phishing resistant MFA sits as the authentication the live phishing kit cannot defeat. MFA that sits not phishing resistant sits as the authentication the operator can defeat in real time, with the user watching the URL bar, with the user entering the code, with everything looking fine until the session walks out the door. The three properties that make MFA actually phishing resistant sit worth understanding before the rollout.
What phishing resistant actually means
Three properties stack. The session has to be cryptographically bound to the origin, so anyone proxying the phishing site cannot replay the credential and cannot lift the session. The design also has to avoid any shared secret, so there is no password, no one time passcode, no SMS code to capture and reuse. Public key cryptography has to stay on the device, with the private key never leaving it. Finally, the origin has to be verified before the credential is released, the domain, the certificate, the URL, so the user cannot be tricked into authenticating to a lookalike site. Each property matters on its own. Together they make the credential unstealable and the user untrickable, which is the floor that all three properties together put under the whole phishing resistant story.
The three options that work in 2026
The hardware key leads on security and trails on user friction. YubiKey 5, Google Titan, Feitian K9, all of them FIDO2 certified, all of them plugging into the USB port or tapping the NFC, all of them refusing to release the credential to a lookalike domain. The hardware key sits as the right answer for the admin accounts, the developer accounts, the finance accounts, anywhere a single compromised credential produces a catastrophic breach. The friction is real. The friction is the feature.
The passkey trails the hardware key on security and leads on user experience. A FIDO2 credential stored on the device, synced through iCloud Keychain, Google Password Manager, or 1Password, unlocked with the biometric, the PIN, or the device pattern. The passkey sits as the right answer for the broad user base, the consumer facing apps, the workforce that will not carry a second device. The passkey cannot be phished. The passkey cannot be typed into a fake site. The passkey just works.
Certificate based auth sits as the third option, with the smart card, the PIV, the CAC, the certificate the device presents to the server, validated against the PKI, bound to the device. Certificate based auth runs as the right answer for the federal environment, the defence environment, the high assurance environment, with the deployment cost and the operational overhead to match. The choice between the three is not really a technical choice. It sits as a deployment choice, and the deployment cost usually picks the answer.
How to roll it out without breaking the business
Start with the high value accounts. The admin accounts, the developer accounts, the executive accounts, the finance accounts, all of them produce the catastrophic breach if compromised, and the hardware key for that group gives the biggest risk reduction for the smallest user base. 200 tokens, 200 admins, the rest of the org can wait.
Use the passkey for the broad user base. The passkey scales. The passkey works on the phone. The passkey works on the laptop. The passkey does not require anyone to carry an additional device, which is the part that makes the rollout actually finish.
Keep the password as the fallback, for now. Keys get lost. Phones get broken. The recovery path is needed, and the path that falls back to the password sits as the path the threat actor will target, so the fallback has to be long, unique, and stored in the password manager. A weak fallback undoes the whole deployment.
The bottom line
Hardware key for the high value accounts, passkey for the broad base, password as the fallback. The org that runs those three holds the line. The one that still uses the SMS code as the primary factor does not.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
