TL;DR: FIDO2 passkeys reduce phishing and password risk, but enterprise environments still face gaps in device visibility, revocation, and session-layer attacks after login, according to Gradient Technologies. Consumer-grade authentication stops at sign-in, while corporate identity programmes need continuous trust validation across the session.
At a glance
What this is: This is an analysis of why consumer passkey models do not fully solve enterprise authentication, especially where device control, revocation, and post-login attacks are in scope.
Why it matters: It matters because IAM teams need controls that extend beyond login to cover session integrity, managed-device enforcement, and lifecycle revocation across human identity programmes.
Context
FIDO2-based passkeys reduce password reuse and phishing exposure, but the enterprise authentication problem is broader than login success. Corporate IAM has to manage provisioning, device compliance, privileged access, and instant revocation across managed and unmanaged endpoints, which is a different operating model from consumer account sign-in.
The gap appears when organisations assume that a phishing-resistant authenticator also solves session risk and governance. In practice, the control plane often splits across an IdP, MDM, and separate policy consoles, leaving visibility and enforcement inconsistent once a credential is enrolled on a device the business does not fully govern.
Key questions
Q: How should security teams adopt passkeys for infrastructure access?
A: Start with the highest-risk interactive accounts, especially administrators who are exposed to phishing and push fatigue. Then tie enrolment to device trust, define recovery requirements, and keep terminal and break-glass workflows under separate policy. Passkeys improve authentication strength, but they only reduce risk when the surrounding identity process is controlled end to end.
Q: Why do FIDO2 deployments still leave organisations exposed after login?
A: Because FIDO2 primarily protects the authentication event, not the full session lifecycle. Once a token is issued, attackers can target session hijacking, replay, OAuth consent abuse, or browser-based man-in-the-middle techniques. If the enterprise cannot continuously verify device trust, the session becomes the easier target.
Q: What do IAM teams get wrong about consumer passkeys in the workplace?
A: They often import a consumer trust model into an enterprise environment that needs central control. Consumer passkeys assume user-owned devices and self-managed authenticator lifecycle, while workplaces need provisioning oversight, compliance checks, and immediate revocation. That mismatch creates visibility and governance gaps.
Q: Who is accountable when phishing leads to account compromise?
A: Accountability is shared, but security leadership owns the control environment that made impersonation succeed. Email authentication, browser trust configuration, access scoping, and incident reporting are governance responsibilities, not just end-user habits. If phishing can repeatedly turn into compromise, the control model is failing at the organisational level.
Technical breakdown
Why FIDO2 passkeys stop at authentication
FIDO2 and passkeys are designed to prove possession of a private key during login, then hand off control to the relying party. That model works well when the user owns the account and the device, but enterprise identity changes the assumptions. Security teams need central oversight of device posture, authenticator lifecycle, and immediate revocation. A passkey alone does not provide continuous trust or session governance. Once the authenticator completes the login ceremony, later abuse of the session is outside its protection boundary.
Practical implication: treat passkeys as an authentication control, not a complete identity security architecture.
Why session tokens and OAuth consent remain the real attack surface
Modern attackers often bypass the authenticator entirely by targeting the live session after successful login. Session hijacking, token theft, replay, OAuth consent phishing, and browser-based adversary-in-the-middle attacks all exploit the period after authentication when a valid session already exists. These attacks succeed because the user passed the login check, but the session can still be reused or delegated from another environment. This is why enterprise controls have to extend into runtime session assurance, not just factor strength at the point of entry.
Practical implication: pair phishing-resistant login with controls that detect session abuse and constrain token reuse.
How continuous remote attestation changes device trust
Continuous remote attestation rechecks device state before session renewal, rather than trusting an initial login event indefinitely. In the architecture described, short-lived hardware-bound X.509 certificates are renewed only when the device proves it still meets trust conditions. Cryptographic session binding ties the session to the originating device, so replay from another machine fails. This is an enterprise control pattern, not just a stronger authenticator. It shifts trust from a one-time ceremony to repeated verification across the session lifecycle.
Practical implication: design controls that can invalidate renewal when device trust changes, not just at initial enrollment.
NHI Mgmt Group analysis
Authentication trust gaps are a session problem, not a factor problem. FIDO2 meaningfully improves the login ceremony, but enterprise risk often begins after the authenticator has done its job. Session hijacking, token theft, and consent abuse all live beyond the boundary of factor verification, which means IAM teams cannot treat phishing-resistant login as the end state. The practitioner conclusion is straightforward: authentication hardening without session governance leaves the primary attack surface intact.
Consumer passkey assumptions break when the enterprise owns the device and the policy. Consumer FIDO2 models assume the user controls enrolment, device state, and authenticator lifecycle, while enterprise programmes require central control, compliance checks, and instant revocation. That is a governance mismatch, not a product defect. The implication is that identity architecture has to be designed for managed-device enforcement and lifecycle control, not just user convenience.
Continuous attestation is the right architectural response to mutable trust. The article’s key insight is that trust should be revalidated before renewal, not only at sign-in. That aligns more closely with NIST Zero Trust thinking than with legacy MFA design. For IAM and PAM teams, the lesson is that credential strength and lifecycle control must be coupled to runtime verification if the organisation wants to reduce replay and unmanaged-device risk.
Session binding creates a more defensible identity boundary than reusable bearer tokens. Binding the session to the originating device makes stolen tokens less useful because the token cannot simply be replayed elsewhere. This is especially relevant in hybrid work and shared-device environments, where device context matters as much as the initial authentication event. The practitioner conclusion is to evaluate whether your current session model still behaves like a bearer system in practice.
Centralised revocation remains the governance test for enterprise authentication. If a terminated user or compromised device can still retain usable credentials in separate consoles or unmanaged devices, the authentication programme has not closed the loop. This is where human IAM, device governance, and session control converge. The conclusion for security leaders is that revocation speed and completeness are as important as phishing resistance.
From our research:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
- That same research shows organisations maintain an average of 6 distinct secrets manager instances, which points to fragmentation that identity teams should not ignore.
What this signals
Enterprise passkey rollouts should be judged on revocation speed, session containment, and device-governance reach, not just phishing resistance at login. When authentication improves faster than lifecycle operations, the control gap simply moves downstream into tokens, browsers, and unmanaged endpoints, where abuse is harder to see and slower to unwind.
Session-bound trust: the practical question is whether your identity programme still behaves like a bearer-token model after authentication. If it does, continuous verification and device binding become the real differentiators for zero-trust-aligned access design.
For teams aligning IAM with NIST Zero Trust Architecture, this is a signal to treat the session as the unit of control and to test revocation paths under compromise conditions. The main failure mode is not bad login strength, but stale trust that survives the original sign-in event.
For practitioners
- Map the authentication boundary to the session boundary Document where your current passkey or FIDO2 deployment stops protecting access, then identify the downstream controls that must take over for token abuse, replay, and consent-based attacks.
- Unify device trust and revocation workflows Require a single operational path for enrolment, compliance enforcement, and credential revocation so that terminated users or compromised devices do not persist across separate management consoles.
- Add runtime checks before session renewal Use continuous attestation or an equivalent trust revalidation step before renewal of short-lived sessions, especially where unmanaged devices or hybrid access paths exist.
- Review bearer-token exposure in your IdP and browser stack Test whether tokens can be reused from a different machine, whether OAuth consent can be abused, and whether browser-based interception can bypass factor strength entirely.
Key takeaways
- FIDO2 passkeys solve a real phishing problem, but they do not by themselves govern enterprise sessions, device trust, or revocation.
- The remaining risk sits after login, where token replay, consent abuse, and browser interception can bypass strong authentication entirely.
- Identity teams should evaluate passkeys as part of a continuous trust architecture, not as a standalone replacement for enterprise controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Enterprise passkey governance is about identity proofing and access control across the session lifecycle. |
| NIST Zero Trust (SP 800-207) | The article centers on continuous verification and trust boundaries after login. | |
| NIST SP 800-53 Rev 5 | IA-2 | Phishing-resistant authentication and central revocation map to identity and authenticator management. |
Apply IA-2 controls to ensure authentication strength is matched by enterprise revocation and oversight.
Key terms
- Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
- Session Binding: A control that ties an authenticated session to the device, connection, or risk context that created it. When applied well, it makes stolen cookies harder to reuse from an untrusted endpoint or a different network context.
- Remote Attestation: Remote attestation is the process of proving, with cryptographic evidence, that a workload is running inside a specific trusted environment. It matters in AI governance because it replaces a verbal trust claim with checkable proof that the inference session used the intended protected boundary.
- Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
What's in the full article
Gradient Technologies' full analysis covers the operational detail this post intentionally leaves for the source:
- How the vendor layers MDM and IdP policy around FIDO2 to recover enterprise control across device types
- The specific mechanics of continuous remote attestation before session renewal and how it blocks replay
- How short-lived hardware-bound X.509 certificates are provisioned, rotated, and revoked in the product flow
- Operational examples of one-time enrollment, zero-friction login, and reduced helpdesk load in hybrid environments
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.
Published by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org