Implementing ZTNA for Remote Support: How to Stop Granting "God Mode" to Your Help Desk

Most IT security leaders can walk you through their zero trust posture with confidence. Identity governance is documented. Network segmentation has been audited. Endpoint hardening policies have been reviewed by InfoSec and signed off at the C-suite level. The architecture diagram looks airtight.

And then a technician opens TeamViewer to resolve a ServiceNow incident, and the entire framework develops a quiet, persistent hole that nobody in that audit process thought to look for.

This is not a configuration problem. It is a belief problem. The belief is that zero trust network access, once implemented at the network and identity layer, extends naturally to every tool running on top of it. It does not. ZTNA for remote support is not the same thing as ZTNA around remote support, and that difference is where the exposure lives. Specifically, it lives in the identity layer your remote support tool brought with it: the one sitting parallel to ServiceNow, ungoverned, and invisible to every control your ZTNA project put in place.

What Most IT Leaders Believe About ZTNA

The prevailing assumption is that ZTNA is a framework applied to infrastructure, and that applications running within that infrastructure inherit its protections. An employee authenticates through an identity provider before reaching the network. Devices are posture-checked. Lateral movement between segments is controlled. In theory, everything inside it is covered.

Remote support tools get filed under "internal tooling" in this mental model. They sit behind the identity provider. They run on hardened endpoints. They are, therefore, covered.

ZTNA frameworks govern access to resources. They do not govern what a resource does once access is granted. TeamViewer, Bomgar, and ScreenConnect do not become zero-trust-compliant because they sit behind an identity-verified perimeter. Their internal architecture, specifically the persistent endpoint agent model they all depend on, operates entirely outside the zero trust verification loop. The framework checked identity at the door. The agent was already inside.

What "God Mode" Actually Looks Like at the Help Desk

Security architects use this term when a single credential, role, or access pathway grants capabilities far beyond what any specific task requires. At the help desk, it is less dramatic than it sounds and more dangerous than it looks: a technician whose access to an endpoint is not scoped to an incident, not time-bound to a session, and not visible to the same governance layer that governs everything else in the environment. The persistent agent is what makes it possible.

The access exists before the incident does. The TeamViewer or Bomgar agent is installed on an endpoint. From that moment, a connection pathway exists regardless of whether a ServiceNow incident has been raised, regardless of whether a technician has been assigned, and regardless of whether anyone in the governance framework has authorised anything.

The access survives after the incident closes. When the session ends, the agent stays. The same access pathway that existed before the session exists after it. Nothing about the endpoint's exposure changes because a ticket was resolved.

None of this is visible to your governance framework. Your ServiceNow RBAC policies, your identity provider, your PAM solution: none of them have line-of-sight to what happens inside the remote support tool's own permission layer. They see that the application was authenticated. They do not see what access the application then exercised.

The architecture grants this unconditionally. No technician has to do anything wrong for it to be a problem.

Why This Gap Survives Every ZTNA Project

The gap persists for a reason that is more organisational than technical.

ZTNA projects are owned by the network security team. The remote support tool is owned by the service desk or desktop engineering team. Neither team has a strong reason to sit in the other's audit process, and so neither does.

The network security team maps the ZTNA implementation for IT infrastructure against the components they own: firewalls being decommissioned, VPNs being retired, identity providers being consolidated, endpoint detection being deployed. The remote support tool passed procurement. It has a vendor security questionnaire on file. It gets categorised as a managed application dependency and drops out of ZTNA scope before anyone asks the question that matters.

The question nobody asks: Is this tool's internal session model compatible with the zero trust framework being built around it?

Compatibility is assumed because the tool authenticates through the same IdP everything else uses. But IdP authentication at login is not zero trust session governance. The former verifies who opened the application. The latter governs what access exists once it is open, under what conditions that access can be exercised, how long it persists, and what trace remains after the session ends. Legacy remote support tools pass the first test. They were never designed to answer the rest.

What Your ZTNA Implementation Leaves Exposed at the Session Layer

Most ZTNA implementations for IT are scoped to infrastructure. What they leave unaddressed is the session behaviour of the remote support tool sitting inside that infrastructure: the specific controls that govern what happens inside a remote support session, not just around it. These are not gaps in the ZTNA framework itself. They are gaps in how the remote support tool responds to the framework's demands.

There are three of them, and legacy tools fail all three.

1. Session identity must come from your corporate directory, not the tool

If your remote support tool has its own identity layer, you are running two parallel governance systems. Permissions can exist in the tool that your identity framework has not authorised, cannot audit, and cannot revoke in real time. Secure remote access for a help desk technician should be a direct expression of what your directory says that person is allowed to do, not a translation of it managed inside a vendor's own admin console.

2. Nothing should persist on the endpoint between sessions

A session starts when a ServiceNow incident requires it. It ends when the incident is resolved. The endpoint's security posture after the session should be identical to its posture before. No agent running in the background. No service listening on a port. No residual connection pathway between the machine and a remote support vendor's infrastructure.

3. The session log must write to the ticket automatically, without technician input

Manual documentation is not an audit trail. An audit trail is a record the system produces regardless of whether the person operating it remembers to, chooses to, or has time to. If the session log depends on a technician filling in notes before closing a ticket, what exists is a compliance aspiration, not a compliance record.

How ScreenMeet Removes the Permission Layer Legacy Tools Leave Behind

Most zero trust implementations are built around the assumption that every tool inside the perimeter will defer to the organisation's identity and governance framework rather than introduce its own. That assumption holds everywhere except, typically, the remote support tool. ScreenMeet is built around the same principle: session identity comes from ServiceNow, access rights come from ServiceNow, and nothing in the session architecture sits outside the governance layer the organisation has already established.

Most remote support tools arrive with their own identity layer. Their own admin console. Their own permission model sitting parallel to everything the organisation already governs in ServiceNow. That parallel system is where the exposure lives — not because anyone configures it badly, but because it exists at all.

With TeamViewer or Bomgar, two governance systems operate simultaneously:

1) What your organisation controls in ServiceNow 

RBAC policies, user groups, access rights. When a technician leaves, IT revokes their ServiceNow access and the job is done.

2) What the vendor controls inside their own tool 

A separate permission layer that does not know what happened in ServiceNow. That same technician may still have active access in the remote support tool until someone separately locates and updates their configuration there too.

These are not theoretical failure modes. They are the routine reality of running a tool whose identity model was never designed to defer to the governance framework sitting around it.

ScreenMeet has no parallel system. When a session launches, the technician's identity comes from ServiceNow's directory. The access rights governing that session are ServiceNow's RBAC, the same policies already managed, audited, and enforced across every other workflow. There is no ScreenMeet admin console where access can be granted that ServiceNow has not already authorised. A technician removed from ServiceNow groups loses session access at exactly the same moment, because there is nothing separate to revoke.

That is the behaviour zero trust assumes of every tool inside its perimeter. Most remote support tools have never delivered it, because their architecture was never designed to.

Every Session Action Writes to the ServiceNow Ticket Automatically 

When every session action writes automatically to the ServiceNow incident record, something more consequential happens than better documentation. The session becomes part of the incident. Not a report generated from the session, not a log exported from a remote support tool and imported into ServiceNow. The session and the incident record are the same object.

An audit trail that lives in a separate system from the incident it documents is, in practice, a reconciliation exercise. Two records that should match but may not. Two systems that need to be queried separately. Two possible points of divergence that an auditor has to manually resolve. When InfoSec investigates an access event, the answer should come from one place: the ServiceNow incident record, not from ServiceNow plus a session log export from a vendor portal.

With ScreenMeet, session duration, device information, actions taken, and the AI-generated session summary write to the incident record automatically when the session closes. The technician does not decide whether to document it. It is a structural output of a session model that is native to ServiceNow, not connected to it. If the session were not genuinely native to ServiceNow, the audit trail could not live natively in the incident record. The automatic write-back is the architectural evidence, not the marketing claim.

Why IT Teams Are Replacing TeamViewer and Bomgar Right Now

Organisations running TeamViewer, Bomgar, or ScreenConnect on top of a ZTNA framework are not outliers. They are the norm, because the ZTNA conversation and the remote support tool selection have historically happened in different rooms, with different stakeholders, against different criteria.

The CVE disclosures against major remote support vendors have accumulated into a pattern too consistent to attribute to individual implementation failures. InfoSec teams that previously categorised remote support as a managed application risk are now categorising it as an architectural risk, and architectural risk requires a different kind of answer than a policy update or a questionnaire response.

IT leaders going through this reassessment are looking for zero trust support tools, not tools that claim ZTNA compliance while running a persistent agent on every managed endpoint. The criteria have shifted from feature lists to session architecture: does this tool create standing access, or does it inherit session identity from the governance framework already in place?

ScreenMeet does not replace a ZTNA implementation. It is the remote support tool that does not undermine one. When a session launches, the technician's identity comes from ServiceNow's directory and the access rights governing that session are ServiceNow's RBAC — the same policies the organisation already manages across every other workflow. There is no parallel permission layer for someone to misconfigure, no separate admin console where access can persist after a ServiceNow revocation, and no governance gap between what the identity framework authorises and what the remote support tool actually allows.

The ZTNA framework has a hole at the help desk session layer. That is the specific gap ScreenMeet closes, and the only one it needs to.

If you are in the middle of a ZTNA implementation or reassessing your current remote support tool, see how ScreenMeet handles session identity, access governance, and audit trail natively inside ServiceNow. Book a demo and see it in action.

‍