Passkeys in the Enterprise: Phishing-Resistant Sign-In Beyond Passwords and OTPs

Phishing remains the most reliable way into corporate networks, and most second factors do little to change that. A password plus an SMS code, TOTP app or push approval counts as multi-factor authentication, yet at its core it is attackable: lure the user onto a fake page and the second factor can be captured in real time too. FIDO2 passkeys address exactly this point.

Why classic MFA stays phishable

The problem is not the number of factors but their transferability. A one-time code is a shared secret: it works wherever it is entered, including on the phishing page. What is missing is a binding to the genuine counterparty. That binding is precisely what WebAuthn, the standard behind passkeys, provides.

What passkeys do differently

A passkey is a cryptographic key pair. The private key never leaves the device, and signing only happens against the domain for which the passkey was registered. This origin binding renders the classic phishing redirect useless: a fake domain simply receives no valid signature. There is no secret that could be entered on the wrong site. Germany’s BSI has published a formal threat model for this, and Technical Guideline BSI TR-03188 sets out requirements for operating a passkey server.

Synced, device-bound or hardware key

Not every passkey is the same. A sound rollout grades the variant by protection need:

• Hardware security keys: for privileged access and administration, where the highest assurance matters.
• Device-bound passkeys: on managed corporate devices, tied to the hardware and not syncable.
• Synced passkeys: for the broader workforce, convenient across several devices, with a slightly lower hardening level.

This grading matches the expectation that regulators and auditors increasingly voice: for sensitive administrative access, phishing-resistant authentication is treated more and more as a requirement, not a recommendation.

The open questions

The hard part is not the sign-in but the edge cases. What happens when a device is lost? What does a recovery path look like that does not itself become a phishable back door? And how do you handle legacy systems that do not yet speak WebAuthn? A well-considered rollout answers these questions in advance instead of improvising them during an incident. As the connective layer of the platform, Datargo ID anchors single sign-on and MFA in one place, which bundles these questions rather than scattering them across each application.

The decisive shift is this: away from a secret you can know and therefore give away, toward a key that stays bound to device and counterparty.