Introduction: What the CRA Means for Your Business
The EU Cyber Resilience Act is no longer a planning exercise. The CRA entered into force on December 10, 2024, with mandatory vulnerability and incident reporting obligations beginning September 11, 2026, and full compliance required by December 11, 2027.
That September 2026 deadline is closer than it appears — and more operationally demanding than most leadership teams realize. Organizations that treat this as a 2027 problem will find themselves compressing months of infrastructure work into weeks.
Most CRA guidance is written for developers and security engineers. This guide is written for boards, executives, and governance leaders — covering oversight obligations, cross-functional accountability, and the questions to ask technical teams before regulators ask them first.
This guide covers what the CRA requires, who it applies to, a seven-domain compliance checklist, what defensible board oversight looks like, and the penalties for getting it wrong.
TLDR
- CRA applies to any software or connected hardware sold in the EU market, including US companies
- Incident reporting begins September 11, 2026: 24-hour early warnings, 72-hour detailed notifications
- Products fall into three tiers; misclassification carries significant regulatory exposure
- Non-compliance fines reach €15 million or 2.5% of global annual turnover
- Board-level accountability is explicit — this cannot be delegated to IT and forgotten
What Is the Cyber Resilience Act and Who Must Comply?
The CRA is an EU regulation requiring cybersecurity standards for all "products with digital elements" placed on the EU market. That covers both software and connected hardware, regardless of where the manufacturer is headquartered.
US companies selling software or connected products to EU customers are fully in scope.
Who Qualifies as a Manufacturer
Under Article 3 of Regulation (EU) 2024/2847, a manufacturer is any natural or legal person who:
- Develops or commissions a product and markets it under their own name or trademark
- Sells for payment or provides it free of charge as part of a commercial activity
- Places a product on the EU market under their own name, even if manufactured elsewhere
Importers and distributors also carry obligations — importers must verify conformity assessment and CE marking; distributors must exercise due care and check product documentation.
Common Scope Questions
| Situation | CRA Status |
|---|---|
| Software product sold to EU customers | In scope |
| Remote data processing tied to a product's function | In scope |
| Pure SaaS with no product link | Generally out of scope |
| Open-source project with zero commercial activity | Generally out of scope |
| Free software supplied in a commercial context | In scope |
| Products for national security or defense | Explicitly exempt |
That SaaS row requires the most scrutiny. If remote processing is developed by or for the manufacturer and necessary for the product to perform its function, it pulls that service into scope. Evaluate each product individually rather than assuming exclusion.
CRA Timeline and Product Classification
Key Compliance Dates
| Date | Milestone |
|---|---|
| December 10, 2024 | CRA entered into force |
| June 11, 2026 | Conformity assessment body rules apply |
| September 11, 2026 | Vulnerability and incident reporting obligations begin |
| December 11, 2026 | Member States must strive to have sufficient notified bodies operational |
| December 11, 2027 | Full cybersecurity and conformity assessment requirements apply |
The September 2026 date deserves attention. Reporting infrastructure must be operational before that date: the processes, escalation paths, and ENISA notification workflows cannot be built in response to an incident.
Product Risk Tiers
Your product's tier determines which assessment route applies — and which deadlines you're working toward. The CRA defines four classification levels:
- Default products (not listed in Annex III): Self-assessment via Module A is permitted. This covers most software products.
- Important Class I (Annex III): Includes standalone browsers and password managers. Third-party assessment is required unless harmonized standards are fully applied.
- Important Class II (Annex III): Includes firewalls and intrusion detection/prevention systems. Requires third-party or certification-type assessment.
- Critical products (Annex IV): May require European cybersecurity certification at "substantial" level or higher.
Misclassifying a product as Default when it qualifies as Class I or Class II creates regulatory exposure and delays CE marking. Each product in your portfolio needs its own evaluation.
The CRA Compliance Checklist: 7 Key Domains
1. Secure-by-Design and Secure-by-Default
Products must be built with security embedded from the start. Annex I requires appropriate cybersecurity protections, secure default configurations, and access controls that prevent unauthorized use.
Board-level checkpoint: Can your product leadership confirm that security requirements and cybersecurity risk assessments are documented for every product targeting the EU market? If the answer is "we think so," that's not sufficient.
2. Vulnerability Management
The CRA imposes ongoing vulnerability management obligations — covering the product's full expected lifetime, not just its release. Article 14 specifies:
- 24-hour early warning to ENISA/CSIRTs upon awareness of an actively exploited vulnerability
- 72-hour detailed notification to follow
- 14-day final report after a corrective or mitigating measure is available
Meeting these timelines requires detection capabilities, defined escalation paths, and pre-built notification workflows in place before an incident occurs. Treat this as operational infrastructure, not a policy document.
3. Software Bill of Materials (SBOM)
Annex I Part II requires manufacturers to maintain an SBOM in a commonly used, machine-readable format, listing all components, libraries, and dependencies. The CRA does not currently mandate a specific format (such as SPDX or CycloneDX) — implementing acts may specify this later.
The SBOM serves two distinct purposes:
- Supply chain transparency across all components you ship
- A documentation artifact required for conformity assessment and regulatory inspection
Ask your team: Do we have a current SBOM for every product in scope? Is it updated when dependencies change?
4. Vulnerability Disclosure Policy
Annex I Part II requires manufacturers to establish and enforce a coordinated vulnerability disclosure policy covering:
- How security reports are accepted and triaged
- How findings are communicated internally and externally
- How resolution timelines align with the 24/72-hour reporting obligations
This process must be documented, auditable, and tested under realistic time pressure. An untested VDP is a liability, not a control.
5. Supply Chain and Third-Party Component Risk
Article 13 requires due diligence when integrating third-party components, including open-source libraries. The manufacturer is responsible for inherited vulnerabilities in components they ship — even when those vulnerabilities originate upstream.
This requires:
- A maintained component inventory aligned with your SBOM
- Processes to monitor newly disclosed vulnerabilities in dependencies
- Clear remediation workflows when a component vulnerability is disclosed
6. Monitoring, Incident Detection, and Response
Meeting the 24-hour early warning requirement assumes you already know when a vulnerability in your product is being actively exploited. That requires monitoring capabilities — not just for your infrastructure, but product-focused detection.
Defensible incident response for CRA purposes includes:
- Defined escalation paths with named owners
- Pre-built ENISA notification workflows
- Post-incident review processes
- Tested (not assumed) operational readiness
7. Security Updates and Product Lifecycle Support
Article 13 requires a support period reflecting expected product use — at minimum five years, unless the product is expected to be used for a shorter period. Annex I Part II requires security updates to be provided separately from feature updates where technically feasible.
This is a supply-side obligation that affects product roadmap decisions and end-of-life planning. Boards should ask whether current product lifecycle policies are aligned with this requirement.
Board Governance and Executive Oversight for CRA
Why This Is a Board Problem
The CRA imposes obligations on manufacturers as legal entities. Boards and executive teams bear ultimate accountability for whether those obligations are met. Treating CRA as an IT problem doesn't reassign that liability — it just creates a governance gap that regulators will find.
Common governance failures that apply directly to CRA:
- No clear ownership — "Security's job" and "engineering's job" can both be true and result in accountability gaps at the seams
- Activity-based reporting — Boards hearing about tool deployments and patch counts without understanding whether reporting infrastructure is operationally ready
- Untested processes — Incident response plans that look good on paper but haven't been walked through under 24-hour pressure
What Defensible Board Oversight Looks Like
Credible CRA oversight at the board level includes:
- Named owners for each compliance domain (CISO, General Counsel, product leadership)
- Documented escalation thresholds defining when and how the board is notified of a reportable incident
- A compliance dashboard tracking progress across the seven domains — not a one-time audit, but a living record
- Evidence trails demonstrating due diligence: documented risk assessments, SBOM records, testing logs, disclosure history
Questions Boards Should Be Asking Now
- Which of our products place us in scope for the CRA?
- How is each product classified — Default, Class I, or Class II?
- Do we have a functioning VDP that has been tested under time pressure?
- Can we operationally meet the 24-hour early warning deadline today?
- What does our SBOM process look like, and when was it last verified?
- Who is the named owner of our Article 14 reporting workflow?
Elevated Risk During Organizational Transitions
Organizations in transition (new CISO, post-M&A integration, active modernization) face compounded CRA risk. Compliance processes depend on institutional continuity. When ownership shifts during leadership transitions, the gaps that open are precisely the ones regulators scrutinize.
For organizations without the internal capacity to build CRA-ready governance infrastructure, a fractional or interim CISO with regulatory compliance experience can compress the readiness timeline and close governance gaps without waiting on a full executive search. Tyson Martin works with boards in exactly this position: establishing decision rights, reporting workflows, and a board-ready compliance dashboard within the first 30 days, so oversight structure is in place while permanent hiring proceeds on its own timeline.
Documentation, SBOM, and CE Marking Requirements
What You Must Maintain
Conformity assessment requires a documented evidence file. Under Annex VII, this includes:
- Product-level cybersecurity risk assessments
- Technical documentation supporting the conformity assessment procedure
- SBOM records
- Security testing records and remediation logs
- Records of vulnerability disclosures and regulatory notifications
Retention period: At least 10 years after placing the product on the market, or the support period — whichever is longer.
CE Marking Requirements
The CE mark must be affixed to the product (digitally for software, with a link on the accompanying website). It must be accompanied by an EU Declaration of Conformity (Article 28, Annex V) that identifies:
- The product and applicable legislation
- The conformity assessment procedure followed
- The product's risk category
- An authorized signatory
Two additional obligations apply to non-EU manufacturers: Article 18 requires an authorized representative within the EU, and Article 19 imposes separate importer obligations for non-EU products placed on the EU market.
Documentation Is a Living Record
Technical documentation must be updated with each significant product change or security event — it is a living record, not a filing exercise. Organizations without centralized posture tracking will find it difficult to produce audit-ready evidence on demand, which is precisely what regulators will require during an inspection.
Penalties for Non-Compliance
Article 64 of Regulation (EU) 2024/2847 establishes fines for non-compliance with Annex I essential requirements or Articles 13-14 obligations at:
Up to €15,000,000 or 2.5% of total worldwide annual turnover — whichever is higher.
Beyond fines, national market surveillance authorities can:
- Require corrective action
- Restrict or prohibit sale of non-compliant products on EU-accessible platforms
- Require withdrawal or recall
- Require manufacturers to notify impacted users of actively exploited vulnerabilities (Article 14(8))
No CRA-specific enforcement actions have occurred yet. Reporting obligations don't begin until September 2026. That window is not a buffer. The EU has built the enforcement infrastructure, and organizations that delay compliance planning will face a compressed remediation timeline when the deadline arrives.
Frequently Asked Questions
Does the CRA apply to US companies?
Yes. CRA scope is market-based, not headquarters-based. Any manufacturer that places a product with digital elements on the EU market — regardless of where the company is located — is in scope. US companies selling software or connected hardware to EU customers must comply.
What products are exempt from the Cyber Resilience Act?
Products governed by specific EU sector frameworks — including medical devices, motor vehicles, civil aviation, and marine equipment — are excluded, as are products developed exclusively for national security or defense. Pure SaaS services with no product link and non-commercial open-source projects are also outside scope.
What are the CRA reporting deadlines for incidents and vulnerabilities?
Manufacturers must submit an early warning within 24 hours of becoming aware of an actively exploited vulnerability, followed by a detailed notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. These obligations begin September 11, 2026.
What are the penalties for non-compliance?
Fines can reach €15 million or 2.5% of global annual turnover (whichever is higher) for violations of essential requirements or reporting obligations. Authorities can also remove non-compliant products from EU-accessible platforms and require user notification.
What is the difference between CRA Class I and Class II products?
Class I Important Products (including password managers and standalone browsers) allow self-assessment when harmonized standards are fully applied — otherwise, third-party assessment is required. Class II Important Products (including firewalls and intrusion detection systems) require third-party or certification-type assessment regardless of standards applied.
When does full CRA compliance take effect?
Full cybersecurity and conformity assessment obligations apply from December 11, 2027. However, vulnerability and incident reporting requirements begin September 11, 2026 — well ahead of full implementation, meaning operational readiness cannot wait until 2027.
