We removed the corporate VPN and moved employees to universal ZTNA. Managed staff laptops were straightforward: the client is deployed through device management, users authenticate with single sign-on, and access policies work as expected. The difficult cases are everyone who does not use a standard company-managed device.
We have contractors working from personal laptops, and legal will not allow us to require an agent on those machines. The clientless portal supports browser applications, but several contractors need a thick-client application. A vendor in another time zone still connects to one billing system through an old site-to-site tunnel. Finance relies on a desktop client, and internal agents now need access to some of the same systems using separate accounts.
As a result, access policies are split between the ZTNA console, the firewall rules for the legacy tunnel, and a clientless configuration that behaves differently from the full client. Keeping all of these paths aligned has become a manual responsibility that was never included in the project.
Universal ZTNA seems simple for managed employees, but the risk and complexity appear in contractor, vendor, unmanaged-device, and agent access. Has anyone managed to bring these use cases under a consistent policy, or did you end up using VDI, managed hardware, secure browsers, or separate jump-host solutions?
4 Answers
There is no technical shortcut if contractors need thick-client access from machines you cannot manage. Your realistic choices are to mandate the security agent, provide company hardware, or deliver the application through VDI or a controlled remote desktop. Regardless of the connection method, use separate sponsored accounts, MFA, least-privilege application access, periodic reviews, and automatic expiration. ZTNA can reduce exposure, but it does not eliminate the need to define an acceptable endpoint posture.
The most common answer is to put contractors and other unmanaged users into a managed VDI or cloud PC environment. Their personal laptop only needs to reach the VDI session, while the desktop, applications, logging, and endpoint controls remain inside your environment. Access can be limited to the exact systems they need and automatically disabled when the engagement ends.
For vendors that cannot use the normal client, use a tightly restricted vendor identity and a controlled jump host or browser-based RDP/SSH gateway. Put the gateway behind MFA and conditional access, allow only the required applications or ports, and make the account time-limited and auditable. This is not as elegant as one universal path, but it is safer than leaving a broad site-to-site tunnel in place.
The important part is to treat the vendor tunnel as a temporary exception with an owner, expiration date, and explicit scope. Otherwise it becomes permanent infrastructure that nobody remembers to review.
If the business will not permit an agent on personal devices, the cleanest options are issuing managed laptops or requiring a managed cloud desktop. A policy saying that company work must happen only from approved devices is much easier to enforce than trying to make several unrelated access paths behave like one security model. For browser-only SaaS work, an enterprise secure browser can be a lighter alternative to full VDI.
Exactly. ZTNA can enforce identity and application-level access, but it cannot magically make an unmanaged laptop trustworthy. That is a business decision involving risk acceptance, device costs, and operational overhead.
That solves the endpoint problem inside the virtual session, but it does not give you EDR or visibility into the contractor’s physical laptop. You still have to accept that residual risk, require a controlled device, or spend more on stronger browser and session-isolation controls.