Cyber Resilience Act Readiness: What Applies on 11 September 2026

The 11 September 2026 Deadline: What Exactly Applies

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. It phases in over several years, and 11 September 2026 is the date a specific, narrow obligation goes live — not the full regulation. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting products with digital elements, under CRA Article 14. Nothing else in the CRA becomes enforceable on that date.

The rest of the timeline runs on its own schedule: Chapter IV notified-body provisions started applying on 11 June 2026, the main essential-requirements obligations become fully enforceable on 11 December 2027, and EU type-examination certificates issued before the CRA expire on 11 June 2028 at the latest. Treat 11 September 2026 as a reporting-readiness deadline, not a certification deadline.

Is Your Product in Scope?

• Your product is software or hardware with a direct or indirect logical or physical data connection to a device or network.
• It is placed on the EU market — including free products distributed commercially.
• If you sell SaaS: the CRA applies where your service is a *remote data processing solution* that is integral to a product with digital elements — not to every standalone cloud service. A self-contained SaaS product with no dependent hardware or software component is more commonly in scope under NIS2 instead. This distinction matters and is easy to get wrong — confirm your specific case rather than assuming either way.
• It is not a medical device, in-vehicle/aviation product, or another product already regulated under sector-specific EU legislation with equivalent cybersecurity requirements — exempt from the CRA, but not from its own sectoral rules.
• It is not open-source software maintained on a genuinely non-commercial basis — commercially monetised open source, including dual-licensing and paid-support models, is in scope as an 'open-source software steward.'
• If you can't confidently tick every line above, don't assume you're exempt — CRA scope determinations are frequently wrong in both directions.

Reporting Timeline: 24 Hours, 72 Hours, 14 Days

These are the Article 14 timelines that actually apply from 11 September 2026. There is no fixed "testing frequency" mandated by the CRA — the obligation is to detect, assess and report, not to run a test on a specific schedule.

What You Cannot Do Yet

Some of the infrastructure the CRA assumes will exist is not fully in place yet. As of mid-2026: the harmonised standards that would give manufacturers a presumption of conformity have not been published in the Official Journal; no conformity assessment body has been notified under the CRA in the NANDO database; and ENISA's single reporting platform is targeted to be operational by 11 September 2026 itself, which is an uncomfortably tight timeline.

Practical consequence: build your internal vulnerability-handling process now, but understand that third-party conformity assessment for critical-class products is not yet operationally available, because the bodies that would perform it don't exist yet. Anyone offering a finished, notified-body-certified CRA compliance package today is getting ahead of the regulation.

Practical Preparation Checklist

• Inventory every product with digital elements you place on the EU market, including free tiers and SaaS.
• Determine your role for each product: manufacturer, importer, or distributor — obligations differ.
• Classify each product: default, important (Class I or II), or critical, under Annex III.
• Build or acquire a Software Bill of Materials (SBOM) for each product.
• Document your vulnerability-handling process end-to-end: intake, triage, fix, disclosure.
• Identify who in your organisation makes the 24-hour reporting call, and write it down.
• Draft notification templates now — the 24/72-hour clock shouldn't start with a blank page.
• Review supplier and component contracts for vulnerability-disclosure and patching commitments.
• Run a vulnerability assessment or penetration test to establish your current baseline — you can't report what you haven't looked for.

How Security Testing Fits CRA Preparation

The CRA does not say the words "penetration test." But Annex I, Part II, point 3 requires manufacturers to apply effective and regular tests and reviews of the security of the product with digital elements — regular security testing is an explicit obligation here, not an inference. The regulation doesn't prescribe a specific method or frequency, so a penetration test or a vulnerability assessment both qualify; what matters is that the testing is regular, evidenced, and documented.

Separately, the CRA also says you must be able to detect and report actively exploited vulnerabilities within 24 hours of becoming aware of them. Different obligation, same practical requirement: you need to know your product's vulnerabilities before an attacker — or a regulator — finds them for you.

The chain is short: from 11 September 2026 you must report actively exploited vulnerabilities within 24 hours → to report one, you first have to know it exists and that it's being exploited → knowing that requires an up-to-date component inventory (SBOM), a working vulnerability-handling process, and a recent, independent look at where your product's weaknesses actually are → a company that has never tested its own product will reach September 2026 with a legal obligation and no operational way to fulfil it.

A fixed-price Vulnerability Assessment is the minimum viable starting point: a dated, evidenced baseline you can point to, and the fastest way to close the gap between "we have an obligation" and "we have a process."

Penalties