IoT memory solutions usually come unstuck for one reason: a mismatch between the part and the environment it ended up in. This guide walks through how to specify storage for a connected device, covering write endurance, unexpected power loss, physical and data security, and long-term availability. The aim is to help you make the call before the design is locked, rather than after the first batch of field returns.
Why commercial memory struggles in a connected device
Commercial memory is built for a device that sits on a desk, gets used in short bursts and is replaced every few years. An IoT device is the opposite. It writes small amounts of data constantly, often for a decade, frequently somewhere nobody wants to visit twice.
That difference shows up in four places. Write endurance, because continuous logging wears a card far faster than occasional file copying. Temperature, because a cabinet on an unheated factory wall or a roadside enclosure in August is nothing like an office. Power behaviour, because a device that loses supply mid-write can corrupt data or lose a filesystem entirely. And security, because a connected device with an accessible memory port is a physical attack surface as well as a network one.
None of this means the original specification was careless. Most designs that fail in the field were specified sensibly with commercial parts, and the problem only becomes visible once the fleet is out there and the returns start arriving.
Start with the environment, not the part number
The fastest way to narrow the field is to describe where the device lives and what it does, before anyone looks at a datasheet.
Operating temperature range does most of the work. So does the duty cycle, meaning how often the device writes and how much it writes each time. Between them, those two figures rule out the majority of parts on the market and turn a long shortlist into a short one. Vibration, humidity, dust ingress and washdown exposure narrow it further, and if the enclosure is opened in the field, an IP67-rated panel mount option may be worth designing in from the start.
Michael recommends sending the operating temperature range and the daily write volume before you send a part number. Those two figures rule out more options than anything else on the specification, and they stop the conversation starting in the wrong place.
Work out how much your device actually writes
Write endurance is where most IoT storage decisions are won or lost, and it is the figure engineers most often skip.
A flash memory cell is good for somewhere between 50,000 and 100,000 program and erase cycles, and both operations are harder on the cell than reading because of the high voltage involved. Wear-levelling circuitry inside a finished card or drive spreads that load across the device, which is why a properly built industrial part lasts so much longer than a raw cell figure suggests. How many bits each cell holds then changes the picture again.
| Cell type | Density and cost | Speed | Endurance | Typical IoT fit |
|---|---|---|---|---|
| SLC, one bit per cell | Lowest density, highest cost per GB | Fastest | Longest | Continuous logging, boot and firmware, safety-critical records |
| MLC, two bits per cell | Moderate | Moderate | Moderate | General industrial storage with a known write budget |
| TLC, three bits per cell | Higher density, lower cost | Slower | Shorter | Read-heavy devices with modest write volumes |
| QLC, four bits per cell | Highest density, lowest cost per GB | Slowest | Shortest | Bulk archive where writes are rare |
Three-dimensional NAND, where cells are stacked rather than laid out in a plane, improves matters across the board. It accommodates more write cycles, draws less power and takes less space than the equivalent two dimensional part, whichever cell type you choose. If you want the underlying detail, the Nexus guide to NAND flash memory covers cell structure, architecture and the NAND versus NOR comparison in full.
The practical step is to estimate your daily write volume honestly, including log rotation, buffered sensor data and any firmware update mechanism, then multiply it out across the intended service life. That number decides the cell type and the capacity, and it is far cheaper to get right on paper than in the field.
Match the memory type to the job
Connected devices rarely need one kind of memory. A gateway might hold firmware in NOR flash, calibration data in a serial EEPROM and captured data on an industrial solid state drive, each chosen for a different reason.
| What you need to store | Sensible starting point |
|---|---|
| Calibration constants, machine settings, small configuration records | Serial memory using EEPROM or NOR flash, from 1 Kbit to 64 Mbit, with SPI, I2C and Microwire interfaces |
| Firmware and code that must execute quickly and reliably | NOR flash, which gives faster access and strong data retention at smaller capacities |
| Embedded bulk storage inside a sealed device | Industrial eMMC, which puts managed NAND and a controller in one package |
| Captured data, images, video or continuous logs | Industrial SSDs spanning PCIe NVMe, SATA and PATA, from 512 MB to 8 TB |
| Removable media in an accessible enclosure | Industrial SD and microSD cards, including read only and encrypted formats |
| Data that has to be carried out to a device or a vehicle by hand | Datakey RUGGEDrive tokens with a unique mating receptacle |
For settings and calibration in particular, Datakey serial memory is worth a look before you default to a card, because it removes the filesystem entirely and with it a whole class of corruption problems.
Plan for the power going off
A connected device will lose power unexpectedly, and it will do so during a write. Design for that rather than hoping.
Two things matter here. The first is data retention, meaning whether the stored data survives a sudden loss of supply at all. The second is what happens to the write that was in progress, because a partially written block can take a filesystem down with it. Industrial parts address this with power loss protection, careful firmware and error detection and correction built into the device, and that is a large part of what separates them from a commercial card that looks similar on paper. Power loss protection is not a niche extra either. It runs across most of the Flexxon industrial range and the whole of the Foremay range, so on an industrial shortlist the useful question is which part suits your duty cycle, not whether the protection is there at all.
If your device is battery powered, power consumption during start-up, write, erase, read and standby all need factoring in separately. They behave differently, and a part that looks efficient in one state can be poor in another.
Michael recommends asking for a sample and running it in the actual enclosure for a fortnight before you commit. A datasheet tells you what the part does in ideal conditions. A sample tells you what it does inside your housing, at your duty cycle, with your power supply.
The memory port is a security decision
Data security in IoT is usually discussed as a network problem, and the storage often gets treated as an afterthought. That is a mistake when the device is physically reachable.
If a device has a standard USB or SD port, anyone who can walk up to it can copy the configuration, clone the device or introduce something you did not put there. A unique form factor with a mating receptacle removes that option entirely, because a standard stick simply will not fit. Receptacles are rated for 50,000 insertions, with the Key series rated considerably higher, so this is a design decision that lasts the life of the product.
Where the data itself needs protecting, hardware encryption keeps it secure at rest without leaning on the host processor. Write-once, read-many media, available through the Flexxon security range, makes captured records physically impossible to overwrite, which matters when the log is evidence. And X-PHY cyber secure drives embed AI protection at the firmware level, guarding against ransomware, zero-day attacks and physical tampering below the level any software defence operates at.
If security is the driving requirement rather than one factor among several, two other Nexus guides go deeper than this post can: one on securing embedded memory and one on choosing an encrypted USB memory stick.
The NCSC device security principles for manufacturers are a sound reference point if you are building the security case for a connected product, and they are worth reading before the architecture is fixed rather than during certification.
Edge computing changes the storage requirement
Processing data at the edge rather than shipping it all to a central platform changes the storage sum in one specific way. The device now has to hold data it would previously have passed straight on.
Size the capacity for the worst outage you are willing to survive, not the average one. If a gateway writes a hundred megabytes a day and you want it to ride out a fortnight with no connectivity, that is your floor before you have stored anything else. Underestimating this is a common reason an edge device runs out of room in its second year rather than its tenth.
The rest follows from where the box physically sits. Edge hardware lives in the environment rather than a controlled room, so temperature range and vibration tolerance come back into play, and the data now rests somewhere a person can walk up to rather than behind a data centre door.
Where this shows up in the field
The pattern repeats across the sectors Nexus supplies, with the emphasis shifting each time.
In industrial automation, recipe and machine settings data has to survive power cycling and stay readable across a fleet of machines built over many years. In transportation, continuous data logging on rail, road and marine assets means high write volumes and constant vibration. In renewable energy, remote monitoring on wind and solar sites puts the storage somewhere nobody wants to send an engineer, so reliability is worth paying for. In medical and healthcare devices, the same sensor and logging requirements arrive alongside a much higher bar for data protection.
Connected urban infrastructure pulls all of these together. Traffic management, environmental sensing, public safety monitoring and utility metering are all IoT deployments in harsh outdoor conditions, run by organisations that expect the hardware to still be working in a decade.
Design out obsolescence before you design the part in
The last consideration is the one that costs the most when it goes wrong. A memory part that disappears from the market forces a redesign, and in a regulated sector that redesign means requalification.
Guaranteed long term availability is why industrial parts carry the prices they do, and why the supply commitment behind the part matters as much as the specification on it. Nexus has been supplying this market since 1987, is the appointed partner for Datakey, Flexxon, Foremay, Kobra VS and X-PHY, and supplies across the UK, Ireland, the DACH region, Benelux and Scandinavia. It works as a value added distributor with applications engineering support rather than as a stockist. Where an off-the-shelf part does not fit, proven designs can often be adapted without paying for a full custom development.
Michael recommends asking about the supply commitment at the same time as the specification, not after prototyping. Finding out a part has a five-year horizon when your product has a fifteen-year life is a problem that gets considerably more expensive the later you discover it.
Frequently asked questions
Is an industrial SD card genuinely worth the difference in price over a consumer one?
For a device that logs continuously or sits outside a controlled environment, yes. The difference is in write endurance, temperature tolerance, power loss behaviour and guaranteed availability, and a single field failure usually costs more than the price gap across an entire production run.
How do I estimate write endurance for my device?
Add up everything your device writes in a day, including sensor data, rotated logs, buffered uploads and firmware updates, then multiply by the intended service life in days. Compare that total against the endurance rating of the part rather than its capacity, since capacity and endurance are different things.
Does an IoT device need encrypted storage if the data is already encrypted in transit?
Often yes. Transport encryption protects data moving across the network and does nothing for data sitting on a device somebody can physically reach. If the device holds credentials, configuration or personal data, hardware encryption at rest is the sensible default.
What is the minimum information you need to make a recommendation?
The operating temperature range, the daily write volume, the interface you have available and the intended service life. With those four, the shortlist is usually short. Anything else is refinement.
Ready to specify with confidence
A connected device needs storage that is rugged enough for where it sits, secure enough for what it holds and long-lasting enough to see the product out. Get those three right at the specification stage, and most field failures never happen.
If you are designing memory into a connected product, talk to the Nexus applications engineering team. You get a straight answer from someone who has specified this part before, rather than a link to a datasheet you have already read.
If you are earlier in the process and want to see how a part behaves in your own enclosure, request a memory sample or download the product brochure to browse the full range first.