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.
Data > opinions