[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. Also based on comments I was wrong on some stuff which needs fixing.]
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. As I write this, we're halfway 2026 now. 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 (including this one!), random web pages, the OpenSSL docs and EU's rules & regulations docs. To save you the pain of having to figure it all out.
Preface
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
EN 18031 / RED Cybersecurity / RED Delegated Act (RED-DA)
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.
Be aware that all RED-DA 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 does EN 18031 really mean?
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 done so by the intended entities (authorized).
- All sensitive data is stored in a secure memory (either by it being physically hard to get to or by some electronic/logical means)
- One device getting compromised despite these measures should not spoil them all.
Proper security: X.509 approach
In practice, for you (a developer of a nRF91xx device using LwM2M), it comes down to the following:
The following is a Kconfig choice, where the other option is CONFIG_APP_LWM2M_SECURITY_MODE_PSK=y CONFIG_APP_LWM2M_SECURITY_MODE_X509=y # The following is an arbitrary number chosen as ID, which needs to match with ID used # in modem credential store (explained later) CONFIG_LWM2M_CLIENT_UTILS_SERVER_TLS_TAG=0 # Size of each key resource in each security object instance; # needs be large enough to fit the PSK or certificate as stored in the modem credential store CONFIG_LWM2M_SECURITY_KEY_SIZE=1024 # Enable DTLS for transport security CONFIG_LWM2M_DTLS_SUPPORT=y CONFIG_LWM2M_DTLS_CID=y
I highly recommend you pick X.509 over using a PSK. You can pass CE while using a PSK, but to do it in a shitty way requires only a marginally smaller effort than just going X.509. You're not saving yourself all that much effort, but you do take a considerable loss in security. And to do PSK's the proper way (which is needed to pass CE!) is actually way more cumbersome than the X.509 approach.
The main reason PSK does not do, is due to how it is done in the lwm2m_client sample: The PSK is set by the firmware and hence the key is in the flash image. If you compile your PSK into program code, all devices will have the same key.
This is very much not desirable: One device getting compromised, spoils them all. Also the key being in the flash image means it's transmitted in over the air updates. Is your transmission channel CoAP or HTTP? Your PSK is then transmitted in the clear at some point, during which it can be easily intercepted. Is your updated flash image stored in external flash memory before being applied? External flash is not secure. The flash image leaks by other means? All devices compromised.
Using a PSK in your flash image will not pass EN 18031 / RED-DA.
You can pass with a PSK, but you will need to provision your devices during production. There's already a very basic guide for this in the Nordic documentation.
Provisioning during production
During device production, you need create some sort of individualization-step. nRF91xx devices already are individuals by means of all having a unique IMEI, but they also need unique keys. There's no technical limitation on provisioning them all with the same PSK, but doing so means one oops spoils all your devices. Which will not pass CE.
As such, all your devices will need a unique key. And when you're at the point of all devices getting a unique PSK, you're actually easier off with X.509 than trying to steer clear of it.
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.]
