The Business Case

The business case for CHERI begins with a familiar problem: valuable products and services still depend on memory-unsafe software. Replacing all of that software may be impractical, while accepting the risk can lead to repeated security work, urgent updates, and incidents whose effects extend beyond one component.

CHERI offers another route. It adds processor-enforced limits to memory access and supports compartments whose access can be restricted to the resources required for their role. This can strengthen existing software as well as new designs.

Why CHERI can be commercially relevant

CHERI is most relevant where memory risk has a meaningful consequence and existing software has continuing value. Examples include a long-lived device built around C or C++, a network service containing native libraries, or a consolidated system in which components of different trust levels share a processor.

Its potential value comes from four connected areas:

• Risk reduction: many invalid memory accesses can be blocked before they become a successful exploit.
• Containment: a compromised parser, driver, plug-in, or service can be prevented from reaching unrelated data and functions.
• Engineering: capability faults occur close to the invalid operation, which can make some defects easier to locate and understand.
• Product value: stronger, demonstrable protection can support customer confidence, assurance activity, and secure-by-design expectations.

The balance differs by product. A small sensor, a cloud host, and a vehicle platform do not have the same assets, lifetimes, performance constraints, or available isolation mechanisms.

Preserving existing investment

CHERI extends established instruction-set architectures rather than defining an entirely separate style of computing. Existing C and C++ source can often be recompiled, with changes concentrated around code that makes unusual assumptions about pointers, memory layout, or object lifetimes.

Hybrid systems allow conventional and capability-aware software to coexist during a transition. Pure-capability systems apply capability protection to all pointers in the covered environment. This range makes CHERI relevant both to targeted protection and to broader platform redesign.

The approach complements memory-safe languages. New services may be written in Rust or another memory-safe language while an established native library runs with CHERI protection inside a restricted compartment. The business choice is therefore not limited to hardware protection or language change.

Where the value can appear

Some benefits affect direct cost, while others affect risk or future opportunity:

• fewer memory defects reaching production;
• less authority available to an exploited component;
• shorter investigations and more informative fault reports;
• reduced dependence on broad, overlapping mitigations;
• reuse of platform and assurance work across a product family;
• a viable protection route for code that cannot yet be rewritten;
• access to markets or customers that value stronger security evidence.

These benefits remain specific to the implementation. Platform availability, porting effort, performance, supply-chain support, and lifecycle maturity all influence whether CHERI is a good fit.

A bounded case, not a universal claim

CHERI does not make every product secure and does not replace secure boot, cryptography, testing, updates, identity, monitoring, or operational controls. Its distinctive contribution is narrower and more concrete: the processor can enforce what memory a piece of software may access, and compartments can limit what that software can reach after compromise.

A credible business case connects those properties to a real exposure. Where the protected code is valuable, difficult to replace, and close to important assets, CHERI can offer a practical reduction in risk without discarding the wider software investment.