Who is accountable when a NIS2-relevant incident spreads through legacy systems?

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.

Related resources from NHI Mgmt Group

• Who is accountable when AI-driven compromise spreads through OT systems?
• How should financial institutions close MFA gaps across legacy systems?
• Who is accountable when OT living off the land abuse reaches production systems?
• Who is accountable when a key compromise affects multiple systems?