The 2026 CISO Guide: Building a Zero Trust Framework for the Modern Help Desk

Every mature Zero Trust program has a version of the same conversation at some point. Identity governance is locked down. Network segmentation is in place. Device compliance is enforced at the perimeter. The CISO is preparing for certification and the framework looks complete. Then someone asks about the help desk session, and the conversation either goes quiet or pivots quickly to a different topic.

The help desk session is the moment in the IT environment where everything the Zero Trust program was built to govern converges in a single interaction. A verified identity, on a verified device, getting unrestricted admin access to a production endpoint through a remote support tool that runs outside ServiceNow's identity framework, maintains a persistent connection to vendor infrastructure whether or not any session is active, and produces an audit trail only if the technician chooses to write one. Most ZT certifications are silent on this. Most CISOs are aware of it and log it as a known risk rather than close it, because the remediation requires changing the tool, not the policy.

This piece argues that the gap has a specific architectural cause, that the tools most commonly deployed to fill it make the gap structurally worse rather than better, and that closing it requires understanding two things in sequence: what the persistent agent model creates between sessions, and what ServiceNow RBAC inheritance eliminates within them.

The Zero Trust Certification Covers Everything Except the Session Where Admin Access Actually Happens

The dominant assumption in enterprise ZT programs is that once identity, network segmentation, and device posture are secured, the program is considered done.

The help desk session sits outside this frame in most program designs, treated as an operational matter, a tooling choice that belongs to the service desk team rather than to the CISO's governance perimeter.

NIST SP 800-207, the authoritative framework for Zero Trust Architecture, does not support that framing. The specification is unambiguous: access to individual enterprise resources must be granted on a per-session basis, with authentication and authorization evaluated as discrete functions before each session is established. No implicit trust can be extended based on network location or prior authentication.

A technician who correctly authenticated to ServiceNow has not, by that act, earned trusted access to a production endpoint. Each access event requires independent verification for each resource.

Two Trust Chains That Never Intersect

What the help desk session creates is precisely the implicit trust condition SP 800-207 requires organizations to eliminate.

The technician's ServiceNow identity and their BeyondTrust or TeamViewer session are two separate trust chains with no shared governance layer. ServiceNow's RBAC governs what the technician can read and update inside the ticket. The remote support tool's own permission layer governs what they can do on the endpoint.

Those two systems do not communicate and are not synchronized. The CISO who has invested in governing one has no visibility into the other. The most privileged access event in the entire service desk operation, a technician with admin rights working live on a production endpoint, sits in the ungoverned layer.

Persistent Agents Were Built for the World Zero Trust Replaced

The standard rebuttal at this point is that TeamViewer, BeyondTrust (formerly Bomgar), and ConnectWise ScreenConnect are enterprise-grade platforms with mature security controls, compliance certifications, and deep deployment histories across regulated industries. The implication is that incompatibility with Zero Trust, if real, would have been surfaced and resolved by the market long before now.

The market has surfaced it, consistently and at significant cost. The incompatibility has been recorded as a series of security incidents rather than identified as the architectural problem it actually is.

The persistent agent model that all three tools depend on was built for a perimeter-trust environment, where the operating assumption was that devices inside the network boundary were trustworthy by virtue of their location. The design logic was straightforward: install an agent on the managed endpoint, maintain a standing connection to the vendor's relay infrastructure, and grant access on demand.

That logic made sense when the perimeter was the primary security control. Zero Trust was developed to replace exactly that assumption. The persistent agent maintains a live external connection to vendor infrastructure across every host in the fleet, continuously, whether or not any session is in progress. That standing access is precisely the condition SP 800-207's per-session access requirement is designed to eliminate.

This is not a configuration problem that tighter policies can address. The standing connection is not a misconfiguration of BeyondTrust or TeamViewer. It is the mechanism those products were built around. Unattended access, a primary use case for both, works because the agent is always connected. Remove the standing connection and the product stops functioning as designed.

The Breach Record Is the Architectural Argument

ConnectWise ScreenConnect, February 2024

CVE-2024-1709 scored 10.0 on the CVSS scale, the maximum possible severity rating. It was an authentication bypass in the remote support agent, exploitable with trivial effort, that gave attackers direct access to environments ScreenConnect was deployed to support. CISA added it to its Known Exploited Vulnerabilities catalog immediately.

A companion vulnerability, CVE-2024-1708, remained under active nation-state exploitation as of April 2026. The entry point in both cases was the standing agent footprint, not any active session.

BeyondTrust, December 2024

A compromised API key in BeyondTrust's Remote Support SaaS gave a Chinese state-sponsored threat actor remote access to US Treasury Department workstations, in an intrusion the Treasury classified as a major cybersecurity incident. CVE-2024-12356 (CVSS 9.8) and CVE-2024-12686 (CVSS 6.6) were both added to CISA's Known Exploited Vulnerabilities catalog. 

The remote support infrastructure was not incidental to the attack. It was the entry point.

TeamViewer, June 2024

APT29, the Russian state intelligence group, breached TeamViewer's corporate environment through a compromised employee account. The breach was contained and did not reach product infrastructure.

What matters is why TeamViewer was targeted at all. It is deployed on over 2.5 billion devices worldwide and used by approximately one in three organizations globally, according to security research firm Obsidian. That concentration of privileged endpoint access is precisely what makes remote support infrastructure a priority target for nation-state actors.

What connects these three incidents is not vendor negligence or isolated engineering failures. Each tool maintained a standing, externally-connected presence across the endpoint fleet, continuously, whether any session was active or not, and that presence is what was targeted. The persistent agent is not incidental to these breaches. It is the attack surface they were built against.

What the Session Gap Looks Like From Inside a ZT Audit

A CISO walking a ZT audit through the remote support layer will face five questions that follow directly from SP 800-207's core tenets. For any organization running TeamViewer, BeyondTrust, or ScreenConnect as the remote support layer inside ServiceNow, none of them produce clean answers.

1) Is the technician's session identity verified per incident through the corporate directory, or through a separate tool credential?

A technician who authenticates to ServiceNow and then opens a BeyondTrust console using BeyondTrust-managed credentials is operating under two identities simultaneously, one inside the organization's governance framework and one outside it. For ScreenMeet, the session is opened by the ServiceNow user assigned to the incident, authenticated through ServiceNow's identity framework, with no separate login and no parallel credential store.

2) Is there standing endpoint access between sessions, or does access close completely when the session ends?

A persistent agent maintaining a live external connection between sessions grants exactly the standing access ZT is designed to eliminate, and it does so across every host in the fleet regardless of whether any session is in progress. ScreenMeet creates a connection for the duration of the session and closes it completely when the session ends, leaving no agent, no external connection, and no footprint on the endpoint. The attack surface that produced the ScreenConnect and BeyondTrust CVEs does not exist in ScreenMeet's architecture because it was never built.

3) Are session permissions scoped to the technician's existing ServiceNow role, or administered in a parallel permission layer?

Legacy tools maintain their own permission administration, separate from ServiceNow, with no automatic synchronization when ServiceNow roles change. ScreenMeet operates through ServiceNow's native role and group structure directly, with no separate permission layer requiring independent administration. This is the RBAC inheritance argument, and the following section makes it in full.

4) Is the session audit trail written automatically to the ServiceNow incident record, or does it depend on the technician's post-session documentation?

A technician who closes a BeyondTrust session and writes a one-line ticket update has produced a record of what they chose to document. ScreenMeet writes session activity back to the ServiceNow incident record automatically throughout the session, from the moment it opens, without any action required from the technician.

5) Can data residency be configured per region by the CISO, without vendor involvement?

ScreenMeet's geo-fencing is configurable inside ServiceNow's governance framework without requiring a vendor support engagement.

Controls two and three sit in a different category from the other three. The first, fourth, and fifth can be addressed through correct integration design. Controls two and three are architectural, describing what the tool does between sessions and whose framework governs access within them. Neither can be resolved through configuration. They require a different tool entirely.

Why the CVE Record Is an Architectural Signal, Not a Vendor Quality Metric

Most CISOs read CVE history as a vendor diligence metric, where a longer record indicates weaker security engineering and a cleaner record suggests more rigorous development practice. That framing positions the evaluation as a question of vendor quality, which is the wrong question entirely.

CVE-2024-1709 scored 10.0 on the CVSS scale not because of how the code was written, but because of what the code was attached to. Over 18,000 ScreenConnect instances were publicly exposed at the time of disclosure, each one a continuously available entry point into the environment it served. The authentication bypass was severe because the surface it exploited never went offline.

CVE-2024-12356 scored 9.8 for the same reason. The command injection vulnerability sat inside infrastructure that maintained continuous administrative access to managed endpoints across thousands of enterprise deployments. The Treasury breach did not require an active support session. The infrastructure was connected and reachable by design, because that is what BeyondTrust's product was built to be.

What the Absence of a Persistent Agent Actually Produces

ScreenMeet has no entries in this category of CVE because it has no architecture that produces them. There is no persistent agent maintaining an external connection between sessions, and therefore no standing attack surface to exploit. 

The attack surface that produced CVE-2024-1709 and CVE-2024-12356 does not exist in ScreenMeet's design because it was never built.

This is not a claim about ScreenMeet's future security posture. No software is permanently free of vulnerabilities, and representing a clean CVE record as a forward-looking guarantee would be inaccurate. The record reflects an architectural absence that a CISO can verify directly, and that is the argument that holds in an audit committee conversation without relying on vendor assurances.

ServiceNow RBAC Inheritance Means One Access Layer, Not Two

Most organizations running a legacy remote support tool alongside ServiceNow are governing two access control systems simultaneously without having made that decision explicitly. Technician roles, permission scopes, and session authorities are configured inside the remote support tool against a user directory that exists independently of ServiceNow's. Every access governance decision the CISO has made inside ServiceNow stops at the boundary of the remote support console.

When a technician's ServiceNow role changes through a promotion, a team transfer, or a termination, that change propagates through ServiceNow immediately. It does not automatically reach the remote support tool's permission layer. When the two systems drift out of alignment:

• A technician may carry session authority in the remote support console that their current ServiceNow role no longer warrants
• The CISO's governance posture reflects a reality that no longer exists
• At audit time, proving that every session was conducted by an appropriately authorized technician requires pulling data from two systems and reconciling them under time pressure

Gaps in that reconciliation are gaps in the audit trail the CISO is responsible for.

How ScreenMeet Closes It

ScreenMeet operates inside ServiceNow's native role and group structure rather than alongside it. Session access is governed by ServiceNow roles assigned directly to the technician's user or group, and ScreenMeet's integration follows ServiceNow's established practice of group-based role assignment, so that when a technician's group membership changes, their session authority changes with it automatically. There is no separate permission layer to update and no separate system to fall out of sync.

When an audit requires a complete record of who accessed which endpoint, under what permissions, at what time, that record exists inside ServiceNow by default. There is no reconciliation exercise between two separate systems, because there is only one system maintaining both the access governance and the session audit trail.

Legacy remote support tools put the help desk session outside the ZT governance perimeter. ScreenMeet puts it inside. That distinction does not turn on feature quality or compliance certification. It turns on whether the tool inherits the access governance framework the organization has already built or requires a second one to operate alongside it.

What Closing the Help Desk Session Gap Actually Looks Like

Zero Trust frameworks in 2026 are sophisticated about perimeter, identity, and device. They have not caught up to the help desk session, where all three converge, where a verified identity gets admin access to a production endpoint, and where the governance framework most commonly stops short.

The persistent agent architecture most organizations have deployed was built for a world where network location implied trust and standing access was the design assumption. That architecture predates Zero Trust by a decade. It cannot be updated to reflect what Zero Trust requires because the standing connection is not a configurable parameter. It is the product.

ScreenMeet closes the gap through architecture, not configuration:

• Sessions launch from inside the ServiceNow incident record
• The technician's identity is their ServiceNow identity, with no separate login and no parallel credential store
• Session permissions derive from ServiceNow's native role and group framework, scoped to the named incident
• The audit trail writes back automatically throughout the session
• When the incident closes, access closes. No persistent agent, no standing connection, no endpoint footprint

ScreenMeet holds SOC2 Type II and ISO27001 certifications and is compliant with GDPR and the EU-US Data Privacy Framework. Geo-fencing is configurable per region inside ServiceNow's governance framework without vendor involvement.

The CVE record reflects the absence of the persistent agent architecture, not as a promise about future behaviour, but as the verifiable consequence of an architecture that never created the standing attack surface.

The CISO's decision, when assessing the remote support layer of a Zero Trust program, is not which vendor carries the more convincing security narrative. It is whether the help desk session, the most privileged access event in the service desk operation, sits inside the Zero Trust governance perimeter or outside it.

The architecture of the tool determines that before the configuration conversation begins.