Critical Infrastructure & Resilience

Critical infrastructure policy is concerned with consequences at the level of services and society. A fault or attack in one component matters because it can interrupt power, water, communications, transport, healthcare, or industrial activity.

CHERI cannot provide service resilience by itself, but it can strengthen the technical foundations underneath it. Capabilities can prevent many invalid memory accesses, while compartments can keep an exposed or lower-trust component away from functions it does not need.

Why memory safety has policy relevance

Essential systems often contain native code, specialist devices, supplier components, and long replacement cycles. Some software remains in operation for decades. A recurring memory vulnerability can therefore affect systems that are difficult to patch, replace, or take offline.

Conventional mitigations reduce the likelihood of successful exploitation, but they may still allow the invalid access to occur. CHERI changes that boundary by making the authorised range and permissions part of the reference used by the processor.

This can reduce two forms of risk:

• initial compromise: many memory errors are stopped at the access that violates the capability;
• wider consequence: a compromised parser, driver, or management service can be restricted from control state and unrelated services.

The distinction is important in infrastructure. Preventing every attack is unrealistic, while preventing one compromised component from reaching an essential function can still preserve part of the service.

Where CHERI can fit infrastructure policy

CHERI is relevant to technology used at boundaries: gateways, protocol converters, remote-management services, update components, monitoring appliances, and network functions. These components often process untrusted data while holding access to more sensitive systems.

It is also relevant to constrained controllers where conventional process isolation is unavailable, and to consolidated systems where software of different trust levels shares one processor.

Because CHERI can protect existing C and C++ software, it offers a route that aligns with gradual infrastructure renewal. Capability-aware components can appear in new equipment while older protocols and neighbouring systems remain in service.

Resilience beyond containment

A capability fault prevents an unauthorised memory operation, but it may stop the affected component. Availability then depends on the wider design: redundancy, restart, failover, safe degradation, logging, and recovery.

Network segmentation, identity, secure configuration, monitoring, backups, incident response, supply-chain assurance, physical protection, and manual alternatives also remain necessary. CHERI adds an internal boundary; it does not replace the layers around it.

More meaningful security claims

Policy and assurance benefit when a technology claim describes an outcome. “The protocol parser cannot access control state” identifies a boundary that can be represented and tested. “The device uses CHERI” does not reveal how much software is protected or what remains reachable.

This is where CHERI’s fit with resilience policy is strongest. It can turn part of an intended trust boundary into a processor-enforced property and give decision-makers clearer evidence about how one software failure is separated from an essential function.

Broader risk-management context is available in the UK NCSC Cyber Assessment Framework and the European Union’s NIS2 policy material.