The EU Cyber Resilience Act Has Global Implications – Who Needs to Prepare and How?

The European Union has made great strides to enhance cybersecurity over the past few years, with a comprehensive framework of core legislative acts designed to protect critical infrastructure. The EU Cyber Resilience Act, originally published as Regulation (EU) 2024/2847 on 20 November 2024, and entered into force on 10 December 2024, shifts the burden of proof so that manufacturers must now show their software is secure, not just claim it.  

On 11 September 2026, a key element of the EU Cyber Resilience Act came into effect: the vulnerability and incident reporting obligations, which require actively exploited vulnerabilities in products with digital elements and severe incidents impacting product security to be escalated to the relevant bodies. This puts responsibility squarely on manufacturers, software publishers, and hardware integrators to prove their software can be trusted. 

Critically, the EU Cyber Resilience Act has global implications. It doesn’t only apply to manufacturers physically based in Europe; the European Commission explicitly states that non-EU manufacturers must comply with the CRA to access the EU market. This means that businesses based in the U.S., APAC, Middle East, Africa, and LATAM may also be subject to the regulations if they make products with digital elements available in the EU. 

What is the EU Cyber Resilience Act? 

The EU Cyber Resilience Act (CRA) is a European Union standardized regulation for all software and hardware, which requires organizations to fix known exploitable vulnerabilities and provide evidence of security updates. This means organizations that build, import, or distribute connected hardware or software must act now to fundamentally overhaul their engineering and compliance processes. 

Who Does the CRA Impact? 

The CRA is designed to safeguard consumers and businesses by addressing inadequate levels of cybersecurity and security updates in many products and services. Organizations of any size that manufacture, import, or distribute products with digital elements available in the EU, even if the business itself is headquartered outside of the EU, are now required to prove they meet stringent security requirements before market entry in Europe. This includes connected hardware, smart devices, software, and apps. 

• Manufacturers: Have the primary legal duty to ensure their products are secure by design and must supply a Software Bill of Materials (SBOM), address vulnerabilities, and report any security incidents. 
• Importers: Must provide proof that manufacturers have adhered to and completed all conformity assessments, ensuring all products bear the required CE marking before they enter the EU. 
• Distributors: Must confirm that products have the CE mark and correct documentation before selling them on to customers. 

What Happens If CRA Requirements Aren’t Met? 

Failure to meet the new requirements carries hefty fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. From 11 September 2026, manufacturers must comply with the new reporting obligations, and the CRA’s broader cybersecurity requirements will become fully applicable from 11 December 2027. Products already placed on the EU market before 11 December 2027 will only become subject to the CRA’s broader requirements if they undergo a substantial modification after that date; however, reporting obligations under Article 14 will apply from 11 September 2026 to all in-scope products already on the EU market, as well as new products. 

Alongside the financial repercussions, businesses found to be in breach of the CRA regulations also face the threat of market exclusion, product withdrawal, or recall.  

Compliance Requirements for Organizations 

Much like the General Data Protection Regulation (GDPR), the CRA is a sweeping extraterritorial legislative framework. Organizations can ensure compliance by adhering to several core operational pillars, including: 

• Secure by Design: Organizations can no longer ship products with known exploitable vulnerabilities or insecure factory settings. They must conduct a formal cybersecurity risk assessment, minimize the product’s attack surface, and embed secure default configurations before the product ever reaches the market. 
• Continuous Vulnerability Management & SBOMs: Organizations must maintain and update a machine-readable Software Bill of Materials (SBOM) tracking all dependencies, including open-source and third-party components. Furthermore, companies must provide free, secure software updates to patch discovered vulnerabilities for a defined period (typically five years). 
• 24-Hour Incident Reporting: If an organization becomes aware of an actively exploited vulnerability or a severe security incident, it must submit an early warning notification within 24 hours to its national Computer Security Incident Response Team (CSIRT) and ENISA (the European Union Agency for Cybersecurity), followed by a detailed technical report within 72 hours. This can be done through the Single Reporting Platform (SRP) — an online tool developed, operated and maintained by ENISA to enable manufacturers to meet their reporting obligations. For severe incidents, organizations must also inform affected users and publish corrective measures. 

• Conformity Assessments and CE Marking: By 11 December 2027, all products must undergo a formal conformity assessment, with higher-risk products requiring third-party assessment by a Notified Body. Upon successful assessment, the product must bear a CE mark as a visible signal of compliance. 

What Each Requirement Looks like in Practice

CRA requirement	What it really asks of you	How Veracode gets you there
Secure by Design	No shipping known exploitable flaws or insecure defaults. Security baked in before release, with documented evidence of architectural decisions.	Static analysis and software composition analysis catch exploitable flaws at the design and build stages, while Veracode Fix remediates them before they ever reach a release. Findings are documented, so you have the evidence regulators expect.
Continuous Vulnerability Management & SBOMs	A live, machine-readable SBOM (CycloneDX / SPDX) covering every dependency, including open source and third-party. Free, secure updates for a defined support period (typically five years).	SCA and the SBOM API generate and maintain SBOMs continuously, including for third-party components you didn’t write. Always current, not a one-time snapshot.
24-Hour Incident Reporting	Early warning to the coordinating CSIRT and ENISA within 24 hours of learning about an actively exploited vulnerability or severe incident; full technical report within 72 hours.	Reachability Analysis tells you which flaws are reachable — the ones that can become reportable. Veracode Fix closes them fast enough to beat the clock.
Pipeline Defense & Artifact Integrity	No known vulnerable or malicious components entering your build pipeline.	Package Firewall blocks noncompliant, risky, or policy-violating open-source artifacts at the CI/CD gate, automatically.
Conformity Assessment & CE Marking (by Dec 2027)	Formal assessment of your security posture — self-assessment or third-party Notified Body audit, depending on risk classification — with documented proof of continuous risk management.	Findings correlated into a single view give you the programmatic, auditable record of application risk management you need to demonstrate conformity.

What Can Organizations Do Now to Ensure They’re Prepared and Compliant? 

The CRA has far-reaching implications for organizations inside and outside of the EU. Traditional AppSec capabilities are essential for analyzing and fixing code after it’s been written, and the CRA legally mandates that security must be integrated during the initial design phase. There are several ways to achieve compliance. 

• SBOM Generation and Maintenance: The CRA explicitly demands machine-readable SBOMs (CycloneDX and SPDX) detailing all top-level dependencies. Veracode’s Software Composition Analysis (SCA) and SBOM API allow organizations to maintain up-to-date documentation, even for third-party, black-box components they didn’t write and can’t see. 
• Pipeline Defense and Integrity: Veracode Package Firewall provides an automated governance solution to proactively block vulnerabilities, malware, and noncompliant policies or risky open-source artifacts from entering CI/CD pipelines. 
• Remediation and Prioritization: The strict 24-hour early warning requirement for actively exploited vulnerabilities is brutal, especially considering third-party and open-source flaws have a fix half-life of 358 days. AI-powered Veracode Fix makes mean time to remediation up to 3X faster and shrinks flaw detection time by 92% — the difference between catching a flaw before it’s reportable and explaining to ENISA why you didn’t. 
• Unified Risk Visibility: Regulators expect centralized risk management. Veracode correlates and contextualizes findings into a single view, supporting the disciplined, programmatic risk management required to prove conformity. 

The 24-hour reporting clock is already ticking. When you can’t see your supply chain, can’t tell which flaws are reachable, and can’t fix them before they’re reportable, what was a process gap becomes a regulatory one. Veracode’s application risk management platform does all three and leaves you with the documented evidence to prove it. 

Software Trust is Now a Universal Business Imperative 

In modern software systems, risk rarely lives in a single file or device. It resides in connected components, where trust extends from one file or device to another. When one component is trusted, everything connected to that component inherits the same level of trust through dependencies. The issue is, once a vulnerability is introduced downstream, those very same dependencies become weaknesses. The software supply chain is poisoned, which, in turn, breaks the trust. 

Software supply chain attacks often involve components that were introduced legitimately and increasingly trusted over time. Rather than targeting a single obvious flaw, attackers can exploit this inherited trust. And the scale of the problem is staggering: 66% of the most dangerous vulnerabilities we see come from third-party and open-source code. That’s the part of your software you didn’t write and can’t see. Our 2026 State of Software Security report data reinforces the point: 70% of critical security debt stems from third-party open-source code. The fix timelines tell the rest of the story. Across all flaw types, the average organization takes 243 days to fix half of its known vulnerabilities. For third-party and open-source flaws specifically, that stretches to 358 days — nearly a full year.  Against a 24-hour reporting deadline, that gap is the difference between compliance and a regulatory crisis. 

The EU CRA raises a question that the industry should have been asking for years: can I trust this software is secure? This is the question Veracode has been answering for two decades, across 47 million scans, 229 million flaws identified, and 148 million fixed. The CRA is asking the whole industry to prove what we’ve been proving all along. 

It mandates organizations to ensure their software can be trusted from the outset. And it should not be considered in isolation. Alongside other directives, like DORA, the Product Liability Directive (PLD), the EU Cybersecurity Act, and the Network and Information Systems Directive 2 (NIS2), it amplifies engineering best practices and turns product security from a post-release afterthought into an enforceable prerequisite for market entry. 

If you’re rebuilding your engineering and compliance processes around the CRA, you don’t have to do it alone. Book time with Veracode to map your current AppSec program against the CRA’s requirements, find out where you’re already ahead, and learn where the gaps are.