You have just been told your product needs to comply with the CRA. You opened Article 10, read 800 words of legal text, and not one line mentioned JTAG, secure boot, or a single thing you do at your bench.
This guide translates the EU Cyber Resilience Act Article 10 obligations into the hardware decisions an embedded engineer already recognises, and flags the dates that matter. By the end you will know what to change in your next firmware build, and which obligations sit with product or legal instead.
The CRA is the EU’s horizontal cybersecurity law for any “product with digital elements,” which means almost anything with software that connects to a device or network. As the manufacturer placing the product on the EU market, you hold the main obligations.
For the wider framing, see our CRA overview for product teams.
Key CRA dates at a glance
- 10 December 2024: CRA entered into force.
- 11 June 2026: rules on notified bodies start to apply.
- 11 September 2026: reporting of actively exploited vulnerabilities and severe incidents begins (Article 14).
- 11 December 2027: full obligations apply, including the Annex I requirements and CE marking.
Products already on the market before 11 December 2027 fall under the full requirements only if they undergo a substantial modification after that date. Reporting applies to all products on the market.
Why does Article 10 not match the regulation you are reading?
If you opened the Official Journal text and Article 10 turned out to be about skills and training, you are not losing your mind. “Article 10” comes from the 2022 draft proposal, where it was the manufacturer obligations article.
In the final law, Regulation (EU) 2024/2847, those obligations moved to Article 13, and the technical requirements live in Annex I, Part I. The search term stuck to the old number. The duties did not change in spirit.
So when this guide says Cyber Resilience Act Article 10, it means the manufacturer security obligations now codified in Article 13 and Annex I, Part I. That is what you have to build to.
Expect harmonised standards such as IEC 62443-4-2 and ETSI EN 303 645 to become the practical yardstick for meeting them.
What does “no known exploitable vulnerabilities” require at launch?
Annex I, Part I, point (2)(a) states a product must be placed on the market “without known exploitable vulnerabilities.” Known means known to you, including in the third-party and open-source components you ship.
You cannot ship a board with a CVE you already know about in your BSP, bootloader, or bundled libraries. The obligation bites at launch, then continues through the support period.
Before sign-off, a hardware team typically checks a few things:
- Scan the firmware image and SDK for known CVEs in the kernel, libc, TLS stack, and vendor BSP.
- Confirm no debug or evaluation firmware with known-weak components ships in the production image.
- Track third-party component versions so a late-breaking CVE can be caught before release.
If a known exploitable issue surfaces during qualification, it gets patched or the affected component gets removed before the product goes out.
How do you ship a connected device that is secure by default?
Point (2)(b) requires a “secure by default configuration,” including the ability to reset the product to its original secure state. The device must be safe the moment it powers on, before the user changes anything.
Default-open is now a defect, not a convenience. For a connected sensor or gateway, secure by default usually means:
- No shared or hardcoded default passwords. Force a unique credential or per-device secret at first boot.
- Unused ports, services, and radios disabled out of the box.
- Encrypted communication enabled by default, not an option buried three menus deep.
The factory-reset path must return the device to this same hardened state, never to an open one.
What counts as protecting a device from unauthorised access?
Point (2)(d) requires protection from unauthorised access through control mechanisms such as authentication and access management, and the ability to report possible unauthorised access. Every interface that can change state or read data needs an identity check and least-privilege scoping.
At the hardware and firmware layer, this looks like:
- Authentication on local and network interfaces, not only on the cloud API.
- Least-privilege partitioning so a compromised process cannot reach secrets or peripherals, for example using Arm TrustZone to isolate a secure world.
- Logging of failed access attempts so the device can report a possible intrusion.
The principle is that no interface grants more access than its job requires.
How do you reduce a hardware product’s attack surface?
Points (2)(j) and (2)(k) require designing the product to limit attack surfaces, including external interfaces, and to reduce the impact of an incident. Every exposed pin, port, and debug path is attack surface the regulation now expects you to justify or close.
This is the most directly hardware-facing obligation, and it maps to decisions you already make:
- Lock or disable JTAG and SWD in production builds, for example by blowing debug-disable fuses.
- Disable or physically remove UART consoles and debug headers before ship.
- Turn off unused interfaces, bootloader download modes, and test points.
Anything left enabled “for field debug” is surface you now have to document and defend.
What data protection does the CRA expect in hardware?
Points (2)(e) to (g) require protecting the confidentiality and integrity of stored and transmitted data, and processing only the data that is necessary, known as data minimisation. Code and configuration must also be protected from unauthorised modification.
For an embedded device, the practical controls include:
- Encrypt data at rest and use a current TLS configuration for data in transit.
- Use hardware secure boot so only signed, unmodified firmware runs, which satisfies the integrity requirement.
- Store keys in a secure element or protected key store, not in plain flash.
- Collect and retain only the sensor or telemetry data the product actually needs.
Secure boot and a hardware root of trust are the foundation most of these controls build on.
What makes an update mechanism CRA-compliant?
Point (2)(c) requires that vulnerabilities can be fixed through security updates, where applicable automatic and enabled by default, with a clear and easy opt-out. The device needs a working, secure update path for its whole support period, not a one-time factory flash.
A compliant over-the-air update path for a gateway or sensor generally needs:
- Cryptographically signed images, with signature verification anchored in secure boot before anything is applied.
- An anti-rollback strategy so a downgraded or failed update cannot brick or weaken the device.
- Secure transport for the update channel and real protection of the signing keys.
Without signed updates verified on the device, the rest of your security model collapses the first time you ship a patch.
What is a “secure development process” under the Cyber Resilience Act Article 10?
The requirements in Annex I sit on top of a cybersecurity risk assessment that Article 13(2) requires you to perform and document. You cannot pick controls at random.
The risk assessment decides which Annex I points apply and how far you take each one, and it lives in your technical documentation. In practice the process obligation means:
- Run and document a cybersecurity risk assessment that feeds your design decisions.
- Test and review the security of the product regularly, not only at launch.
- Keep technical documentation that shows how each requirement was met, ready for market surveillance authorities.
This is the connective tissue that turns individual controls into a defensible compliance position.
Does Article 10 get harder if your product is Class I or II?
Yes, but not in the way you might expect. The engineering obligations in Annex I are identical. What changes is how you have to prove you met them.
Most products self-assess using the internal control procedure (module A). If your product is an “important” product of class I or II, or a “critical” product, Article 32 limits or removes that option.
Class I important products can self-assess only if they fully apply harmonised standards, otherwise a notified body must assess them. Class II and critical products generally require third-party assessment.
Examples of important products include routers, password managers, and microcontrollers with security functions, listed in Annexes III and IV.
Which CRA obligations are not yours to own?
Some Article 10 era duties are not engineering tasks. They sit in Annex I, Part II on vulnerability handling, and they usually belong to product or legal, even though you will feed them the technical inputs.
Flag these to whoever owns product compliance, then keep building:
- A software bill of materials documenting components, required by Annex I, Part II (1).
- A coordinated vulnerability disclosure policy and a reporting contact, Part II (5) and (6).
- The end-of-support date and support period, declared at point of sale under Article 13 and Annex II.
- Incident and vulnerability reporting to ENISA and your national CSIRT from 11 September 2026, under Article 14.
You will supply the component list, the patch, and the impact assessment, but the policy and the filing usually sit elsewhere.
Frequently Asked Questions
Is CRA Article 10 the same as Article 13?
Not exactly. Article 10 was the manufacturer obligations article in the 2022 draft proposal. In the final Regulation (EU) 2024/2847, those obligations are in Article 13, with the technical requirements in Annex I, Part I. Article 10 in the final text covers skills and training.
When does the EU Cyber Resilience Act apply to hardware?
Full obligations apply from 11 December 2027. Vulnerability and incident reporting starts earlier, on 11 September 2026. The CRA entered into force on 10 December 2024.
Does the CRA require secure boot?
The CRA does not name secure boot. It requires data and code integrity and protection from unauthorised modification (Annex I, Part I, point (2)(f)). Hardware secure boot is the standard way to meet that on an embedded device.
Who has to comply with the Cyber Resilience Act?
The manufacturer placing a product with digital elements on the EU market holds the main obligations. Importers and distributors have supporting duties, and in some cases inherit the manufacturer’s obligations.
What happens if my product is an important or critical product?
You may lose the option to self-assess. Class I important products need a notified body unless harmonised standards are fully applied. Class II and critical products generally require third-party assessment.
Conclusion
The obligations behind “Article 10” now live in Article 13 and Annex I, Part I, and most of them map directly to hardware decisions you already make.
Locking down debug interfaces, shipping secure by default, signing your updates, and anchoring integrity in secure boot cover the bulk of the technical requirements.
SBOM, disclosure policy, and end-of-support sit with product and legal, but they depend on inputs only you can give.
Start with a documented risk assessment on your next build, because every other CRA requirement traces back to it.
IMAGE NAMING: cyber-resilience-act-article-10-hardware-checklist.jpg
- SVG
<title>: “CRA Article 10 hardware obligations checklist” - SVG
<desc>: “Checklist mapping EU Cyber Resilience Act Annex I Part I requirements to hardware design actions: no known vulnerabilities, secure by default, attack surface reduction, data protection, secure updates.”
