In an article in the February, 2025 issue of Communications of the ACM, I join 20 coauthors from across academia and industry in writing about the remarkable opportunity for universal strong memory safety in low-level Trusted Computing Bases (TCBs) enabled by recent advances in type- and memory-safe systems programming languages (e.g., the Rust language), hardware memory protection (e.g., our work on CHERI), formal methods, and software compartmentalisation. These technologies are seeing increasing early deployment in critical software TCBs, but struggle to make headway at scale given real costs and potential disruption stemming from their adoption combined with unclear market demand despite widespread recognition of the criticality of this issue. As a result, billions of lines of memory-unsafe C/C++ systems code continue to make up essential TCBs across the industry – including Windows, Linux, Android, iOS, Chromium, OpenJDK, FreeRTOS, vxWorks, and others. We argue that a set of economic factors such as high opportunity costs, negative security impact as an externality, and two-sided incomplete information regarding memory safety lead to limited and slow adoption despite the huge potential security benefit: It is widely believed that these techniques would have deterministically eliminated an estimated 70% of critical security vulnerabilities in these and other C/C++ TCBs over the last decade.

In our article, we describe how developing standards for memory-safe systems may be able to help enable remedies by making potential benefit more clear (and hence facilitating clear signalling of demand) as well as permitting interventions such as:

• Improving actual industrial practice
• Enabling acquisition requirements that incorporate memory-safety expectations
• Enabling subsidies or tax incentives
• Informing international discussions around software liability
• Informing policy interventions for specific, critical classes of products/use cases

Most importantly, we need good consensus on what strong memory safety actually means, with documentation of best engineering practices, clear information on inevitable tradeoffs (e.g., with respect to minimising TCBs for those mechanisms themselves, adoption challenges that vary by mechanism), and guidance on how to safely compose multiple technologies within a larger system (such as across multiple application cores and microcontrollers in a contemporary system-on-chip, or across software layers of firmware, operating systems, and higher-level language runtimes).

We propose an overall agenda around standardisation, which includes:

• Developing an intellectual framework spanning diverse technologies and approaches,
• Developing and documenting improvements to current industrial practices, and
• Enabling the clear enunciation of technology-neutral memory-safety requirements.

This will be a challenging area to work in, requiring us to first build technical consensus amongst stakeholders spanning industry, academia, and government, and to explore how technical and engineering standards feed into a larger ‘supply chain’ of sector standards, acquisition frameworks, and so on. Ultimately, however, we would like to enable statements such as:

• A smartphone’s general-purpose OS and all of its network-facing applications must be implemented with at least probabilistic data and control-flow pointer protections within five years, and strong (deterministic) memory safety within fifteen years. Mobile device management (MDM) systems must support enterprises administratively prohibiting installation of memory-unsafe applications.
• All data-centre TCBs responsible for isolating hosted government systems from each other, and from other customers, must be implemented with strong memory safety within fifteen years.
• All networking infrastructure (such as wireless access points) or cyber-physical systems where software interacts with the physical environment (such as automobiles or certain IoT devices such as smart locks, security cameras, smart thermostats, etc.) shipped after 2034 must be implemented with strong memory safety.
• Smart phones and IoT devices using machine-learning models on sensitive personal data, such as inputs from cameras, microphones, GPS and other sensors as well as stored data preserved in order to answer questions such as “where are my glasses?” must, by 2040, be strongly isolated using compartmentalization in order to preserve the privacy and integrity of the data, particularly from the large number of other applications typically running on the same device.

We proceed to proposing a candidate timeline that begins in our current period of widespread adoption of probabilistic mitigation techniques (such as ASLR and PAC) alongside selected adoption of strong memory-safety technologies (such as Rust and CHERI) in selected TCBs in critical application areas such as secure enclaves or in national security applications. We consider various paths including a migration to deterministic protection at first in security-critical systems and then broader industry use over the coming decades.

An extended technical report version of the paper explores these and other considerations in greater detail, including the impact of potential research successes around formal methods or automatic translation from C to Rust, regulatory impacts, technology adoption failures, and so on. Over the coming year, we hope to develop a clearer agenda (and broader collaboration) to pursue these goals.

Many thanks to my coauthors on this work: John Baldwin (Ararat River Consulting), Tony Chen (Microsoft, Inc.), David Chisnall (SCI Semiconductor), Jessica Clarke (University of Cambridge), Brooks Davis (SRI International), Nathaniel Wesley Filardo (SCI Semiconductor), Brett Gutstein (University of Cambridge), Graeme Jenkinson (Capabilities Limited), Christoph Kern (Google, Inc), Ben Laurie (Google, Inc; Capabilities Limited; University of Cambridge), Alfredo Mazzinghi (Capabilities Limited), Simon W. Moore (University of Cambridge, Capabilities Limited), Peter G. Neumann (SRI International), Hamed Okhravi (MIT Lincoln Laboratory), Alex Rebert (Google, Inc.), Alex Richardson (Google, Inc.), Peter Sewell (University of Cambridge), Lawrence Tratt (King’s College London), Muralidaran Vijayaraghavan (Google, Inc.), Hugo Vincent (Arm Limited), and Konrad Witaszczyk (University of Cambridge).

We gratefully acknowledge Graeme Barnes (Arm), Ron Black (Codasip), Mike Eftimakis (Codasip), Andy Frame (VyperCore), John Goodacre (UKRI), Richard Grisenthwaite (Arm), Alice Hutchings (University of Cambridge), William Martin (NSA), Ed Nutting (VyperCore), Anjana Rajan (ONCD), Jonathan Ring (ONCD), Carl Shaw (Codasip), Howie Shrobe (DARPA), Domagoj Stolfa (University of Cambridge), Dan Wallach (DARPA), and Paul Waller (NCSC) for their thoughtful comments and detailed conversations with us about these ideas. Finally, we acknowledge – and remember – Professor Ross Anderson (University of Cambridge), who developed key ideas in the application of economic principles to computer security, and whose advice helped inspire this work.

Robert N. M. Watson