Not long ago, security in hardware design was something handled late in the development process. Not because competence was lacking, it was simply not on the agenda. Other factors were driving decisions: functionality, cost, and time to market, and they had a higher priority. Security had to adapt to what had already been built, like a bolt on, last minute feature. Testing came last, when everything else was done.
That logic no longer holds.
What we are seeing now is not just an increase in requirements, but a shift in where they apply. New regulations all point in the same direction: security is moving from the end of the development cycle into the design phase of the IoT product.
This is where critical trade-offs have to be made. And in hardware-centric systems, those decisions are very difficult to change later.
EU regulation is making secure by design unavoidable
It is easy to view the NIS2 as an organisational requirement, CRA as a product regulation, and RED as something related to radio equipment. In practice, they converge at the same point: the physical product.
NIS2 pushes requirements upstream through the supply chain, meaning that component selection and design decisions are affected. RED, through EN 18031, defines a technical baseline for what is considered an acceptable level of security in connected IoT products. CRA adds lifecycle responsibility, where the manufacturer is accountable not only at delivery, but throughout the entire lifespan of the product. At the same time, the Data Act reshapes how data is exposed and shared, affecting both architecture and interfaces.
This means security can no longer be treated as a layer added on top. It has to be built into the design itself, from the component level and upwards—what we call secure by design.
Secure by design in practice
A whitepaper from Rapid7 shows how relatively simple attacks can go far when basic security principles are missing. By manipulating the circuit board and exploiting unprotected debug interfaces, weak update mechanisms, or insufficient, sometimes even non-existent, authentication between device and backend, it is possible to extract credentials directly from the system.
What stands out is not the complexity of the attack, but the lack of resistance. No advanced methods are required—only that someone takes advantage of what was left open in the design.
This is where secure by design becomes concrete. The new regulations are not just about managing risk. They address recurring design flaws that appear again and again in real implementations, and they move responsibility to the point where those flaws can actually be eliminated: in the design of the IoT product.
Firmware updates without signing. Keys handled insecurely in software. Debug interfaces left open to simplify development and production.
This is not acceptable. It is covered by RED’s cybersecurity requirements, and it must be complied with. If a product does not meet the baseline requirements, it cannot be sold in the EU. This is no longer about what is technically appropriate. It is about regulation.
This is where secure by design moves from principle to requirement.
Security as a fundamental principle
At its core, it comes down to a few fundamental decisions. Cryptographic keys must be generated, stored, and used in a secure execution environment, not exposed in general-purpose software. Firmware must be signed and verified throughout the entire chain, from bootloader to application. Communication must be secured from the first packet, with authentication and protection against replay attacks —not just encrypted transport.
At the same time, physical interfaces such as UART, JTAG, or other debug ports must be treated as part of the attack surface and handled accordingly. They cannot be left as remnants from development. They must be secured.
These are architectural decisions. Once the product is deployed, it is often too late to correct them without significant redesign of hardware or software.
EN 18031 makes it concrete
Within RED’s cybersecurity requirements, EN 18031 defines what is required in areas such as access control, authentication, secure updates, protection of data and keys, and secure communication.
What is interesting is not that these areas are new, but that they are now formalised and testable. It is no longer enough to claim that a solution is secure—it must be demonstrated.
For many existing IoT products, this means the original architecture is not sufficient. For new products, it means the bar is significantly higher from the start.
Security across the lifecycle
With the Cyber Resilience Act, the time perspective also changes. An IoT product can no longer be considered finished at delivery. It must support secure updates, handle vulnerabilities when they are discovered, and enable incident reporting within defined timeframes.
At the same time, requirements linked to digital product passports extend traceability and data availability across the entire lifecycle. Even decommissioning becomes part of the security model, where sensitive information and cryptographic material must be handled and destroyed in a controlled way.
Security is no longer a property of the product. It is a continuous process that follows it from design to end-of-life.
Where the difference is made
It is easy to see this as added complexity in IoT. But it can also be seen as structure.
For those working close to the hardware, this is an opportunity to differentiate. By taking control of identity, key management, and update mechanisms already in the design phase, the need for late adjustments and external fix