They should prioritise ZTNA when the need is controlled access to applications or internal resources rather than direct desktop takeover. If the business objective is ordinary telework, the access path should be policy-driven, session-scoped and identity-bound, not dependent on a support tool built for supervised maintenance.
When ZTNA is the better fit than remote-control software
ZTNA should be the default choice when the worker needs access to business applications, internal web tools, file services, or service endpoints without taking over the whole device. That distinction matters because ZTNA narrows the access path to approved resources, while remote-control tools create a much broader support channel that can expose the full desktop, local files, and other active sessions.
For home-working, the deciding factor is usually not convenience but blast radius. If the requirement is to let a person use a managed application from an unmanaged or mixed-trust location, ZTNA gives you a more bounded, policy-enforced connection than a screen-sharing utility built for helpdesk support.
ZTNA also aligns better with identity-led access decisions. The session can be tied to the user, device posture, location signal, and application entitlement, so access is granted only for the specific resource and only for the time it is needed. That is a materially different model from remote-control software, which is often designed to let one operator interact with an entire endpoint as if they were seated in front of it.
What remote-control software is still good for
Remote-control software remains useful when the business objective is supervised maintenance, troubleshooting, or guided support. It is a support-plane tool, not an access architecture. If the goal is to diagnose a broken desktop, assist a user through a configuration problem, or administer a host under explicit support conditions, the broad interactive capability is acceptable because that is the purpose of the tool.
The problem appears when organisations use that same tool as the normal way to enable home-working. At that point, they are conflating support with access. The result is usually excessive reach, weaker segmentation, and a habit of granting far more than the worker actually needs to do their job.
A practical way to draw the line is this: if the worker should be able to continue operating even when the endpoint itself is not trusted, use ZTNA. If the operator needs to see and manipulate the endpoint itself in order to resolve a problem, remote-control software is the appropriate narrow-use exception.
How to decide what to prioritise
The strongest indicator is the access objective. When the user only needs controlled access to an application, internal resource, or published service, ZTNA is the right baseline. When the need is full-screen interaction with a machine for support or remediation, remote-control software is the narrower and more defensible choice.
The second indicator is governance. ZTNA is easier to align with least privilege, session controls, and conditional access because each request can be evaluated against a policy. Remote-control software is harder to make proportionate for ordinary telework because the access path is inherently broader than the task.
The third indicator is exposure tolerance. If you would not be comfortable giving a home worker visibility into every local application, notification, and stored file on an endpoint, that is usually a sign that remote-control software is the wrong default and that application-level access is the better design.
Risk and Threat Considerations
Remote-control tools expand trust too far when they are used as a general access layer. They can expose an entire desktop session, allow lateral movement from one open application to another, and create a single high-value channel that is attractive to attackers and abusers.
Failure mechanism: Broad remote-access tooling can turn a narrow support exception into a persistent high-privilege pathway, especially when credentials, approvals, or unattended access are weakly governed.
Impact: A compromise or misuse event can expose more data and more functions than intended, increasing the chance of account abuse, data theft, or uncontrolled changes on the endpoint.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | PR.AA-05 — Identity Management, Authentication and Access Control | ZTNA is an application-access and least-privilege design choice. |
| Recommendation — Enforce policy-based access to specific resources instead of broad remote desktop access. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Home-working access should grant only the minimum resource reach needed. |
| IA-5 — Authenticator Management | Identity-bound sessions depend on controlled credentials and session entry points. | |
| Recommendation — Limit remote access to the specific applications and functions the user needs. Manage credentials so access sessions remain tightly controlled and revocable. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The choice between ZTNA and remote-control software is an access-control design decision. |
| Recommendation — Apply access-control policy to prefer resource-scoped remote access over full desktop takeover. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Remote-working access should be governed through strong access control and review. |
| Recommendation — Restrict and review remote access paths so support tools are not used as default access. | ||
Practitioner Guidance
What to prioritise: Treat ZTNA as the standard pattern for home-working access and reserve remote-control software for break-fix support and tightly supervised administration. If the task can be completed without full desktop takeover, it should not be routed through a tool designed for takeover.
What to verify: Confirm that the access model is session-scoped, resource-specific, and identity-bound, with device posture and application entitlement enforced before the session starts. If the control cannot express those limits, it is not a ZTNA-quality design.
Practitioner takeaway: The right question is not which tool is more powerful, but which one gives the smallest access surface that still lets the worker do the job safely.
Related resources from NHI Mgmt Group
- When should organisations prioritise customer control over convenience in software delivery decisions?
- When should organisations prioritise Zero Standing Privilege for non-human identities?
- When should organisations prioritise access governance over software spend optimisation?
- When should organisations prioritise ZTNA over broader network access models?