For a long time, designing a connected device meant focusing on electronics, firmware, radio, battery life, and unit costs. Today, a new topic is coming up in almost every project meeting: cybersecurity. And it is no longer something to tick off at the end of the process.
"Have you accounted for the CRA?" — the question that keeps coming up
Over recent months, at Codium, we have been hearing questions we never heard two years ago:
These questions are no longer the preserve of large enterprises or defence projects. They come from SMEs, industrial startups, and system integrators. And they arise earlier and earlier in the project lifecycle.
There is also a concrete catalyst, less widely covered: over recent months, many local authorities have been audited and briefed by ANSSI teams. The findings were sometimes stark — some discovered they were significantly exposed across their digital systems. This translated very quickly into procurement requirements: local authorities now want to bring their entire systems infrastructure up to standard, including IoT networks now ubiquitous in cities — gas, water and electricity meters, traffic management, smart traffic lights, environmental sensors. These devices, long deployed without serious security consideration, are now firmly in the spotlight.
Why this goes far beyond "a compliance topic"
The first temptation, when you hear "regulatory cybersecurity", is to file it alongside quality constraints. One more stamp to obtain before going to market.
Except that when you dig in, you quickly see that the cybersecurity of a connected device is not a coat of varnish applied at the end. It is a series of genuine architecture questions:
These questions directly impact the electronic architecture, firmware, production and maintenance. We are squarely in the heart of product development.
At Codium, one of the partners specialises in cybersecurity — and in 2026, the timing could not be better
"Having a partner whose doctoral thesis focused on connected device security, at a time when the entire industry is suddenly discovering that its products need to be conceived differently… is objectively very good timing."
— The Codium teamTo be honest: for a long time, this sensitivity to security could come across as slightly excessive. The instinct to challenge the authentication architecture as early as the first prototype, to ask about key storage before the microcontroller has even been selected, to refuse to leave JTAG active in production "just in case it's useful for debugging"… was sometimes met with a wry smile. A little too paranoid for some projects. A little too detail-oriented for clients who mainly wanted to move fast.
Except that in 2026, we are really glad to have these reflexes in the team. Because the questions we were asking "ahead of time" are exactly the ones now being asked by test labs, large accounts, local authorities and prime contractors. And projects that integrated this thinking early are the best equipped to answer them.
Cybersecurity is not treated as a constraint imposed at the end of the project, but integrated from the very first decisions: choice of microcontroller, secrets storage strategy, OTA update architecture, maintenance interfaces. Pragmatic, calibrated to the real risk level of the product and the target market.
In the real world of embedded electronics development, this changes a great deal.
RED and CRA: two texts, two levels of requirement
For many manufacturers, the acronyms pile up and start to blur together. Here is what concretely distinguishes the two main regulatory texts:
| Criterion | RED Directive | Cyber Resilience Act (CRA) |
|---|---|---|
| Scope | Radio equipment (WiFi, BT, LTE-M, LoRa…) | Any product with a connected digital component |
| Objective | Prevent a radio product from threatening networks and data | Security designed, maintained and documented throughout the entire lifecycle |
| Obligations | Compliance before market placement | Design + updates + vulnerability management + documentation |
| Timeline | Cybersecurity provisions already applicable | Progressive entry into force until 2027 |
| Product impact | Security architecture to integrate before CE marking | Full lifecycle: from prototype through to end of commercialisation |
| Products concerned | Any equipment transmitting/receiving (WiFi, BLE, LTE-M, Zigbee, GNSS…) | Virtually all connected devices, including industrial equipment |
The 4 pillars to integrate from the design stage
This is probably the most profound shift. Cybersecurity can no longer be addressed after the prototype. Here are the four topics we now challenge from the very first scoping meetings:
1. Product identity
Should each device have its own identity — unique key, individual certificate, robust authentication method? The answer is almost always yes. An entire fleet of devices sharing the same access logic means that compromising a single unit can potentially compromise the entire fleet.
This choice directly impacts the electronic architecture (Secure Element? eFuse? TrustZone?), the boot firmware and the production process (key injection on the workshop floor).
2. Secrets and key management
Where are secrets stored? In the microcontroller? External memory? A secure element? Injected at which point in the manufacturing process? How can they be renewed in the event of a compromise?
These questions cannot be deferred to the end of the project — they condition component selection, firmware architecture and sometimes BOM cost. An unencrypted external flash memory storing session keys is a vulnerability etched into silicon.
3. Secure updates (FOTA / OTA)
A connected product without a genuine update strategy is already partially a problem. If a vulnerability is discovered after market launch (and it will be), you need to be able to patch the firmware in the field, remotely, without risk of malicious code injection.
This requires: firmware signing, integrity verification before flashing, a rollback mechanism in case of failure, version compatibility management, and a secure distribution infrastructure.
4. Maintenance modes and technical access
This is often where future vulnerabilities hide. The most dangerous interfaces are not always those exposed to the end user — they are debug ports, development UARTs, JTAG interfaces, and support backdoors left active in production.
At Codium, this is typically the kind of point we prefer to challenge very early, rather than discovering it during an audit or lab evaluation. Disabling JTAG in production, locking a bootloader, conditioning maintenance access behind strong authentication — these are architecture decisions, not configuration choices.
The market is evolving: cybersecurity is becoming a selection criterion
There is a market phenomenon adding to the regulatory pressure. Customers, integrators, large accounts and even some distributors are starting to ask precise questions about the security of the products they integrate.
This is no longer purely a technical risk topic. It is a commercial one. A supplier capable of documenting the security architecture of their product, demonstrating a vulnerability management strategy and supporting a certification process — that is a supplier who wins contracts.
For critical products: CSPN and IEC 62443
In certain contexts — industrial, critical, or with demanding clients — basic regulatory compliance is not enough. You need to be able to demonstrate it seriously.
First-Level Security Certification
Issued by ANSSI (the French National Information Systems Security Agency), this is the reference product certification framework in France. It requires rigorously structuring the product perimeter, its security assumptions, documentation and protection mechanisms.
This is not a commercial label. It is the difference between "we believe the product is secure" and "we can demonstrate it under independent evaluation."
Relevant for: government markets, defence, critical healthcare, smart metering, public authorities.
Industrial systems security
International standard (IEC = International Electrotechnical Commission), recognised worldwide for industrial and OT environments. As soon as automation, critical infrastructure or connected equipment in industrial settings is involved, it stands as the fundamental reference framework.
What sets it apart: IEC 62443 does not stop at the product itself. It goes as far as evaluating development methods — design processes, design office practices, patch management, traceability. In other words, it is an audit of the product and the organisation that produces it.
It requires reasoning about architecture, network segmentation, security levels (SL 1 to 4) and hardening within a potentially critical system.
Relevant for: PLCs, industrial gateways, connected HMIs, edge SCADA systems, export markets.
Our approach at Codium: integrate early, not suffer later
This is our very clear conviction, and it has guided our approach to projects for several years now.
- ✓ From scoping: cyber risk analysis and security architecture review before the first component choices are made.
- ✓ Component selection: availability of a Secure Element, hardware crypto accelerator or protected memory area factored into the BOM from the start.
- ✓ Firmware architecture: authentication strategy, key management and OTA update defined in line with hardware constraints.
- ✓ Technical interfaces: systematic review of debug, maintenance and production access — disabled or locked before volume production.
- ✓ Documentation: production of a documented security architecture, useful for clients, test labs and future certification processes.
- ✓ Long-term maintenance: consideration of post-commercialisation vulnerability management and the field fleet update strategy.
The connected products that will fare best tomorrow will be those whose cybersecurity was thought through from today — not hastily patched together before certification.
Conclusion: in 2026, it is no longer optional
Between the RED Directive, the Cyber Resilience Act, rising market expectations and evaluation frameworks such as CSPN and IEC 62443, IoT cybersecurity has moved from a peripheral topic to a central one in product development.
At Codium, we do not claim this makes projects simpler. But we are convinced of one thing: this topic, addressed early, methodically and with the right expertise in the team, is entirely manageable. Addressed late, it can be very costly — in technical rework, in delays and in commercial credibility.
And frankly, in the current context, we are genuinely glad to have these cybersecurity skills in the team from the start of a project — rather than sorely regretting their absence during a painful end-of-project audit.
Are you developing a connected device, radio equipment or an embedded product? Let's talk about your project and your cyber strategy.