RDP support can prove that a gateway handles RDP. It cannot prove it secures your proprietary client-server application, database connection, SSH workflow, or mixed-port legacy service.
If one protocol assumption fails, a Zero Trust rollout can add latency, bypass paths, outage risk, or an expensive return to VPN.
The Best ZT On-Prem for Legacy Apps (No Rewrites) supports each application's actual protocol. It uses outbound-only connectors and integrates with your IdP.
It also delivers HA without code changes. Compare protocol coverage, latency, failover, data residency, licensing, and rollback options before approving a pilot.
Choose by protocol, connector, and failover proof
A suitable on-premises gateway protects a named private app through an outbound connector. The connector starts an encrypted connection outward.
This approach avoids exposing a server to the internet.
Match the gateway to the actual flow
Validate the actual client-server flow. HTTP/S publishing does not prove support for RDP, SSH, SMB, database clients, or proprietary software.
| Application pattern | What to validate | Pilot risk |
|---|
| HTTP/S web app | Host headers, TLS certificates, SSO redirect | Low to medium |
| RDP or SSH | Session length, clipboard, file transfer, reconnect | Medium |
| SMB or database client | Name resolution, secondary ports, throughput, auth | Medium to high |
| Proprietary client-server app | All ports, callbacks, licensing, persistent sockets | High until proven |
Test high availability as a user would
Test an active session for 4 to 8 hours. Kill one connector and measure reconnect time.
Confirm whether the client resumes or requires a new login. Also test IdP loss, DNS failover, capacity, and added round-trip delay.
Purchase gate: Require evidence for every critical app. Test successful login, a normal business transaction, an 8-hour session, connector loss, and rollback. A vendor claim of “TCP support” does not prove your client behavior works.
A practical on-premises ZTNA design keeps the gateway connector inside the protected application's network segment. Users authenticate through an IdP before receiving an identity-based access policy.
External users connect to the provider edge or control plane. The connector creates the outbound path to the private application.
No inbound application port needs publication.
Internal DNS should resolve the approved application name consistently. Firewall rules should let each connector group reach only assigned servers and ports.
Separate production, development, and third-party connector groups reduce lateral movement. They also make residency boundaries, log ownership, and HA failover easier to audit.
When comparing products, classify the gateway by how it carries traffic. Do not rely on a broad “Zero Trust” label.
A browser-only reverse proxy can work well for HTTP/S. It usually does not give equal access for native database, SMB, or proprietary TCP clients.
A client-based broker may support more protocols. It can also add endpoint deployment and compatibility needs.
Connector-based private application access often fits when inbound firewall changes are unacceptable. It must still prove DNS handling, persistent sessions, secondary connections, throughput, and connector-loss testing.
Score each option against the same protocol matrix. Include IdP integration, HA failover behavior, data location, licensing metric, and operating ownership.
RDP and SSH access can move first
RDP and SSH are often the best first migration group. Their ports and user flows are known.
Access can also be limited to named servers.
Put connectors near approved servers
Place each connector in the segment that reaches its target server. Limit firewall rules to required ports.
Use separate connector groups for production, development, and vendor access where risk warrants it.
Preserve names, identity, and certificates
Validate internal DNS and SAML or OpenID Connect sign-in. Also validate LDAP, Active Directory, Kerberos, local-account, certificate, and service-account requirements.
Those requirements may be separate from the application itself.
For RDP and SSH, select a gateway with outbound connectors and native-session behavior. It should also have identity-based policy and tested failover.
Keep VPN available during the pilot. Do not apply RDP results to SMB, SQL clients, or proprietary software.
Databases and thick clients need deeper proof
Database tools and proprietary thick clients need deeper testing. A visible server connection can hide license checks, file shares, callback ports, or secondary database links.
Find hidden network dependencies
Create a flow inventory for source, destination, protocol, port, DNS name, authentication, session duration, and business owner. Record traffic during startup, reporting, printing, exports, recovery, and overnight jobs.
Hidden dependencies often appear only during business work.
Inspect TLS without breaking the client
Test TLS inspection on and off for each path. It can break certificate pinning, mutual TLS, or legacy clients that trust only a vendor certificate.
Avoid buying a web proxy as a ZTNA gateway
A web reverse proxy may suit web apps. It is not automatically a private-application gateway for all legacy traffic.
Count operating cost and data location
Include user, app, connector, or traffic licenses. Also include support, certificates, SIEM logging, retention, and staff time.
Confirm where identity events, policy decisions, telemetry, and logs reside.
Run failure and rollback drills
Keep the existing VPN or access path usable until agreed tests pass. Define who can revert policy.
Preserve DNS and firewall settings. Set a recovery target, such as restoring the old path within 15 to 30 minutes.
Do not force this approach when an application depends on hard-coded IP addresses or broadcast discovery. It also fails with multicast discovery, unsupported UDP, unmanaged devices, or flat lateral network access. Avoid it with impossible-to-federate authentication or extremely low deterministic latency. Use network segmentation, a controlled VPN, VDI, a jump host, partial modernization, or application redesign.
Run a 3-to-7-day proof-of-compatibility pilot with application, network, identity, and security operations owners. Approve production only when success tests, failure tests, log visibility, and rollback targets are met.
Treat migration as a staged service change. Do not treat it as a single VPN replacement.
Start with a low-risk RDP zero trust access or SSH zero trust access workflow. Run it in parallel with the existing route for a defined user group.
Expand only after help-desk teams can support sign-in, client installation, DNS behavior, and session recovery. Business owners must also approve real transactions.
The next wave can include database client security and SMB application access. It can also include proprietary client-server applications.
Each application should retain a documented VPN rollback plan.
This approach makes no-rewrite application security a controlled migration. Policy changes move first, while application code and server addresses stay unchanged.
Exceptions remain isolated until a safer design is available.
Your questions answered
Can ZTNA replace our VPN for every legacy app?
No. Unsupported UDP, multicast, flat-network discovery, and unpredictable callback traffic may still need a segmented VPN or VDI.
Is RDP support enough to approve a gateway?
No. Test session failover, file transfer, clipboard policy, DNS, MFA, and at least one 4-hour active session.
Can an on-premises connector avoid inbound ports?
Yes, if it starts outbound encrypted connections. Validate firewall egress, proxy authentication, TLS inspection, and DNS requirements.
Will gateway MFA fix an old application?
Not always. Gateway MFA protects the access decision, but Kerberos, LDAP, local accounts, certificates, or service accounts may control the session.
How many connectors do we need for high availability?
Use at least 2 connectors for a critical zone. Size between 2 and 4 based on measured sessions and throughput.
What should a legacy-app pilot cost?
Include licenses, connector capacity, support, SIEM ingestion, certificate work, and operations time. Compare a 12-month total.
Does a cloud control plane create compliance risk?
It can. Confirm where policy data, identity events, telemetry, and audit logs are stored, retained, and accessed.
Approve only a tested access path
Choose the gateway that passes your protocol matrix and failure drill. Do not choose the one with the broadest Zero Trust claim.
Start with RDP or SSH and retain VPN rollback. Measure latency and session recovery.
Move database and proprietary clients only after each real business transaction passes.
