[This writeup is a work in progress - it was meant to be a quickie, but to write it all down properly exceeded the limits of reasonable working hours. Writing will continue tomorrow.]
Hey all,
I've been working on a family of commercially available cellular IoT devices using the LwM2M protocol utilizing nRF9160 and nRF9151 SoCs. In the European Union, those sort of things are mandated to have proper security since halfway 2025 already. But the road to piecing together this proper security for my product was kinda rocky, because documentation on the needed components was, and unfortunately still is, rather lacking.
So, here's my writeup of what I learned from the AT commands manual, Nordic modem firmware documentation, various issues on nRF DevZone, random web pages, the OpenSSL docs and EU's rules & regulations docs. To save you the pain of having to figure it all out.
To sell certain types of products in the European Economic Area (EU + Norway & Iceland), they are required to meet or exceed certain standards. When a product is claimed to meet all the applicable standards for what type of product it is, it is to be designated Conformité Européenne, otherwise known as the CE mark. The General Product Safety Regulation (GPSR) stipulates a product must comply with all applicable standards to legally carry that CE mark.
CE in itself is not a certification. It is a self-proclaimed statement the product bearing it has passed all the applicable certification procedures, for it to be sold for use within the European Economic Area. When you're doing cellular IoT stuff, CE will include the Radio Equipment Directive. RED is all the run-of-the-mill radio testing stuff including electrical safety, EMF, EMC and your product not unintentionally being a radio jamming-device. Nothing exciting, has been around for years.
But then, the Radio Equipment Directive got extended in 2025: Published in January 2025 and in full effect since August 2025: EN 18031. Otherwise know as RED Cybersecurity and RED Delegated Act (RED-DA): https://en.wikipedia.org/wiki/Radio_Equipment_Directive_(2014)#Harmonised_standard_EN_18031
The EN 18031 directive explicitly targets internet-connected radio-enabled devices. Otherwise commonly referred to as IoT devices. Developers (yes, that's you) have to up their security game to sell their stuff in the European Economic Area.
There's a good deal of information on the web about EN 18031 / RED-DA. Be aware a lot of this information available on the public internet is really an infomercial / advertorial! Much about EN 18031 on the web today is written by certification companies that want you to use their services.
What these certification companies obscure on their infomercial websites is that you can self-certify the cybersecurity part of your product. For the run-of-the-mill radio testing stuff you will still need the certification company with their special rooms & radio equipment, but the cybersecurity-part is something you can do in-house yourself.
Also be aware that all documentation for your device must be available up to 10 years after its last sale and you lying about it being Conformité Européenne is criminally punishable and will likely trigger a recall you have to pay for. So, you can't be & should not be Mr. Nice guy to yourself when doing your cybersecurity self-assessment. And if you decide to use the services of a certification company, they will not be either.
What EN 18031 comes down to is basically this: No sloppy security practices allowed.
Proper security practices look like this:
- All sensitive data going over your wireless connection is mathematically guaranteed to be confidential (encrypted).
- Any attempt to alter sensitive data in transit (including a firmware update) is detected & dealt with (discarded).
- Whomever you're communicating with must be verified to be whom/what is claimed (authenticated).
- Whenever sensitive data is accessed (over the network & local interfaces) it can only be so by intended entities (authorized).
- All sensitive data is stored in a secure memory.
- One device getting compromised despite these measures should not spoil them all.
All sensitive data will have some sort of Access Control Mechanism, will be stored using a Secure Storage Mechanism, and communicated only using a Secure Communication Mechanism.
In practice, for you (a developer of a nRF91xx device using LwM2M), it comes down to the following:
CONFIG_APP_LWM2M_SECURITY_MODE_X509=y
No more single PSK (Pre-Shared Key) for all devices. If you compile a PSK into program code, all devices will have the same key. So one device getting compromised, spoils them all. Also the key being in the flash image means it is transmitted in over the air updates. Is your transmission channel for those secure? Likely it is CoAP or HTTP, meaning it can be easily intercepted. Also PSK implies symmetrical encryption: The same key for encryption & decryption, in both directions.
Using a PSK in your flash image will not pass EN 18031 / RED-DA.
Use X.509 instead: https://en.wikipedia.org/wiki/X.509
Using X.509, the device authenticates the endpoint, and the endpoint authenticates the device. Make every X.509 certificate with a unique key-pair. When done correctly, the encryption is asymmetrical: The key used for decryption is different from encryption, and both directions have their own key-pair. If a private key leaks, it only spoils the one device it leaked from, and only for communication in one direction. If a key leaks, you can blacklist this one device. No other devices are compromised.
The nRF91xx modem firmware maintains what's called a credential store. It is a memory separate from the program memory where keys & related data can be stored. Presently it is most easily manipulated using AT commands.
[Writing will continue tomorrow; there's a lot to write down.]
