Why Existing Defences Are Not Enough
Passwords, encryption, testing, and updates reduce risk, but they cannot guarantee that every connected device will always handle memory safely.
A connected camera can have a strong password, encrypt its connection, sit behind a firewall, and receive regular updates. All of those protections are worthwhile. The camera can still contain a memory vulnerability in the software that processes video, network messages, or app commands.
That does not mean existing security has failed. It means each defence solves a different part of the problem.
Different protections answer different questions
- Passwords and authentication control who or what may connect. They cannot guarantee that the software will safely process every request after connection.
- Encryption protects data while it travels. It cannot guarantee that the receiving device will handle the decrypted data safely.
- Firewalls control which network traffic may reach the device. Permitted traffic can still trigger a vulnerability.
- Code review and testing find many mistakes before release. They cannot examine every possible input and path through a complex product.
- Automatic updates correct known flaws in deployed products. They take effect only after the flaw is found, fixed, distributed, and installed.
- Process isolation and sandboxes limit what a compromised process can reach. They may not separate every component inside that process.
Security works best when these measures overlap. The remaining concern is what happens when a memory mistake gets through them.
Safe delivery does not guarantee safe handling
Encryption is like a secure delivery service: it protects a parcel while it travels and helps ensure it came from the expected sender. It does not control what happens when the parcel is opened.
Once an encrypted message reaches a smart device, software must still read its fields, copy information into memory, and decide what to do. If that code makes a memory mistake, the message can trigger a failure even though the connection itself was secure.
The same applies to an authorised mobile app. The user may be genuine and signed in, but an unusual image, name, or command could still expose a defect in the device software.
Testing cannot try every situation
Product teams use reviews, automated analysis, and tests that send unusual or malformed data. These techniques find real vulnerabilities and should always be part of secure development.
A connected product may still contain millions of possible states and input combinations. Its software may include an operating system, network stack, drivers, libraries, and code supplied by several organisations. Testing can prove that a particular problem exists; it generally cannot prove that no unexpected path remains anywhere in the product.
Even sustained review and testing cannot guarantee that every mistake has been found in a complex system. A resilient design limits what can happen if a defect remains at release.
Patches arrive after a vulnerability exists
An update removes a known flaw, but several things must happen first: someone discovers the problem, the supplier understands it, a safe correction is created and tested, and the update reaches each affected device.
Some products are offline for long periods, managed by another organisation, or too old to receive frequent updates. Even with excellent update support, there is a period when a newly discovered vulnerability may still be present.
Updates are essential for correcting software. They are stronger when the device also has protection that operates before a specific vulnerability is known.
One vulnerable component may have too much access
Consider a smart building controller. A service that reads temperature sensor messages may share memory with network credentials, configuration, and commands for other equipment. If that service is compromised, the attacker may inherit all of the access held by the wider program.
Traditional process isolation can separate large applications, but many IoT devices have limited processing power and memory. It can also be difficult to split established software into a separate process for every parser, driver, or library.
The result is often a gap between the access a component needs and the access it actually has.
The processor cannot usually see the intended boundary
A conventional processor can check whether software has access to a broad region of memory. It does not normally know that one part of that region holds a 32-byte sensor message while the next part contains a password or control setting.
If vulnerable software accidentally moves beyond the sensor message, the access may still look valid to the hardware. The code has crossed the boundary intended by the programmer, but not a boundary the processor understands.
What CHERI adds
CHERI lets software give the processor more precise rules. A protected reference, called a capability, can describe the permitted section of memory and whether it may be read, changed, or used to run code. The processor checks those rules whenever the reference is used.
CHERI also supports smaller software compartments. A message parser can receive access to its input and the specific service it needs, without automatically receiving access to credentials, update keys, or every device function.
If the parser tries to go beyond those limits, the processor can stop the invalid access. If the parser is compromised in another way, a carefully designed compartment can restrict what the attacker inherits.
Stronger layers, not a single cure
CHERI does not replace passwords, encryption, firewalls, testing, updates, safe programming languages, or good product design. It adds another layer beneath them:
- Authentication controls who may connect.
- Encryption protects information in transit.
- Testing and review remove defects that can be found.
- Updates correct vulnerabilities discovered after release.
- CHERI can block many invalid memory accesses as they happen.
- Compartments can limit the damage if one component is compromised.
When software contains a mistake, the aim is to prevent it from becoming unrestricted access to private data, important functions, or the rest of a connected system.
Further reading: CISA’s case for memory-safe roadmaps and the CHERI FAQ.