./cra/readiness --check
CRA readiness check
Everything the Cyber Resilience Act asks of a manufacturer of a connected product, as one checklist. Answer three questions, tick what you already have, and take the gaps to your next planning meeting.
cat ./product.conf
Is the product already sold in the EU?
Which CRA category is it in?
Most sensors, trackers and controllers are default. Annex III lists important products, such as routers, smart locks, cameras and operating systems. Annex IV lists critical ones, such as smart meter gateways. Not sure the CRA covers it at all? Run the scope check →
How big is the company?
Small means fewer than 50 people and no more than €10 million turnover or balance sheet.
grep todo ./readiness.md | head -5
Your next five steps
date --since 2026-09-11
Applies now
Since 11 September 2026 you must report actively exploited vulnerabilities and severe incidents for every product on the EU market, units sold years ago included.
Reporting readiness · Art. 140/7
Register on ENISA's Single Reporting Platform
Personal EU Login accounts with multi-factor authentication for the people who will submit reports, and your company verified on the platform. One primary and up to twenty secondary representatives.
Name who makes the call, and who covers
One person decides that a vulnerability is actively exploited or that a severe incident happened, with a deputy for holidays and weekends. Write down the steps from first signal to early warning so they work at two in the morning.
Know what runs where
For every product: which firmware versions are in the field and in which Member States it is sold. The early warning asks for the countries, and you cannot assess exposure without the versions.
Watch your components for exploitation
Keep an SBOM for every release and check it daily against lists of vulnerabilities exploited in the wild, such as CISA KEV and ENISA's EUVD. A match does not start the clock by itself, but it is the signal to assess your product the same day.
Be able to notice a severe incident
Logs and alerts on the backend, the update server and the signing infrastructure. A stolen signing key or a compromised update server is a severe incident, and you can only report what you can see.
A way to reach affected users
After you become aware, impacted users, and where appropriate all users, must be told about the issue and what they can do. Know in advance whether that is an email list, a customer portal, an in-app message or a call to your B2B customers.
A published vulnerability contact
Formally required from December 2027, but without it nobody can tell you about a problem today. A security.txt file and a short disclosure policy take an hour.
date --until 2027-12-11
For every unit placed on the market from 11 Dec 2027
The test is per unit, not per model. A device that leaves your warehouse on 12 December 2027 must meet all of this, even if the model has been on sale for years.
Risk assessment · Art. 130/2
Documented cybersecurity risk assessment
Based on intended purpose, reasonably foreseeable use, operating environment, the assets to protect and how long the product will be in use. Include your cloud backend, which counts as part of the product. It drives every decision below.
Each Annex I requirement implemented or justified
For every point of Annex I Part I below, the assessment says how it is met or why it does not apply. A requirement silently skipped is the easiest finding for a market surveillance authority.
Product security · Annex I Part I0/13
No known exploitable vulnerabilities at release
Scan the release SBOM before it ships and fix or justify every exploitable finding. Firmware that sits in a warehouse for months needs a check before it goes out.
Secure by default, with a reset
No shared default passwords, debug and unused services off, the safest settings out of the box, and a way to reset the device to its original state.
Security updates, automatic by default
Where applicable, updates install automatically by default within an appropriate time, with a clear opt-out, notification of available updates and the option to postpone them.
Protection from unauthorised access
Per-device credentials, mutual TLS to the backend, authentication on every local interface, and a record of possible unauthorised access such as failed logins.
Confidentiality of data
Current TLS in transit, and sensitive data and secrets encrypted at rest, for example with flash encryption or a secure element.
Integrity of data, commands, firmware and configuration
Secure boot, signed firmware images, authenticated commands and configuration, and a report when corruption is detected.
Data minimisation
Collect and process only the data the product needs for its intended purpose, personal or otherwise.
Essential functions stay available
Also after an incident: watchdogs, rate limits, resilience to denial of service, and sensible behaviour when the backend is unreachable.
No harm to other devices or networks
Reconnects with backoff and jitter, no retry storms, and nothing that turns ten thousand devices into a flood against someone else's service.
Limited attack surface
Debug ports such as JTAG and UART locked in production, no open ports you do not need, no test endpoints left in the firmware or the API.
Exploitation mitigations
Stack protection, memory protection or non-executable regions where the hardware allows, and least privilege between tasks and services.
Security logging, with an opt-out
Record and monitor relevant internal activity, such as access to or changes of data, services or functions, and let the user opt out.
Secure, permanent data removal
Users can easily and permanently remove all data and settings, and any transfer of data to another product or system happens securely.
Vulnerability handling · Annex I Part II0/9
SBOM for every release
In a common machine-readable format such as CycloneDX or SPDX, covering at least the top-level dependencies. Generate it in the build, not by hand.
Fix without delay, security separate from features
Address vulnerabilities without delay according to risk and, where technically feasible, ship security updates separately from functionality updates.
Regular security tests and reviews
Effective and regular, for example dependency scanning in CI, a yearly penetration test of device and backend, and a review before major releases.
Publish advisories for fixed vulnerabilities
Once an update is out: what the vulnerability is, which products and versions are affected, impact, severity and how to fix it. Publication can wait until users have had the chance to patch.
Coordinated vulnerability disclosure policy
Written, published and actually followed: how reports are received, acknowledged, fixed and disclosed.
Single point of contact
Easy to find, lets people choose how to reach you and is not limited to automated tools. It also takes reports about third-party components in your product.
Secure update distribution
Signed images over an authenticated channel, with rollback protection, so fixes reach the fleet in a timely manner and, where applicable, automatically.
Free updates, with advisories
Security updates go out without delay and free of charge (unless agreed otherwise for a tailor-made B2B product), with a message telling users what to do.
Due diligence on third-party components
Check that libraries, SDKs and modules you integrate do not compromise the product, open source included. When you find a vulnerability in one, report it to its maintainer and share your fix.
Support period · Art. 130/3
Support period set and justified
At least five years, longer if the product stays in use longer. A meter on a wall for fifteen years needs fifteen. Document what you based the decision on.
End of support shown at purchase
At least month and year, clearly visible when buying. Where technically feasible, the product tells users when support has ended.
Keep every security update available
For at least ten years after release or the rest of the support period, whichever is longer. Plan storage and signing keys for that horizon.
User information · Annex II0/2
User information pack
Manufacturer contact, vulnerability contact and CVD policy, product identification, intended purpose and security properties, foreseeable risks, where to find the declaration of conformity, support end date, secure setup, how to update and how to turn off automatic updates, secure decommissioning, and what integrators need. Online is fine if it stays up for ten years.
Identification and contact on the product
Type, batch or serial number on the product, plus manufacturer name, postal address and a digital contact on the product, its packaging or an accompanying document.
Conformity · Art. 28–320/6
Technical documentation
Product description (with photos of the hardware), architecture, vulnerability handling with SBOM, CVD policy and update distribution, production and monitoring, the risk assessment, support period rationale, standards applied, test reports and the declaration of conformity. Keep it current during the support period.
Plan the conformity route, likely with a notified body
Class I can use self-assessment only when harmonised standards, common specifications or a certification scheme at level substantial are applied in full. Otherwise, and always for class II, it is EU-type examination (B+C) or full quality assurance (H). Critical products may need a European certificate. Notified bodies could start from 11 June 2026, and their calendars will fill up before December 2027.
EU declaration of conformity
One declaration covering every EU act that applies, for example the CRA together with the Radio Equipment Directive. Ship a copy, or a simplified declaration with the exact web address of the full one.
CE marking
Visible, legible and indelible on the product before it is placed on the market, or on the packaging and declaration when that is not possible. For software, on the declaration or the product website.
Series production stays compliant
A procedure that catches design, production or standards changes, so unit ten thousand is as compliant as unit one.
Keep the file for ten years
Technical documentation and the declaration stay available to authorities for ten years after placing on the market, or for the support period if that is longer.
while support_period; do
For as long as support lasts
Compliance is not a one-off. These run for the whole support period.
Lifecycle0/3
Keep the risk assessment and documentation current
Record vulnerabilities you learn about and what third parties tell you, and update the assessment and technical file when they change the picture.
Act on non-conformity
If you learn the product or your processes do not meet Annex I, fix it immediately, or withdraw or recall the product.
Watch for substantial modifications
Units placed on the market before 11 December 2027 stay outside the design requirements, but a substantial modification after that date brings them into full scope. A security patch alone is generally not one.
./start_project.sh --scope=cra
Turn the gaps into a plan
I help small hardware teams close exactly these items: SBOMs in the build, signed OTA, secure boot, vulnerability monitoring and the technical file, without hiring a compliance department.
# runs in your browser · answers are saved only on this device
Engineering guidance, not legal advice. Based on Regulation (EU) 2024/2847 and the Commission guidance of July 2026. Harmonised standards are still being finalised and may refine how individual requirements are met.