Because modern critical infrastructure depends on interconnected providers, cloud services, and shared operational platforms, so security failures rarely stay isolated. When end users carry too much of the burden, controls become inconsistent and recovery slows. Shifting responsibility upstream helps standardise protections, improve accountability, and reduce the chance that under-resourced operators absorb all the risk from systemic dependencies.
Why the burden moves upstream in critical infrastructure
critical infrastructure is not protected by a single end user choosing a stronger password or clicking more carefully. Power, transport, healthcare, finance, telecom, and cloud-dependent public services rely on shared operators, vendors, managed platforms, and interdependent recovery processes. That means one weak control can propagate across many sites, so strategy has to focus on the parties that can standardise protections, enforce change, and absorb systemic risk.
Responsibility shifts upstream because those providers control the control points: secure defaults, patching cadence, segmentation, logging, recovery design, and service continuity. End users still matter, but their choices cannot compensate for insecure platform design, opaque dependencies, or inconsistent operator maturity. The result is less about replacing user responsibility and more about matching responsibility to the actor that can actually reduce aggregate exposure.
For infrastructure that depends on shared identity and service access, upstream governance matters even more. NHIMG’s Ultimate Guide to Non-Human Identities notes that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts, which illustrates why isolated local controls are not enough when access is distributed across providers and operators.
What changes when providers and operators own more of the control plane
Moving responsibility upstream changes both prevention and recovery. Providers can apply baseline hardening once, at scale, instead of asking thousands of downstream users to implement the same safeguards inconsistently. Operators can also centralise monitoring, maintenance windows, rollback planning, and incident coordination, which matters when outages or intrusions cut across multiple customers or physical sites.
It also changes accountability. In a shared-service model, the party that designs the platform should be responsible for the security properties the platform can actually deliver, such as secure configuration, identity assurance, least privilege, and resilience testing. That is why critical infrastructure strategies increasingly treat security as a shared obligation across manufacturers, managed service providers, cloud providers, operators, and government rather than a consumer choice made at the edge.
That pattern is visible in frameworks and guidance for critical sectors. CISA Industrial Control Systems guidance and ENISA Threat Landscape reporting both reflect the reality that operational technology, cloud services, and supply chains create sector-wide dependencies, not isolated endpoint problems.
Why shared responsibility is a resilience strategy, not just a compliance idea
The practical reason for pushing responsibility upstream is resilience. If a critical service depends on many downstream parties making good decisions independently, failure becomes uneven and slow to remediate. If the provider, operator, and government set the baseline, the system can recover faster, communicate more clearly, and reduce variance in how controls are applied during stress.
This is also why critical infrastructure policy often looks beyond end-user behaviour toward sector coordination, reporting, and minimum operational standards. Modern service disruption is frequently driven by concentration risk, supplier compromise, misconfiguration, or delayed recovery rather than by any single user error. The strategy therefore aims to reduce blast radius and make security measurable at the points where dependencies are concentrated.
CISA cyber threat advisories and the EU NIS2 Directive both reinforce the same principle: when the service is essential, the security burden has to sit with the organisations that can directly influence the reliability, reporting, and continuity of the system.
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, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the technical controls, while NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC — Organisational Context | Critical infrastructure risk depends on shared-sector roles and dependencies. |
| ID.SC — Supply Chain Risk Management | Upstream responsibility addresses concentration and supplier dependency risk. | |
| PR.AC — Access Control | Shared platforms need consistent privilege and access enforcement. | |
| Recommendation — Define provider, operator, and government responsibilities around the service context. Assess and manage third-party dependencies that can spread failure across critical services. Enforce least privilege and centralized access governance across critical service environments. | ||
| CIS Controls v8 | 5 — Account Management | Upstream control of accounts and access reduces inconsistent local privilege handling. |
| 15 — Service Provider Management | The question is fundamentally about placing responsibility with providers and operators. | |
| 17 — Incident Response Management | Critical infrastructure depends on coordinated detection, escalation, and recovery. | |
| Recommendation — Centralize account governance and remove unnecessary access across critical environments. Assign security and resilience obligations to providers through enforceable service requirements. Prepare joint incident response processes with clear reporting and restoration duties. | ||
| NIST Zero Trust (SP 800-207) | 3 — Policy Decision and Enforcement | Shared infrastructure needs centralized policy enforcement rather than user-by-user judgment. |
| Recommendation — Centralize access policy enforcement so critical services are protected consistently. | ||
| NIS2 | Article 21 — Cybersecurity Risk-Management Measures | NIS2 directly pushes essential and important entities toward managed, systemic controls. |
| Article 23 — Reporting Obligations | Upstream responsibility matters when incidents must be detected and reported quickly. | |
| Recommendation — Implement risk-management measures across providers, operators, and essential service chains. Establish incident reporting processes that work across operator and supplier boundaries. | ||
Practitioner Guidance
What to prioritise: Focus first on the controls that are reusable across the whole sector, especially identity governance, secure defaults, patching, logging, and recovery ownership. Those are the levers that reduce inconsistency at scale.
What to verify: Check whether responsibilities are explicit at each layer, provider, operator, and government, and whether contracts, playbooks, and incident procedures actually assign who patches, who reports, who isolates, and who restores service.
Common mistake: Treating end users as the primary control plane in environments where they do not own the platform, the access model, or the recovery process. That approach shifts burden without shifting capability.
Practitioner takeaway: Critical infrastructure strategy works best when responsibility follows control, because the organisations closest to the shared platform are the ones best placed to reduce systemic risk, enforce consistency, and recover quickly.
Related resources from NHI Mgmt Group
- Who should own AI-era cyber defense hardening when risk spans government, vendors, and critical infrastructure operators?
- How should security teams respond when sanctions target ransomware infrastructure providers and cybercriminal enablers rather than only the operators themselves?
- How should critical infrastructure operators build a SOCI-aligned risk management program for cyber resilience?
- Why does SOCI require proactive cyber controls for critical infrastructure rather than reactive incident handling?