Accountability sits with the organisation that allowed unmanaged privilege to persist around the legacy environment. If a system cannot support modern identity controls, the compensating controls and containment boundaries still need clear ownership. NIS2 is concerned with whether the business can prove control over impact, not whether the asset is old.
Why This Matters for Security Teams
NIS2 incidents rarely stay “legacy-only.” Once unmanaged privilege exists around an older platform, an attacker can use that system as a pivot point into modern directories, backup services, file shares, and integration tokens. Accountability therefore follows the organisation that failed to contain the blast radius, not the age of the asset. The legal test is whether control over impact can be shown, which is why the NIS2 Directive matters as much as technical root cause.
NHIMG’s research on 52 NHI Breaches Analysis shows how often identity weakness becomes the real incident driver, not the initial vulnerable host. That pattern is especially relevant in legacy estates where service accounts, embedded secrets, and shared admin access outlive any single application owner. In practice, many security teams encounter this only after a lateral movement path has already crossed a trust boundary that nobody formally owned.
How It Works in Practice
Accountability in a NIS2-relevant legacy spread should be traced through ownership of the controls that should have prevented or contained the spread. That means asking who owned privileged access, who approved exceptions, who maintained compensating controls, and who could prove revocation or isolation after detection. If legacy systems cannot support modern identity controls, the organisation still needs a documented control owner for containment, monitoring, and recovery. The legal question is not whether the platform is obsolete; it is whether governance was effective.
Practitioners usually map this across three layers:
- Identity and privilege: service accounts, local admins, shared credentials, and any long-lived secrets tied to the legacy environment.
- Containment: segmentation, jump hosts, application allowlisting, and least-privilege pathways that limit lateral movement.
- Evidence: logs, access reviews, exception approvals, and revocation records that show who controlled the environment before and during the incident.
For legacy estates, this is where guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls becomes operationally useful: access enforcement, auditability, and incident response must still be demonstrable even when the platform itself is constrained. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is clear that unmanaged secrets and excessive privileges turn technical debt into governance debt. These controls tend to break down when a legacy system depends on shared admin accounts and undocumented exceptions because no one can prove which team was responsible for containment at the time of spread.
Common Variations and Edge Cases
Tighter containment often increases operational friction, requiring organisations to balance recovery speed against evidence quality and access constraints. That tradeoff becomes sharper in mixed estates where older applications cannot support MFA, modern SSO, or per-user attribution. Current guidance suggests compensating controls are acceptable, but there is no universal standard for this yet, so the organisation must be able to justify why the alternative still limited blast radius.
Two common edge cases matter. First, if a third party operates part of the legacy stack, accountability may be shared contractually, but the regulated entity still retains responsibility for proving oversight and impact control. Second, if the spread involved embedded credentials or machine-to-machine trust, the incident often traces back to NHI governance rather than endpoint hygiene. That is why NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now is directly relevant: secrets persistence and excessive privilege are often the real failure points. External threat reporting such as the ENISA Threat Landscape reinforces that initial footholds frequently become broader incidents when identity controls are weak. Where legacy systems remain exempt from standard access governance, accountability usually becomes visible only after the spread has already demonstrated that the exemption was itself the control failure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack surface, NIST CSF 2.0 and NIST AI RMF set the technical controls, and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIS2 | Article 21 | Requires risk-management measures and accountability for incidents that spread through legacy systems. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access control determine whether legacy spread was contained. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Legacy incidents often spread through unmanaged non-human identities and secrets. |
| CSA MAESTRO | TRUST-03 | Agentic trust and control boundaries mirror the need to contain legacy system blast radius. |
| NIST AI RMF | GOVERN | Governance needs clear ownership for risk, impact, and escalation when systems spread harm. |
Assign an owner for legacy containment controls and prove they work before, during, and after an incident.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
