Future Direction

Working prototypes have answered the first question: capability memory protection can be integrated with modern processors, operating systems, compilers, and large C and C++ codebases. Commercial products have answered another: CHERI technology can move into licensable processor designs and silicon.

The next questions concern scale, interoperability, maintenance, and deployment. This page describes active directions, not promises about a particular product roadmap.

Stable and portable architecture definitions

An ecosystem needs specifications that different implementers can follow and software can target with confidence. Work continues on CHERI-RISC-V architecture definitions, embedded profiles such as CHERIoT, formal models, compliance tests, and common terminology across instruction sets.

Standardisation must preserve useful security properties while allowing processors at very different scales. A small microcontroller and a server processor may represent capabilities differently or offer different supporting mechanisms, but developers still need predictable language and software behaviour.

Support in mainline software projects

Long-term adoption depends on reducing the number of permanent forks. Important directions include:

• integrating CHERI support into mainstream compiler infrastructure
• maintaining cross-architecture Linux support and working towards acceptance in the main Linux project
• extending operating-system and runtime coverage
• improving package, library, debugger, and build-system portability
• strengthening Rust and other memory-safe language support
• providing continuous integration across simulators and hardware

Moving support into mainline projects is not only a technical task. Projects need maintainers, review capacity, test infrastructure, and designs that serve users beyond one demonstration.

Broader hardware and product choices

Current implementations cover embedded cores, FPGA platforms, application-class processors, and commercial devices. Future growth is likely to add different performance, power, safety, virtualisation, and integration points.

Product diversity makes clear comparison more important. Buyers need to know the architecture version, software mode, temporal-safety support, compartment model, toolchain, lifecycle, and evidence attached to each offering.

Practical compartmentalisation

Memory-safe pointers reduce one major vulnerability class. Compartmentalisation addresses the authority that remains when code is buggy or compromised.

Active work includes compartment models for applications, operating systems, real-time systems, language runtimes, virtual machines, drivers, and third-party libraries. The engineering challenge is to make boundaries practical to define, inspect, test, and maintain without unacceptable transition or communication costs.

Temporal safety

Capability bounds provide strong spatial protection, but object lifetime requires additional attention. Different systems are exploring allocator integration, revocation, quarantine, schemes that distinguish generations of reused storage, time periods known as epochs, and architecture-specific mechanisms to stop stale capabilities being reused.

Future guidance needs to state these guarantees precisely. The phrase “uses CHERI” does not identify the temporal-safety mechanism or its limits.

Assurance, safety, and certification

Adopters in automotive, infrastructure, aerospace, medical, and industrial markets need evidence that fits established assurance and safety processes. Useful work includes formal models, processor verification, compiler validation, fault-injection tests, security cases, traceable configuration, and certification criteria.

The CHERI Enabled programme provides one product-focused evidence route. It is expected to evolve as standards, tests, and implementation experience mature.

Adoption evidence and economics

Technical demonstrations need repeatable evidence from real workloads. Organisations need to compare:

• vulnerabilities prevented or contained
• porting and training effort
• performance, memory, power, and silicon cost
• update and incident-response burden
• assurance evidence reused across a product line
• supplier availability and long-term support

Publishing both benefits and limitations will help buyers make decisions without treating CHERI as a universal answer.

A layered future

CHERI is likely to develop alongside safer programming languages, improved C and C++ practices, formal methods, exploit mitigations, and stronger operational security. These approaches protect different boundaries.

The direction is not “hardware instead of software”. It is a hardware-software foundation in which pointers carry enforceable authority, components receive less privilege, and higher layers can build on stronger guarantees.

The CHERI Alliance and the University of Cambridge CHERI project track current work and product announcements. Individual open-source projects and suppliers provide details for their own releases.