Security ownership should sit with both infrastructure operators and their vendors, because the advisory says organisations even adjacent to critical infrastructure will be of interest to the group. That means shared accountability for patching, MFA, segmentation, monitoring, and third-party exposure. If suppliers or partners are weak, they can become the initial access point into more sensitive environments.
Why shared ownership matters at the critical infrastructure boundary
Threat readiness at or around critical infrastructure is not a single-team responsibility because the exposure often crosses organisational boundaries. Operators own the core environment, but vendors, managed service providers, and integration partners can shape patch speed, remote access paths, monitoring coverage, and the initial foothold an adversary tries to exploit. That is why readiness has to be treated as a shared operating model, not a handoff.
The practical question is who can actually reduce blast radius before an incident, not who writes the policy. When suppliers, support channels, or connected systems are weak, they can become the shortest route into higher-value environments, especially where trust relationships are long-lived and operationally privileged.
- Own the systems you run, but also the access paths you permit into them.
- Require vendors to meet the same patch, MFA, segmentation, and logging expectations as internal teams.
- Review third-party exposure as part of readiness, not only during procurement.
Where readiness fails in practice
The weak point is usually not the abstract policy, it is the operational exception. Remote support accounts, stale privileged access, flat network segmentation, and incomplete monitoring create situations where a compromise in one environment can be used to reach another. In critical infrastructure-adjacent environments, that kind of dependency is exactly what attackers look for because it turns an ordinary supplier relationship into an access path.
Readiness also degrades when accountability is split but not coordinated. One party may believe another is handling rotations, alerting, or isolation, so gaps persist until an incident forces the issue. Shared ownership only works when both sides can prove who is responsible for each control and what evidence exists that the control is functioning.
For a wider view of how adversaries exploit access chains and compromised supplier paths, see The 52 NHI breaches Report and the Critical Gaps in Machine Identity Management report. For infrastructure-sector threat context, CISA cyber threat advisories and the ENISA Threat Landscape are useful references.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while NIS2 and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-03 — External Dependencies and Supplier Relationships | Shared readiness depends on operator and vendor dependency governance. |
| PR.AA-03 — Identity Management, Authentication and Access Enforcement | MFA and access enforcement are central to partner and vendor readiness. | |
| PR.PS-01 — Configuration Management | Patch timing and segmentation are core hardening issues in readiness. | |
| Recommendation — Document supplier-dependent readiness controls and verify who owns each one. Enforce MFA and access rules for all privileged third-party paths. Apply configuration controls that keep systems patched and segmented. | ||
| CIS Controls v8 | 6 — Access Control Management | Readiness around suppliers hinges on controlling and reviewing access paths. |
| 7 — Continuous Vulnerability Management | Patch speed is a direct readiness factor for critical environments. | |
| 8 — Audit Log Management | Monitoring and alerting must cover supplier-originated activity. | |
| Recommendation — Review and remove third-party access that exceeds operational need. Track and close exploitable vulnerabilities on a defined remediation cadence. Collect and retain logs needed to detect vendor-driven access and misuse. | ||
| NIS2 | 8 — ICT business continuity, backup management and crisis management | Critical infrastructure readiness includes resilience and coordinated incident response. |
| 21 — Supply chain security | The question centers on shared accountability for third-party exposure. | |
| Recommendation — Test continuity and crisis procedures with connected suppliers and operators. Impose supply-chain security requirements on connected vendors and partners. | ||
| DORA | 24 — ICT third-party risk management | Vendor readiness and shared accountability are third-party risk issues. |
| 26 — ICT incident management | Readiness must include coordinated detection and response across parties. | |
| Recommendation — Contractually verify third-party controls that can affect operational readiness. Align incident handling and escalation paths with external service providers. | ||
Practitioner Guidance
What to prioritise: Assign one named owner for each readiness control, then require the counterpart party to evidence the same control from its side. If a vendor can reach production, its access, logging, and rotation obligations should be treated as part of the operator’s readiness baseline, not an optional add-on.
What to verify: Confirm that MFA, segmentation, patch timing, alert routing, and third-party access reviews are measurable and testable. If the organisation cannot prove when a supplier last rotated access or how quickly it would detect supplier-originated misuse, readiness is not mature enough for a high-consequence environment.
Practitioner takeaway: In critical infrastructure contexts, shared readiness is strongest when ownership is explicit, controls are testable, and vendor access is governed as a live attack surface rather than a contractual assumption.
