Just read Zscaler's latest piece on "Zero Trust for Mainframes." I have to say, the technical substance is, frankly, underwhelming. It reads like a marketing team took a perfectly good concept—zero trust—and tried to force-fit it onto mainframe architectures without addressing the real, gritty engineering challenges. The post is heavy on generic principles ("never trust, always verify," "least privilege access") but almost comically light on *how*.
My main issue is the apparent disconnect between ZPA's agent-based, micro-tunneling architecture and the reality of mainframe access patterns and legacy systems. They talk about "replacing legacy VPNs," but gloss over critical details.
* **Agent Deployment:** The blog suggests using the Zscaler Client Connector. On what? Every 3270 terminal? On the CICS regions themselves? The mainframe ecosystem isn't a fleet of cloud VMs where you can simply `apt-get install` a daemon. The overhead and operational risk are hand-waved away.
* **Protocol Handling:** Mainframe access isn't just HTTPS. It's TN3270(E), VTAM, raw TCP for custom applications. ZPA is fundamentally built for web and TCP *application* proxying. The post doesn't clarify if they are just fronting a TN3270 gateway with ZPA (which just adds a complex layer to your existing gateway) or if they've built deep protocol-level integration, which would be a massive engineering undertaking they haven't announced.
* **Identity Context:** This is the biggest miss. Zero trust is about identity *and* context. The blog mentions "user-to-mainframe" zero trust. Fine. But in mainframe environments, a huge portion of access is *application-to-application* (batch jobs, downstream systems). Where is the identity for the batch scheduler? How is MQSeries or IMS transactions authenticated and authorized through this model? The post treats the mainframe as a monolithic "app," which is a dangerous oversimplification.
What I was expecting, and didn't get, was something concrete like:
> "We've extended the ZPA App Connector to run on z/OS as a started task, integrating with RACF or Top Secret to translate enterprise identity into mainframe security calls, and we proxy TN3270 traffic at the protocol level to enforce policy before the session ever hits the VTAM network."
Instead, we get architecture diagrams with clouds and padlocks. This feels like a box-ticking exercise to get "mainframe" on the zero trust feature list, aimed more at CISOs than at the data center or operations teams who would actually have to implement and support this.
Has anyone here actually piloted ZPA for mainframe access, specifically for developer or operator terminals, not just webified mainframe apps? I'm deeply skeptical of the operational feasibility and the true security value-add over a well-configured, network-segmented, and tightly monitored traditional firewall/VPN approach to the mainframe perimeter. The devil is in the details they've omitted.
—davidr
—davidr
Your point about agent deployment hits the nail on the head. Even if you theoretically placed an agent on a z/OS LPAR, you're then faced with the monumental task of defining application segments for every single CICS transaction, IMS program, or batch job that needs external access. The identity context ZPA relies on simply doesn't map to a mainframe's native security constructs like RACF profiles or SAF calls.
The protocol abstraction is the deeper flaw. ZPA's model assumes a clean, session-oriented TCP flow it can intercept and proxy. Mainframe comms are often not that. Take TN3270, it's not just a TCP stream, it's a telnet negotiation followed by a 3270 data stream with embedded control codes. ZPA would have to become a full 3270 gateway, understanding the data stream to make any intelligent access decision, which moves it far beyond its core architecture. The post treats these protocols as mere network noise to be tunneled, which misses the entire security model of the platform.
You're right about the identity mapping being a huge gap. Even if you could somehow tag a CICS transaction with a user's AD identity, you're then asking RACF or ACF2 to make an access decision based on that foreign context. It would require a re-engineering of the mainframe's security boundary itself, not just tunneling the traffic.
And the protocol point is critical. I've seen a few products try to be "smart" about 3270 data streams for auditing, and they become incredibly complex and fragile. The idea of ZPA having to parse screen control codes to understand what "application" is being accessed shows how different the models are.
This makes me wonder, is the real use case they're imagining just for modern APIs coming off the mainframe, like REST services, where the session is more standard? But then the blog's title and premise of "zero trust for mainframes" feels misleading.
Yeah, the protocol point really hits home. If ZPA can't understand the actual conversation happening over TN3270, how does it decide what's allowed? It's just tunneling the noise like you said.
I wonder if they're thinking more about modern mainframe APIs, like REST services, where the session is clearer. Maybe that's the only real fit?
Still, calling it "zero trust for mainframes" feels like a stretch if it ignores the actual protocols most access uses.