The Mainframe Blind Spot in Enterprise Zero Trust

Why Mainframe Security Falls Outside Zero Trust Strategies

Disconnected identity controls, overlooked integration paths, and siloed teams can leave mainframes outside Zero Trust strategies. Closing the blind spots starts with shared accountability. 

Mainframe Zero Trust security often falls outside enterprise programs built around cloud identity and endpoint detection. Mainframe environments running core financial and transaction systems for many of these same organizations are often left out of the conversation entirely. 

Security roadmaps get built around identity providers, conditional access policies, and EDR agents—without consistently extending equivalent controls and visibility to the systems processing critical transactions every day.

This isn’t so much a technology gap as an organizational one. Zero Trust programs are usually owned by teams whose tooling, vocabulary, and metrics were built for distributed, cloud-native architecture. Mainframe teams run a different stack, use a different security model, and often report through an entirely different chain of command. As a result, two halves of the same enterprise end up securing two different threat models, with little shared visibility between them.

Where the Scope Gap Comes From

Most modern security tooling was built assuming a specific set of primitives: identity providers that speak SAML or OIDC, endpoints that can run an agent, and network traffic that flows through infrastructure the security team can instrument. Mainframe environments don’t always fit these assumptions out of the box. 

Access control runs through RACF, ACF2, or Top Secret—mature, effective systems in their own right, but ones that aren’t always fully integrated into the identity architecture supporting an enterprise’s broader Zero Trust strategy.

That mismatch tends to produce one of two outcomes. Either the mainframe gets a parallel, manually maintained security process that never quite stays in sync with the rest of the identity program, or it gets treated as a black box that’s “someone else’s problem”—audited on its own schedule, by its own team, using its own controls. Both outcomes can leave a structural blind spot exactly where an attacker would want one: a system processing the organization’s most sensitive transactions, sitting just outside the visibility of the broader security program.

Access-Control Assumptions That Stop Holding Up

Gaps in Zero Trust implementation become consequential when mainframe environments connect to broader hybrid infrastructure. Web front ends, middleware, and integration layers bridge distributed systems to mainframe back ends. Some integrations authenticate on the distributed side with Kerberos or NTLM, then use a separate service identity to access the mainframe.

This is where the risk can compound. A credential compromised on the distributed side—through, for example, NTLM relay abuse against a vulnerable integration server—could provide a path toward mainframe resources if the compromised identity can use or control a privileged integration service. Whether that path exists depends on the account’s permissions, the authentication configuration, and the controls governing the connection.

This does not automatically bypass mainframe access controls. RACF, ACF2, or Top Secret still governs what the mainframe identity can do. But an attacker operating through an authorized, overly privileged service account may gain access that those controls permit, even though the activity no longer reflects a legitimate business request.

Zero Trust calls for verification and authorization throughout the access path. In practice, the hop between distributed middleware and the mainframe can receive less scrutiny—because nobody owns integrating the controls, and the tooling on both sides wasn’t built with the other in mind.

What a Unified Posture Requires

Closing this gap doesn’t mean replacing RACF, ACF2, or Top Secret with something else. It means treating mainframe identities, permissions, and integration paths as part of the enterprise’s broader identity and access architecture.

A few things make that possible in practice:

• Integrate mainframe identity and account lifecycle management with enterprise identity governance so account creation, access changes, reviews, and removal stay coordinated across environments.
• Log mainframe access events into the same SIEM used for the broader enterprise, so teams can correlate activity across environments instead of reviewing it in isolation. Where middleware uses a shared service identity, preserving the originating user’s identity in audit records helps teams trace the full request.
• Audit every integration point—every service account, every middleware bridge—as a first-class access path, including its permissions, credential handling, and authorization controls.
• Include mainframe teams in the same architecture conversations as cloud and identity teams, so Zero Trust principles apply consistently instead of stopping at the edge of the systems that are easiest to instrument.

None of this requires abandoning decades of mature, well-understood mainframe security practice. It requires treating that practice as part of the same verification and authorization model applied across the enterprise.

The System Still Processes What Matters Most

The “legacy” label doesn’t match the role these systems still play. For many organizations, the mainframe remains the system processing the transactions the rest of the business depends on. Leaving it structurally outside the security conversation creates gaps in visibility and accountability around those critical services.

Zero Trust was never meant to have an asterisk next to it that reads “except the systems that are hardest to integrate.” Closing that gap starts with shared ownership across mainframe, identity, and security teams—and recognition that the mainframe was never actually outside the threat model. It was just outside the conversation.