Passkeys use public-key cryptography to make sign-in resistant to credential phishing.A password can be long, unique and carefully stored, yet still be surrendered to a convincing fake login page. A one-time code adds protection, but an attacker who operates a real-time phishing proxy may capture the password and relay the code before it expires. This is why security teams are moving toward phishing-resistant authentication: the sign-in proof is bound to the legitimate service instead of being a reusable secret that a person can type into the wrong site.
What a passkey changes
A passkey is based on public-key cryptography. During registration, the user’s device creates a private key that remains protected on the device and a public key that the service stores. At sign-in, the service asks the device to prove possession of the private key. The user approves the action with a device PIN, fingerprint, face recognition or another local unlock method.
The website does not receive the fingerprint, face image or private key. It receives a cryptographic response for the correct site. Because the credential is scoped to the legitimate domain, a look-alike phishing site cannot ask the device to produce a valid response for the real service.
Why an OTP is not the same control
SMS and authenticator-app codes are useful improvements over a password alone. They reduce many attacks involving stolen password databases. However, the code is still a transferable value: if a user can read and type it, an attacker may persuade the user to type it into a fraudulent page. Push notifications can also create approval fatigue when repeated prompts pressure a user to accept.
CISA recommends phishing-resistant MFA for critical services and identifies FIDO-based credentials and public-key infrastructure as strong options. This does not mean an organisation should disable every existing method overnight. It means the security roadmap should give the strongest methods to the accounts whose compromise would cause the most harm.
Start with the accounts that can change everything
- Administrators: cloud, domain, identity, backup and security-tool administrators should receive the strongest authentication first.
- Email and collaboration: these accounts often enable password resets, business-email compromise and access to sensitive conversations.
- Finance and executive roles: payment approvals, payroll changes and sensitive decision-making make these identities attractive targets.
- Remote access: VPN, virtual desktop and support tools expose an entry point beyond the physical office.
A migration plan that people can actually follow
- Inventory authentication: identify applications, identity providers, account owners, current MFA methods and unsupported systems.
- Define recovery before rollout: require more than one registered authenticator where appropriate, protect help-desk resets and record who may approve recovery.
- Pilot with a small group: include different devices, accessibility needs, travel patterns and job roles. Capture where users become confused.
- Protect privileged users: issue managed security keys or managed-device passkeys, then remove weaker fallback methods once recovery is proven.
- Expand by risk: move high-impact business functions next, communicate the reason in plain language and offer guided enrolment.
- Measure the result: track phishing-resistant coverage, fallback use, recovery events, enrolment failures and authentication-related support tickets.
Recovery is part of authentication security
A strong front door with a weak recovery process is still a weak system. Attackers may call a help desk, impersonate an employee and request an MFA reset. Recovery should require proportionate evidence, separation of duties for privileged accounts, alerts to the account owner and a reviewable audit trail. Emergency access accounts should be tightly controlled, monitored and tested without becoming ordinary daily accounts.
Questions leaders should ask
- Which accounts can alter identity settings, backups, payments or security monitoring?
- What percentage of those accounts use phishing-resistant authentication today?
- Can an attacker downgrade a user to SMS or bypass the control through account recovery?
- Are unmanaged devices permitted to create or synchronise credentials?
- Do sign-in logs distinguish passkey use from weaker methods?
The practical conclusion
Passkeys are not a magic replacement for device security, access review or user education. They solve a specific and important problem: they greatly reduce the chance that a reusable sign-in secret can be captured and replayed through a fake website. A phased rollout, strong recovery controls and useful adoption metrics turn that technology into a dependable identity-security improvement.
