Key takeaways
- The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. Reporting obligations under Article 14 apply from 11 September 2026, and the full set of requirements from 11 December 2027.
- An actively exploited vulnerability triggers a three step clock: an early warning to your national CSIRT and ENISA within 24 hours, a full notification within 72 hours, and a final report within 14 days of a fix being available.
- Every product with digital elements needs a declared support period of at least five years, unless its expected lifetime is shorter, with free security updates for the whole period.
- Annex I Part II sets eight vulnerability handling obligations, one of which is a software bill of materials in a commonly used, machine readable format covering at least top level dependencies.
- Fines reach EUR 15 million or 2.5 percent of worldwide annual turnover, whichever is higher, for breaches of the essential requirements or of the Article 13 and 14 manufacturer obligations.
The Cyber Resilience Act in one block
The Cyber Resilience Act is the first EU law that regulates the cybersecurity of products rather than the security of organizations. If you place hardware or software with digital elements on the EU market, it applies to you, and it applies for years after the sale rather than at the point of shipment. Every figure below comes from the regulation itself or from the official legislative summary.
A common misconception is that the CRA is a 2027 problem. It is not. Article 14 reporting applies from 11 September 2026, and it applies to products already on the market, including ones you shipped years ago. The 2027 date governs conformity and CE marking. The 2026 date governs what happens the next time somebody exploits a vulnerability in code you shipped.
1. Secure by design becomes a legal property of the product
Under Article 13, manufacturers must design, develop, and produce products with digital elements so that they meet the essential cybersecurity requirements in Annex I Part I. That means secure default configuration, no known exploitable vulnerabilities at the point of placing on the market, and protection of the confidentiality and integrity of the data the product processes.
The practical shift is where security lives in your process. Annex I Part I is assessed at the moment the product goes on the market, which means the evidence has to exist before shipping, not after. You need a cybersecurity risk assessment for the product, it has to be documented, and it has to be part of the technical documentation you keep for ten years after placing the product on the market or for the length of the support period, whichever is longer.
If you already run an information security management system certified to ISO 27001, a good deal of the organizational scaffolding is in place. What is usually missing is the product level artifact. An ISMS proves your company manages security. The CRA asks you to prove that a specific version of a specific product does.
2. Vulnerability handling runs for the whole support period
Annex I Part II sets eight vulnerability handling obligations that run for as long as you support the product. They cover identifying and documenting vulnerabilities and components, remediating without delay, regular security testing, public disclosure of fixed vulnerabilities, a coordinated vulnerability disclosure policy, a public contact address for reports, secure update distribution, and security updates that are free of charge and shipped separately from feature updates.
The one that changes engineering practice most is the first. It requires a software bill of materials in a commonly used, machine readable format covering at least top level dependencies. "At least" is the floor. Because the SBOM has to reflect the product throughout the support period, treating it as a document you produce once for a release is the wrong model. It belongs in the build pipeline, regenerated with every build.
Then there is the support period itself. Article 13 requires you to determine it, communicate its end date to the buyer at the point of purchase, and set it at no less than five years unless the product's expected lifetime is genuinely shorter. Free security updates for five years is a commercial decision as much as a technical one, and it is one many product roadmaps have not priced in.
3. Reporting runs on a 24, 72, and 14 day clock from September 2026
Article 14 obliges manufacturers to notify actively exploited vulnerabilities and severe security incidents to the CSIRT designated by their Member State and to ENISA, simultaneously, through the CRA single reporting platform. The sequence has three steps.
The mistake most teams make here is reading the 24 hour figure as a deadline to report a resolved problem. It is not. It is an early warning obligation that starts when you become aware, which in practice means the moment a security researcher's email lands or your monitoring flags exploitation in the wild. Nobody has a fix in 24 hours. What you need in 24 hours is a named owner, a route to the reporting platform, and the authority to file without waiting for a legal review.
Micro and small enterprises are exempt from fines for missing the 24 hour deadline specifically, and open source software stewards sit outside the penalty regime. Neither exemption removes the obligation itself. If you already run incident reporting under the NIS2 requirements, the timing pattern will look familiar, but the trigger is different: NIS2 reporting follows incidents affecting your services, while Article 14 follows vulnerabilities in the products you sell.
4. Your product class decides who signs off
The CRA sets a risk based approach, but not the one the earlier drafts described. The adopted regulation uses three tiers above the default, listed in Annexes III and IV, and the tier determines your conformity assessment route under Article 32.
Note what the table does not say. There is no "highly critical" tier in the adopted text, and the majority of products with digital elements fall into the default category where self assessment is permitted. If a vendor or consultant tells you the CRA forces every connected product through a notified body, check which version of the text they read. Where multiple categories could apply to one product, the stricter class governs.
Classification is also not a one time exercise. Add a VPN feature to a product that previously sat in the default tier and the classification moves with it. Teams that treat product classification as a release gate rather than a legal opinion filed once tend to catch this before a substantial modification resets their obligations.
5. Third party components become your due diligence problem
Article 13 requires manufacturers to exercise due diligence when integrating components sourced from third parties, and to ensure those components do not compromise the product's security. Your dependencies are not somebody else's compliance problem any more.
In practice this is where the SBOM stops being paperwork and starts being useful. You cannot exercise due diligence on a dependency tree you have not enumerated, and you cannot answer a market surveillance request about a component you did not know you shipped. The obligation extends to open source components you pull in, though the upstream maintainers themselves are treated differently: open source stewards carry a lighter set of duties and sit outside the penalty regime, which means the responsibility for what you ship lands on you rather than on them.
The gap most product teams find here is contractual rather than technical. Dependency scanning is a solved problem. Having a route to a fix when a commercial supplier's component is the vulnerability, and having that route written into the contract before you need it, is not. If a supplier cannot commit to a disclosure timeline that fits inside your own 72 hour window, that is a procurement decision, not an engineering one.
Why December 2027 is tighter than it looks
Here is the part that rarely makes the summaries. The self assessment route for important class I products depends on applying harmonized standards in full, and those standards are still being developed. Notified bodies could only begin operating from 11 June 2026, when Chapter IV started applying. So the cheapest compliance route for a whole tier of products depends on standards that are not finished, assessed by bodies that have been in business for a matter of months.
Consider a 40 person company selling an industrial network monitoring appliance. It lands in important class I. If the harmonized standards for its product category are published and stable in good time, one internal owner at roughly half capacity can carry the technical documentation, the SBOM pipeline, and the disclosure policy through to conformity. If they are not, the same company is queuing for a notified body in 2027 alongside everyone else who made the same bet, and notified body capacity is finite.
That asymmetry is the argument for starting with the parts that do not depend on anyone else. Your SBOM pipeline, your vulnerability disclosure policy, your public contact address, and your support period decision are all fully within your control and none of them wait on a standard. Your Article 14 reporting runbook is the one with a hard 2026 date on it. Cost is driven far more by how much of this you have to build from nothing than by any assessment fee, and we have deliberately not put a euro figure on the assessment itself: notified body pricing for CRA scopes is not yet established enough to quote honestly.
None of that list requires a standards body, a notified body, or a harmonized standard to be finished. It is also the pattern to expect from here on: like the EU AI Act, the CRA regulates what you ship rather than how you run, and product teams now carry obligations that used to sit with a compliance function. The September 2026 date is a few weeks of preparation for most teams and a genuine liability for the ones that skip it. Start with the runbook.
Where Kertos fits
Kertos is a European compliance automation platform. For CRA work, the parts that map onto the platform are the ones that repeat: control evidence that has to stay current rather than be assembled before an assessment, policies that need version history and an owner, and the reporting and disclosure processes that need to exist in a form somebody can follow at 2am.
Where it matters most in practice is the overlap. Most companies facing the CRA are already carrying ISO 27001, and often NIS2 or a SOC 2 report as well. The ISO 27001 controls covering secure development, supplier relationships, and vulnerability management do real work against Annex I, and mapping them once rather than per framework is what keeps a small team from doing the same evidence collection four times. That is the same logic behind harmonizing a multi framework compliance program.
Kertos customers tend to describe the shift in commercial rather than compliance terms. One co founder puts it as compliance having "turned from a risk into a selling point", which is roughly what the CRA does to product security: it moves the CE mark on a connected product from a formality to something a procurement team will ask about.
If you want to see how the platform handles the evidence and control side of this, book a demo.
Frequently asked questions
When does the Cyber Resilience Act come into effect?
It entered into force on 10 December 2024. The reporting obligations in Article 14 apply from 11 September 2026, and the remaining obligations, including conformity assessment and CE marking, from 11 December 2027. Products placed on the market before 11 December 2027 fall under the full requirements only if they undergo a substantial modification, but Article 14 reporting covers them from September 2026 either way.
Who does the Cyber Resilience Act apply to?
Manufacturers, importers, and distributors placing products with digital elements on the EU market. That includes software sold on its own, not only connected hardware. Free and open source software supplied outside a commercial activity is out of scope, and open source software stewards have a lighter set of obligations and sit outside the penalty regime.
What are the penalties under the Cyber Resilience Act?
Article 64 sets a maximum of EUR 15 million or 2.5 percent of worldwide annual turnover, whichever is higher, for breaches of the essential cybersecurity requirements or of the manufacturer obligations in Articles 13 and 14. Other obligations carry up to EUR 10 million or 2 percent, and supplying incorrect or incomplete information to authorities up to EUR 5 million or 1 percent.
Does the Cyber Resilience Act require an SBOM?
Yes. Annex I Part II requires a software bill of materials in a commonly used, machine readable format covering at least top level dependencies, and it has to stay current for the whole support period. Full transitive dependency coverage is not mandated but is the safer position, since market surveillance authorities can request the SBOM you hold.
How long is the support period under the Cyber Resilience Act?
At least five years, unless the product's expected lifetime is shorter, in which case the support period matches that lifetime. You must determine the period, state its end date as a month and year at the point of purchase, and provide free security updates throughout. The technical documentation is kept for ten years after placing the product on the market or for the support period, whichever is longer.
