Key Takeaways

• A login only verifies identity for an instant; attackers increasingly steal the authenticated session afterward, so identity has to be verified continuously, not once at the gate.
• To verify identity at the browser level means checking who the user is (passkeys/WebAuthn), what device they're on (device posture), and the context of each action (conditional access) throughout the session, not just at sign-in.
• Phishing-resistant methods like passkeys and WebAuthn prove the user at login; keeping that proof alive during the session is a separate problem the browser layer is positioned to solve.
• Because enterprise work now runs through the browser, the browser is the practical place to enforce continuous identity verification, device posture, and conditional access together.

Your login proves a moment, not the person behind the session

Most security teams have invested heavily in strong authentication. MFA is deployed. Password policies are tight. And yet account-takeover incidents keep appearing in the queue. That gap between what the controls should prevent and what still gets through isn't a mystery: it's the difference between proving identity once and proving it continuously.

Stolen or compromised credentials remained the single most common initial access vector in the 2025 Verizon DBIR, involved in 22% of breaches, even as vulnerability exploitation (now at 20%) closes the gap. Credentials work because they're reusable, and in the median case only 49% of a user's passwords across services are unique. The login event might succeed, but the session that follows is where the real risk lives.

Adversary-in-the-middle (AiTM) attacks have refined this problem. According to the Canadian Centre for Cyber Security, AiTM phishing intercepts the connection between user and login server, capturing usernames, passwords, MFA secrets, and tokens. Threat actors have almost entirely shifted from traditional AiTM campaigns to proxy-based versions. The key nuance: AiTM doesn't break MFA. It waits for MFA to complete, then steals the authenticated session cookie. Your strong login worked; it just didn't protect the session.

AI raises the stakes further. FinCEN has documented an increase in suspicious activity reports describing deepfake media used in fraud schemes targeting financial institutions, with criminals using generative AI to circumvent customer identification and verification. MFA solved the login problem of its era; the session layer wasn't where the threat lived then. The gap surfaced as work and attackers both moved past the login screen. The login was never the weak point. Everything after it was.

Work moved into the browser, so identity checks belong there too

Your users live in SaaS tabs. Procurement, HR workflows, customer data, source code reviews: the browser is the shared surface where all of it actually happens. Enterprise SaaS spending approached $300 billion in 2025 according to Gartner, making it the largest enterprise cloud spend segment. That spending is a proxy for something more fundamental: work consolidated into the browser years ago, and identity enforcement hasn't caught up.

Identity signals still scatter across IdP logs, network telemetry, and endpoint agents. Each system sees its own slice. The IdP knows who authenticated; the endpoint agent knows the device state; the network sees the traffic flow. But the one place every SaaS session converges is the browser. That makes it the practical vantage point to keep verifying identity throughout the session, not just at the door.

A finance analyst logs in at 8 a.m. with MFA to access a spend management application. The authentication succeeds, the session starts, and the analyst begins reviewing invoices. Three hours later, the analyst clicks a link in what looks like a routine vendor email. It's a proxy-based phishing page that captures the session cookie silently, without triggering another login prompt. By noon, an attacker is operating inside the same authenticated session: approving payments, exporting vendor lists, and browsing contract terms. The IdP log shows one successful login that morning. The endpoint agent sees no malware. But someone else has been acting as that analyst for hours, and no control noticed because none of them watched the session after authentication.

This shift is architectural, not a rip-and-replace event. Verification moves closer to where the work and the risk actually are. If you accept the premise that a login proves a moment and not an ongoing state, the question becomes where to anchor continuous verification. The browser already sits at the intersection of user, device, application, and session. It's where SaaS credentials get entered, where sensitive data gets rendered, where cut-and-paste happens, and where context can be evaluated in real time. The infrastructure exists; the policy layer is what's missing.

What verifying identity at the browser level actually checks

The phrase "browser-level identity verification" gets tossed around, but what does it actually mean? It's the continuous confirmation, at the point of each action, that the right person on a trusted device is doing the work. Not just that someone logged in once twenty minutes ago.

The signals that combine at the browser layer:

1. Who the user is: passkeys, WebAuthn, phishing-resistant credentials that bind authentication to a specific device and origin.
2. What device they're on: device posture checks confirming whether the device is managed or unmanaged, patched or vulnerable, compliant or not.
3. The context of the action: conditional access evaluated by identity, device, network, location, and the specific application being accessed.
4. Whether to re-verify: step-up authentication prompts when risk context changes mid-session, triggered by signals like location shift, unusual data access, or time since last verification.

The difference from traditional access control is both scope and timing. Traditional models make a yes/no decision at the perimeter and trust the session from there. Browser-level verification treats identity as a state, not an event. It evaluates continuously and can adjust mid-session based on what the user is actually doing. That's the gap most architectures leave open.

Passwordless proves the user; the browser keeps proving the session

Teams rolling out passkeys sometimes assume they're done with identity. Phishing-resistant authentication deployed, checkbox complete. But passkeys solve one problem extremely well, and it's not the only problem on the table.

CISA calls phishing-resistant MFA the "gold standard" and identifies FIDO/WebAuthn as the only widely available phishing-resistant authentication. Government guidance backs the move to passkeys, and adoption is accelerating. Among early-adopting platform companies, 93% of accounts are now passkey-eligible and 26% of sign-ins use passkeys, according to the FIDO Alliance. But those figures come from large platform providers like Amazon, Google, and Microsoft; enterprise adoption varies.

Passkeys prove the user at the moment of sign-in. They don't keep proving it. The session that follows is a separate layer, and that's where session hijacking, token theft, and post-authentication compromises occur. Phishing-resistant login is necessary; it's not sufficient.

Browser-native identity capabilities are expanding beyond authentication. The Digital Credentials API, now shipping in Chrome and Safari, lets a site verify a specific identity attribute from a mobile wallet without exposing the underlying document. For example, the API can confirm a user is over 18 without revealing their full date of birth. This is distinct from WebAuthn: passkeys authenticate who is logging in, while the Digital Credentials API verifies identity attributes through selective disclosure. Both live in the browser, and both are moving identity decisions closer to where sessions actually run.

The contrast matters:

• Proved once: strong authentication at login, then trust the session.
• Verified continuously: authentication at login, plus ongoing checks on user, device, and context at each sensitive action.

Most organizations are still operating in the first model while facing threats designed to exploit the second gap.

Where the browser becomes the enforcement point

You've assembled the tools: IdP for authentication, EDR for the endpoint, DLP for data, network controls for access. Each sees part of the picture. The challenge is that none of them sees the whole session from the inside. That's where architectural approach matters.

Security built into the enterprise browser operates natively at the session layer. It sees inside the rendered page, knows which application is active, and can evaluate identity, device posture, and context together at the moment of each action. Extensions that add a layer to a consumer browser provide a complementary option, scoped to what the extension API exposes. Network and proxy approaches work indirectly; they can control access but can't see inside the encrypted session once it's established. Each approach has trade-offs, but the native browser layer is uniquely positioned to enforce policy at the point where user, device, application, and data actually converge.

When identity, device posture, and conditional access live in the browser, the same policy engine can re-check identity continuously and enforce last-mile controls at the point of each action. Download blocked because the device fell out of compliance. Screenshot disabled because the user shifted to an unmanaged network. Step-up authentication triggered because the session touched sensitive data. These aren't separate tools firing alerts; they're one environment responding to context in real time.

The proving ground isn't the hardest use case. It's whether users route around the control. Continuous verification only works if it's invisible enough that people don't reach for an unmanaged browser to get work done. The best security architecture fails if the workforce avoids it. Island's Enterprise Browser is trusted by roughly 20% of the Global 1000 and 20 of the Fortune 100. That scale wasn't built on the strength of the login. It was built on what happens after.

How to pressure-test a browser-level identity approach

Evaluations tend to focus on the strength of the login and stop there. Feature matrices get compared, authentication protocols get checked off, and procurement moves forward. But the threats documented earlier in this piece don't target the login; they target the session. Evaluations should follow the risk.

Questions worth asking:

• Does it re-verify identity during the session, or only at login?
• Can it combine identity, device posture, and context in a single policy decision?
• What happens on an unmanaged or BYOD device?
• Does it add friction users will route around?

Most vendors can describe what happens at authentication. Ask what the system knows and does after authentication. That's where account takeover actually happens. Ask for deployment-friction data, not just feature lists. The architecture that users avoid is the architecture that doesn't protect them.

The pilot that reveals the most isn't always the technically complex one. Consider starting with the workflow that has the most political friction: the application where a senior leader's team has historically pushed back on security controls, or the process where exceptions get granted quietly because enforcement creates too much noise. Technical stress tests show whether the system can handle load; political stress tests show whether it can survive the organization. If users in a high-visibility group start routing around the managed browser within the first week, that signal matters more than any performance benchmark. Measure shadow browser usage from day one. Track how often users open the same application in an unmanaged browser after encountering a policy. Ask what telemetry exists for the session after authentication, not just the authentication event itself. A pilot that only proves the login works is testing the wrong surface.

Frame the evaluation as architectural fit. A browser-level approach isn't automatically right for every environment. But if your workforce lives in SaaS applications, if you're seeing session-based compromises, or if your current stack leaves a gap between login and everything after, the browser layer is worth examining on its own terms. The goal isn't to replace every control you have; it's to close the gap those controls weren't designed to cover.

Closing the gap between login and everything after

If you're rethinking where identity gets verified, we're happy to walk through what we've built. Request a demo.

FAQs

What does it mean to verify identity at the browser level?
It means continuously confirming the right person on a trusted device is performing each action in the browser, combining passkeys, device posture, and conditional access, rather than trusting a single login.

Isn't multi-factor authentication enough to verify identity?
MFA strongly verifies the user at sign-in, but adversary-in-the-middle attacks steal the authenticated session afterward, so identity still needs to be re-verified during the session.

How do passkeys and WebAuthn fit into browser-level identity verification?
They provide phishing-resistant proof of the user at login, which CISA calls the gold standard; browser-level verification extends that proof across the whole session.

What is the Digital Credentials API?
It's a browser-native standard, now shipping in Chrome and Safari, that lets a site verify a specific identity attribute (like being over 18) through selective disclosure without exposing the underlying document.

How is browser-level identity verification different from device-based MFA?
Device-based MFA checks a device at login, while browser-level verification continuously combines user, device posture, and action context at the point where the work actually happens.