The European Commission has published a 66-page “FAQs on the Cyber Resilience Act” (FAQ Version 1.0, dated 03 December 2025). It’s a major milestone: the first substantial, official guidance we’ve had from Commission services on how the CRA is expected to be implemented in practice.
This post is a developer / business-focused breakdown of the biggest clarifications and the actions you can start taking now — without waiting for harmonised standards or a last-minute compliance scramble.
TL;DR
- Reporting starts before “full compliance”. The first operational deadline for many teams is vulnerability/incident reporting (September 2026).
- Security support has a floor. Your “support period” for vulnerability handling is at least 5 years (unless the product’s expected lifetime is shorter).
- “Actively exploited” is the reporting trigger. Including “zero-days” only if there’s evidence they’re exploited in the wild.
- Legacy products aren’t off the hook for reporting. Reporting obligations apply broadly, including many products already on the market.
- Supply-chain diligence is explicit. You can use third-party and open-source components, but you must do risk-based due diligence and you own the outcome.
- Conformity assessment isn’t one-size-fits-all. Some products can self-assess; others (important/critical categories) can require notified bodies and more formal routes.
The CRA timeline to put on your calendar
The FAQ makes it clear that CRA obligations arrive in phases — and the early phase matters a lot for operational readiness.
| Date | What kicks in | Why you should care |
|---|---|---|
| 10 Dec 2024 | CRA entered into force (transition period starts) | Time to build your compliance and reporting programme |
| 11 Jun 2026 | Articles 35–51 apply (Member States set up conformity assessment infrastructure) | Signals maturity of the ecosystem: notifying authorities, notified bodies, processes |
| 11 Sep 2026 | Reporting obligations apply (Article 14) | First hard operational deadline for many teams (reporting workflows + comms) |
| 11 Dec 2027 | Full CRA applies (essential requirements, market surveillance, enforcement) | The “big” compliance date for CE marking / conformity / documentation |
Practical takeaway: If you’re planning a programme, treat September 2026 as the “you must have a working process” deadline (reporting), and December 2027 as the “you must have a compliant product system” deadline (full CRA).
Support period: plan for at least 5 years of security fixes
The FAQ is direct: manufacturers must set a product support period for effective vulnerability handling. The support period must reflect expected use — but it’s also bounded by a minimum.
- Minimum support period: 5 years, unless the product is reasonably expected to be in use for less than five years.
- Not a “set it and forget it” number: if a product is reasonably expected to be used longer (common for infrastructure, hardware, platforms, operating systems), the support period should be longer.
- Document your reasoning: the inputs you used to determine the support period should be included in technical documentation.
Business impact: This drives pricing, packaging, and lifecycle decisions. If you sell “one-and-done” licences today, you’ll want to look hard at how you fund multi-year security updates (or how you structure subscriptions and paid support) while meeting CRA expectations.
Reporting: “actively exploited” is the trigger — and legacy products aren’t off the hook
The FAQ gives helpful clarity on what counts as an actively exploited vulnerability and when reporting is mandatory.
What counts as “actively exploited”?
In practice, it comes down to reliable evidence that a malicious actor has exploited the vulnerability in the wild. The FAQ also distinguishes this from good-faith testing and disclosure (e.g., bug bounty or lab testing), which shouldn’t automatically trigger mandatory reporting.
Do “zero-days” have to be reported?
Only if exploited. A zero-day without evidence of malicious exploitation is not automatically reportable (though voluntary reporting may be possible).
Does reporting apply to products already on the market?
Yes — this is one of the biggest operational implications. Reporting obligations apply broadly, including to many products placed on the market before the CRA’s main application date. The FAQ acknowledges the reality that older products may be difficult to investigate or patch (tooling gone, build environments unreproducible, staff moved on), but still expects notification when required.
Engineering takeaway: You need an “evidence → triage → notify” workflow that can operate even when patching is hard. Think of this as a muscle separate from your normal “ship a fix” pipeline.
Supply chain: due diligence is explicit (including open source)
The CRA doesn’t prohibit third-party components or open source — but it does make the integrating manufacturer’s responsibility crystal clear: you must exercise risk-based due diligence so that integrated components don’t compromise the cybersecurity of the final product.
Depending on risk, due diligence can include:
- checking whether a component bears CE marking (where applicable),
- reviewing security update history and maintainer responsiveness,
- checking known issues in vulnerability databases (including EU sources),
- and performing additional technical assessment (e.g., analysis, fuzzing, penetration testing) where warranted.
If you develop a patch for an integrated component, the FAQ indicates you may be expected to share it with the party maintaining that component.
Business takeaway: SBOMs, dependency governance, and supplier accountability aren’t “nice to have”. They’re becoming core risk controls for selling into the EU.
Conformity assessment: self-assessment vs notified bodies (classification matters)
The FAQ explains three main conformity assessment routes (in increasing formality):
- Module A — internal control / self-assessment
- Module B + C — EU-type examination + conformity to type (involves a notified body)
- Module H — full quality assurance system (notified body oversight)
Why classification matters: whether your product is “default”, “important”, or “critical” can materially affect which route you can take and how much time/money you should budget.
The FAQ points to the technical descriptions of categories of important and critical products and stresses a key principle: core functionality drives classification. Also, integrating an important/critical component does not automatically make your whole product important/critical.
Yes, software also needs CE marking
The FAQ clarifies that software products also need to bear the CE marking. For software, that can be done via the declaration of conformity and/or a website accompanying the software (with the relevant page easily accessible).
Standards roadmap: what’s coming (and why you can’t wait)
Harmonised standards are under development. The FAQ describes a split between:
- Horizontal standards (product-agnostic methodology + vulnerability handling), and
- Vertical standards (product-specific standards aligned to important/critical product categories).
Practical takeaway: Don’t wait for standards to “start”. Use the transition period to build the fundamentals now: risk assessment, secure development practices, vulnerability handling, testing strategy, and documentation. When standards land, you’ll be in a position to adopt them quickly and treat them as an accelerator.
A practical CRA readiness checklist (2026–2027)
Engineering
- Establish/refresh a cybersecurity risk assessment process that covers the whole product and is updated as conditions change.
- Implement dependency due diligence: SCA + SBOM workflows, vulnerability checks, and risk-based deeper testing when needed.
- Define a support period policy and ensure your build and release systems can patch for that long (reproducible builds, signing, update mechanism).
Security / Operations
- Create an “actively exploited” playbook (evidence threshold, triage, escalation, decision log).
- Stand up your reporting workflow well before 11 September 2026 (including customer/user communications when required).
Product / Commercial
- Align product lifecycle plans with the CRA support period expectation (pricing, renewals, EOL policy, customer messaging).
- Assess whether each product’s core functionality could fall into an important/critical category (this affects assessment route and cost).
Leadership / Compliance
- Decide your likely conformity path (Module A vs B+C vs H) and budget accordingly.
- Start building technical documentation early — treat it as an auditable product artefact, not a last-minute PDF.
Source
Official Commission FAQ (document redirection):
https://ec.europa.eu/newsroom/dae/redirection/document/122331
Disclaimer: This post is an implementation-oriented summary for builders and product/business teams, not legal advice. For binding scope/classification or conformity route decisions, involve your compliance function and counsel.
Categories: Developer Chat
greenchapel.dev 
Leave a comment