Designing connected products for EU and UK cybersecurity rules

Cybersecurity is now part of getting a connected product onto the market in Europe and the UK, like emissions and safety. For a hardware team, the key point is that much of what these rules call for depends on parts chosen in the concept phase: the processor, the memory, the way keys are stored. Those are cheap to get right at the start and expensive to change after layout.

This article covers what to build in. For which approvals apply in each market, see Compliance by market, and for when compliance work belongs in a project, see Plan for compliance from day one. It is not legal advice: scope and details depend on your product, and these rules are still settling.

The three regimes in brief

EU Radio Equipment Directive (RED), cybersecurity delegated act. Since 1 August 2025, Delegated Regulation (EU) 2022/30 has applied cybersecurity requirements to radio equipment that can communicate over the internet, directly or through other equipment such as a phone app or gateway. Radio toys, childcare products, and wearables that can process personal data are also covered, even without an internet connection. The harmonized standards EN 18031-1, -2, and -3 give a presumption of conformity, with restrictions. One matters for most designs: if your product lets the user skip setting a password, the standard does not give a presumption of conformity on that point, so you would need a notified body (EU-type examination or full quality assurance) instead of self-declaring.

EU Cyber Resilience Act (CRA). Regulation (EU) 2024/2847 covers most products with software and a data connection, radio or not. Its reporting duties have applied since 11 September 2026: manufacturers must report actively exploited vulnerabilities and severe security incidents through ENISA’s single reporting platform, with an early warning within 24 hours of becoming aware, including for products already on the market. Its full requirements apply from 11 December 2027, when the RED delegated act is repealed and the CRA takes over. Harmonized standards for the CRA are still being finalized at the time of writing. Products the CRA lists as “important,” such as routers, smart locks, security cameras, baby monitors, connected toys with social or location features, and wearables for health monitoring or for children, can self-assess only by fully applying harmonized standards, common specifications, or a European cybersecurity certification scheme, and no harmonized standards have been cited yet. Higher-risk categories need a third party. Annexes III and IV of the CRA define the categories. Some sectors with their own rules, such as medical devices and vehicles, are outside the CRA.

UK PSTI regime. Since 29 April 2024, consumer connectable products sold in the UK must meet three requirements: no universal default passwords, a published way to report security issues, and a published minimum period of security updates. A statement of compliance ships with the product. Some product types are exempt.

Every unit placed on the EU market from 11 December 2027 must meet the CRA, so if you will still be shipping the product then, it makes sense to design for the CRA now even if the RED is what applies on launch day.

What the rules ask for, and what you build to meet them

The regulations mostly state outcomes. The CRA asks, for example, that a product protect its programs and configuration against unauthorized changes, ship with a secure default configuration, limit its attack surface, and accept security updates. It does not say “use secure boot” or “fit a secure element.” Those are engineering choices you make to meet the outcomes and to show in your technical file that you did.

No universal default passwords

This is required in the UK under PSTI. In the EU, it is how the harmonized standard EN 18031 meets the RED requirement, and the CRA’s secure-by-default and authentication requirements point the same way. Each unit needs either a unique password or one the user sets during setup. Under PSTI, a unique password must not be based on an incrementing counter or on public information, and must not be derived from an identifier such as the serial number or MAC address unless that is done with a keyed cryptographic function accepted as good practice. In practice this means generating a random credential per unit in manufacturing, and printing it on a label or loading it into the device. Plan the label, the provisioning step, and the factory reset behavior together.

Secure boot and signed firmware

The rules ask that code not be modified without authorization. The usual way to meet that is a boot chain that verifies a signature on each firmware image before running it, rooted in an immutable boot ROM and a public key or key hash in one-time-programmable memory. Not every microcontroller can do this, so it belongs on the part-selection checklist, next to flash size and price.

Secure updates, with recovery

Being able to fix vulnerabilities in the field is a core requirement of the CRA, and the CRA asks that security fixes be separable from feature updates where technically feasible. Where it applies, the CRA also asks for automatic security updates enabled by default, with a clear way to opt out, a notice when updates are available, and an option to postpone them. On a product with no screen, plan how that works through the app.

Build the update path to:

• Verify the signature before installing.
• Keep a known-good image, in a second flash bank or as a recovery image, so a failed or interrupted update does not brick the unit.
• Refuse to roll back to older, vulnerable versions, typically using a monotonic counter. Advance the counter only after the new image has booted and confirmed itself, so the recovery image is never one the bootloader refuses.

Two full images roughly double the flash the firmware needs; a small recovery image, or staging updates in external SPI flash, costs less. Either way it is a part-selection and schematic decision.

Secure key storage

Identity keys and credentials need somewhere an attacker with the board on the bench cannot simply read them. The options, roughly in order of strength:

• A secure element: a separate chip that holds keys and does cryptography without exposing them.
• An MCU with a hardware key store, often behind Arm TrustZone isolation, that can use keys without exposing them to the application.
• OTP or protected flash in an ordinary MCU, with readout protection enabled. Readout protection on many general-purpose MCUs has been bypassed with voltage glitching, so weigh that against your threat model.

Which is enough depends on your risk assessment, which the CRA requires you to document in the technical file. The decision affects the BOM, the board, and the provisioning flow.

Debug ports locked in production

An open JTAG or SWD port lets anyone read and replace the firmware, which undoes everything above. Lock or disable debug access in production units, using the chip’s readout protection or debug authentication. Decide early how you will analyze returned units; some chips support authenticated debug for this reason.

Secure provisioning in manufacturing

Unique keys and credentials have to be generated and loaded on the production line, and the firmware signing key must never sit on a line PC. Options include provisioning by the chip vendor or distributor, a secure element that arrives pre-provisioned, or a provisioning station with a hardware security module. This is part of the manufacturing package, and it is easier to set up with the contract manufacturer before the first production build than during it.

A smaller attack surface

Required by the CRA in general terms, and good practice anywhere. Ship with unused services, ports, and radios turned off. Remove test commands, factory shells, and debug logging from production builds. Authenticate every interface that can change the device’s behavior, including local ones like a BLE configuration service.

Data protection

Encrypt data in transit, and encrypt sensitive data at rest. Collect only the data the product needs. The CRA also asks for a way for users to securely remove all their data and settings, so make sure factory reset actually erases credentials and personal data, not just a flag.

Beyond the hardware

Several requirements are process rather than design, but they shape the design:

• An SBOM. The CRA requires a machine-readable software bill of materials covering at least the top-level dependencies. Generate it from the build so it stays current; it is how you will tell whether a new vulnerability affects you.
• A vulnerability disclosure policy. Both the CRA and PSTI require a published contact for reporting security issues. The CRA also requires a coordinated disclosure policy and timely fixes.
• A defined support period. PSTI requires you to publish the minimum period of security updates, and you cannot shorten it afterward. Under the CRA, the support period must reflect how long the product is expected to be in use, and must be at least five years unless that expected use time is shorter. The end date, at least month and year, must be clear at the time of purchase.
• A way to meet the reporting deadlines. Someone has to watch for exploited vulnerabilities and incidents and be able to file an early warning within 24 hours. Device logs and field telemetry help you tell what happened.

Plan the update lifetime

A support period is a promise that has to be kept with real hardware and real infrastructure. Before committing to one, check that:

• The processor, radio stack, and any third-party libraries will get security fixes for that long, or that you can maintain them yourself.
• The flash has headroom for future fixes, not just today’s image.
• The cryptography and certificate lifetimes will not expire before the support period ends.
• Someone will own the signing keys, the build environment, and the update server for the whole period.
• Each security update stays available for at least 10 years after release, or the rest of the support period if longer (CRA).

What to build in, and when

1. Concept

   Hardware selection

   • MCU or SoC with secure boot
   • Secure key storage: secure element, TrustZone, or OTP
   • Flash sized for two images, or a recovery image
   • Debug ports that can be locked
2. Design

   Firmware

   • No universal default password
   • Signed images, verified at boot
   • Signed updates with recovery and rollback protection
   • Only the interfaces and services you need
   • Encrypted communication; minimal data; factory reset that erases
3. Pre-production

   Manufacturing

   • Per-device credentials and keys
   • Signing keys kept off the line
   • Debug locked before shipping
   • Records that tie each unit to its identity
4. For the support period

   After launch

   • Published vulnerability contact and policy
   • Stated support period
   • SBOM kept current with each release
   • Security fixes shipped promptly
   • Exploited vulnerabilities reported within 24 hours

The short version

Design for the CRA if you will still be shipping the product after December 2027. Choose a processor with secure boot and secure key storage, and leave flash for a recovery image. Remove universal default passwords, lock debug ports, and plan per-unit provisioning with your contract manufacturer. Set up the SBOM, disclosure policy, and support period before launch, and make sure you can keep the update promise.

If you are planning a connected product for the EU or UK and want help building security into the design from the start, get in touch.