Passkeys Protect Login but Do Not Secure the Whole Session

Passkeys strengthen enterprise sign-in, but they are not immunity from account takeover. CISA’s phishing-resistant MFA guidance makes migration a security priority, while NIST’s identity guidelines finalised in July 2025 provide an authentication-assurance framework. The business question is now broader than replacing passwords: how well does an organisation protect account recovery, authenticated sessions and the permissions available after login?

The Login Improvement Is Real

The FIDO Alliance describes passkeys as public-key credentials that provide phishing-resistant authentication. Rather than asking users to enter a reusable password, authentication relies on cryptographic proof.

Microsoft’s Entra ID announcement describes making passkeys the default phishing-resistant authentication method. That is a substantive change in the sign-in experience, not evidence that every application, fallback route or existing session receives equivalent protection.

Buyers should therefore distinguish support from enforcement. A platform offering passkeys is different from an organisation consistently requiring them for sensitive access.

A Session Is a Separate Security Asset

CISA’s session-cookie threat description explains that stolen authentication cookies can let an attacker use an already authenticated session, bypassing some MFA protections.

That does not mean the passkey’s cryptography has been broken. It means the attacker is abusing access established after successful authentication.

OWASP’s session-management guidance addresses expiration, reauthentication and server-side session invalidation. These controls should remain part of procurement and incident-response planning.

For organisations deploying AI agent workflows or agent plugins, software permissions also require separate assessment. Strong human sign-in should not be treated as authorisation for everything an integration subsequently attempts.

Device Binding Addresses a Different Problem

Chrome’s Device Bound Session Credentials documentation describes short-lived cookies whose renewal requires proof of possession of a device-associated private key. Secure hardware is used when available.

Its Windows availability announcement explains how this makes stolen cookies harder to reuse from another device. Websites must integrate the mechanism; installing a supporting browser alone does not establish protection across every service.

There are limitations. Chrome documents fallback behaviour where secure key storage is unavailable. Buyers should ask which users and applications actually receive device binding, and how unsupported environments are handled. This is layered risk reduction, not a promise that compromised endpoints become harmless.

Recovery Must Match the Intended Assurance

Passkeys can be device-bound or synchronised. NIST’s authentication requirements require non-exportable keys at the highest authentication assurance level. Organisations should choose an appropriate model rather than assume all deployments satisfy identical requirements.

The FIDO Alliance’s migration white paper recommends testing registration, authentication and recovery through pilot groups.

For buyers, that means examining lost-device recovery, helpdesk verification and retained fallback methods. A secure everyday login does not justify leaving recovery outside the threat model. Digital sovereignty requirements also belong in the assessment of credential providers, without assuming that synchronisation itself exposes plaintext keys.

Buy Evidence Across the Access Lifecycle

Security teams should request evidence of enforced authentication coverage, recovery safeguards, session invalidation and controls on sensitive actions. Tests should include device replacement and account-compromise response, not just a successful sign-in demonstration.

As with runtime agent administration and agent safety platforms, actual enforcement matters more than a feature appearing on a product page.

The investment case for passkeys remains clear: reduce exposure to credential phishing. The purchasing mistake is treating that improvement as complete account security. Enterprises should evaluate authentication, recovery, session continuity and authorisation together—and require evidence for each layer.