A legacy thick-client application negotiates many dynamic ports and uses server-initiated connections, and it fails over per-application ZTNA. Remote users still need it, and the company wants to deliver this through Secure Access rather than its own VPN headend. Which option fits?
Select an answer to reveal the explanation.
Short Explanation
Some old apps just won't fit through a per-app door — they need the whole hallway. VPN as a service in Secure Access gives Secure Client users network-level access without you running your own headend. Browser-based access is the trap; a thick client isn't a web page.
Full Explanation
Cisco Secure Access includes VPN as a service, delivered from the cloud and used with Cisco Secure Client. It provides remote access VPN connectivity with network-level reach to private resources through the service and its connections to the data center, while access rules still govern what the VPN user is allowed to reach. That makes it the fit for legacy applications that negotiate dynamic ports, rely on server-initiated connections or otherwise break per-application zero trust access, and it lets the company retire or avoid its own VPN headend. Browser-based zero trust access publishes web applications for use in a browser; a thick-client application using dynamic ports is not a web application and cannot be delivered that way. DNS-layer security resolves names and blocks malicious domains; it neither carries application traffic nor opens dynamic ports. An API-based CASB connects to SaaS tenants out of band to scan data; it does not broker user sessions to an on-premises application. Exam caveat: prefer zero trust access where the application supports it and reserve VPN as a service for the cases ZTNA cannot serve, keeping access rules as narrow as possible. Operational check: connect a test user with Secure Client using VPN as a service, launch the legacy application, and confirm its sessions appear in the activity logs under the expected access rule.