To Secure Apps With Zero Trust, Stop Onboarding Them One by One

Key Takeaways

• To secure apps with zero trust, enforce per-session policy in the layer your apps share instead of onboarding applications one at a time.
• Per-app SSO, connectors, and ZTNA segments protect prioritized apps. Internal web apps, legacy tools, and new AI apps often wait in the backlog.
• Zero trust application security has to cover what happens after login, including downloads, copy and paste, uploads, printing, and data entered into AI tools.
• Measure zero trust coverage by the share of work sessions governed by policy, not by the number of applications onboarded.

App-by-app zero trust was the right first move, and the long tail outgrew it

Most zero trust roadmaps share a familiar shape. One column lists the apps already onboarded, each with SSO federated, conditional access tuned, and a ZTNA segment in place. The column next to it, the apps still waiting their turn, keeps getting longer.

Per-app onboarding was the right first move, because identity was the most urgent gap and the highest-value apps needed hardening before anything else. Teams federated those apps with SSO, wired up API connectors, and placed a reverse proxy or ZTNA segment in front of each one.

The approach solved the access problem of its era, and it solved it well. What's changed is the size of the app estate it's now being asked to cover, and the pace at which new apps arrive.

Each onboarding is a small project, with an app owner, a change window, a compatible connector, and testing before anyone flips the switch. Those costs don't shrink as the app count grows, because the 80th app needs the same steps as the eighth.

In practice, the backlog is a spreadsheet of app names with a status column and a target date that keeps moving. One app waits on a busy owner, another on a vendor's connector roadmap, and a third on a change freeze that delayed testing. Meanwhile, people keep working in those apps daily, under whatever controls existed before the program started.

In the patterns we see, coverage runs out in a long tail of internal apps without modern authentication, legacy tools, and SaaS without usable APIs. Departmental tools and newly adopted AI apps join it faster than most review queues can move.

The tail isn't getting shorter, either. Gartner predicts, as reported by TechRepublic, by 2027, 75% of employees will acquire, modify, or create technology outside IT's visibility. That's up from 41% when Gartner made the forecast, and plenty of that technology will show up as apps nobody scheduled for onboarding.

Federal policy points the same direction. The Office of Management and Budget's M-22-09 zero trust memo tells federal agencies "every application should be treated as internet-accessible from a security perspective." Pair that expectation with a delivery model where each app is its own project, and the math gets hard quickly.

Most zero trust roadmaps don't stall on the hard apps. They stall on the hundredth easy one.

Zero trust for applications was always meant to be per session, not per login

Most teams can tell you exactly who signed in to the finance app this morning. Fewer can tell you what left the app afterward, where it went, or which device it landed on.

SSO and MFA do their job well at the moment of sign-in. The standards behind zero trust describe something more granular, and they've described it for years. The third tenet of NIST SP 800-207, the zero trust architecture standard, reads: "Access to individual enterprise resources is granted on a per-session basis."

Its fourth tenet ties access to dynamic policy, including the observable state of the user's identity, the application, and the requesting device. Read together, the two tenets make the session the unit of trust. NIST doesn't say where to enforce it and leaves the choice to each organization's architecture.

CISA's Zero Trust Maturity Model v2.0 is a maturity roadmap written for federal agencies. Its "Optimal" stage describes an agency that "continuously authorizes application access, incorporating real-time risk analytics." Continuous authorization is hard to deliver from a check that runs once at sign-in.

Login-time checks also miss what happens to a session once it exists. The FBI's Atlanta field office warns stolen "Remember-Me" cookies can let attackers sign in to web email accounts without a password or MFA. In that scenario the strong sign-in did its job, and the session was still exposed.

Most session risk, though, comes from ordinary work rather than attackers. Here's what login-time checks don't see once a session is open:

• Downloading files from a sanctioned app to an unmanaged device.
• Copying customer records into a personal email or notes app.
• Uploading internal data to an unsanctioned AI tool.
• Printing or screenshotting a view full of sensitive data.
• Sharing the page with an unvetted browser extension.

These actions typically don't trigger a login prompt, and each one happens after the identity check has passed. If the session is the unit, enforcement belongs wherever sessions happen, and for most enterprise work that's one place.

The scalable unit of zero trust is the layer every app shares

Your users already open most of their work apps the same way, in a browser tab. The CRM, the HR portal, the internal tool built years ago, and the new AI assistant all render on the same surface. That shared surface is where per-session policy can apply once and reach all of them.

When policy lives in the browser layer, identity, device posture, and in-session controls apply to any web or SaaS app without a per-app connector. The 101st app inherits the policy the first app has, on its first day. The connector work, change windows, and testing cycles from the per-app model drop out of the picture.

Policy defined once in the shared layer also stays consistent, which matters more than it sounds. When a rule changes, it changes across those apps at once, instead of drifting as separate connectors update on separate schedules. Auditors get one policy to review rather than a stack of per-app configurations, each slightly different from the last.

Analysts have noticed the same shared surface. In its April 29, 2025 enterprise browser forecast, Gartner put adoption at less than 10% of organizations. By 2028, Gartner predicts 25% of organizations will augment existing remote access and endpoint security tools by deploying at least one enterprise browser technology.

The word worth noticing is "augment." It describes a layer added to the stack most organizations already run, and that's the right mental model for session-level enforcement.

Session-level enforcement can sit in three places, ordered here by how much of the session each one can see:

1. Enterprise browser with security built in. Policy runs where the page renders, covering copy and paste, download, print, screenshot, and data masking.
2. Extensions that add policy to existing browsers. They reach consumer browsers and contractor devices, and they work well alongside an enterprise browser.
3. Network and proxy enforcement. It sees traffic in transit, though not what the user does on the rendered page.

Each approach has a role, and extension-only approaches inherit the strengths and limits of the host browser's architecture. Network controls stay valuable for traffic outside the browser, while the deepest session visibility comes from the place where the page actually renders.

Island's Enterprise Browser applies conditional access, device posture checks, last-mile controls, and DLP inside the browser itself, so security is built in, not bolted on. The Island Extension brings policy to consumer browsers for people who work there, and customers use the two in tandem. Island Enterprise AI uses the same session layer to govern data headed into AI tools.

SSO and ZTNA stay where they are, doing their jobs at sign-in and on the network. The shared layer extends their reach into the session itself, where the data actually moves.

The benefit extends to incident response: for one customer, The Bank of Marion, phishing investigations dropped from hours to three minutes with browser-native session visibility. It's one bank's experience, and it shows what changes when session data lives in one place instead of a dozen logs.

The long tail is mostly people and tools you don't control

A contractor needs two internal apps by Monday, and their laptop belongs to someone else. Most per-app models were built around a managed device or an installed agent, and this user has neither.

The standards are candid about this gap. NIST SP 800-46r2, the telework and BYOD security guide, notes agreements with third-party and BYOD device users "generally cannot be automatically enforced." A signed acceptable-use policy is a comforting document and a fairly weak control.

The usual workarounds are shipping a corporate laptop or standing up a VDI session for a two-app workflow. Both made sense when they were the only practical options, and both still carry weeks of logistics or a heavy per-user cost. A shared session layer changes the shape of the problem.

The contractor signs in on their own device and reaches the two apps under per-session policy. Sensitive views can be read without being downloaded, copied, or printed to hardware the company doesn't own. When the engagement ends, access ends with the session policy, with no device to collect.

Inside that session, policy can watermark sensitive views, mask fields the contractor doesn't need, and block pasting into personal apps. To the contractor, it still feels like an ordinary browser tab. BYOD programs and newly acquired teams share the contractor's problem at a larger scale, and the same model reaches them.

AI tools follow a similar pattern, only faster. Gartner's November 19, 2025 survey release found 69% of organizations suspect or have evidence employees are using prohibited public GenAI. Few people file a ticket before pasting a spreadsheet into a chatbot.

Blanket blocking tends to move the same work somewhere less visible. A shared session layer lets security teams see what data is going into AI tools and apply policy in the moment. With that visibility, the business can say yes to AI without guessing what left in the prompt.

Start where onboarding never reached, and measure sessions instead of apps

Most zero trust programs already have a pilot plan. The harder question is which apps go first, and how anyone will know the program is working six months from now.

Here's a sequence built around the shared-layer model:

1. Inventory sessions, not apps. Use browser-level telemetry to see which apps people actually use, and expect a longer list than the catalog.
2. Start with the long tail, not the crown jewels. Internal web apps, contractor workflows, and AI tools usually offer the fastest risk reduction.
3. Write policy once and reuse it across apps. Define data rules by sensitivity and user context, such as view-only access on unmanaged devices.
4. Report coverage as governed sessions. Track the percentage of work sessions under policy instead of the number of apps onboarded.

The inventory step tends to surprise teams, because browser telemetry shows where sensitive data actually moves rather than where the architecture diagram says it moves. Expect a few tools nobody approved, and a few more nobody remembers approving. Use the list to rank the long tail by data sensitivity rather than by how often an app owner asks.

The second step runs against instinct, which is why it matters. Crown-jewel apps already have SSO, MFA, and close scrutiny, so another control there adds less than it seems.

The long tail has had the least attention, yet it's the easiest to cover with one policy layer. Most of it doesn't need a connector, an app owner's sign-off, or a change window to inherit session controls.

Step three is where the per-app tax starts to fall away, because a rule like "unmanaged device means view-only, no downloads" gets written once. It then applies to the HR portal, the contract repository, and the internal tool whose original owner left years ago. If the contract repository later moves to a new SaaS provider, the rule follows the session instead of waiting for a new integration.

Keep SSO and ZTNA exactly as they are during this step. The shared layer adds session controls on top, so the rollout is an extension of the existing architecture rather than a migration away from it.

The fourth step changes the conversation with leadership, because an apps-onboarded count sounds like progress until someone asks how many apps are left. A governed-sessions percentage answers the question boards actually care about, and it exposes the long tail the first number hides. It also gives security teams a number they can raise each quarter by extending policy to the next group of users.

Adoption matters as much as policy depth. When controls live in a familiar browser, users have fewer reasons to route around them, and fewer workarounds mean fewer blind spots. Friction is one of zero trust's quiet adversaries, since a control people avoid doesn't protect much.

The next app you add shouldn't need its own project

If you're rethinking how zero trust reaches the rest of your apps, we're happy to walk through what we've built. Request a demo.

FAQs

What are the three principles of zero trust security?

NSA's zero trust guidance names three guiding principles: never trust, always verify; assume breach; and verify explicitly. For applications, all three have to hold for the whole session, not just at login.

How does zero trust application access differ from a traditional VPN?

A traditional VPN typically connects users to the network, and joint CISA and FBI guidance warns a compromised account on VPN can reach all services on that network. Zero trust instead authenticates and authorizes access to each application, and NIST SP 800-207 grants that access per session.

What happens after a user logs in to an app under zero trust?

Policy should keep governing the session, including what can be downloaded, copied, printed, or entered into AI tools. Those rules depend on who the user is and which device they're on.

How do you apply zero trust to apps that don't support modern authentication?

Enforce policy in the layer the app is accessed through, such as the browser. Legacy and internal web apps then inherit session controls without a per-app integration.

What are the disadvantages of zero trust security?

Implementation takes real effort: a 2025 GAO review found some federal legacy systems can't adopt OMB's zero trust strategy without modernization. NIST SP 800-207 also flags user experience tradeoffs from repeated reauthentication, and both costs tend to grow when zero trust is delivered app by app.