Agentless ZTNA is the fastest path to get legacy apps out of the DMZ without rewriting them. If you have internal web apps (Java WAR, old .NET, anything with a browser interface), you can wrap them in zero trust principles in about a week. The key is treating the ZTNA gateway as a reverse proxy with strict identity context.
You need three core components:
* A public-facing ZTNA gateway/service (Cloudflare Access, Zscaler Private Access, Netskope, etc.)
* An identity provider (Okta, Azure AD, even on-prem AD with sync)
* Your legacy app, still sitting in your private network
The workflow is simple. Instead of users hitting a VPN to reach an internal IP, they:
1. Navigate to a company-specific gateway URL.
2. Authenticate against the IdP (with MFA).
3. The gateway establishes an *outbound* tunnel from your network to the cloud service, proxying only approved requests.
The config is all about defining who gets to which app. Here's a generic policy structure you'll be replicating:
```yaml
# This isn't literal vendor config, but the mental model
application: legacy-inventory-app
host: inventory.internal.corp
allowed_users: group:inventory-users
allowed_idp: AzureAD
access_policy: {
session_lifetime: "8h",
require_mfa: true,
device_check: basic_browser_agent
}
```
The heavy lift isn't technical—it's inventorying your apps and defining access groups. The actual ZTNA setup is often declarative. Biggest gotchas:
* Session timeouts: Legacy app sessions might outlive ZTNA sessions. Align them.
* Header injection: The gateway can inject user identity headers (like `X-REMOTE-USER`) so your app might get SSO for free.
* Internal DNS: Your apps still need to be reachable via the hostname the gateway expects.
Skip the agent-based model for these. It's overkill when you just need to secure HTTP/HTTPS/TCP traffic to a few internal servers. The outbound tunnel from your data center means no firewall holes. DMZ gone on Friday.
Build once, deploy everywhere
"In a week" assumes your app doesn't do anything weird with headers, client certs, or websockets. Try that with an app that passes internal IPs in response bodies or uses mTLS.
Your reverse proxy now becomes a single point of failure and a huge log aggregation problem. What's your incident runbook when the gateway service has an outage and your internal app is still healthy but unreachable?
Also, that outbound tunnel. Hope your security team is fine with a persistent connection from your network to a third-party cloud. That's just a different kind of perimeter.
Don't panic, have a rollback plan.
> Try that with an app that passes internal IPs in response bodies
You've hit on the real showstopper. It's not just headers, it's the app logic itself. I've seen a vendor dashboard that embeds the server's local IP in a config panel for "administrators," assuming they're already inside the network. The proxy strips the original client IP, but it can't rewrite that hardcoded string buried in a JSON payload.
Your point about the perimeter is fair, but isn't a tunnel outbound to a single cloud provider inherently simpler to monitor than a VPN's inbound attack surface? It's still a chokepoint, just a different flavor.
The outage runbook is usually "wait for the vendor." That's the real trade-off they don't put in the sales deck.
You're absolutely right about the speed, and that generic policy structure is exactly how the vendor configs end up looking in practice. I'd just add one critical procurement step before anyone starts the clock on that week.
When you're evaluating those ZTNA gateways, you have to treat the "agentless" claim as a compatibility matrix, not a blanket guarantee. Your POC must include a *representative sample* of your oldest, weirdest apps. Not just a simple test app. Build your evaluation criteria around the specific legacy behaviors user49 and user23 mentioned: header manipulation, embedded IPs, client certificate passthrough, and session stickiness.
If you skip that, your one-week project turns into a months-long remediation effort, because you'll be the one rewriting app configs or chasing the vendor's support for a new feature flag. The speed comes from a known-good fit, not from the technology itself.
null
The mental model in your example policy is correct, but the critical implementation detail is session translation. That generic `allowed_idp: AzureAD` is only half the story.
The gateway becomes the new session originator, so your legacy app, which might rely on a specific header like `REMOTE_USER` or a JSESSIONID tied to an IP, now sees the proxy's identity. You'll spend most of that week mapping SAML attributes or OIDC claims into something your app understands, and handling timeouts. If your app uses its own local authentication *in addition* to the gateway, you've just built a dual-prompt mess.
The outbound tunnel also requires careful egress firewall rules. It's not just "allow out to cloud." You need to lock it down to specific FQDNs and ports for the vendor's tunnel endpoints, and your security team will want to inspect that traffic, which breaks the TLS to the gateway service.
infrastructure is code