Most cyberattacks on an embedded system end up at the memory, because that is where your executable code, your workspace and your passwords all live. This guide covers how to secure embedded memory at the design stage, from hardware partitioning and secure boot through to the form factor and specification decisions that quietly decide how exposed your product is. It is written for the point in a project where you can still change something without a redesign.
Why your memory is the target
Attackers go after memory because that is where the value sits. Non volatile memory holds the data they want and the functionality they hope to compromise, so a system with a lot of memory and little protection around it is an attractive proposition.
The awkward part is that most embedded systems were never designed with security as a priority. Functionality, low power consumption, a small form factor and cost usually come first, and that is a reasonable set of priorities for a product that was originally never going to touch a network. The moment that product gains a connection, its exposure changes and the specification behind it does not.
That matters more in industrial applications than in consumer ones, because your service life is longer. An IoT enabled kettle might last five years. An industrial system is often still in the field twenty years later, sometimes with dormant remote access software nobody has thought about since commissioning.
The two ways an embedded system usually gets attacked
There are broadly two routes in, and it helps to hold both in mind when you specify.
The first is straightforward unauthorised access. Someone reaches the operator interface through a remote access tool, a default password that was never changed or a port that was left open, and then drives the system in a harmful way. The software has no idea the operator is not legitimate, because the program is executing exactly as designed. Self propagating botnets have made a living out of scanning for devices still using factory credentials.
The second alters the behaviour of the program itself, most often through a memory buffer overflow. When data is written to memory it goes to an allocated address. Write more data than that space can hold and the excess does not get discarded, it spills into the next location and overwrites whatever was there. If that overwritten content is executable code or a return address, the system starts doing something else.
The attacker’s aim is for it to keep looking normal. No crash, no error, just a system that now reveals a password or grants access to something else on the network. Many memory addressing functions in C and C++ are unbounded, so without additional code to validate or crop incoming data there is no safeguard at all.
Michael recommends. Ask what the end of life process looks like for a part before you design it in, not after. An end of life notice usually gives you a last time buy window, and that window is frequently shorter than the time it takes to qualify a replacement. Knowing who tells you, and how far ahead, is worth as much as the specification itself.
Start with enforced hardware partitioning
The first practical control is hardware partitioning. Many microcontrollers split internal memory into secure and non secure regions, with only the secure region used for executable code, and many ARM based parts offer internal memory protection units with one unit per memory region.
A memory protection unit controls which areas of memory can be accessed during different modes of operation, and with which privileges, so you can allow read access where read write access is not needed. Strict partitioning stops anything being written into memory space reserved for executable code during normal operation, which is the practice usually called executable space protection.
This is worth doing even when your microcontroller has enough internal memory, because most systems end up needing more. Adding external memory to support later expansion, or to keep the same microcontroller across a family of products, is sensible engineering. It also widens what you need to protect.
Protect the boot process, not just runtime
Partitioning covers normal operation. Bootload is where a lot of embedded systems are genuinely vulnerable, particularly any product that accepts field upgrades.
Most low cost bootloaders do very little beyond a checksum to confirm the firmware image is whole. A bootloader is capable of far more than that, because it can establish a chain of trust. In outline, a checksum is generated for the new firmware and encrypted with a private key to create a signature. Firmware and signature are loaded into the system in the field, the system uses a public key to decrypt the checksum, and only authenticated, intact firmware is allowed to load.
To support that, the microcontroller needs a cryptographic engine, secure storage for keys and memory protection. If your specification does not currently include all three, secure boot is not available to you no matter what the software team does later.
There is a related risk in updates themselves. Most require a reboot, during which the system executes commands that are not part of normal runtime behaviour, and an update path that is not well architected is an opening. Security patches are the other half of this. Where a system runs an open source operating system and has no mechanism to check for updates automatically, the gap between patches becomes a gap in your defences.
The specification questions that decide how secure your memory is
Software security gets most of the attention, and there is nothing wrong with that, but it often means less thought goes into whether your hardware is secure by design. From a hardware point of view, memory is a good place to start. These are the questions worth answering before you commit.
How much memory do you actually need. Memory is frequently overspecified. Minimising the allocation reduces the attack surface available for buffer overflows and memory corruption exploits, so the honest number is the safer number.
Does it need to be removable, and in what form factor. If memory has to come out of the product, ask whether it needs to be a standard form factor at all. An SD card or a USB stick can be read by anyone who finds it, and a USB receptacle on a panel is a doorway. A proprietary form factor such as a Datakey RUGGEDrive token cannot be interrogated without the matching receptacle, and both parts are only available through an appointed distributor.
If it has to be a standard form factor, what else can you do. Not all cards and drives are equal. Ranges such as the Flexxon secure memory products offer additional protection at the device level, including write once read many and read only behaviour, which helps prevent unauthorised removable memory being accepted by the system in the first place.
If the memory is embedded and cannot be removed, how secure can you make it. Non removable does not mean inaccessible. Embedded memory is available with on board security features, and that is a materially better starting point than a standard component chosen on price and capacity alone.
What environment will it operate in. Temperature range, vibration, shock and moisture all belong in the specification before component selection, not after. If a device has to read and write reliably under high vibration or G force, that constrains your options early.
What is the expected life of the product. There are two halves to this. Can you source the same memory for as long as the product will be sold and supported, and how long will each individual device survive inside the system. Nexus still supplies customers whose systems were designed in the late 1980s and 1990s, because the memory chosen then was the sort that stays available.
Is the memory fit for the way you will actually use it. There are many variations of NAND flash, and how your system writes matters more than the headline capacity. Consider the volume of data, the frequency of writes, whether you need protection against sudden power loss and how long the data has to remain readable.
Michael recommends. When a customer comes to us with SD cards failing in the field, the cards themselves are usually fine. We have investigated a number of these, sometimes by testing the cards, and in most cases the problem was that the wrong card was specified for the write pattern. Move to memory that suits the application and the failures tend to stop.
Form factor is a security decision as well as a mechanical one
It is easy to treat the connector as a mechanical detail. In a secure design it is doing more work than that.
A removable memory device used for maintenance access is effectively a key to expensive equipment. If it is lost or stolen, an industrial form factor device is hard to interrogate without its corresponding receptacle. A standard USB stick offers no such protection, and the receptacle it plugs into is an open route into the system.
Durability numbers tell you something too. A commercial USB connection is rated at a minimum of 1,500 insertion cycles. Industrial removable memory devices and their receptacles are rated far higher, and while maintenance access is not a daily task, the higher rating is a fair measure of how the part has been built. Industrial grade receptacles are also available with IP67 protection, which means fully protected against dust and protected against temporary immersion, and that is what keeps an outdoor or wash down installation working.
| Consideration | Commercial removable memory | Industrial removable memory |
|---|---|---|
| Form factor security | Standard USB or SD, readable by anyone | Proprietary token and matching receptacle, available only through an appointed distributor |
| Insertion cycle rating | USB rated at 1,500 cycles minimum | Rated considerably higher, figure varies by product |
| Environmental testing | Not typically tested to military standards | Options tested to MIL-STD-810F vibration and salt fog methods |
| Ingress protection | Not usually rated | IP65 and IP67 panel mount receptacles available |
| Long term availability | Subject to consumer product cycles | Long term supply commitments suited to decade long product lives |
Figures in this table are drawn from Nexus published material. The insertion cycle figures behind the general comparison are keyceptacles 200,000 and receptacles 50,000, confirmed by Nexus, and any part specific figure should be checked against the current datasheet.
What secure by design looks like in practice
Renewable energy is a useful illustration, because it combines remote sites, long service life and genuine security consequences.
Wind and solar installations sit in places where wired or wireless data transfer is not always practical, so removable memory is used for configuration and for data logging. Large turbines run condition monitoring systems with accelerometers on the gearbox and other drivetrain components, and the vibration signature they record is what tells an operator whether a component is wearing gradually or has failed suddenly. Even where remote monitoring exists, storing that data locally is common practice.
The environment is unforgiving. Temperature extremes, high moisture and, above all, vibration, which is the condition most likely to disturb the electrical connection between a removable device and its receptacle. That is why industrial devices tested to military vibration and salt fog methods find their way into offshore and coastal installations.
The service life makes it harder again. A turbine is expected to run for around twenty years and nobody wants to climb one to change a component. One Nexus customer put a Datakey serial memory token and its matching receptacle through highly accelerated life testing to simulate twenty years inside a nacelle, with rapid temperature cycling and high vibration. Beyond contact wear, the device kept its electrical integrity and worked. You can see more applied examples on the Nexus success stories page and on the renewable energy sector page.
Solar sites raise the same questions in a slightly different order. Inverter health is monitored for predictive maintenance, dust and sand are often the dominant environmental problem, and removable memory is commonly used for user authentication during maintenance visits. Large scale wind and solar assets are increasingly treated as critical national infrastructure, so who can plug what into them is no longer a minor design detail. The same logic applies on a production line, where recipe and calibration data are handled the same way, as covered on the industrial automation sector page.
Authentication at the memory level
If authentication is central to keeping attackers out, it is worth running dedicated security silicon alongside your microcontroller rather than relying on the microcontroller alone.
Datakey CryptoAuthentication tokens pair a Microchip high security hardware integrated circuit with a rugged removable form factor. The parts that matter for your design are a unique and non changeable device identity set at manufacture, a hardware random number generator and support for certificate handling, which together let you establish the chain of trust described earlier and carry it on something an engineer can physically hand over. Full capacities, cycle ratings and dimensions are on the product page.
The practical benefit is that cloning becomes extremely difficult and the silicon includes features to detect tampering. For transferring passwords, security keys, certificates or system configuration files into an embedded system, that is a very different proposition from a thumb drive.
Where the threat is firmware level rather than physical, X-PHY cyber secure drives take a different approach again, embedding AI based protection inside the drive so that ransomware and tampering are detected at the hardware layer rather than by software sitting above it.
Michael recommends. Ask for a sample and put it through the interface you will actually use, not a development board on a bench. A datasheet will tell you the specification. Only a sample in your own system tells you about connector clearance, mounting and how the part behaves when your firmware talks to it.
Do not forget the operating system and the language
The focus here is physical memory, but two software decisions have a direct effect on it.
A trusted operating system is one evaluated against the internationally recognised Common Criteria security evaluation standard and given an evaluation assurance level. The features that make an operating system trustworthy are the ones that matter to you here, namely memory protection, file protection, user authentication and control over access to I/O devices.
On languages, low level languages such as C are unconstrained, which is exactly why buffer overflows happen by accident as well as by design. A higher level language reduces the risk, because languages such as Java check array bounds automatically. Operating systems help too, by declaring areas of memory non executable and by randomising the location of memory spaces used at runtime, which is effective because an attacker planning an overflow needs to know exact addresses.
The regulatory direction of travel
Security expectations for connected products in the UK have moved from guidance to law. The Product Security and Telecommunications Infrastructure Act 2022 and the regulations under it came into force in April 2024, banning universal default passwords and requiring manufacturers to publish a vulnerability reporting route and a minimum security update period.
Read the scope carefully before you assume it applies to you. The regime targets consumer connectable products, and several categories are excepted, so a great deal of industrial and operational technology sits outside it. That is not a reason to design to a lower standard. The longer service life and the consequences of a compromise in a defence, medical or infrastructure application argue hard in the other direction, and the NCSC device security principles for manufacturers are a sensible benchmark whether or not the law obliges you to meet one.
Frequently asked questions
Is embedded memory really the main target in a cyberattack?
In most cases the attack ends up at the memory even when it does not start there. Executable code lives in memory, memory provides the workspace for the running program and it stores sensitive data and credentials, so attacks against an embedded system are very often attacks against its memory.
Can I make a standard USB or SD card secure enough for an industrial product?
You can improve it considerably with device level protection such as write once read many, read only modes and hardware encryption. What you cannot change is that a standard form factor can be read by any standard reader, so if the physical security of the data matters, a proprietary form factor removes a risk that no amount of software can.
Does a memory protection unit remove the need for secure coding?
No. A memory protection unit stops writes into space reserved for executable code during normal operation, which closes off one important route. It does not validate the data your program accepts, so bounds checking and a safer language still matter.
How do I stop memory obsolescence forcing a redesign later?
Treat availability as a specification line alongside capacity and temperature range. Ask your supplier what long term supply commitment sits behind the part before you design it in. This is one of the reasons Nexus works as a value added distributor with applications engineering support rather than shipping boxes, because a memory change part way through a product life usually means requalification.
What should I send when I ask for help specifying secure memory?
The operating temperature range, the vibration and shock environment, how much data you write and how often, whether the memory must be removable, the expected service life of the product and any security or classification requirement you are working to. That is usually enough to narrow the options quickly.
Talk it through before you commit
Securing embedded memory is much cheaper at specification stage than after a field failure or an incident. If you are choosing memory for a new design, or you are trying to work out why the memory in an existing one keeps failing, talk to a Nexus applications engineer and bring your requirements rather than a part number.
If you are earlier in the process and just want to see how the parts behave in your own system, you can request a memory sample instead. Either way you get a straight answer from someone who has specified this before.