Introduction
Picture this: your security team flags an actively exploited vulnerability in a third-party library embedded across six product lines. You sell into the EU. You're publicly listed in the U.S. Within hours, two regulatory clocks start running simultaneously—one in Brussels, one in Washington.
The EU Cyber Resilience Act (CRA) requires you to notify the relevant CSIRT within 24 hours of becoming aware of the actively exploited vulnerability. The SEC's Form 8-K Item 1.05 requires disclosure within four business days of determining the incident is material. Same event — two legal standards, two regulators, two audiences, and a governance structure that may not be ready for either.
This is the operating reality for any U.S.-listed company that sells software, connected devices, or hardware with embedded software into EU markets.
Most compliance guidance addresses these frameworks separately, in technical language that doesn't reach the boardroom until after a crisis. This article maps where the two regimes intersect, where they conflict, and what boards, general counsel, and risk committee chairs need to decide before the clock starts — covering SBOM obligations, materiality determination, disclosure sequencing, and defensible governance.
TL;DR
- The CRA applies to any company placing products with digital elements on the EU market—U.S. headquarters doesn't exempt you.
- Vulnerability and incident reporting obligations activate September 11, 2026; full SBOM and conformity requirements apply December 11, 2027.
- The CRA's incident notification clock starts at awareness, not confirmed impact—within 24 hours for active exploitation.
- The SEC's Form 8-K Item 1.05 requires disclosure within four business days of a materiality determination, creating a second, overlapping clock.
- The real governance test: can your organization detect a vulnerable component, assess materiality, and satisfy both regulatory timelines before either clock expires.
Who Needs to Pay Attention: CRA Scope and the U.S. Connection
The CRA's jurisdictional trigger isn't where a company is incorporated. It's where products are sold.
Under Article 2(1) of Regulation (EU) 2024/2847, the regulation applies to any product with digital elements made available on the EU market — where foreseeable use includes any logical or physical connection to a device or network. U.S.-headquartered manufacturers, importers, and distributors placing products into EU commerce are in scope.
What Counts as a "Product with Digital Elements"
In plain terms: nearly anything that connects to a network or processes data.
- Consumer devices, smart home products, wearables
- Industrial control systems and operational technology
- Networking equipment, routers, switches
- Hardware with embedded firmware or software
- General-purpose software sold or licensed commercially
Key exemptions cover several product categories:
- Medical devices governed by Regulation (EU) 2017/745
- Certain motor vehicles under Regulation (EU) 2019/2144
- Products developed exclusively for national security or defense
- Free and open-source software developed outside commercial activity
- Standard SaaS offerings without a tethered local component
Scope edge cases are common — verify each product individually.
The Timeline Boards Need to Know
| Date | Obligation |
|---|---|
| June 11, 2026 | Notified body provisions apply |
| September 11, 2026 | Vulnerability and incident reporting (Article 14) activates |
| December 11, 2027 | Full CRA requirements, including SBOM and conformity assessment |
| Penalties | Up to €15 million or 2.5% of annual global turnover, whichever is higher |
What the EU CRA Actually Requires: The Governance-Level View
Security as a Legal Product Requirement
The CRA's "secure by design and by default" mandate changes the accountability structure for product security. Security is no longer a feature: it is a legal condition of market access.
Manufacturers must document, through risk assessments, architecture decisions, and test results, that security was engineered into the product. This shifts accountability beyond the security team to the product organization and, by extension, to board-level oversight. If the technical file cannot demonstrate security was built in, the product cannot legally carry the CE mark and cannot be sold in the EU.
Lifecycle Vulnerability Management
The CRA creates an ongoing operational obligation, not a one-time certification exercise. After a product reaches market, manufacturers must:
- Monitor for newly discovered vulnerabilities in their products
- Assess severity and impact across affected products
- Deliver remediations within a reasonable timeframe
- Maintain this process for the product's supported life
Why does the operational cadence matter? Verizon's 2024 Data Breach Investigations Report found a median of just 5 days to exploitation for vulnerabilities listed in CISA's Known Exploited Vulnerabilities catalog. Boards overseeing product companies need to understand that vulnerability management is now a regulatory obligation with a very short response window.
The Incident Notification Clock
Governance miscalculations are most common here.
Under Article 14 of Regulation (EU) 2024/2847, when a product is actively exploited, manufacturers must:
- Submit an early warning within 24 hours of becoming aware
- Follow with a vulnerability notification within 72 hours
- File a final report within 14 days after a corrective or mitigating measure is available (one month for severe incidents)
Notifications go simultaneously to the designated CSIRT coordinator and ENISA through the single reporting platform.
The critical governance point: the clock starts at awareness, not at confirmed business impact. Organizations accustomed to waiting for full damage assessment before escalating will miss this deadline. Boards should ask management directly: does your incident response plan define "awareness" as the escalation trigger — and is that threshold documented?
Technical Documentation and Conformity
Before placing a product on the EU market, manufacturers must compile a technical file that includes:
- Product descriptions and architecture documentation
- Security risk assessments and test results
- Vulnerability handling policies
- Update and patching documentation
- SBOM documentation
Product classification determines the conformity path. Default products can generally self-certify.
Important products (Class I and Class II — including password managers, browsers, firewalls, and intrusion detection systems) require escalating levels of third-party review. Critical products face the most rigorous conformity assessment requirements. Without completed conformity assessment, CE marking cannot be affixed, and the product cannot legally be placed on the EU market.
One important confidentiality note: Recital 77 of the CRA explicitly states that manufacturers are not required to make SBOMs public. SBOMs must be provided to market surveillance authorities and conformity assessment bodies upon request. Boards managing competitive sensitivity concerns have this protection — but it requires a standing process to produce SBOMs on request.
SBOM Requirements: What They Mean Beyond the Tech Team
What an SBOM Actually Is
A Software Bill of Materials is a structured inventory of every software component, library, and dependency used in a product. The closest analogy is a food product's ingredient list—flour and salt replaced by open-source libraries, vendor SDKs, and third-party code packages.
Without this inventory, an organization cannot answer the most basic incident response question when a vulnerability is announced: "Which of our products contain this component?"
The operational stakes are real. Synopsys's 2024 Open Source Security and Risk Analysis found that 96% of audited codebases contained open-source components, and 74% contained high-risk open-source vulnerabilities—a 54% increase from the prior year.
What the CRA Specifically Requires
The CRA's SBOM obligations (Annex I Part II, Article 13) are specific:
- Machine-readable format (CISA guidance points to SPDX and CycloneDX as the recognized standards—the CRA text does not name specific formats)
- Top-level dependencies at minimum, covering all in-scope products
- Retained for 10 years after market placement, or the product's support period, whichever is longer
- Updated as components change throughout the product's life
A note on coverage: the CRA mandates top-level dependencies as the legal minimum. In practice, most exploitable vulnerabilities live in transitive dependencies—the components your components depend on. Operationally prudent programs go deeper than the legal floor.
That list defines the compliance floor. Whether the organization can actually act on an SBOM under time pressure is a separate question—and the one boards should be asking.
The Governance Loop That Actually Matters
An SBOM sitting in a document repository is a compliance artifact. An SBOM integrated into vulnerability management is a security tool. The board's oversight question is whether the company has a functioning process to:
- Receive a vulnerability alert for a specific component
- Query SBOMs to identify affected products immediately
- Prioritize and remediate based on severity
- Notify customers and authorities within required timeframes
Without that loop, the SBOM doesn't help when the 24-hour CRA clock starts running.
The CRA also holds manufacturers accountable for third-party components under Article 13(5), requiring due diligence when integrating open-source or vendor-supplied code.
Boards overseeing organizations that rely on contracted development or vendor SDKs need assurance that SBOM practices extend into the supply chain, not just first-party code.
What Boards Should Confirm
Directors don't need to review SBOMs. They should confirm:
- A documented SBOM program exists and covers all in-scope products
- SBOMs are integrated into vulnerability management workflows—not stored separately
- The program is audit-ready and can produce SBOMs for regulators on request
- Named owners are accountable for maintaining and updating SBOMs as products change
The SEC Disclosure Intersection: When EU Obligations Trigger U.S. Reporting
The SEC Framework
SEC Release No. 33-11216, effective December 2023, created two primary disclosure obligations:
- Regulation S-K Item 106: Annual Form 10-K disclosure of the company's cybersecurity risk management processes, strategy, and board oversight practices.
- Form 8-K Item 1.05: Disclosure of material cybersecurity incidents within four business days of determining materiality. The SEC applies the traditional securities-law standard: whether a reasonable investor would consider the information important.
Critically, the materiality determination must be made without unreasonable delay after discovery. The clock doesn't start when the board learns about it—it starts when the company discovers the incident.
Where the Two Clocks Collide
The governance collision is direct:
| Framework | Trigger | Timeline |
|---|---|---|
| CRA Article 14 | Awareness of active exploitation | Early warning: 24 hours |
| SEC Item 1.05 | Materiality determination | Form 8-K: 4 business days |
A single exploited vulnerability in a product component can simultaneously activate both clocks. The CRA notification to ENISA/CSIRT and the SEC's materiality analysis are running in parallel, driven by the same underlying event, but governed by entirely different legal tests with different regulators and different disclosure audiences.
The gap most organizations haven't closed: the CRA will frequently require notification before SEC materiality is resolved. Your incident response governance must account for this sequence and pre-define who owns each decision.
SBOM Quality as a Material Factor in SEC Timing
Under the SEC framework, materiality assessment requires understanding the scope and severity of an incident. An accurate, maintained SBOM dramatically accelerates this by immediately identifying which products are affected and how many customers are exposed.
Organizations without operational SBOMs face extended assessment windows. That extended window creates direct SEC timing risk—the longer materiality takes to assess, the greater the exposure to "unreasonable delay" claims.
The SEC has not issued staff guidance specifically addressing product security incidents or component-level software vulnerabilities in relation to Item 1.05 timing. The intersection of CRA and SEC obligations remains a governance gap, not settled doctrine. Pre-incident governance preparation carries more weight precisely because there is no regulatory safe harbor to fall back on.
Closing the Silo Problem
Many boards oversee SEC disclosure governance through the audit committee and EU regulatory compliance through legal or compliance functions—in separate tracks that don't communicate during incidents. The CRA/SEC scenario requires both to operate under a single incident response governance model with:
- Pre-agreed escalation thresholds tied to business impact
- Named decision owners for CRA notification and SEC materiality determination
- Outside counsel coordination that addresses both regulatory regimes
- A defined sequence of notifications when obligations overlap
Tyson Martin's board advisory work addresses this directly: building the escalation ladders, materiality thresholds, and pre-approved decision frameworks that give boards the authority to act quickly when an incident hits — without improvising governance under pressure.
What Boards Should Be Asking Right Now
If your board hasn't had this conversation, these are the questions to put to management:
Which of our products are subject to CRA? Can management produce a current product inventory with EU revenue exposure identified?
Do we have maintained SBOMs for in-scope products? Are they integrated into vulnerability management workflows, or filed separately with no operational connection?
What is our process when a CRA-notifiable incident occurs? Who makes the initial 24-hour ENISA notification, and who simultaneously begins the SEC materiality assessment?
Who owns the Form 8-K decision when a product vulnerability is actively exploited? Is there a named owner with pre-agreed authority, or does it require a board convening mid-incident?
Have we stress-tested our incident response against both regulatory timelines simultaneously? A tabletop exercise that only runs against SEC disclosure—without the CRA notification timeline—leaves a material gap.
What evidence exists that these processes work? Not assertions—actual artifacts: a product inventory, a sample SBOM, a documented escalation decision tree, and a defined materiality threshold.
The Inspectable Execution Standard
Management telling the board that processes exist is not governance. The board should expect:
- A named product inventory with EU market exposure flagged
- Evidence that SBOMs are being generated and updated
- A documented incident response decision tree showing CRA and SEC trigger points
- Pre-approved materiality thresholds for cybersecurity incidents
- Named owners for each regulatory obligation with alternates
If management cannot produce these artifacts, that is itself a material governance finding—regardless of whether an incident has occurred.
Organizations navigating leadership transitions, M&A activity, or technology modernization carry amplified exposure here. Product inventory knowledge and compliance program status erode fast when key people leave or roles shift.
In these situations, an interim CISO with board-level regulatory fluency can assess the gap and build inspectable governance on a defined timeline — often the fastest path to defensible oversight.
Frequently Asked Questions
Does the EU Cyber Resilience Act apply to U.S.-based companies?
Yes. The CRA applies to any organization placing products with digital elements on the EU market, regardless of headquarters location. U.S. companies generating EU revenue from software, connected devices, or embedded-software hardware must meet CRA conformity requirements to maintain market access.
Does an SBOM have to be made public under the CRA?
No. Recital 77 of Regulation (EU) 2024/2847 explicitly states manufacturers are not required to make SBOMs public. SBOMs must be provided to market surveillance authorities and conformity assessment bodies upon request and can be treated as commercially sensitive information.
What is the CRA's timeline, and when does enforcement actually begin?
Three key dates: Article 14 vulnerability and incident reporting activates September 11, 2026; full requirements including SBOM obligations apply December 11, 2027; penalties reach up to €15 million or 2.5% of annual global turnover, whichever is higher.
How does an actively exploited vulnerability trigger both CRA and SEC obligations simultaneously?
A CRA-notifiable incident—active exploitation of a product vulnerability—simultaneously triggers the board's obligation to assess SEC materiality for a potential Form 8-K. The CRA early warning is due within 24 hours of awareness; the Form 8-K is due within four business days of a materiality determination. Pre-planned, coordinated governance is required to meet both deadlines without conflict.
What SBOM format does the CRA require?
The CRA requires a commonly used, machine-readable format. CISA guidance identifies SPDX and CycloneDX as the widely used standards meeting this requirement. The SBOM must cover at least the product's top-level dependencies and be retained for at least 10 years post-market placement.
What is the board's actual oversight responsibility for CRA and SBOM compliance?
Boards are not expected to review SBOMs directly. They should confirm that a documented SBOM program exists, that it is integrated into vulnerability management workflows, and that escalation and disclosure decision rights are defined and tested before an incident occurs.
