Passkeys have effectively tackled phishing at the login stage. But what happens if an attacker hijacks a session twenty minutes after a user logs in? Or if a device is stolen mid-task? The question isn't whether passkeys work, they do, but whether authentication alone provides enough security throughout a session's lifecycle.
This isn't a theoretical concern. Session hijacking, token theft, and device compromise can happen regardless of how strong your initial login was. The debate now is whether to invest in continuous verification mechanisms or if that's just security theater that frustrates users and wastes budget.
The Case for Continuous Verification
Authentication is a single event, but sessions can last hours or days, with security contexts changing constantly.
Advocates for continuous verification highlight real attack patterns. An attacker with a stolen session token bypasses your FIDO2 authenticator, they're already inside. Malware that activates post-authentication doesn't trigger your phishing-resistant controls. A stolen laptop with an active session grants full access, regardless of how the user logged in.
The technical argument is clear: passkeys confirm possession and user verification at login. They don't ensure the same user is present ten minutes later, that the device is uncompromised, or that the network context remains trusted. If you're protecting sensitive transactions, like financial approvals or healthcare records, a single authentication event leaves a window of risk.
There are various implementation options. Behavioral biometrics can flag unusual typing patterns or mouse movements. Step-up authentication can require re-verification for high-risk actions. Device posture checks can ensure endpoint security controls are active. Session binding can cryptographically tie tokens to device state. These features are available in enterprise IAM platforms.
Compliance is also a factor. Frameworks like PSD2 require strong customer authentication for payment initiation, not just login. NIST SP 800-63B defines different Authenticator Assurance Levels because different contexts demand varying confidence levels. If your risk model indicates a need for ongoing verification, your architecture should support it.
The Case Against Layering More Verification
The opposing view is that continuous verification adds complexity that many organizations can't manage well, and it undermines the user experience benefits that passkeys offer.
Consider the implementation burden. You've moved users off passwords, reduced help desk tickets, and thwarted phishing attempts. Now you're considering adding behavioral analytics, step-up flows, and device trust checks? Each layer is another integration point, another vendor relationship, another potential failure. Most security teams are already overwhelmed with basic tasks like patch management and vulnerability remediation. Adding continuous verification diverts resources from these essentials.
The user experience trade-off is significant. Passkeys are fast and transparent. Users touch their fingerprint sensor and they're in. Interrupting workflows with re-authentication prompts or blocking actions due to behavioral analytics reintroduces the friction that led users to weak passwords initially. Your CEO won't accept being locked out of email for typing faster than usual.
There's also a measurement challenge. How do you quantify the risk reduction from continuous verification versus its cost? You can measure passkey adoption and phishing attempt success rates. Continuous verification prevents attacks that might have happened under different conditions, making the business case harder. Security teams that can't demonstrate ROI risk ending up with unused solutions.
Moreover, session-based attacks aren't your biggest threat. Most breaches result from credential theft, misconfigured cloud storage, unpatched vulnerabilities, and social engineering that doesn't involve session hijacking. If you haven't addressed these issues, continuous verification is focusing on the wrong part of the attack chain.
Where Practitioners Actually Land
In practice, most organizations tailor their approach. They don't apply the same verification requirements to every session.
High-value transactions get step-up authentication. A user accessing email doesn't need continuous verification, but initiating a wire transfer does. Administrative actions in production environments trigger device posture checks. Sessions from unmanaged devices have shorter timeouts and restricted access scopes.
This approach is known as risk-adaptive authentication, using the context of the request to determine the necessary level of assurance. This isn't continuous verification in the strict sense; it's conditional verification based on user actions and locations.
Session timeout policies also help. If sessions expire after thirty minutes of inactivity and require re-authentication, you're limiting the window for session-based attacks without needing real-time behavioral monitoring. It's a simple, effective solution.
Our Take
Continuous verification is sensible for specific use cases, not as a blanket policy. If you're protecting financial transactions, healthcare data, or administrative access to critical systems, the risk model justifies the complexity. For securing corporate email and productivity apps, it likely doesn't.
The key is integrating these capabilities into your architecture without enforcing them in every workflow. Your IAM platform should support step-up authentication, device trust signals, and session binding, but you should apply these controls based on policy, not by default. Start with your highest-risk scenarios and demonstrate value before expanding.
Passkeys solved the authentication problem. The session assurance problem is real, but not universal. Treat it like any other security control: deploy it where the risk justifies the cost, measure the outcomes, and don't let perfect be the enemy of good enough.
The future isn't continuous verification for everyone. It's selective verification for the contexts that matter, with the infrastructure ready to scale when your risk model demands it.
