Secure Web Zero Trust: Users Are Only Half the Trust Decision

Key Takeaways

• Secure web zero trust verifies two halves of each decision: the user and device asking, and the account, page, and action they're reaching.
• Most zero trust architectures, including ZTNA, secure web gateways, and SSO with MFA, verify the user half well and leave the destination implied.
• On the web, one URL can lead to a corporate tenant, a personal account, or a convincing lookalike, so network-level trust alone can't separate them.
• The destination half is best verified inside the browser session, and contractors, BYOD users, and AI tools are the smartest place to start.

Most web zero trust programs answer "who are you" and stop there

Most security teams know the feeling of a zero trust program that verifies the user thoroughly and still leaves the web feeling exposed. The dashboard is green: MFA is everywhere, device posture checks pass, ZTNA is in place, and the secure web gateway is inline. Yet the incident review still starts in a browser tab, on a page nobody thought to question.

There's a good reason programs look this way. Identity and device are two of the five zero trust pillars, and for most teams they became the practical baseline. Federal guidance codified it when OMB memorandum M-22-09 told agencies to consider "at least one device-level signal alongside identity information about the authenticated user."

That 2022 memo binds federal agencies, though it reads as a useful benchmark for the user half in any enterprise.

The network controls around that baseline made sense too. VPNs, secure web gateways with URL categories, and network-based zero trust network access were the right answers when applications lived behind a perimeter. Back then, a destination meant an IP address or a domain, and checking it told security teams most of what they needed to know.

Then the web changed shape. SaaS providers host many customers on shared domains, so a corporate tenant, a personal account, and a partner's workspace can sit behind one hostname. The old criteria were correct for their era, and the destination simply stopped being a single thing.

Here's the quiet assumption underneath most secure web zero trust programs: once the user is verified, wherever they land is treated as trusted. The trust didn't disappear when the perimeter did. It moved to the destination, and few programs ever wrote the move down.

NIST SP 800-207 warns against a closely related pattern. It says an enterprise "should not rely on implied trustworthiness" once a subject has met a base authentication level. Implied trust in the destination is the same habit pointed at a different target, which is why the login got stricter while the tab stayed as trusting as it was.

On the web, the destination raises three questions the login doesn't ask

The missing half of the trust decision gets concrete in a single afternoon of ordinary work. A finance analyst signs in with phishing-resistant MFA on a compliant laptop, then opens two tabs on the same file-sharing domain. One is the corporate tenant and the other is a personal account, yet the policy engine sees one approved destination.

The user half is complete, but the destination half raises three questions the login had no way to answer:

• Which account is this? The corporate tenant, a personal account, and a partner's tenant can all share one SaaS domain.
• Is this page what it claims to be? Lookalike pages can relay sign-ins, and the UK's National Cyber Security Centre (NCSC) says traditional MFA approvals "can be observed and relayed during a live session."
• What is the user about to do with data? They might upload, paste, download, print, or send it to a generative AI tool.

URL categories and DNS can't reliably separate those accounts, because the domain is identical and the difference lives inside the signed-in session. Without account context, "approved app" is the most granular answer a policy can give.

Page authenticity is a harder problem than it sounds. OMB M-22-09 notes "many approaches to multi-factor authentication will not protect against sophisticated phishing attacks, which can convincingly spoof official applications." The NCSC also warns attackers often "use a stolen session credential to promptly find and steal sensitive data" before anyone notices.

Phishing-resistant MFA strengthens the sign-in itself, and it's worth the effort. The question of whether a page is genuine keeps going long after sign-in, though, and session security depends on someone asking it.

The third question is where data actually moves. A Gartner survey of 302 cybersecurity leaders found 69% of organizations suspect or have evidence employees are using prohibited public GenAI. Those tools are web destinations, and the risk sits in the paste or the upload far more than in the login.

Knowing which account and which data are involved is what lets teams say yes to AI safely. Zero trust data protection on the web starts with that knowledge, and it can't come from the login alone.

Nothing here is exotic; for most security teams, it's just Tuesday. Each question concerns the destination and the moment rather than the person, so a fully verified user can leave all three unanswered.

NIST's zero trust model already puts the resource in the decision

Many leaders hear "destination half" and brace for another framework, another tool, or another maturity model to report against. The reassuring news is the destination already sits inside the zero trust model most organizations adopted. It's simply the part the industry implemented last.

Start with NIST SP 800-207, the 2020 guidance most zero trust architecture programs trace back to. Its third tenet says "Access to individual enterprise resources is granted on a per-session basis." The fourth says access is set by dynamic policy, including "the observable state of client identity, application/service, and the requesting asset."

Read that fourth tenet closely and the application or service sits right next to the user in the decision. NIST goes further, noting "action permission policies can vary based on the sensitivity of the resource/data." The action is part of the model too, which covers the third question from the analyst's afternoon.

OMB M-22-09 points the same direction for federal agencies. It says "every application should be treated as internet-accessible from a security perspective." It also envisions access decisions based "not only on who or what is accessing data, but also on the sensitivity of the data being requested."

The memo goes on to call for the ability to "continuously evaluate any active session." Taken together, the two documents describe decisions made per session, informed by the resource, and adjusted to the data involved.

To be precise, neither document explicitly requires verifying a SaaS tenant or the authenticity of a page. Destination verification is a natural extension of what they describe, and it's consistent with zero trust principles as written. Nobody has to adopt a new framework to get there.

Seen this way, a fully verified user on an unverified destination is half a zero trust decision. Completing it is mostly a question of where you can observe the destination, and that's an architecture question more than a policy one.

The destination half is best verified where the page renders

Most teams reasonably expected the secure web gateway or proxy to handle the destination half, and it does see the domain. The trouble is both of the analyst's tabs share that domain, so the proxy sees two identical requests where the business sees two different destinations.

Network and proxy inspection was built for a world where the URL was the destination, and it still handles reputation, categorization, and threat blocking well. Account context, rendered page content, and in-page actions are largely outside its view, especially when traffic isn't decrypted in line. That limit comes from where the proxy sits in the path, which is also why it excels at the job it was built for.

It helps to compare browser security approaches by how much of the session each one can see:

• Security built into the browser sees the signed-in account, the rendered page, and each data action natively.
• Extensions on consumer browsers add useful in-page visibility, working within the capabilities the host browser provides.
• Network and proxy controls see traffic in transit, with the least view of what happens inside the session.

Many organizations run more than one of these layers, and that's sensible, since browser-native controls and extensions often work in tandem. Gartner describes browsers as "an endpoint-agnostic enterprise security control point," an analyst view published in April 2025. Island builds in this category, so treat Gartner's framing as context rather than endorsement.

This is the layer an enterprise browser was built for, and it's where Island's Enterprise Browser does its work. It verifies the destination half in the same policy that verifies the user, with conditional access by identity, device, and application. Application boundaries separate corporate from personal accounts on the same domain, and anti-phishing checks the page itself.

Last-mile controls then govern copy, paste, upload, download, and print, so data loss prevention applies to the action itself. Island Network Services adds a secure web gateway without default backhaul or forced TLS inspection, extending web protection beyond the browser tab. Neither one asks you to tear out your stack; together they reduce how much of the destination decision rests on the network alone.

When those checks run inside the session, they don't depend on extra login prompts, which is how zero trust can get simpler instead of heavier. The proxy knows where the traffic went. It doesn't know who the tab thinks you are, and that's the half of the decision worth moving closer to the page.

Four moves to bring the destination into secure web zero trust

If you're deciding where to take your zero trust implementation next, the user half gives you a strong foundation to build from. These four moves add the destination half without starting over, and each one can begin this quarter.

1. Inventory destinations by account, not by app. Write policy as "corporate tenant yes, personal tenant read-only or blocked."
2. Run the "same app, wrong tenant" test before buying anything. Upload a file to a sanctioned app using a personal account on a managed device.
3. Start where the destination is the only thing you control. Begin with contractors, BYOD users, and acquired teams on devices you can't fully manage.
4. Measure in-session decisions, not just logins. Track how often policy acted after authentication, such as a blocked paste or a flagged lookalike page.

The first move changes what an approval means. "Approved: file sharing" is an app-level answer, while the riskiest case is usually the sanctioned app on the wrong account. App allowlists hide that case by design, so tenant-level rules are the quickest way to make least privilege real on the web.

The second move is cheaper than any maturity assessment. Sign in to a sanctioned SaaS app with a personal account from a managed device, then try the upload. If nothing in your stack notices, you've found your destination gap and have a concrete finding for the next architecture review.

Repeat the test with a GenAI tool and a personal webmail account in a second tab. Each result shows which of the three destination questions your current controls can answer today.

The third move flips the usual rollout order, which tends to start with the easiest population. NIST SP 800-207 acknowledges "Devices on the network may not be owned or configurable by the enterprise." For BYOD zero trust and contractor access, the session is where policy has to live, so starting there proves the model where it's hardest.

The fourth move gives leadership a number worth tracking. Count the times policy acted after sign-in, such as a redirected personal-account upload, a blocked paste into a GenAI tool, or a lookalike-page warning. A count of zero isn't proof you're safe, because it can just as easily mean the decision isn't being made.

The user half got your program to the door. These four moves complete secure web access with zero trust by deciding what happens once someone walks through it. That's the half most programs left implied, and it's the half your users already spend their day in.

Finish the trust decision your login started

If you're rethinking where your web zero trust decisions get made, we're happy to walk through what we've built. Request a demo.

FAQs

How do you secure web access with zero trust?

Verify the user and device, then verify the destination: which account is in use, whether the page is authentic, and what action is happening. Tenant-level policy and in-session measurement make that second half practical.

Is ZTNA enough to secure SaaS and web applications?

ZTNA is strong at deciding whether a verified user should reach an application. It isn't designed to tell a corporate tenant from a personal one or to govern what happens on the page afterward.

How does zero trust work for unmanaged and contractor devices?

When you can't manage the device, the browser session becomes the practical place to apply policy. That's why contractors and BYOD users make a strong first population for destination checks.

Does zero trust stop data loss after a user logs in?

It can, if policy keeps evaluating the destination and the action throughout the session. A login check alone leaves copy, paste, upload, and download decisions unmade.

What are the disadvantages of zero trust?

The most common complaint is friction, when "verify" turns into more prompts. Moving destination checks into the session lets more decisions happen in context, rather than through extra prompts.