EU CRA: The Compliance Clock Nobody Is Watching
December 11, 2027. The EU Cyber Resilience Act becomes enforceable. Fines up to fifteen million euros or 2.5 percent of global annual turnover, whichever is higher. Mandatory Software Bills of Materials for every product. Twenty-four hour vulnerability disclosure to ENISA on awareness, not on confirmation. CE marking required to sell digital products in the EU.
If your organization sells software, firmware, IoT devices, or anything with digital elements into the European Union, this applies. Open source is partially scoped — commercial open source maintainers and corporate contributors fall under specific obligations. The shape of those obligations is still being clarified through implementing regulations.
Most engineering organizations I work with are doing nothing about this. The mood is identical to GDPR pre-2018 — a regulatory deadline that feels distant until it suddenly does not. The outcome will be similar.
// what the cra actually requires
The Cyber Resilience Act, formally Regulation (EU) 2024/2847, applies to "products with digital elements" sold into the EU market. The definition is broad: software, firmware, components, smart devices, and the cloud services that integrate with them. The regulation classifies products into three categories with progressively stronger obligations.
The four obligations that have the largest engineering impact:
Every product must ship with a Software Bill of Materials in a machine-readable format. CycloneDX and SPDX are the practical formats. The SBOM must list components, versions, suppliers, and known vulnerabilities. The SBOM must be maintained for the support period of the product, which means it cannot be a static artifact generated at release. It must be updated when components are updated.
When a manufacturer becomes aware of an actively exploited vulnerability in their product, they have twenty-four hours to file an early warning notification with ENISA. A more detailed vulnerability notification follows within seventy-two hours. A final report follows within fourteen days. This is not "after we have investigated and confirmed" — it is "when we become aware." The clock starts at internal awareness, not at confirmation.
Products must ship with secure default configurations. No default credentials. No unnecessary services enabled. Authentication required for management interfaces. Cryptographic protections enabled. The CRA defines this in Annex I as a set of essential cybersecurity requirements. Products that ship with admin/admin will not pass conformity assessment.
Manufacturers must provide security updates for the duration of the declared support period, which must be at least five years for most categories. The update mechanism must itself be secure. End-of-life products must be communicated clearly to customers. The "ship it and forget it" model of consumer IoT does not survive CRA.
// the timeline
December 11, 2024 — entry into force. December 11, 2026 — vulnerability reporting requirements become applicable. December 11, 2027 — full applicability of all obligations. The intermediate dates are not theoretical. The vulnerability reporting clock is twenty months away from this writing.
There is no grandfather clause for products already in market. If a product is on the EU market on December 11, 2027, it must comply. The lead time for product changes — particularly in firmware and embedded software — means that work needs to start now if it has not already.
// what to do this quarter
The work breaks into four streams. Each can start independently. Each requires sustained execution.
Build a real, current inventory of what software your organization ships into the EU. Not a Notion document that is eighteen months stale. A maintained registry with product owners, versions, support timelines, and component lists. The inventory is the foundation of every other CRA work stream. If you cannot list your products, you cannot certify them.
Every release pipeline must generate an SBOM. Syft, cyclonedx-cli, Trivy SBOM, and Snyk SBOM all produce CRA-acceptable output in CycloneDX format. Sign the SBOM with cosign. Store it as a release artifact. Make it accessible to customers. The technical work is approximately a week per pipeline. The organizational work — getting every team to do this — is longer.
Establish a documented vulnerability disclosure process. Public security.txt file or equivalent. Monitored intake channel. Defined internal escalation. Defined external communication path. Practice the timeline. The first time you run a twenty-four hour disclosure clock should not be when an actively-exploited bug shows up in your product. Tabletop exercises with realistic scenarios produce significantly better outcomes than paper procedures alone.
Every product needs a security review of its default state. No default credentials. Unnecessary services disabled. Logs configured. Auth required for administrative functions. Encryption enabled where applicable. The review produces a list of changes. The changes go into the product roadmap. The roadmap completes before December 11, 2027.
// the open source question
The CRA has special provisions for open source software. Pure open source maintainers are largely exempt. Open source software made available "in the course of a commercial activity" is in scope. The line between these categories is blurry and is being clarified through implementing regulations and guidance from ENISA.
The practical impact for organizations: if you are a corporate contributor to open source projects that you also use commercially, you have obligations. If you embed open source components in your products, you remain responsible for those components from the perspective of CRA compliance — your supplier chain analysis must include them, and your SBOM must list them.
The "we are not responsible because it is open source" position is not consistent with CRA. Manufacturers integrate components and ship products. The product is what is regulated, regardless of the origin of its components.
// the bottom line
CRA is the largest regulatory shift to hit software product security since GDPR hit data privacy. The fines are large enough to matter to public companies. The scope is broad enough to affect every organization that sells into the EU. The technical requirements are achievable but require sustained engineering work.
The runway feels long. It is not. Twenty months to vulnerability reporting. Three years to full enforcement. The work is not glamorous. SBOM generation, secure defaults, and disclosure infrastructure are unsexy categories. They are also exactly what the regulation requires.
Organizations that start now will treat CRA as a manageable program. Organizations that start in 2027 will treat it as a crisis. The difference is operational maturity. The difference compounds.
