Why do mainframes complicate Zero Trust programmes?

Mainframes complicate Zero Trust because they are often essential, long-lived, and technically incompatible with the same agent-based controls used on modern endpoints. Zero Trust still applies, but it must be enforced through boundaries, policy, and continuous verification appropriate to the workload. The challenge is governance consistency, not identical tooling.

Why This Matters for Security Teams

Mainframes often sit inside the most sensitive parts of the enterprise, where payments, core records, or high-volume transaction processing still depend on systems that cannot be treated like commodity endpoints. That creates a tension for zero trust programmes: the security objective is consistent verification, but the control surface is different. NIST SP 800-207 Zero Trust Architecture makes clear that Zero Trust is a strategy built around identity, policy, and continuous evaluation, not a requirement to deploy the same tooling everywhere.

Security teams get caught out when they assume the absence of an endpoint agent means the absence of control. On mainframes, trust is more often expressed through workload boundaries, privileged session governance, cryptographic controls, and transaction-level policy rather than endpoint telemetry. NIST Cybersecurity Framework 2.0 helps translate that into governance by tying protection and detection activities to business risk, asset criticality, and recovery expectations.

The practical risk is that organisations create a two-speed security model, one rigorous for modern platforms and one loosely governed for legacy systems. In practice, many security teams encounter mainframe risk only after an audit finding, a privileged access review, or a change failure exposes how much exception handling has been normalised.

How It Works in Practice

Zero Trust on a mainframe is usually implemented through layered controls rather than device posture checks. The architecture should still enforce strong identity proofing, least privilege, segmentation, and continuous verification, but the mechanisms are adapted to the platform. That often means strong MFA for administrative access, tightly controlled jump paths, policy-based session brokerage, and cryptographic protection of data in transit and at rest.

For operational teams, the key is to define where trust is evaluated. A mainframe workload may not support an endpoint agent, but it can still participate in Zero Trust through surrounding controls: privileged access management, API gateways, z/OS security controls, SIEM integration, and well-defined service accounts. The emphasis is on making every access path explicit and reviewable rather than assuming a local agent will enforce policy. For identity-centric programmes, this is where mainframe governance intersects with privileged identity management and, in some cases, NHI governance for technical accounts and batch jobs.

• Classify mainframe workloads by business criticality and data sensitivity.
• Map each access path to an approved identity, privileged role, or technical account.
• Use a brokered admin path for interactive access instead of direct connectivity where possible.
• Log authentication, privilege elevation, and transaction anomalies into the SIEM for correlation.
• Apply continuous review to exceptions, including shared IDs, batch credentials, and cross-system trust links.

Current guidance suggests the most effective design is boundary-based verification combined with strong identity governance, not a forced replica of endpoint-centric controls. The NIST Cybersecurity Framework 2.0 is useful here because it supports control mapping across legacy and modern environments without pretending they have the same technical capabilities. These controls tend to break down when shared service IDs, hard-coded credentials, or unmanaged batch interfaces are allowed to bypass normal access review because the resulting trust chain becomes invisible.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance stronger assurance against change latency and legacy dependency constraints. That tradeoff is most visible on mainframes where a single control can support many downstream applications, making any change appear disproportionately risky.

There is no universal standard for this yet on every mainframe pattern, especially where agencies, outsourcers, or hybrid operations share responsibility. Best practice is evolving toward explicit trust segmentation: separate administrative access from application-to-application access, distinguish human and non-human identities, and document which technical accounts are exempted from interactive controls and why. That distinction matters because some mainframe estates still rely on long-lived batch credentials that do not map neatly to modern session-based models.

Edge cases also arise during modernization. When APIs are exposed from a mainframe, Zero Trust controls should move outward to the API layer without weakening the underlying host governance. Similarly, if a mainframe participates in a broader hybrid identity fabric, policy consistency must extend across directory services, PAM, and audit logging, even if the enforcement mechanisms differ. The NIST SP 800-207 Zero Trust Architecture remains the anchor, but implementation should respect the realities of legacy uptime, tooling limits, and operational dependencies. The approach becomes fragile when teams assume modernization means policy convergence will happen automatically, because legacy trust relationships often persist long after the migration plan has changed.

Related resources from NHI Mgmt Group

• Why do AI agents complicate zero trust and least privilege programmes?
• Why do service accounts and workloads complicate Zero Trust programmes?
• Why do non-human identities complicate zero trust architecture?
• Why do NHIs complicate zero trust and least privilege efforts?