The first Cyber Resilience Act (CRA) deadline that touches product teams is 11 September 2026, when reporting obligations start. The main obligations follow on 11 December 2027. Reporting depends on process and people, and that is slow to build, so it comes before everything else.
What applies when
The CRA is Regulation (EU) 2024/2847. According to the European Commission's CRA page, it sets mandatory cybersecurity requirements for manufacturers across planning, design, development and maintenance of products with digital elements. It also requires manufacturers to handle vulnerabilities throughout the product lifecycle.
| Date | What happens |
|---|---|
| 10 December 2024 | CRA entered into force |
| 11 September 2026 | Reporting obligations apply |
| 11 December 2027 | Main obligations apply |
Compliant products will carry the CE marking, and national market surveillance authorities enforce the rules. Some products of particular relevance for cybersecurity may need a third-party assessment by a notified body before sale on the EU market. Work out early which side of that line your product sits on, because it changes your timeline.
The Commission also published practical guidance for manufacturers on 27 July 2026. Read it before you commit to a design for any of the processes below.
Secure development evidence
Regulators and customers will ask what you did, so build records as a by-product of normal work rather than reconstructing them later. A recognised structure helps.
The NIST Secure Software Development Framework, SP 800-218, is a core set of high-level practices that you add to whatever SDLC you already run. Its stated aims are fewer vulnerabilities in released software, less impact from the ones that remain, and fixing root causes so they do not recur. It also gives you a common vocabulary to use with buyers and suppliers. It is a US document and not a CRA checklist, so treat it as a scaffold.
Evidence worth keeping per release:
- the threat model or design review that covered the change
- code review and test results, including security tests
- dependency lists with versions, and what you decided about known issues in them
- the release approval, with a name and a date
CISA's Secure by Design material adds two practical points. Ownership should sit at executive level, and defaults matter: MFA, logging and SSO should be available out of the box at no extra cost. If your product sells these as paid add-ons, expect that to be questioned. CISA also publishes guidance on memory safe roadmaps, which is worth reading if your code is in C or C++.
Vulnerability handling and reporting
From 11 September 2026, manufacturers must report actively exploited vulnerabilities, along with the other items listed on the Commission's reporting page. Check that page for the exact scope and the channel to use. Do not rely on a summary, including this one.
What you need internally, whatever the final details:
- A single intake point. A monitored security contact on the product site and in the documentation, with a named owner and a deputy.
- A triage routine. Someone decides within a set time whether a report is valid, whether it is exploited, and which products and versions it affects. A consistent severity score makes this faster; our CVSS calculator is useful for agreeing scores in the team.
- A reporting decision path. Write down who decides that an exploited vulnerability triggers a report, and who files it. Rehearse it once with a fictional case, outside office hours if that is when it would really happen.
- A record of every decision. Including reports you judged out of scope, and why.
Reporting cannot work if you do not know what is inside your product. Keep a current component inventory for every shipped version, because you cannot assess exposure to a new vulnerability from memory.
Update processes
The Commission names the lack of timely security updates as one of the problems the CRA addresses. Products must be designed, updated and maintained to protect users. In practice that means testing your update path as seriously as your features.
Check the following on every product line:
- You can ship a security fix separately from a feature release.
- Customers can find out an update exists, and installing it does not need a support call.
- Old versions have a stated support end date that customers can see before they buy.
- For hardware, you have tested updating a device that has been offline for a year, and recovering one that fails halfway.
The common gap is not the technology but the ownership. Many teams can build a patch in a day and then spend three weeks finding who may release it.
Technical documentation
The sources I used do not list the required contents of the technical file, so take those from the legal text and the Commission's guidance. The practical point is that documentation should be assembled continuously from the evidence above, not written in the last quarter before the deadline.
Give each product a documentation folder or repository section with an owner. Put into it the design and risk assessment, the component inventory, test results, the vulnerability handling procedure and the update policy. Version it with the product. When an auditor or authority asks for a file, you want to export it, not commission it.
If you also fall under the NIS2 Directive, which the Commission says the CRA complements, reuse the same incident and vulnerability procedures rather than keeping two sets.
Where to start
- Read the Commission's 27 July 2026 guidance and the reporting page, and write down which of your products are in scope and whether any might need a notified body.
- Name an owner for vulnerability intake and exploited-vulnerability reporting, publish a security contact, and run one rehearsal this quarter.
- Produce a component inventory for each supported release and make generating it part of your build.
- Map your current SDLC against SSDF practices, record the gaps, and start retaining review, test and approval records per release.
- Test your update path end to end, and publish support end dates for each product.
- Create the per-product documentation folder and fill it from what you already have. If you want an outside view of the gaps, our consulting service and secure software development service cover exactly this.
