We removed the corporate VPN and moved employees to universal ZTNA. Managed laptops are straightforward: the client is deployed through device management, users authenticate with single sign-on, and access policies work as expected. The difficult cases are contractors on personal, unmanaged laptops, vendors in other time zones, applications that require thick desktop clients, and internal agents using separate accounts.
Legal will not allow us to require an agent on personal devices, so contractors currently use a clientless portal that supports browser applications but not several of the desktop tools they need. One vendor still connects to a billing system through an old site-to-site tunnel, and Finance relies on an application that only works through its own client. Each access method has separate policies, configurations, and security controls, with no reliable way to keep them synchronized.
For those who have implemented this more completely, how did you bring managed employees, unmanaged contractors, vendors, and internal agents under a consistent access model without maintaining several unrelated policy systems?
4 Answers
Do not focus only on making every connection look identical. Start with an access matrix: user type, device trust, application, required protocol, business owner, and expiration date. Then enforce least privilege and regular reviews across the ZTNA policies, firewall tunnel, portal, and remote desktop systems. Some exceptions may remain, especially vendor tunnels, but they should be documented as exceptions instead of being treated as part of the universal design.
If VDI is too expensive or too slow to deploy, issue company-managed laptops and make approved company devices a contract requirement. Requiring the ZTNA agent, MFA, sponsored accounts, and periodic access reviews is much easier to defend than allowing unknown endpoints to make broad network connections.
Exactly. A connection can be authenticated and narrowly scoped while the endpoint is still compromised. Without device control or a managed workspace, you have to accept that blind spot or spend more to remove it.
Use different controlled entry points when the workloads genuinely differ, but keep the authorization model consistent. Browser-only users can use a secure browser or clientless portal, while thick-client users can reach a locked-down RDP or SSH jump host. Vendors should have separate named accounts, least-privilege ACLs, approved source hosts where practical, MFA, and automatic expiration dates.
That approach worked for us with a browser-based remote access gateway. External users never get direct Layer 3 access; they only reach the specific jump hosts and applications they need.
The most common answer is to put contractors and other external users into a managed VDI or cloud PC environment. Their personal laptop only needs to reach the virtual desktop, while the desktop itself has the agent, EDR, application controls, and access policies. That also handles thick-client applications much better than a browser-only portal.
That was my first choice too, but the business is pushing back on both issuing equipment and paying for another desktop platform. I may have to make the risk and cost tradeoff explicit rather than pretending ZTNA can solve every exception.
For vendors and contractors, time-limited access and named accounts often reduce more risk than trying to force every use case through one product. The remaining question is whether the business accepts the endpoint risk or funds managed hardware or VDI.