EU Cyber Resilience Act: The Architecture It Forces (2026)

Q: When does the EU Cyber Resilience Act actually start applying?

In phases, and the first phase is sooner than most teams think. The CRA (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Its reporting obligations under Article 14 — the mandatory notification of actively exploited vulnerabilities and severe incidents — apply from 11 September 2026. The conformity-assessment-body notification provisions apply from 11 June 2026. The full essential-requirements regime, including secure-by-design duties, conformity assessment, technical documentation and CE marking, applies from 11 December 2027. The practical consequence is that "we will deal with the CRA in 2027" is wrong: the reporting duty is live from September 2026, and the capability it demands — detecting active exploitation, making a defensible severity determination within hours, and filing a 24-hour early warning to the right regulator — is a runbook and an on-call path that take longer than a few weeks to stand up. Sequence the reporting readiness first and build the 2027 conformity regime behind it.

Q: Does the Cyber Resilience Act apply to SaaS and cloud services?

Generally no, and this is the most common scope error. The CRA regulates "products with digital elements" placed on the EU market — software and hardware that ships code to the customer, such as commercial applications, firmware, connected devices and downloadable components. Pure software-as-a-service, where nothing is delivered to run on the customer's own systems, is largely outside CRA scope. That does not mean cloud services are unregulated: they typically fall under the NIS2 directive as an operator obligation, which is a separate regime with its own duties around risk management and incident reporting. The distinction matters because it changes who is liable and which artefacts you must produce. Building CRA conformity documentation for a pure SaaS product wastes effort on a regulation that does not cover it, while leaving the actual NIS2 obligations unmet. Determine first whether you ship a product or operate a service — many companies do both, in which case both regimes apply to their respective parts, and you map each obligation to the component it governs rather than running one blanket program.

Q: What SBOM does the CRA require, and does it have to be public?

The CRA requires manufacturers to draw up a software bill of materials in a commonly used, machine-readable format — in practice CycloneDX or SPDX — covering at least the product's top-level dependencies. It does not have to be published. The SBOM lives in your technical documentation and is provided to market-surveillance authorities on request, not posted for the world or handed to competitors. But it must be kept current across the entire support period and retained for ten years or the length of the support period, whichever is longer. Those two requirements — continuously current, decade-long retention — are what make a manually produced, once-off SBOM a fiction. A mid-sized product routinely depends on well over a thousand components across several gigabytes of build artefacts, and any of them can update weekly. The only workable architecture is to generate the SBOM in continuous integration, on every build, from the same dependency graph your package manager already resolves, and to store it as a versioned build artefact. Publishing the SBOM is a voluntary supply-chain-transparency choice with real merits, but do not confuse that choice with the legal duty, which is satisfied by a private, authority-accessible, continuously maintained bill of materials.

Q: What is the CRA incident and vulnerability reporting timeline?

Article 14 sets a three-stage clock that runs from the moment you become aware of an actively exploited vulnerability or a severe incident, not from when you finish fixing it. Stage one is an early warning within 24 hours: a short notification, via ENISA's single reporting platform, that you are aware of the issue. Stage two is a fuller notification within 72 hours: what you know, the severity, initial mitigations, and whether the vulnerability is being exploited. Stage three is a final report — for an actively exploited vulnerability, no later than 14 days after a corrective or mitigating measure is available; for a severe incident, within one month of the 72-hour submission. Notifications go to ENISA and your designated national CSIRT through the single reporting platform. Meeting the 24-hour deadline is an engineering-and-process problem, not a legal one: your organisation must be able to detect active exploitation, decide within hours that the threshold is met, and route the report correctly. The severity determination is a technical judgment you must be able to make quickly, under pressure, and defend afterwards — which is why the reporting duty is really an incident-response runbook with a legally binding deadline attached.

Q: How long is the CRA support period and what does it commit you to?

The support period must be at least five years, or the product's expected time in use if that is shorter than five years, and it must be clearly and understandably specified at the time of purchase. During that period the manufacturer must ensure vulnerabilities are handled effectively — which in practice means shipping free security updates promptly. This is a maintenance commitment with hard architectural implications. A product with no update mechanism, or one whose update requires the customer to manually re-flash firmware or reinstall, cannot credibly meet a five-year security-update obligation. The CRA is therefore, among other things, a mandate to build reliable update-delivery infrastructure — over-the-air or equivalent — into anything that ships code, along with the ability to reach every supported deployment. Declaring a support period you cannot technically honour is worse than declaring a short one honestly: it is evidence of a false declaration if you are later unable to deliver the promised updates. Teams should set the support period against what their update infrastructure and product economics can actually sustain, and invest in that infrastructure before making the commitment binding at point of sale.

Q: What are the penalties for CRA non-compliance?

Article 64 establishes a tiered penalty structure, and the top tier is severe. Non-compliance with the essential cybersecurity requirements in Annex I, or with the manufacturer obligations in Articles 13 and 14 (which include the vulnerability-handling and reporting duties), carries administrative fines of up to €15 million or, for an undertaking, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. A middle tier of up to €10 million or 2% of worldwide turnover applies to a range of other obligations, and a lower tier of up to €5 million or 1% applies to supplying incorrect, incomplete or misleading information to authorities. This is GDPR-tier exposure attached to product security, which is why the CRA has moved from an engineering footnote to a board-level concern. The turnover-percentage basis matters for larger companies: for a business with substantial revenue, the percentage figure exceeds the flat cap, so the fine scales with the size of the offender. The exposure is not theoretical paperwork risk — it is tied to whether the shipped product actually meets the essential requirements and whether the reporting duties are actually met, which is why treating the CRA as documentation rather than engineering is the expensive mistake.

Q: Does the Cyber Resilience Act apply to open-source software?

Mostly not to the development of it, but the exemption is narrower than "open source is exempt" suggests, and it does not shield your product. Non-commercial open-source software development — the work of individuals and communities not monetising the software — sits largely outside the CRA, and the regulation introduces a lighter "open-source software steward" regime for certain not-for-profit foundations and organisations that support open-source projects, with reduced duties compared to commercial manufacturers. What the exemption does not do is exempt commercial products built on open-source components. The moment you take open-source dependencies, integrate them, and place a commercial product on the EU market, those components are part of your product, their vulnerabilities are part of your attack surface, and handling and reporting them becomes your Article 14 obligation. Upstream being exempt does not make your downstream product exempt. The correct posture is to treat open-source dependencies exactly as you would any other component in your SBOM and vulnerability-handling process: inventory them, monitor them for vulnerabilities, and be able to ship updates when they are patched. The CRA effectively formalises the responsibility that commercial software has always had for the open-source code it ships.

Q: How should an engineering team sequence its CRA readiness work?

Cover the September 2026 reporting duty first, then build the 2027 conformity regime incrementally behind it, in five levels. Level 0 is unmapped: no one owns CRA scope and the team assumes 2027 — where most product teams sit today. Level 1 is reporting-ready and is the immediate target: you can detect active exploitation, make a defensible severity determination, and file a 24-hour early warning to your national CSIRT via the ENISA platform. This is a runbook, an on-call path and a decision rubric, buildable in weeks, and it is the only thing the 2026 deadline actually demands. Level 2 is inventory-ready: SBOMs generate in continuous integration on every build in CycloneDX or SPDX, so you can answer "is this component in any shipped product?" as a query. Level 3 is maintenance-ready: every shipped product has a declared support period backed by a working update-delivery mechanism, a monitored vulnerability-intake channel, and a coordinated-disclosure policy. Level 4 is conformity-ready: product classification is documented, essential-requirements evidence is assembled, the EU declaration of conformity is drafted, and any needed notified-body relationship exists, so CE marking is a formality on top of practices already running. Teams with a mature SOC 2 or supply-chain-security program will find Levels 2 and 3 mostly reuse existing controls, concentrating the CRA-specific work at Levels 1 and 4.

Satyam Kumar

Back to Blog

cyber-security-patterns

The Cyber Resilience Act Is a Product Security Contract, Not a Paperwork Exercise

By Satyam KumarAugust 26, 202613 min read

cyber resilience act cra regulation eu 2024/2847 sbom cyclonedx spdx vulnerability handling article 14 reporting ce marking product security coordinated disclosure support period enisa conformity assessment eu cyber regulation 2026

The Cyber Resilience Act Is a Product Security Contract, Not a Paperwork Exercise

Frequently Asked Questions

Share this article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI & Cloud Architect. Helping teams build systems that scale to millions.

LinkedIn GitHub

The Cyber Resilience Act Is a Product Security Contract, Not a Paperwork Exercise

Frequently Asked Questions

Share this article

Comments

Leave a comment