The EU Cyber Resilience Act makes cybersecurity a condition of selling hardware and software in the EU, and since 11 September 2026 manufacturers have had to report actively exploited vulnerabilities in their products within 24 hours. Regulation (EU) 2024/2847 (the CRA) entered into force on 10 December 2024. Its reporting obligations have applied since 11 September 2026 and its main obligations, including the essential cybersecurity requirements and CE marking, apply from 11 December 2027. This briefing is for directors, chief executives, chief product and technology officers, general counsel and CISOs of companies that make, import or distribute products with digital elements. It covers product scope, the reporting duty, the 2027 obligations, penalties and how to oversee management's readiness. It stays at board level; the detail is in the EU Cyber Resilience Act Guide. Dates are stated as checked on the European Commission's CRA pages on 8 November 2026.
The risk in one paragraph
Most products now contain software, and most software contains third-party and open-source components. The CRA treats security flaws in those products as a product safety problem: manufacturers must design products to meet essential cybersecurity requirements, handle vulnerabilities for a declared support period, document all of this, pass a conformity assessment and affix the CE marking before selling in the EU. Importers and distributors must check that they have done so. From 11 September 2026 manufacturers must also notify actively exploited vulnerabilities and severe incidents on a 24-hour clock, for products already on the market as well as new ones. The board's exposure is commercial as much as regulatory: a product that cannot show conformity cannot be sold in the EU after 11 December 2027, market surveillance authorities can require corrective action or withdrawal, and fines for breaching the essential requirements or the reporting duties can reach EUR 15 million or 2.5% of worldwide annual turnover.
Why this is a board-level issue now
- The 24-hour reporting clock is live. Since 11 September 2026, manufacturers must send an early warning of an actively exploited vulnerability or a severe incident within 24 hours of becoming aware, a notification within 72 hours, and a final report (14 days after a corrective measure is available for a vulnerability, or one month after the notification for an incident). Reports go through ENISA's Single Reporting Platform, which the Commission states has been operational since 11 September 2026.
- Market access depends on it from December 2027. The Commission states that the main obligations apply from 11 December 2027. Products without conformity assessment and CE marking cannot then be placed on the EU market.
- Fines are set as a share of turnover. Article 64 allows fines of up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher, for non-compliance with the essential requirements or the manufacturer obligations in Articles 13 and 14; up to EUR 10 million or 2% for breaches of other operator obligations; and up to EUR 5 million or 1% for supplying incorrect or misleading information.
- Engineering lead times are long. Secure development processes, software bills of materials, vulnerability handling and update infrastructure cannot be retrofitted in a quarter. Product roadmaps that ship in late 2027 are being designed now.
- Customers will ask before regulators do. Business customers that integrate your products into their own CRA-scoped products need your conformity evidence, vulnerability information and support commitments.
Product scope: are we in?
The CRA covers products with digital elements: hardware and software products, from baby monitors and smart watches to apps and computer programs, including remote data processing solutions essential to their function. Some products are excluded where other Union legislation already covers them, and products that are not made available on the market are out of scope.
| Category | Examples given by the Commission | Conformity route |
|---|---|---|
| Default (most products) | Memory chips, mobile apps, smart speakers, computer games | Manufacturer self-assessment |
| Important, class I (Annex III) | For example operating systems, anti-virus, routers | Self-assessment only where harmonised standards are applied in full; otherwise a notified body |
| Important, class II (Annex III) | For example firewalls and intrusion detection and prevention systems | Third-party assessment by a notified body in all cases |
| Critical (Annex IV) | Smart cards, secure elements, smart meter gateways | Notified body assessment or European cybersecurity certification |
Commission Implementing Regulation (EU) 2025/2392 sets out the technical descriptions of the important and critical categories. See the EU CRA Product Classes Guide.
- Roles matter: manufacturers carry most obligations; importers must make sure the manufacturer has met the essential requirements, carried out conformity assessment and affixed the CE marking; distributors must verify the CE marking and the information supplied. Both must inform the manufacturer of vulnerabilities they learn of.
- Open source: open-source software stewards have lighter duties, including a cybersecurity policy and reporting to the extent they are involved, from 11 December 2027, and are not subject to fines. Companies that monetise open-source products in the course of a commercial activity should take advice on whether they are manufacturers.
Exposure: what the business stands to lose
Boards should ask management to express CRA exposure per product family, in revenue and cost, rather than as a compliance percentage.
| Exposure | What drives it | Question to put to management |
|---|---|---|
| EU market access | Products that cannot show conformity and carry the CE marking after 11 December 2027 | What share of EU revenue comes from products whose conformity plan is not yet funded? |
| Corrective action and withdrawal | Market surveillance authorities enforcing the rules on products already sold | Could we patch or recall a product at scale, and what would it cost? |
| Fines | Article 64 tiers up to 2.5% of worldwide turnover | Which obligations carry the top tier, and where are our gaps against them? |
| Support cost | Declared support periods that require years of security updates | What does each year of support cost per product, and is it priced in? |
| Customer contracts | Business customers passing CRA obligations down the supply chain | Which customers depend on our conformity evidence for their own products? |
The 2026 reporting duty
| Stage | Deadline | Board's preparatory role |
|---|---|---|
| Early warning | Within 24 hours of becoming aware of an actively exploited vulnerability or severe incident | Approve who decides "aware" and who submits, with out-of-hours cover |
| Notification | Within 72 hours | Expect a briefing to the accountable executive |
| Final report, vulnerability | No later than 14 days after a corrective measure is available | Track the fix and customer communication |
| Final report, severe incident | Within one month of the notification | Review root cause and remediation at committee |
- Where it goes: a single submission through the ENISA Single Reporting Platform reaches the CSIRT of the Member State of the manufacturer's main establishment, and ENISA at the same time.
- Small company relief is narrow: under Article 64(10), microenterprises and small enterprises are not fined for missing the 24-hour early warning deadline, but the duty to report still applies.
- Overlap with other regimes: a severe incident affecting your own systems may also trigger NIS2, DORA or GDPR clocks. See the EU Cyber Resilience Act Vulnerability and Incident Reporting Guide and the EU Incident Reporting Clocks comparison.
The 2027 obligations in business terms
| Obligation | What it means for the business | Typical owner |
|---|---|---|
| Essential cybersecurity requirements (Annex I) | Products designed, developed and produced to an appropriate level of security, with secure defaults and no known exploitable vulnerabilities at release | Product engineering |
| Vulnerability handling | Identify and document components (a software bill of materials), fix vulnerabilities without delay, publish advisories, operate coordinated vulnerability disclosure | PSIRT |
| Support period | Manufacturer determines the support period and must state its end (month and year) clearly at the time of purchase | Product management and commercial |
| Technical documentation and conformity assessment | Evidence that requirements are met, and the assessment route for the product class | Compliance and quality |
| CE marking and EU declaration of conformity | Required before placing on the market | Compliance |
| Third-party components | Due diligence on integrated components, including open source | Engineering and procurement |
See the SBOM Guide, the PSIRT Guide and the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide for the engineering practices behind these obligations.
Five questions for the board to ask
- Which of our products are in scope, and in which class? A credible answer is a product list with class and conformity route, including legacy products still on sale.
- If an actively exploited vulnerability in one of our products were reported at midnight, who would file the 24-hour early warning? Expect a named owner, deputies, a registered account on the reporting platform and a rehearsal record.
- What support period do we commit to for each product, and can we fund it? The answer should link support periods to revenue, update infrastructure and engineering capacity.
- Do we know every component in our products? Look for software bills of materials for current releases and a process to act on vulnerabilities in third-party components.
- What has to be true by 11 December 2027 for us to keep selling in the EU, and are we on track? Expect a plan per product family with conformity assessment dates and, for important and critical products, notified body engagement.
Red flags in management answers
- "We are a software company, so it does not apply": standalone software is a product with digital elements.
- "Reporting starts in 2027": reporting has applied since 11 September 2026; only the main obligations start in December 2027.
- "Our products are low risk, so self-assessment covers us": self-assessment still requires full technical documentation and meeting every essential requirement, and important and critical products have stricter routes.
- "We will publish an SBOM when asked": component knowledge is needed to handle vulnerabilities and report in 24 hours, not only to answer customers.
- "The support period is a marketing decision": it is a legal commitment with engineering and cost consequences.
- Notified body capacity assumed: class II and critical products need third-party assessment; waiting until 2027 to engage risks delays.
What good looks like
| Area | Good practice |
|---|---|
| Governance | Named accountable executive, CRA programme with board-approved budget, product scope register |
| Reporting | Registered on the reporting platform, 24-hour process rehearsed, PSIRT able to confirm active exploitation quickly |
| Engineering | Secure development lifecycle aligned to a recognised framework, secure defaults, release gates for known vulnerabilities |
| Components | SBOM per release, monitoring of component vulnerabilities, supplier security requirements |
| Support | Declared support periods per product, funded update capability, secure update delivery |
| Conformity | Technical documentation started, harmonised standards tracked, notified bodies engaged where needed |
| Update infrastructure | Signing keys and build pipeline credentials protected as high-value non-human identities |
Where to invest first
- Reporting readiness: already in force, and failure is visible to the CSIRT and ENISA. Confirm the process, the platform account and the decision authority.
- Product scope and classification: every later decision depends on knowing which products are default, important or critical.
- Vulnerability handling and SBOM: the foundation for both the reporting duty and the 2027 obligations. See the Bug Bounty and Vulnerability Disclosure Guide.
- Secure build and update pipeline: the update channel is how fixes reach customers and also a prime target. Protect build systems, signing keys and pipeline credentials. See the Code Signing Security Guide.
- Conformity assessment plan: technical documentation and notified body engagement for important and critical products.
Metrics to track
- Percentage of products on sale with scope and class confirmed.
- Time from first signal to confirmed active exploitation, and to early warning, in incidents and exercises.
- Percentage of current releases with an SBOM.
- Median time to fix critical vulnerabilities in supported products.
- Percentage of products with a declared support period and funded update plan.
- Percentage of product families with conformity assessment complete or scheduled before 11 December 2027.
A 90-day plan
- Days 1 to 30: confirm the accountable executive; confirm the 24-hour reporting process, platform registration and out-of-hours authority; commission the product scope and class register.
- Days 31 to 60: run a reporting exercise based on an actively exploited vulnerability in a flagship product; review SBOM coverage and vulnerability handling; agree how support periods will be set and funded.
- Days 61 to 90: approve a funded plan per product family to 11 December 2027, including notified body engagement for important and critical products; add CRA requirements to supplier contracts; agree the quarterly metrics above.
Common failure patterns
- Treating 2027 as the start date: the reporting duty began in September 2026 and also covers products already on the market.
- No owner for "aware": the 24-hour clock starts on awareness, and teams argue about whether exploitation is confirmed while the clock runs.
- SBOMs that stop at the first layer: transitive open-source dependencies are where many exploited vulnerabilities sit.
- Support periods promised without funding: commitments made in product literature that engineering cannot maintain.
- Weak build pipeline identities: stolen CI tokens and signing keys turn the update channel into a distribution route for attackers, which is the kind of severe incident the CRA requires manufacturers to report. See the Software Liability and Secure by Design Policy Guide.
Practitioner checklist
- Maintain a register of products with digital elements, with class, conformity route and support period.
- Keep the reporting platform account, decision authority and out-of-hours cover current, and rehearse yearly.
- Produce an SBOM for every release and monitor its components for vulnerabilities.
- Operate a PSIRT with coordinated vulnerability disclosure and published advisories.
- Set and fund support periods, and state their end dates at the point of sale.
- Start technical documentation now and engage notified bodies for important and critical products.
- Protect build systems, signing keys and pipeline credentials as high-value non-human identities.
- Report the six metrics above to the risk or audit committee each quarter.
Standards and references
- EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)
- European Commission: Cyber Resilience Act
- European Commission: CRA reporting obligations
- European Commission: Cyber Resilience Act summary
- European Commission: CRA conformity assessment
- EUR-Lex: Implementing Regulation (EU) 2025/2392 on technical descriptions of important and critical products
- ENISA: CRA Single Reporting Platform FAQ
How NHI Mgmt Group can help
We provide independent identity and non-human identity risk assessments and board briefings, with a focus on the build pipelines, signing keys and machine credentials that protect a product's update channel. Our NHI Foundation Level Training Course helps security and engineering teams govern service accounts, API keys and secrets. Contact us to arrange a briefing.
Related NHI Mgmt Group resources: EU Cyber Resilience Act Guide · EU CRA Product Classes Guide · SBOM operations · Board and Director Cyber Liability Guide. This guide summarises Regulation (EU) 2024/2847 for board members and is not legal advice.