The control model breaks because compliance assumes a deployable agent, while some legacy systems cannot host one without destabilising operations. In that situation, organisations need an approved compensating control that still demonstrates risk reduction, such as segmentation and traffic governance. Without that, the programme ends up measuring tool presence instead of security outcome.
Why This Matters for Security Teams
When EDR becomes mandatory on an endpoint that cannot reliably run it, the problem shifts from detection to governance. Security teams may still have a policy that says every asset must have an agent, but legacy operating systems, embedded controllers, and fragile industrial workloads often cannot absorb the overhead. The result is a gap between policy intent and operational reality, which is exactly where audit findings, risk exceptions, and unmanaged exposure accumulate.
The more important issue is that “EDR present” is not the same as “risk reduced.” A mature control model should show how the organisation maintains visibility, containment, and response when agent deployment is technically impossible. That aligns with the broader control thinking in the NIST Cybersecurity Framework 2.0, which emphasises outcomes rather than tool checkboxes. In practice, teams often discover this only after a legacy device is already in production, rather than through deliberate architecture review.
How It Works in Practice
The practical answer is to treat unsupported systems as a distinct asset class and apply compensating controls that approximate the security outcomes EDR would have provided. That usually means stronger network segmentation, tightly scoped allowlisting, protocol restriction, jump-host mediation, central log collection, and continuous monitoring of adjacent systems that can observe the legacy device’s traffic and behaviour. The control design should be documented, approved, and reviewed on a schedule, not left as an informal exception.
Security teams should also define what evidence will replace endpoint telemetry. For example, if host agents are impossible, then firewall policy logs, network detection rules, remote admin session records, and configuration baselines may become the primary sources of assurance. This is consistent with the outcome-driven approach in CISA EDR implementation guidance, which is useful even where the endpoint itself cannot host an agent because it reinforces layered monitoring and response design.
- Classify which systems are truly incompatible with EDR and why.
- Approve compensating controls that reduce exposure, not just administrative exceptions.
- Shift visibility to network, identity, and management-plane telemetry.
- Restrict administrative paths with privileged access controls and session oversight.
- Test response playbooks against the legacy asset path, not only modern endpoints.
Where possible, the security team should also evaluate whether the asset can be modernised, virtualised, or isolated behind a brokered access path. These controls tend to break down when unsupported systems sit flat on the corporate network with shared credentials and direct admin access, because there is no longer any practical boundary between the legacy asset and the rest of the environment.
Common Variations and Edge Cases
Tighter endpoint control often increases operational overhead, requiring organisations to balance detection coverage against system stability and business continuity. That tradeoff becomes sharper in OT, medical, and embedded environments, where reboot sensitivity, vendor restrictions, or certification constraints make agent installation risky or impossible. In those cases, best practice is evolving, and there is no universal standard for how much compensating control is sufficient; the answer depends on criticality, exposure, and observability.
One common edge case is a partially supported platform where the vendor permits only a limited agent build or an approved sensor. Another is a shared host that supports EDR technically but cannot tolerate the performance impact once business workloads peak. In both cases, the question is not whether the tool is “installed,” but whether it measurably improves the security outcome. That is where identity and access governance matters, because unmanaged local admin rights can undo even well-designed monitoring.
Organisations operating under resilience or supply-chain pressure may also need to document this as a formal compensating control path, especially where ENISA guidance or sectoral requirements expect demonstrable risk management rather than a single mandated technology. The practical rule is simple: if EDR cannot run, the environment must still be observable, segmented, and recoverable. When that is not true, the exception becomes a permanent blind spot rather than a controlled deviation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Continuous monitoring is the fallback when endpoint agents cannot run. |
| MITRE ATT&CK | T1562 | Agent gaps increase the risk of defence evasion and reduced visibility. |
| CIS Controls | 8 | Logging and monitoring are essential compensating controls for unsupported endpoints. |
| NIST Zero Trust (SP 800-207) | Zero trust supports brokered access when direct endpoint trust is weak. |
Shift assurance to alternative telemetry and verify monitoring coverage for unsupported systems.
