The Business Case

The best case for adoption starts with a product decision, not a technology slogan. Identify the assets at risk, the native code that handles them, the lifetime of the system, and the cost of the controls already used to protect it.

Frame the decision

Ask a question that can be tested, such as:

Would a CHERI-enabled processor and compartment design reduce the security and support risk of our network-facing control component enough to justify migration?

Define the comparison. It might be an existing C or C++ product on conventional hardware, a rewrite in a memory-safe language, stronger process isolation, or a combined approach.

Four sources of value

Four areas can shape the case for adoption:

• Security: which invalid accesses are blocked, and how much authority remains after a compromise?
• Engineering: are defects found earlier and closer to their cause, and does diagnosis become faster?
• Lifecycle: does the design reduce emergency updates, backports, assurance rework, or support exposure?
• Strategic value: does the platform help meet customer expectations for secure-by-design products or open a target market?

CHERI can enforce fine-grained memory protection for existing low-level software and support smaller isolation boundaries than a process alone. It is most valuable where native code, valuable assets, and long product lives meet. It complements, rather than replaces, memory-safe languages and established security controls.

Include the full cost

The investment side may include processor or board availability, toolchain integration, software porting, test infrastructure, developer training, performance analysis, certification work, and maintaining more than one product variant during transition. Some costs are one-off; others recur for every release.

Avoid treating all source code as equally difficult. A pilot often reveals that most code recompiles cleanly while a smaller set of pointer-heavy interfaces, custom allocators, assembly, device access, or serialisation code needs focused work.

Build evidence in stages

1. Baseline: measure current defects, incident effort, performance, memory use, and assurance activity.
2. Prototype: port a bounded, representative component and keep the comparison reproducible.
3. Security test: exercise known defect patterns and measure both prevention and containment.
4. Operational test: assess debugging, updates, developer workflow, and supply-chain dependencies.
5. Decision gate: record benefits, costs, unknowns, and the conditions for expansion.

Make uncertainty visible

Use ranges and sensitivity analysis. A long-lived safety controller, a short-lived web service, and a deeply constrained sensor will not produce the same answer. Record who owns each assumption and when it will be reviewed.

A credible conclusion may be to adopt now, continue a targeted evaluation, wait for a platform dependency, or use a different memory-safety approach. The purpose of the business case is to make that choice explicit and evidence-based.