Most UK manufacturers tracking the EU CRA are watching one deadline. In fact, there are three, and they don’t land the same way. Compliance with the EU Cyber Resilience Act can be managed with the help of a checklist, enabling manufacturers to monitor the key stages and to plan for the compliance requirements in time. Conformity assessment body provisions apply from June 11, 2026. Vulnerability and incident reporting obligations start September 11, 2026, and they apply to products already sitting on shelves, not just new releases. Full compliance, including CE marking, doesn’t land until December 11, 2027. This is the date from which the CRA’s main manufacturer obligations become fully applicable, including the core product cybersecurity, vulnerability-handling, conformity-assessment, technical documentation, and CE-marking requirements.
Get the sequencing wrong, and you’ll either scramble in September because you thought you had until 2027. Or you’ll over-invest in conformity assessment work eighteen months before authorities actually enforce it. The CRA establishes maximum administrative-fine levels for certain infringements, including fines of up to €15 million or 2.5% of the infringing manufacturer’s total worldwide annual turnover for the preceding financial year, whichever is higher, subject to the regulation’s specific provisions and exemptions.
What Counts as a Product with Digital Elements Under the EU CRA?
Certain software components placed separately on the Union market can fall within the CRA’s scope where they meet the definition of a product with digital elements. Whether a particular open-source or commercial component is covered depends on how it is made available and the applicable CRA scope rules.
EU CRA Product Risk Categories: How Will You Be Assessed?
The EU CRA distinguishes ordinary products with digital elements from specified important products in Class I and Class II and certain critical products. Classification depends primarily on whether the product has the core functionality of a category listed in Annex III or Annex IV, rather than simply on the manufacturer’s own assessment of its cybersecurity risk.
Password managers and firewalls are examples of important products covered by Annex III, with password managers in Class I and firewalls in Class II. Critical products are separately identified under Annex IV and include categories such as certain hardware security devices, smart-meter gateways and smartcards or secure elements.
Important products in Classes I and II are subject to additional conformity-assessment requirements. The exact route depends on the product class and, for Class I products, on the applicable harmonised standards, common specifications or cybersecurity certification arrangements.
Ultimately, getting this classification wrong at the start of a product’s development cycle is the single most expensive mistake to unwind later. That’s because the documentation trail differs depending on which tier applies. Consider a team that builds its technical file assuming self-assessment. If a notified body later needs to review it, that team is often looking at months of rework, not a quick reclassification. It’s worth settling this question with legal and engineering input together, early, rather than defaulting to whichever tier seems administratively lighter.
Conduct a CRA Cybersecurity Risk Assessment
Classification tells you which conformity route applies. It doesn’t tell you what the product actually needs to defend against, or which Annex I requirements are relevant to it and which aren’t. That’s what the risk assessment is for, and Annex I requires manufacturers to carry one out and keep it current for the life of the product. Treated properly, it’s the document that everything else in the technical file traces back to: secure-by-design choices, SBOM scope, support period, incident reporting readiness.
A CRA cybersecurity risk assessment should cover:
- Intended purpose – what the product is designed to do, and in what setting it’s meant to be deployed
- Reasonably foreseeable use – how the product is likely to actually be used, including misuse a manufacturer should anticipate even if it isn’t the documented intended use
- Operational environment – the network, physical, and organisational context the product will run in, since the same vulnerability carries different risk on an isolated industrial network than on an open internet-facing deployment
- Assets to protect – the data, functions, and system access the product handles or exposes
- Threats – the realistic threat actors and attack paths relevant to the product’s category and environment
- Vulnerabilities – known and reasonably anticipated weaknesses in the product’s design, dependencies, and configuration
- Impact – the consequence if a given threat exploits a given vulnerability, covering safety, data, and availability
- Applicable Annex I requirements – mapping which essential requirements are actually engaged by the product’s risk profile, so the technical file can show why a given control was or wasn’t implemented
- Residual risk – what’s left once mitigations are in place, and whether that remaining risk is acceptable and defensible
- Updates during the product lifecycle – the risk assessment isn’t a one-off document. It needs to be revisited when the threat landscape shifts, when a new vulnerability is disclosed in a dependency, or when the product’s use in the field turns out to differ from what was originally foreseen.
Skipping this step means the risk assessment gets reconstructed retroactively, usually under time pressure, once a notified body or market surveillance authority asks to see it.
The EU Cyber Resilience Act Checklist: 21 Essential Requirements
Annex I sets out the CRA’s essential cybersecurity requirements. They cover both the security properties of products with digital elements and the manufacturer’s vulnerability-handling processes. Referencing a comprehensive EU Cyber Resilience Act Checklist can help teams systematically evaluate these obligations. The rest tend to fall out naturally once secure-by-design practices are actually followed.
| CRA area | What the manufacturer should check | Evidence |
| Risk assessment | Document product cybersecurity risks | Risk assessment |
| Secure by default | Secure configuration, no unnecessary attack surface | Architecture/configuration evidence |
| Access control | Protection against unauthorised access | Security design/testing |
| Secure updates | Secure update mechanism | Update architecture/test evidence |
| Vulnerability handling | CVD, remediation, tracking | Vulnerability management records |
| SBOM | Required dependency information | Machine-readable SBOM |
| Support period | Defined and justified | Technical documentation |
| Incident reporting | 24h/72h process | Incident response procedure |
| Technical documentation | Annex VII evidence | Technical file |
| Conformity assessment | Correct route based on product class | Assessment records |
| User information | Annex II information | Product documentation |
| CE marking | Declaration and marking | EU DoC/CE evidence |
Article 14: Reporting Actively Exploited Vulnerabilities and Severe Incidents
Treating this as a documentation exercise misses the point entirely. Article 14 cares whether you can actually answer three questions, right now, under pressure:
- Would anyone on your team notice if a vulnerability in a shipped product started being actively exploited today?
- Could you get an early warning to ENISA and the relevant national CSIRT within 24 hours of finding out?
- Does your detection process even cover products you shipped years ago, or only whatever’s currently in development?
CISA’s KEV catalogue can be one useful source for tracking vulnerabilities known to have been exploited in the wild. And the clock Article 14 sets doesn’t care whether your process is ready for it:
- 24 hours – early warning, from the moment you become aware
- 72 hours – full notification
- 14 days – final report, once a patch exists
- 1 month – final report for severe incidents
None of these deadlines pause while you build the process to meet them. A team that’s never rehearsed detecting live exploitation tends to find out where its gaps are at the worst possible moment: after the clock has already started, not before.
The EU CRA Framework’s Staggered Timeline
The CRA’s obligations activate in three separate stages, and each one requires different preparation, not a single big-bang compliance push. Treating December 2027 as the only date that matters means walking into September 2026 without a working incident reporting process.
June 11, 2026: Conformity Assessment Bodies
The CRA provisions concerning the notification of conformity assessment bodies begin applying on this date, with Member States required to designate notifying authorities. This is an important implementation milestone for products that will require third-party conformity assessment, but it is not the date on which the CRA’s full manufacturer obligations begin.
September 11, 2026: Mandatory Vulnerability and Incident Reporting
Manufacturers must report actively exploited vulnerabilities and severe security incidents to ENISA and the relevant national CSIRT through the CRA’s Single Reporting Platform. The clock is unforgiving. It starts with a 24-hour early warning, followed by a 72-hour full notification. Once a patch exists for an exploited vulnerability, a 14-day final report follows, and severe incidents require a one-month final report. The reporting obligations apply to qualifying products already made available on the Union market, including products placed on the market before the CRA’s full application date.
December 11, 2027: Full Compliance and CE Marking
Every remaining obligation lands here. That includes secure-by-design and secure-by-default requirements, full technical documentation, SBOM generation, the CE marking itself, and the duty to provide security updates through the declared support period. After this date, manufacturers can no longer legally place a product on the EU market without CE marking and matching CRA conformity.
Building Your EU CRA SBOM
A machine-readable Software Bill of Materials must cover at least the top-level dependencies of every product with digital elements. They also need to keep it current and hand it to market surveillance authorities on request. The CRA does not generally require manufacturers to publish their SBOM publicly. However, manufacturers must maintain the required SBOM information as part of their technical documentation and provide it to market surveillance authorities when required.
CycloneDX, SPDX, and What Machine-Readable Means
The Commission hasn’t mandated a single format outright. Even so, CycloneDX and SPDX are the two formats doing the heavy lifting in practice, largely because most SBOM tooling already generates them by default. Machine-readable rules out a PDF with a components table. Instead, it has to be something a market surveillance authority’s own tooling can parse automatically. That tooling then cross-references it against known vulnerability databases, the same way analysts query NIST’s National Vulnerability Database programmatically rather than reading it line by line.
Generation is the easy part. Keeping the SBOM current as dependencies update is where most tooling setups quietly fall behind. That’s because a build pipeline often produces an SBOM only once, at release time. It won’t reflect a dependency that gets patched or develops a new vulnerability six months later.
The Open-Source Software Steward Category
The CRA distinguishes between free and open-source software made available in commercial activity and open-source software developed or maintained outside that commercial context. It also creates a specific category of open-source software steward for legal persons that systematically provide sustained support for qualifying open-source projects intended for commercial activities. Stewards have a lighter regulatory regime and are not subject to administrative fines under Article 64(10).
However, the regulation introduces a distinct open-source software steward category with lighter obligations for organisations that maintain open-source projects in a more structured capacity. Commercial vendors who bundle open-source components into a paid product remain fully responsible for those components under the CRA, full stop. Pulling in a popular open-source library doesn’t transfer the compliance burden to whoever maintains it upstream.
Vulnerability Handling and the Support Period Obligation
Manufacturers must clearly state the security support period for each product and provide free security updates throughout it. A five-year minimum applies by default, unless the product’s expected lifecycle is shorter. Vague statements like supported while stock lasts won’t satisfy Annex II’s disclosure requirement.
Manufacturers must retain records connected to a product’s technical documentation, risk assessment, and conformity evidence. The retention period runs for ten years after the product reaches the market, or for the full support period if that runs longer. In practice, this creates a real operational problem for teams running end-of-life dependencies. If a component your product depends on stops receiving upstream security patches before your own support commitment ends, that gap becomes your liability, not the component maintainer’s.
This is where the SBOM and the support period obligation actually connect. A ten-year record retention requirement is manageable when it applies to a handful of well-documented components. However, it becomes a genuine operational risk when a product ships with dozens of transitive dependencies. Some of those dependencies come from small open-source teams who may stop patching long before your own support window closes. Building an end-of-life tracking process into the SBOM workflow now avoids discovering the gap only once a component actually needs updating.
How Qualysec Helps UK Manufacturers Meet the EU CRA Checklist
The EU Cyber Resilience Act Checklist provides a structured approach for organizations to follow and link technical controls to legal obligations. Qualysec helps UK manufacturers to tackle this very list with targeted technical services:
Secure-by-Design Gap Assessment
Qualysec reviews product architecture and configuration against Annex I’s essential requirements before a product ships. We identify issues like default credentials, unencrypted local storage, and missing update mechanisms while they’re still cheap to fix. Findings map directly to the specific Annex I clause they relate to, and this shortens the path to a usable technical file.
SBOM Validation and Vulnerability Monitoring Readiness
We test whether an SBOM is actually complete, not just present. Specifically, we check for the transitive dependency gaps that commonly slip past automated tooling. We also confirm the output is genuinely machine-readable, rather than a static export that breaks the moment a market surveillance authority tries to parse it.
Penetration Testing Evidence for the Technical Documentation Package
Qualysec’s penetration testing can provide security-testing evidence that may form part of the technical documentation supporting a manufacturer’s CRA conformity assessment. This evidence supports both self-assessment documentation and, where a product falls into the critical tier, the review a notified body will expect. Retesting after remediation is part of every engagement, so the final technical file shows a vulnerability actually closed, not just flagged once and left open.
Conclusion
The EU Cyber Resilience Act isn’t a filing that a legal team completes once and files away. Instead, it lands on the codebase, the CI/CD pipeline, and the update mechanism a product carries at design time. That’s exactly why the September 2026 reporting deadline catches teams off guard, even when they’ve heard of the CRA for years.
Manufacturers that treat the three-date timeline as three separate work streams get real benefits. They avoid facing one distant deadline eighteen months out. Instead, they’ll have a working EU SBOM, a tested incident reporting process, and clean technical documentation ready before an authority ever asks to see them. Using the EU Cyber Resilience Act checklist early in the pipeline keeps development focused on verifiable requirements rather than an end-stage panic situation.
The gap between those two positions isn’t really about resources. Instead, it’s about whether the engineering team started building toward September 2026 in 2026, or waited until the reporting clock was already running against a live incident.
Contact Qualysec to build your EU Cyber Resilience Act compliance roadmap.
FAQ
1. What is the EU Cyber Resilience Act and who does it apply to?
The EU Cyber Resilience Act, Regulation (EU) 2024/2847, sets mandatory cybersecurity requirements for hardware and software products with digital elements. It applies whenever a manufacturer places such a product on the EU market in the course of commercial activity. That includes manufacturers, importers, and distributors, and it also includes UK companies selling into the EU, no matter where the manufacturer operates.
2. Is the EU CRA SBOM requirement mandatory before December 2027?
The EU SBOM obligation formally ties to the December 11, 2027 full-compliance deadline. Even so, continuous vulnerability monitoring can make it easier to identify affected products quickly. That’s simply because you can’t report on exposure you haven’t mapped. For example, say a newly disclosed vulnerability affects a dependency three layers deep in your stack. The 24-hour reporting clock still starts the moment you become aware of active exploitation. That’s true whether or not your SBOM was ready to tell you that dependency existed. Building the SBOM early is a practical necessity well before it becomes a formal legal requirement.
3. Does the EU Cyber Resilience Act apply to UK companies post-Brexit?
Yes, if a UK manufacturer places a product with digital elements on the EU market. A UK manufacturer can fall within the CRA when it places a product with digital elements on the Union market. The manufacturer’s location outside the EU does not by itself remove the product from the CRA’s scope.
4. What happens if a manufacturer misses the September 2026 reporting deadline?
Failure to comply with the applicable reporting obligation can constitute an infringement under the CRA. However, failing to report an actively exploited vulnerability within the 24-hour and 72-hour windows is itself a breach of the essential cybersecurity requirements. That exposes the manufacturer to the same penalty structure of up to €15 million or 2.5% of global turnover.
5. How does the CRA Regulation treat open-source software differently from commercial products?
Non-commercial open-source developers are exempt from CRA fines entirely. Instead, the CRA regulation introduces an “open-source software steward” category with lighter obligations for those maintaining open-source projects more formally. Commercial vendors who incorporate open-source components into a paid product remain fully responsible for those components under the CRA, exactly as they would for code they wrote themselves.
