GCRI · Cybersecurity and Digital Resilience
Critical service cyber
Power grids, water systems, hospitals, payment networks and transport rely on information and operational technology that attackers target for disruption, extortion or espionage. Incidents can stop physical services and endanger lives. This page sets out how cyber threats reach critical services, why operational technology is different, how resilience is measured, and what evidence serves the operators, regulators and national agencies responsible.
Critical service cyber on the record.
Critical service cyber: how the risk develops.
Cyber-physical lifelines and safety. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Operational technology is long-lived
Control systems run for decades, often on old software that cannot be patched easily. They were designed for reliability and isolation, not for connected networks.
IT and OT have converged
Remote access, cloud monitoring and business integration connect control networks to corporate IT. Attacks that begin in IT can reach operations or force precautionary shutdowns.
Disruption becomes physical
Ransomware on a hospital or pipeline operator can stop care or supply even without touching control systems, because operations depend on IT for scheduling, billing and records.
State actors pre-position
National agencies report that some state-linked actors gain access to infrastructure networks in advance, to be able to disrupt them in a crisis.
Incident response timeline.
The screen a team would use to follow this subject: its measures, states and decisions. Names are examples and values are illustrative.
Incident response timeline
Critical service cyber · Critical service A · Incident IR-8651
CSF 2.0 functions
- GovernGV
- IdentifyID
- ProtectPR
- DetectDE
- RespondRS
- RecoverRC
Timeline
- T+00:00DE.AEAnomalous logins flagged on identity platform
- T+00:38RS.MAIncident declared, commander assigned
- T+01:21RS.ANScope: 9 hosts, one service account
- T+02:48RS.MIAccount disabled, hosts isolated
- T+04:00RS.CORegulator notification window opens
Affected assets
| IDP-01 | Identity | Compromised | Identity platform |
| APP-07 | Payments API | Isolated | Service owner |
| DB-02 | Customer data | Forensics | Data owner |
| BK-01 | Backups | Clean | Operations |
Response actions
- RS.MIRotate keys for affected service accountsIdentity team33 min
- RC.RPRestore APP-07 from clean backupAfter containment2 h
- RS.CODraft customer noticeLegal review5 h
Critical services share cyber dependencies across domains.
- WaterCouplingOperational technology in water often runs legacy systems.What to watchLegacy system exposure
- EnergyCouplingGrid control systems follow IEC 62443 and sector standards.What to watchPatch and segmentation status
- HealthCouplingMedical devices and building systems connect to networks.What to watchConnected device inventory
Findings are designed for the Strategic Systems series. IEC 62443 sets security for industrial control systems; the page names no vulnerable asset.
- Sector security exercises' lessons.
- Anonymised OT incident reviews.
A cascade through interdependent networks.
A hazard footprint takes out co-located assets in every layer; fragmentation, dependency between layers and overload of the survivors then spread the failure. The 3D view separates the layers by depth. Teaching model with stated illustrative values, not a prediction.
Controls
- Assets per layer
- 18
- Hazard footprint
- 8% of area
- Assets that depend on another layer
- 60%
- Spare capacity (tolerance)
- 30%
Readouts
- Assets hit by the hazard
- 17%
- Assets still working
- 20%
- Amplification of the initial damage
- 4.8 times
- Steps to settle
- 4
Numbers, methods and sources
| Step | Data centres working (%) | Networks working (%) | Power working (%) |
|---|---|---|---|
| 0 | 83 | 89 | 78 |
| 1 | 61 | 78 | 78 |
| 2 | 28 | 44 | 72 |
| 3 | 22 | 6 | 39 |
| 4 | 22 | 6 | 33 |
Methods
- Interdependent networks Buldyrev and others (2010), Catastrophic cascade of failures in interdependent networks, Nature 464
- Overload cascades Motter and Lai (2002), Physical Review E 66
- Betweenness load Brandes (2001), Journal of Mathematical Sociology 25
- Multilayer networks Kivela and others (2014), Journal of Complex Networks 2
- Infrastructure interdependencies Rinaldi, Peerenboom and Kelly (2001), IEEE Control Systems 21(6)
- Uncertainty fan (parameter Monte Carlo) Spiegelhalter, Pearson and Short (2011), Visualising uncertainty about the future, Science 333
- One-at-a-time sensitivity (tornado) Saltelli and others (2008), Global Sensitivity Analysis: The Primer, Wiley
Data
The model runs on the teaching values set by the controls. To calibrate it for a place, read it against these admitted layers and series, which this page's map can draw:
- Major roads Natural Earth
- Railways Natural Earth
- Seaports Natural Earth
- Airports Natural Earth
- Urban extents Natural Earth
- Night lights tonight, outages (VIIRS Day/Night Band) NASA/NOAA VIIRS (Suomi NPP) · register nasa.gibs.context-live-layers
- Natural events (NASA EONET) NASA EONET · register nasa.eonet.events
Across the six pillars, led by Nexus Consortium
- Experiments Labs
- Built in Cybersecurity and Digital Resilience in Foundry
- Tested at Cybersecurity and Digital Resilience in Universe
- Codified in Digital, Cyber and AI in Standards
- Published in Cybersecurity and Digital Resilience in Reports
- Taught in Faculty of Technology and Digital Systems in Academy
What is measured, and how well.
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Incidents reported by critical sectors | count by sector | annual | Mandatory incident reporting | Published statistics |
| Internet-exposed industrial control devices | count | monthly | Internet scanning studies | OBSERVED |
| Operators with tested manual fallback | percent of operators | per assessment | Regulator assessments | REPORTED |
| Service outage hours caused by cyber incidents | hours | per incident | Incident reports | OBSERVED |
| Security advisories for industrial control systems | count | monthly | National advisories | Published statistics |
| IT and OT network segmentation | percent of sites segmented | per assessment | Operator assessments | DECLARED |
How critical service cyber is modelled, measured and tested.
The model, its assumptions, its data and its uncertainty, in the form a scientist or engineer would check. Structures follow published methods. The values drawn are illustrative, not findings.
System model
The couplings between the systems in critical service cyber: signs of influence, a reinforcing and a balancing loop, and cross-links where stress jumps.
Where the evidence comes from.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| CISA industrial control systems advisories | Vulnerabilities and mitigations for control system products | Public domain, US government |
| ENISA annual reports on NIS incidents | Aggregated incident reports from essential sectors | Public, ENISA terms |
| Joint advisories from national cyber agencies on threats to critical infrastructure | Assessments of actor behaviour and mitigations | Public, terms per agency |
| IEC 62443 series | Security requirements for industrial automation and control systems | Licensed standards, purchase required |
| Published post-incident reviews from operators and regulators | Causes and effects of critical service incidents | Public records, terms per publisher |
Who decides, and what the evidence serves.
Cybersecurity and Digital Resilience prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Critical infrastructure operators | How to segment, monitor and keep manual fallback for operations | Baseline reviews; dependency maps |
| Sector regulators | What cyber requirements and testing to set | Incident reports; assessment evidence |
| National cyber agencies | Where to focus support and advisories | Exposure scans; incident trends |
Outputs this topic produces
- OT security baseline reviews against IEC 62443
- Manual fallback and recovery exercise designs
- Dependency maps from IT into operations
- Evidence notes for sector regulators
What experts ask.
In most information systems, the worst outcome of a breach is data loss or downtime. In cyber-physical systems, the worst outcome can be a flood, a blackout, a contaminated water supply or harm to patients. Operational technology was often designed for isolated networks and long lifetimes, and connecting it to corporate and internet networks has created exposures that conventional IT security does not fully address.
- Which digital functions are essential to keep a critical service safe and available, and what is the minimum service level in a crisis?
- How could compromise of a control system lead to physical damage or safety hazards, and which engineering safeguards limit that?
- Can operators run essential functions manually or in isolation if digital systems are lost?
- How do safety engineering and security engineering work together without undermining each other?
Drivers and processes.
Cyber-physical risk depends on how digital control, physical processes and human operators interact.
Operational technology
Programmable controllers, supervisory systems and field devices that run physical processes, often with long lifetimes and limited ability to patch.
Engineered safeguards
Independent safety systems, physical interlocks and manual overrides that limit harm even when digital control is compromised.
People and procedures
Operators' ability to detect abnormal behaviour and fall back to manual operation is often the last line of defence.
Security measures that work in office networks can be harmful in control systems. Aggressive scanning can crash older devices, automatic updates can interrupt continuous processes and remote access added for convenience can open new paths for attackers. Critical service cyber therefore needs engineers who understand both the process and the threat.
How the evidence is built, and its limits.
- 01
Consequence-driven analysis
Starts from the worst physical outcomes and works back to the digital paths that could cause them. It requires deep process knowledge.
- 02
Safety and security co-engineering
Combines hazard analysis with threat modelling, using software and safety-critical systems engineering and reliability and resilience engineering. Methods are maturing and not yet standard across sectors.
- 03
Incident evidence
Public reports of attacks on industrial systems are few and often incomplete, which limits statistical analysis.
- 04
Testbeds and simulation
Laboratory testbeds reproduce control systems for testing. They cannot capture every real configuration.
How it is studied, and what the methods cannot say.
- 01Cybersecurity and cryptographyControl baselines and gap analysis · Exploited vulnerability prioritisationApplied here
- 02Software and safety-critical systems engineeringSecure development life cycle · Safety and security co-assuranceApplied here
- 03Reliability and resilience engineeringRecovery architecture · Degraded operation modes · Recovery time testingApplied here
- 04Communications and network technologyNetwork segmentation design · Protocol security review · Post-quantum protocol readinessApplied here
- 05Network science and contagionAttack path analysis · Digital dependency concentration · Coordination detectionApplied here
Where this page's references lead.
The bodies and documents this page is read against. Status and editions change; each link goes to the issuing body.
Questions and answers.
What is operational technology?
Why is OT harder to secure than IT?
Can a cyberattack cause a blackout?
Can a cyber attack cause physical damage?
Why is patching harder in operational technology?
Does the platform publish details of vulnerable facilities?
Is manual fallback realistic?
Contribute evidence from this page.
Reports is the Consortium's quarterly publication. What you know about this subject can become evidence, a case or a correction in the next edition, credited to you and published under CC BY 4.0 where it is your own work.
- EmailGateway GW-GCRISend it from this pageEvidence, a correction, a case, a method, a review, a translation or profile input. It arrives tagged with this page, so the editor who owns it receives it.
- ZenodoOpen depositDeposit it and submit to the communityPublish your own record on Zenodo with your ORCID iD, then submit it to the Reports community there. Curators review it; the DOI stays yours.
- ReportsGCRISee every way to contributeThe contribution types, how each is reviewed, what credit you receive, the licence and what is never accepted.
Never send personal data, sensitive infrastructure detail or anything you have no right to share. A contribution is reviewed before use; sending it confers no authorship or editorial rights, and sponsorship never buys a finding.
Bring a method, a dataset or a question.
Information and enquiries are open today. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.
Legal documents.
Maps, data and figures on this site are shown for context and general information. They are not advice, forecasts or warnings; the limits of the information are set out in the Disclaimers and Data Notices.