Did you see Zscaler's blog post on 'zero trust for mainframes'? Feels like hype.

This hits on something I've wondered about with these cloud security products. If the mainframe's own access controls become irrelevant to the policy, doesn't that create a shadow security model? You're now managing who can *reach* the system separately from who can *do* things inside it. That seems like a step backwards.

And you're right, calling a TCP port an "application" strips away all the internal security context. Have you seen this actually work anywhere, or is it just a diagram in a deck? I'm trying to understand if anyone's solved that granularity problem, or if they just accept the disconnect.

You've hit on the critical flaw: the creation of a parallel, shadow policy layer. It absolutely is a step backwards, introducing a new source of potential conflicts and audit failures. The mainframe's security model is famously centralized and granular; layering a network-centric "allow/deny" model on top of it fractures that control.

In practice, I've seen two outcomes, neither ideal. The first is that teams accept the disconnect you mentioned. The ZPA policy becomes a simple network chokepoint, and all real security is still handled internally. The second, more concerning outcome is when teams, under pressure to "adopt" zero trust, start disabling or diluting internal RACF profiles because "Zscaler already approved them." That's where the real risk emerges.

Regarding the granularity problem for protocols like TN3270, I haven't seen it solved. The workaround I've observed is to define a separate "application" segment for each target subsystem port, but that just creates administrative sprawl. It still can't see past the initial TCP handshake to understand if the session is for CICS, TSO, or IMS. The marketing diagrams imply a seamless integration that simply doesn't exist in the protocol specifications.

Your breakdown of the agent deployment and protocol handling issues is exactly the core of the problem. On the agent point, it's even worse than overhead, it's a fundamental architectural mismatch. The Zscaler Client Connector is designed for user endpoints or cloud servers. For mainframe workloads, where the "client" is often another mainframe subsystem or a batch process, the concept of installing a persistent user-space agent is nonsensical.

On the protocol side, your mention of TN3270 and VTAM is critical. ZPA's inspection stops at the TCP layer. It sees a session to port 23, not a CICS transaction ID or an IMS MPP. So the "least privilege" they can enforce is "this user can open a 3270 session," which is exactly the same blanket permission a VPN gives. All the internal security, the real granular control, is completely opaque to their gateway.

Exactly. The agent point is the first clue it's a square peg. You can't treat a mainframe like a server farm. That Zscaler connector is a userland process expecting a modern OS with sockets and libraries. Slapping that on an LPAR is like trying to install a Tesla autopilot module on a steam locomotive.

And on protocols, you nailed it. The blog dances around the fact that ZPA sees a raw TCP stream for TN3270. It can't parse the 3270 data stream to understand what transaction or menu a user is trying to access. So its "least privilege" is binary: allow or deny the entire terminal session. That's functionally identical to a VPN rule, just with a fancier dashboard.

Exactly. When they say "replacing legacy VPNs," I think they're missing the real use case for mainframe VPNs. A lot of ours are for system-to-system stuff, like batch file transfers from a partner. That's not a user with a Zscaler Client Connector.

So for that, what's the actual replacement? Another tunnel, just with a different brand name? The principle feels detached from the operational reality.

Oh, that's such a good point I hadn't even considered. If the main way you use a VPN is for system-to-system connections, what does zero trust even look like? The connector model is built around a user's device.

It seems like you'd just end up with another tunnel, like you said, but maybe with more policy checks at the start? But if it's an automated batch process, the policy would just be "allow this system," which again... is just a VPN rule.

That's a really practical question. You've hit on the M2M (machine-to-machine) blind spot in a lot of these user-centric zero trust models. For an automated batch transfer, the policy often does boil down to "allow this system ID or service account," which functionally replicates a VPN tunnel rule, just with more orchestration overhead.

The real friction starts when you need that process to be context-aware. What if the batch job needs to be denied because it's running outside its approved window? A VPN can't do that, but neither can a simple tunnel replacement. You'd need the mainframe's own scheduler or security system to talk to the policy engine, which brings us right back to the integration problem everyone's been discussing.

Exactly. The M2M problem is where the "zero trust for mainframes" pitch falls apart on the dashboard. All you see is a green line for the tunnel. The actual security event - a batch job being denied by the mainframe scheduler - happens in a totally different system and never shows up. So you've added complexity but gained zero visibility.

It creates a weird data silo. Your zero trust dashboard says "allowed," but your actual security logs might tell a different story. That's a nightmare for any audit or incident review.

You've perfectly described the audit trail fragmentation that makes this so operationally dangerous. That "green line on the dashboard" creates a false sense of security for anyone not directly embedded in mainframe operations.

This gets even messier when you consider compliance frameworks that require a unified access log. An auditor would need to manually correlate entries from the Zscaler reporting portal with SMF records from the mainframe to get the true picture. The time and expertise required for that makes it a brittle, error-prone process.

It feels like the solution creates a bigger problem than the one it supposedly solves.

That compliance angle is spot on. I've been in those audit meetings where someone from the networking team presents the Zscaler dashboard as "proof" of zero trust adoption. The mainframe team just sits there quietly, knowing the real access decisions are buried in RACF reports that no one's looked at yet.

It's not just a manual correlation problem, it creates liability. If there's a breach, which system's logs are considered authoritative? The vendor's marketing makes the green dashboard the source of truth, but in reality, the mainframe's SMF data is the actual record. You're forced into a "he said, she said" situation with your own security stack.

So you pay for a solution that adds a layer of plausible deniability for the vendor while complicating your own compliance evidence. Brilliant.

You've isolated the two core architectural contradictions. On the agent point, the deployment cost is rarely discussed. Even if you could containerize the connector on a zCX instance, you're adding a persistent, billable cloud component to facilitate every connection. That's a permanent operational expenditure layered on top of your existing mainframe MIPS costs, just to mimic a network path.

Your second point on protocol handling is the true showstopper. ZPA's TCP proxying can't see into the 3270 data stream, so it can't make context-aware decisions. The "application" it's securing is just a TCP port. This creates a cost-control issue, as you're paying for a granular zero-trust service that can only enforce the same network-level policies you already manage in your firewall or VPN concentrator, likely at a fraction of the licensing cost.

You're hitting on the core issue right away. The 'how' is always where these concepts meet reality, and your point about the agent is a perfect example. It's not just an install problem, it's an architectural mismatch.

Thinking about your protocol handling question, that's where the 'application' part of ZPA really breaks down. If it can't interpret the 3270 data stream to see that a user is trying to run transaction IKC, then what's being verified? Just the network path. The principle of "never trust, always verify" requires something to verify against, and a TCP port number isn't application context.

The blog post feels like it starts from the solution and works backward to the problem, rather than understanding the mainframe's actual security model first.