The EU Cyber Resilience Act for US Companies: What Engineering Teams Must Prepare Before September 2026
The EU Cyber Resilience Act mandates cybersecurity standards for all "products with digital elements" sold in the European market. For US companies, this means your software, IoT devices, and connected products face binding requirements that go far beyond voluntary US frameworks. The first enforcement deadline is months away.
The Deadlines That Matter
June 11, 2026: The framework for Conformity Assessment Bodies becomes operational. These are the third-party auditors who will assess products in higher-risk categories.
September 11, 2026: Mandatory reporting of actively exploited vulnerabilities within 24 hours. This is the deadline US companies are most focused on because it requires operational readiness — not just policy, but functioning triage-to-report workflows.
December 11, 2027: Full application of all cybersecurity requirements and mandatory CE marking. By this date, products must demonstrate secure-by-design, vulnerability handling, and ongoing support commitments.
The 24-Hour Vulnerability Reporting Challenge
September 2026 is the immediate operational challenge. When an actively exploited vulnerability is discovered in your product, you have 24 hours to submit an early warning to EU authorities. This isn't a policy exercise — it requires engineering teams to have automated vulnerability detection in their CI/CD pipeline, pre-built triage workflows that can classify severity within hours, documented escalation paths from engineering to legal to regulatory affairs, and template-ready reporting that can be submitted to ENISA within the window.
Most US companies don't have this infrastructure. The ones that do have it built it for SOC 2 or FedRAMP — and even those teams are finding CRA's 24-hour window significantly tighter than anything they've operated under before.
SBOMs: The Foundation You Can't Skip
The CRA requires a machine-readable Software Bill of Materials for every product with digital elements. Without an SBOM, you cannot meet the September 2026 vulnerability reporting obligations — because you won't know whether a newly discovered vulnerability affects your product's components.
US engineering teams are investing in automated SBOM generation integrated into their build pipelines. The SBOM must be kept current — not generated once and filed. Every dependency update, every transitive dependency change, needs to be reflected. This is a practice maturity issue: teams with strong dependency management practices can generate SBOMs as a natural output; teams without them face a significant tooling and process gap.
End-of-Life Dependencies: Technical Debt Becomes Legal Liability
The CRA turns what was previously an engineering inconvenience into a legal obligation. If your product ships with end-of-life frameworks — legacy versions of Node.js, AngularJS, Vue 2, or any dependency no longer receiving security patches — you're shipping a product that can't meet CRA vulnerability handling requirements.
US manufacturers are searching for commercial support providers that offer patched versions of abandoned frameworks. But the longer-term solution is practice maturity around dependency lifecycle management — knowing what you depend on, tracking end-of-life dates, and budgeting upgrades as a compliance obligation rather than an engineering preference.
CE Marking and Conformity Assessment
Approximately 90% of products can self-assess conformity. The remaining products — those classified as "important" (Class I) or "critical" (Class II) — require third-party audits from accredited Conformity Assessment Bodies. Higher-risk categories include industrial control systems, password managers, firewalls, VPNs, and operating systems.
Even for self-assessed products, the evidence burden is substantial. You must demonstrate secure default settings, mandatory encryption, vulnerability handling procedures, and support commitments covering the product's expected lifetime (minimum five years).
Mapping US Standards to CRA Requirements
US companies with NIST SP 800-218 (Secure Software Development Framework) compliance have a significant head start. The SSDF's secure-by-design principles align well with CRA requirements. However, the gaps are real: NIST doesn't mandate the 24-hour reporting window, doesn't require machine-readable SBOMs with every release, and doesn't impose product lifetime support obligations.
The financial risk for non-compliance is substantial — fines of up to €15 million or 2.5% of total annual global revenue, a penalty structure deliberately modelled on GDPR.
Practice Maturity Is Your Compliance Foundation
Every CRA requirement maps back to engineering practice maturity. SBOM generation requires dependency management practices. Vulnerability reporting requires detection and incident response practices. Secure-by-design requires security review and testing practices. CE marking evidence requires documentation and release management practices. The teams that will meet these deadlines without heroic effort are the teams whose foundational practices are already in place.