How to Implement Zero Trust Past the Login Screen

Key Takeaways

• To implement zero trust, verification has to continue past login. Policy should follow what people do inside a session, not only how it began.
• Many zero trust architectures concentrate controls at access, leaving copy, download, upload, and paste activity inside SaaS and web apps implicitly trusted.
• A zero trust roadmap should map data movement inside sessions, add last-mile controls tied to identity and device, and expand one population at a time.
• Zero trust maturity is best measured by how rarely people need workarounds, because a bypassed control often takes verification with it.

Most zero trust rollouts stop verifying at the login screen

The MFA rollout is finished, device posture checks are live, and VPN users are moving to zero trust network access (ZTNA). The dashboard looks healthy, and the board update says the program is on track. Then a contractor signs in, and the more useful question is what happens in the minute after.

Most efforts to implement zero trust, and most guides on how to implement zero trust, put identity, MFA, device posture, segmentation, and ZTNA first. That work is necessary and hard-won, and it decides who gets in with real rigor. What it usually doesn't decide is what happens once they're in.

After login, the session tends to become a trusted space. The contractor opens the CRM, copies a page of customer records, and pastes them into a consumer AI tool to draft a summary. In many access stacks, nothing evaluates that paste, because access was granted a few clicks earlier.

The session itself is also a target. NIST SP 800-63B-4 defines a session hijack as an attacker inserting themselves between user and verifier "after a successful authentication exchange." A strong login doesn't protect a session someone else is now riding.

The adoption data points the same way. A Gartner survey released April 22, 2024 polled 303 security leaders at organizations implementing or planning zero trust in late 2023. Of those, 63% had fully or partially implemented a strategy.

Gartner's John Watts noted the strategy "typically addresses half or less of an organization's environment" for most of them. It mitigates "one-quarter or less of overall enterprise risk," which describes a front door far stronger than the rooms behind it.

VPNs, VDI, and network proxies were the right answer when applications lived in the data center and the network was where policy could live. The browser session wasn't a control point in that era, and it had no reason to be.

Work has since moved into SaaS and web apps, and the zero trust architecture now has to follow it. Nobody designed it this way; the login screen just became the last place anyone was still checking.

The zero trust standards already expect verification to continue after access

If you're deciding what phase two of your zero trust program should be, the standards have already answered the question. The work ahead is catching implementation up to guidance written years ago.

NIST SP 800-207, the 2020 reference for zero trust architecture, warns against "implied trustworthiness" after a basic login. Its tenets call for dynamic policy and "continual monitoring with possible reauthentication and reauthorization" throughout user transactions.

NIST adds the evaluation "should be continual for as long as the session lasts." It presents these zero trust principles as goals to work toward, which leaves room for a phased approach rather than a single cutover.

Federal policy made the same point in OMB memo M-22-09, issued in January 2022 with agency objectives through FY2024. It says zero trust "requires the ability to continuously evaluate any active session."

The memo also says users should "log into applications, rather than networks," which moves the checkpoint much closer to the data. The same memo concedes "many approaches to multi-factor authentication will not protect against sophisticated phishing attacks," so even the front door needs ongoing attention.

CISA's Zero Trust Maturity Model v2.0, published in April 2023, organizes the work into five pillars and three cross-cutting capabilities. At its Optimal stage, identity is validated continuously, "not just when access is initially granted."

Data loss prevention at that stage can "dynamically block suspected data exfiltration." Its Traditional stage, by contrast, describes static access decisions, which is a fair portrait of a program that verifies once at login.

Continuous verification is the stated destination in all three documents, so the gap is one of reach rather than intent. Most controls sit at the network or identity layer, while session activity happens inside the app, often in a browser tab. The standards got there first, and the tooling has been catching up ever since.

A six-step roadmap to implement zero trust where users touch data

If you're sequencing the work, plan for a custom path rather than a single blueprint. NIST's SP 1800-35 guide, announced June 11, 2025, offers 19 example implementations built with 24 industry collaborators. One of the guide's NIST co-authors put it plainly: "every ZTA is a custom build." SP 800-207 likewise encourages adopting zero trust incrementally.

The zero trust roadmap below is a sequence to adapt, ordered so verification reaches the session early instead of in year three. Two principles shape the order. Session visibility comes before session control, because a policy written without a map of data movement tends to block the wrong things.

Each step should ship to a real group of users before the next one starts, so feedback arrives while it's cheap to act on. Pilots with real users also surface the exceptions people need, which become the first entries in the workaround metric from step six.

1. Inventory sessions, not just assets. Map which apps people use after login and how data leaves them: copy, download, upload, print, share, or paste. Flag users on unmanaged or third-party devices, since that's usually where the session map is emptiest.
2. Make identity and device posture the entry condition. Phishing-resistant MFA and posture checks decide whether a session starts, and many programs have already built this foundation. Keep it, and treat it as the starting line rather than the finish line.
3. Move policy to the last mile. Attach controls to in-session actions such as copy and paste, download, upload, print, screenshot, and sharing. Make each one conditional on identity, device, and data sensitivity, which is what least privilege access looks like inside the app.
4. Re-verify on risky actions, not on a timer. Step up authentication when a user enters a sensitive area of an app or attempts a high-risk action, and re-check when session characteristics change. NIST SP 800-63B-4 describes session monitoring, an optional control, as the ongoing evaluation of session characteristics to detect possible fraud during a session.
5. Expand one population at a time, starting with the most awkward. Many roadmaps begin with managed employees on managed laptops, the cleanest group available. Starting with contractors on personal laptops, a newly acquired team, or a BYOD support desk tests your controls against unmanaged-device risk on day one. The business case tends to write itself there, too.
6. Measure maturity per pillar, and track the workaround rate. Score each pillar against CISA's four stages: Traditional, Initial, Advanced, and Optimal. Then add one internal metric the model doesn't name, which is how often people route around a control.

Steps one and two describe where many programs already stand, while steps three through six are where zero trust implementation reaches the data. A step that can't name its population and the in-session action it governs is probably still an access project. These later steps also raise a practical question about which layer can see an in-session action in the first place.

The browser is the zero trust control point most architectures predate

A contractor on a personal laptop opens a SaaS admin console in a browser tab. The access stack can see the connection, the identity, and the destination, but it typically can't see the clipboard. That tab is where the sensitive work happens, and many zero trust architectures weren't built to look inside it.

In an April 29, 2025 release, Gartner's Max Taggett called web browsers "the primary access method for most modern corporate applications." He added they "provide an endpoint-agnostic enterprise security control point," which is the last mile described in analyst terms.

The standards anticipated this, too: NIST SP 800-207 names browser isolation as one way to compensate when the enterprise has no agent on the device. Three architectural approaches now reach the session, ordered by how much in-session context each one carries:

• Enterprise browser with built-in policy: native visibility into the session, so copy, download, upload, and paste are governed with identity, device, and data context.
• Extensions on consumer browsers: practical reach into browsers people already use, bounded in extension-only deployments by what the host browser's framework exposes.
• Network or proxy inspection: connection-level visibility into users and destinations, typically without the in-page action or the user's intent.

Island's Enterprise Browser builds conditional access, last-mile controls, and private app access without a VPN into the browser itself. That private access comes through Island Private Access, so internal apps sit behind the same policy as SaaS.

Where an organization isn't ready to switch browsers, the Island Extension brings Island policy to the consumer browsers people already use. Island Enterprise AI applies the same session-level policy to AI prompts, so the paste from the contractor's CRM tab gets evaluated where it's typed. The browser and the extension both work on managed and unmanaged devices, which matters most for the awkward populations from step five.

Policy and session living in the same place means one decision engine with full context, and zero trust gets simpler rather than heavier.

Gartner frames these tools as able to "complement or reduce reliance on VPNs and VDIs," and that's the honest framing. VPN and VDI did their job well for the architecture of their era, and the browser can now carry more of the load. You decide how far that shift goes in your environment.

Friction is how zero trust quietly fails inside the session

Most security teams can tell when a control starts failing, because the help desk tickets stop and the personal webmail attachments start. The quiet is the warning sign. It usually means people found a faster path, and the program no longer sees where the data went.

Controls that only know how to say no push people toward personal devices, personal email, file-sharing accounts, and consumer AI tools. Each workaround creates a session the architecture doesn't see, which inverts the premise of zero trust. The person is usually just trying to finish the work, and the controlled path offered nowhere to go.

A better pattern is the safe yes, which allows the action in a governed form instead of blocking it. Paste goes into the approved AI tool, files open without downloading, sensitive fields get masked, and screens get watermarked. Each option keeps the work moving and keeps the session inside policy.

A support agent who needs a customer's order history can see it with payment details masked, instead of requesting an exception that outlives the ticket. Personal AI accounts deserve particular attention, since a paste blocked in one place has a way of reappearing in an unsanctioned tool.

Most maturity reviews count controls deployed, yet a more honest signal is how rarely people need a workaround. Many teams already collect the data to measure it:

• Sanctioned-app usage versus personal-account usage for the same task
• Blocked actions followed by the same data appearing somewhere else
• Help desk volume tied to access friction
• Exceptions granted and still open long after the need passed

When those numbers fall over successive quarters, verification is reaching the session and the safe yes is doing its job. When they rise, the architecture is pointing to exactly where people need a better yes.

The session is the last layer of zero trust left to close

If you're mapping what comes after the login screen, we're happy to walk through how teams extend zero trust into the session. Request a demo.

FAQs

How do you implement zero trust step by step?

Make identity and device posture the entry condition, then extend policy into the session with last-mile controls and step-up checks on risky actions. Expand one population at a time, and measure how often people route around controls.

How long does it take to implement zero trust?

It's typically a multi-year program; OMB's January 2022 memo gave federal agencies until the end of FY2024 to meet its objectives. The first population can usually be covered well before then.

Is zero trust replacing VPN?

In many scenarios, ZTNA and browser-level controls reduce reliance on VPNs, especially for SaaS and web apps. NIST expects most enterprises to run in a hybrid zero trust and perimeter mode for an indefinite period.

Why does zero trust fail?

It usually stalls rather than fails outright, either because the program stops at the access layer or because friction pushes people onto unmonitored paths. Both outcomes leave the session unverified.

What are the five pillars of zero trust?

CISA's maturity model defines five pillars (identity, devices, networks, applications and workloads, and data) plus three cross-cutting capabilities. The data pillar is where in-session controls do most of their work.