Mainframe security exposes the gap in federal EDR mandates

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Illumio's blog post: Federal EDR requirements expose a gap for mainframes, where endpoint agents are not a viable control and compensating controls become necessary.

Why it matters: This matters because identity and security teams still have to govern high-value legacy workloads that cannot be treated like modern endpoints, and Zero Trust programmes fail if they exclude the systems that still run critical missions.

Context

Mainframes remain a governance problem when modern control mandates assume every system can run the same telemetry and response stack. In this case, the gap is not visibility alone but the mismatch between federal EDR requirements and platforms that were never designed to host endpoint agents.

For IAM, PAM, and NHI programmes, the practical issue is control coverage: critical workloads still need policy enforcement, segmentation, and access boundaries even when standard endpoint tooling is unavailable. The article frames mainframes as mission systems, not obsolete exceptions, which is the reality many public sector estates still face.

Key questions

Q: What should agencies do when EDR cannot run on a mainframe?

A: They should define a compensating control that preserves the original security objective, usually by enforcing workload segmentation, restricting communication paths, and improving monitoring around the legacy system. The key test is whether the alternative control reduces exposure in practice, not whether it looks like endpoint protection on paper.

Q: Why do mainframes create a compliance gap in endpoint mandates?

A: Because endpoint mandates assume the system can host an agent, collect telemetry, and support response actions locally. Mainframes often cannot support that model, so the requirement and the platform capability do not line up. That mismatch produces compliance friction unless the programme accepts platform-specific control alternatives.

Q: What fails when a Zero Trust programme excludes legacy workloads?

A: The trust boundary becomes incomplete. Attackers and insiders can still exploit paths through older systems that are outside the modern control plane, which creates uneven enforcement and weakens the overall architecture. Zero Trust only works when the mission-critical exceptions are governed with equal discipline.

Q: How should security teams evaluate compensating controls for unsupported systems?

A: They should ask whether the control enforces containment, limits movement, and provides enough evidence to support assurance. If it only documents a policy exception, it has not reduced the underlying risk. The right comparison is not tool parity but control effectiveness against the original threat.

Technical breakdown

Why endpoint detection and response does not fit mainframes

Endpoint detection and response assumes an agent can run locally, collect telemetry, and support response actions on the host. Mainframes do not reliably support that model, so the control premise breaks before detection even begins. In practice, this creates a gap between policy intent and deployable enforcement. The problem is not that mainframes are invisible by nature. It is that the mandated control architecture was built for endpoint-class systems, while mainframes are constrained, specialised, and deeply embedded in mission workloads.

Practical implication: teams need compensating controls that secure the workload without requiring an endpoint agent.

How flow-based workload control substitutes for host-based tools

Flow data and communication context shift the control point from the endpoint to the network and workload relationship. Instead of depending on a host agent, policy is enforced by understanding which systems talk to each other and restricting unnecessary paths. That makes microsegmentation and traffic-aware policy central to protecting legacy platforms. For mainframes, this is especially relevant because the security objective is containment, not endpoint inspection. The architectural benefit is that policy can still be applied even when the underlying OS cannot support modern telemetry agents.

Practical implication: define allow-lists and communication boundaries around mainframe workloads rather than waiting for host instrumentation.

Zero Trust for legacy systems depends on containment, not replacement

Zero Trust does not require every system to become a modern endpoint, but it does require continuous control over access and movement. For legacy platforms, the security model has to start with limiting blast radius and preventing lateral movement. That is a different problem from device health checking, and it is where many federal programmes get stuck when they equate compliance with tool parity. The mainframe lesson is that Zero Trust succeeds when the control objective is preserved, even if the implementation differs by platform class.

Practical implication: treat unsupported platforms as containment targets inside the Zero Trust architecture, not as exceptions outside it.

Threat narrative

Attacker objective: The attacker objective is to move through legacy mission systems that have weak containment because standard endpoint controls cannot be applied.

1. Entry occurs through the control gap created when a mandated endpoint tool cannot be deployed on the mainframe.
2. Escalation is avoided only if compensating controls restrict communications and prevent uncontrolled movement between mission workloads.
3. Impact would come from a lateral movement path or policy blind spot that leaves critical legacy systems under-governed despite formal compliance pressure.

Breaches seen in the wild

• BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Mainframe security is a Zero Trust governance problem, not a legacy-modernisation debate. The article shows that some federal workloads cannot be forced into endpoint-centric control models without creating blind spots or unsupported architecture. The right question is how to enforce boundary control, visibility, and policy on systems that remain mission-critical. Practitioners should treat legacy coverage as a design requirement, not a temporary exception.

Compensating control coverage is the real compliance test. When an agency cannot deploy an EDR agent, security governance has to evaluate whether the alternative control actually preserves the intent of the mandate. That means looking at containment, communication policy, and auditability instead of tool substitution. A programme that passes validation on paper but leaves critical workloads unmanaged has not reduced risk.

Policy enforcement must follow workload behaviour, not platform age. The article reinforces that security controls should attach to trust relationships and traffic patterns, because those remain governable even on older systems. This is where mainframe security intersects with broader identity governance: if workload access is not bounded, the access model becomes the attack surface. Practitioners should map those trust relationships explicitly.

Legacy mainframe exposure creates governance debt across the whole federal stack. The longer agencies treat unsupported platforms as outliers, the more Zero Trust becomes unevenly applied across the estate. That increases operational inconsistency and weakens assurance over mission services. The practical conclusion is simple: programmes need a repeatable model for securing non-standard systems, not an exception process that never ends.

From our research library:

• Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.

What this signals

Mainframe security will remain a policy problem until control objectives are separated from tool assumptions. Federal and enterprise teams need to stop treating endpoint agents as the only legitimate proof of security coverage. Where older platforms cannot support host tooling, the governance model has to shift to containment, segmentation, and evidence of control effectiveness.

The stronger programme pattern is to classify unsupported platforms by mission criticality and then enforce trust boundaries around them, rather than waiting for perfect modernisation. That approach reduces the chance that compliance language outruns operational reality.

Legacy workload governance is now part of identity security, even when the system is not an identity platform. Once access to critical systems depends on trust boundaries, entitlement scope, and path restriction, IAM and Zero Trust teams inherit the responsibility to govern those relationships consistently.

For practitioners

• Define compensating controls for unsupported platforms Document the exact control objective that EDR was meant to satisfy, then map the mainframe alternative controls that preserve it through segmentation, policy enforcement, and monitoring.
• Map mainframe communication paths Identify which workloads and services exchange traffic with the mainframe so you can restrict unnecessary paths and reduce lateral movement opportunities.
• Treat legacy systems as Zero Trust scope Include mainframes, IBM Z, iSeries, and similar platforms in the same trust-boundary review as modern workloads, even when control mechanisms differ.
• Validate compliance against security intent Check whether the deployed compensating control actually enforces containment and access restriction, rather than only satisfying a checklist requirement.

Key takeaways

• Mainframes expose a real gap between endpoint-based mandates and the systems federal agencies still rely on for mission delivery.
• The core issue is not whether modern tools are desirable, but whether a compensating control actually enforces containment on platforms that cannot host them.
• Zero Trust programmes must include legacy workloads or they create uneven governance across the estate and leave critical systems under-protected.

Key terms

• Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.
• Unsupported Workload: An unsupported workload is an application, server, or container running on a platform that no longer receives security maintenance. The workload may still operate, but its underlying operating system becomes progressively harder to defend. Teams should treat unsupported workloads as remediation priorities because the security gap widens with time.
• Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
• Lateral Movement: A post-compromise technique where an attacker uses a compromised NHI to move through a network, accessing additional systems and escalating impact without triggering detection.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.