[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 like that 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.
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.
You can pass CE with a PSK, if you program them all with a unique PSK. There's no technical limitation on provisioning them all with the same PSK, but doing so means one key-leaking oops spoils all your devices.
Provisioning all your devices with the same PSK will not pass EN 18031 / RED-DA.
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.
Why? Because you need track & save every unique PSK, and properly store it such you know what device (IMEI) you programmed what PSK into. This is not an issue with X.509, using which you can create a chain of trust. Using this chain of trust, you can verify each device certificate using the higher-level certificate, which means you not need store the certificates you have programmed into your devices. All you need do is set up a proper chain-of-trust using the X.509 scheme. More on how to do this later (but reading up on it now already won't hurt you).
Modem credential store (1)
With nRF91xx devices, provisioning is most effectively done using the modem credential store. What this is and how it works is already touched upon by the very basic provisioning guide in the Nordic documentation coming with the lwm2m_client sample.
In short: The modem credential store is a piece of memory managed by the modem firmware, only accessible by the modem firmware. It can store X.509 certificates, PSK's and arbitrary strings if needed. It groups those by type, and certain types have restrictions. Most important for us: A private key can only be written to the credential store, it can never be read. This counts as a secure memory under the terms of EN 18031.
Programming public certificates and private keys into the modem credential store will pass EN 18031 / RED-DA.
Once PSK's, certificates, private keys are in the modem credential store, the modem firmware can directly use them when setting up connections for you.
Generating X.509 certificates
As the title of this writing tells you, this is the most basic way.
Using X.509, the device authenticates the endpoint, and the endpoint authenticates the device. Make every X.509 certificate with a unique key-pair. If a key leaks, you can blacklist this one device. No other devices are compromised.
[Writing will continue here; there's a lot to write down.]
