The Commission's CRA FAQ and Guidance: What Actually Changed in July 2026

2026-08-14 · Updated 2026-09-17 · Yunus Yildiz

Updated 17 September 2026. The Commission published FAQ version 1.4 on 4 September 2026. It adds FAQ 5.5: through Article 24(3), open-source software stewards are subject to the reporting obligations in Article 14(1), (3) and (8) under certain circumstances, and Article 24(3) applies from 11 December 2027.

Context

The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Its reporting obligations bind from 11 September 2026 and most of the remaining obligations from 11 December 2027. Between those two dates, the open question for manufacturers has been less "what does the text say" and more "how will it be read in practice."

In July 2026 the European Commission gave two partial answers to that.

What was published

There are two distinct documents, and it is worth keeping them apart.

1. The implementation FAQ — last updated 2 July 2026. The Commission maintains a Cyber Resilience Act implementation — Frequently Asked Questions page. First published on 3 December 2025, it carries a "Last update: 2 July 2026" marker. It is a technical FAQ compiled by the Commission services from recurring questions collected since the CRA entered into force — a short, evolving reference rather than a comprehensive treatment.

2. The application guidance — 27 July 2026. Separately, the Commission published its first official guidance on applying the CRA. This is the more substantial document. It develops the Commission's position on the scope of software products and spare parts, on what counts as a substantial modification, on how support periods should be understood, and on the reporting obligations, with worked examples aimed particularly at microenterprises and SMEs.

Reality check: what this is, and is not

Neither document is law. The binding text is the Regulation; the FAQ and the guidance are the Commission services' interpretation of it. They are not adopted acts and they do not bind national market surveillance authorities or courts.

That said, they are the clearest signal available of how the institution that drafted the CRA reads its own harder edges — and in a regime where the first enforcement questions will turn on scope and classification, that signal is worth reading closely. Where the guidance says a case is in or out of scope, a manufacturer taking the opposite view should expect to have to defend it.

What it clarifies that was genuinely unclear

A few of the recurring interpretation problems the July material speaks to:

• Scope of software. Which software products fall under the CRA, and how standalone software, software-as-a-service boundaries and spare parts are treated.
• Substantial modification. When a change to an already-placed product re-triggers conformity obligations — the question that decides whether a routine update is a compliance event.
• Support period. How to determine the period during which a manufacturer must handle vulnerabilities, and how it interacts with the expected product lifetime.
• Reporting. Further detail on the 24-hour / 72-hour / 14-day reporting clock that binds from 11 September 2026, routed through the CRA Single Reporting Platform to the relevant CSIRT with ENISA in parallel. (Section 9.1 of the guidance and Section 5 of the FAQ.)
• Boundaries with adjacent law. How the CRA sits alongside other EU instruments its scope brushes against — the questions manufacturers keep raising about overlap with existing product and data regimes.

Engineering implications

For teams that build or ship products with digital elements, the practical value is narrower than the headlines suggest. Two things are worth acting on now:

1. Re-run your scope and classification analysis against the guidance. If your earlier assessment relied on a favourable reading of "substantial modification" or of the software/service boundary, check it against the Commission's stated position before you rely on it in a technical file.
2. Wire the support period into your process, not a spreadsheet. The support period is where vulnerability-handling obligations live. Determining it once is easy; keeping the evidence that you handled vulnerabilities across it, per product and per version, is the operational load — and the reporting clock starts the moment you become aware, not when you finish investigating.

Limits

This is guidance, not certainty. It can be revised, it does not settle every edge case, and the parts most people want — the exact line on scope for their specific product — are still, deliberately, examples rather than rules. The FAQ in particular is explicitly an evolving document; the "2 July 2026" date is a checkpoint, not a final word.

Key takeaways

• Two July 2026 documents: an updated implementation FAQ (2 July) and the first official application guidance (27 July). Keep them distinct.
• Neither changes the law. Both narrow how the Commission services read it — usefully, on scope, substantial modification, support periods and reporting.
• The dates that bind are unchanged: reporting from 11 September 2026, most obligations from 11 December 2027.
• If the CRA is on your roadmap, the highest-value move is to re-test your own scope and support-period assumptions against the guidance now — while there is still time to be wrong cheaply.

Primary sources: the Commission's CRA implementation FAQ and its application guidance. The full text of the Regulation is mirrored in the CRA library.