On September 11, 2026, the first compliance deadline of the EU Cyber Resilience Act takes effect. If you manufacture a product with digital elements and place it on the European market, you must have a process for reporting actively exploited vulnerabilities and serious cybersecurity incidents to ENISA within 24 hours of awareness.

Five weeks. If this is the first you're hearing of it and you ship software to EU customers, read on.

What the CRA Is

The Cyber Resilience Act entered into force on December 11, 2024. It's an EU regulation — not a directive — which means it applies directly in all member states without national transposition. No waiting for each country to pass its own version.

The law establishes mandatory cybersecurity requirements for "products with digital elements" throughout their lifecycle. That means software, hardware with embedded software, and connected devices. The scope is broad. If your product processes data, connects to a network, or is digital in nature, it's likely in scope.

The timeline is staggered:

  • August 30, 2026: Harmonized standards for horizontal (type A) products must be available.
  • September 11, 2026: Vulnerability and incident reporting requirements become applicable. This is the first deadline that hits manufacturers.
  • October 30, 2026: Harmonized standards for vertical (type C) and horizontal (type B) products.
  • December 11, 2027: All remaining obligations take full effect — conformity assessment, CE marking, technical documentation, post-market monitoring.

The September 11 deadline is narrow but concrete: you need a vulnerability reporting process. Not full conformity assessment. Not CE marking. A process for detecting, tracking, and reporting actively exploited vulnerabilities and serious incidents to the relevant authority.

What "Reporting" Means

The obligation is specific. When a manufacturer becomes aware of an actively exploited vulnerability or a serious cybersecurity incident affecting a product they've placed on the EU market, they must:

  1. Report to ENISA within 24 hours of becoming aware.
  2. Provide a preliminary assessment of the incident or vulnerability, including its impact.
  3. Submit a more detailed report within 72 hours if requested.

This is vulnerability disclosure with legal force. The voluntary CVE process becomes mandatory for in-scope products. For organizations that already have a security disclosure process — coordinated disclosure, security advisories, CVE assignments — this is largely formalizing what you do. For organizations that don't have a process, five weeks is tight but not impossible.

The fines for non-compliance are severe: up to €15 million or 2.5% of global annual turnover, whichever is higher. Products can be pulled from the market until compliance is demonstrated.

The FOSS Question

This is where it gets relevant to the audience of this site.

About 76% of the code in a typical software product is open source dependencies. The remaining 24% is built in-house or procured. The CRA impacts the entire supply chain, including that 76%. This is the law's most significant feature and its most contentious one.

The European Commission and the ORC Working Group have spent considerable effort clarifying how the CRA applies to open source. The current understanding:

Open source projects that are not monetized are not directly impacted. If you maintain a FOSS project on a volunteer basis, with no commercial activity around it, the CRA does not impose obligations on you directly. This was a hard-won clarification — early drafts of the law would have made every maintainer a "manufacturer," which would have been catastrophic for the FOSS ecosystem.

Open Source Stewards have obligations. A "steward" is a foundation or organization that hosts and governs open source projects — the Eclipse Foundation, the Linux Foundation, the Apache Software Foundation. Stewards must implement security policies for the projects under their governance. They don't become manufacturers, but they have due diligence obligations. The Eclipse Foundation's ORC Working Group has been the primary community vehicle for negotiating this distinction.

If you monetize a FOSS project, you're a manufacturer. A company that sells a product built on an open source codebase, offers a hosted/SaaS version, or sells support and services around a project — that company is a manufacturer under the CRA. The open source license doesn't exempt you. The obligation attaches to the commercial activity, not the code.

If you embed FOSS in a product, you're responsible for it. A manufacturer's conformity assessment must account for the open source components in their product. The "I just used a library" defense doesn't work. You need to know what's in your product, including transitive dependencies, and you need to have a process for tracking vulnerabilities in those components.

What the ORC Working Group Has Built

The Open Regulatory Compliance Working Group, hosted by the Eclipse Foundation, has been the practical community response to the CRA. It's the group that negotiated the steward-vs-manufacturer distinction with the Commission, and it's been producing concrete resources:

  • CRA FAQ — a living document answering common questions from open source maintainers about how the law applies to them. Maintained at cra.orcwg.org.
  • White paper on open source software stewards and the CRA — shipped. Defines what a steward is, what obligations apply, and how foundations should structure their security policies.
  • White paper on due diligence obligations of manufacturers — in progress. Will cover the supply-chain requirements that reach FOSS dependencies.
  • Vulnerability management specification — in progress. A technical specification for how vulnerability reporting should work in practice, aligned with the CRA's 24-hour requirement.
  • White paper on SBOMs — planned. Software Bills of Materials are foundational to CRA compliance because you can't report vulnerabilities in components you don't know you have.

The ORC WG operates in the open. Their work is the most practical guidance available for FOSS projects navigating the CRA. If you maintain or steward open source software, their resources page is the starting point.

What This Means for Community Infrastructure Operators

If you're running Proxmox, Nextcloud, Matrix, Keycloak, Postgres, and the rest of the FOSS infrastructure stack for a community — a fire hall, a town office, a small business — the CRA probably doesn't apply to you directly. You're not placing products on the EU market. You're deploying software internally.

But the CRA affects you indirectly in two ways.

First, the software you run will change. The projects you depend on — Debian, NixOS, the Linux kernel, Nextcloud, Synapse, Continuwuity — are now subject to CRA-driven security requirements through their stewards. You'll see more security policies, more vulnerability disclosure processes, more SBOMs, more coordinated disclosure. This is good. It makes the FOSS stack more auditable, which is one of the reasons to choose it over proprietary alternatives.

Second, if you build and distribute software. If your community infrastructure work involves building tools, patches, or distributions that you share publicly — even for free — and especially if you operate in or serve EU users, the CRA's reach depends on whether that activity constitutes "placing on the market." The ORC FAQ covers this distinction. The short version: sharing code on a Forgejo instance isn't placing on the market. Selling a product that includes that code is.

The Five-Week Checklist

If the CRA applies to you — you ship a product with digital elements to the EU — here's what you need by September 11:

  1. Know what's in your product. An SBOM. If you don't have one, syft, trivy, or cyclonedx tools generate them from container images, language manifests, or filesystem scans. This is the prerequisite for everything else. You cannot report a vulnerability in a component you don't know you have.

  2. Have a vulnerability intake process. A way for people to report security issues to you. A security@ email address monitored by a human. A security.txt file at /.well-known/security.txt on your product's domain. A private vulnerability reporting channel (GitHub's private advisories, Forgejo's issue templates, etc.).

  3. Have a vulnerability tracking process. When a CVE drops for a dependency in your product, someone needs to see it, assess whether it affects you, and decide what to do. Subscribe to the NVD feed for your dependencies. Use dependabot, renovate, or osv-scanner to automate detection.

  4. Have a reporting process. The 24-hour clock starts when you become aware. Know where to report (ENISA's CSIRTs Network portal). Know who in your organization is authorized to file the report. Have a template ready: product name, vulnerability identifier, affected versions, impact assessment, mitigation status.

  5. Document all of the above. The CRA is about demonstrable process, not just having a process. Write it down. Put it in a security policy. The ORC WG's security policy specification for stewards is a good template even if you're not a steward.

The Broader Pattern

The CRA is the first regulation to explicitly address the open source supply chain in software products. It's imperfect — the steward definition is still being refined, the boundary between "monetized" and "non-monetized" FOSS is blurry, and the 24-hour reporting window is aggressive for small teams. But it establishes a principle that aligns with how FOSS infrastructure should work: you should know what you're running, you should track vulnerabilities in it, and you should have a process for responding.

These are things community infrastructure operators should do anyway. The Matrix homeserver security release on July 28 — 11 vulnerabilities, 6 rated high — is a concrete example. If you run Synapse, you need to know about that release, assess whether your deployment is affected, and patch. The CRA formalizes this obligation for commercial actors. The operational practice is the same whether or not the law applies to you.

The auditability point matters here too. When a CRA-regulated product has a vulnerability, the manufacturer must disclose it, report it, and fix it — on a legal timeline, with documented process. When a proprietary product has a vulnerability, you find out when the vendor's PR team decides you find out. The CRA extends the FOSS security model — transparent, auditable, community-verifiable — into the regulatory framework. That's not a coincidence. The FOSS community, through the ORC WG, shaped the law's treatment of open source. The result reflects FOSS values: disclosure, process, accountability.

What to Watch

The September 11 deadline is the first of several. The full CRA obligations take effect December 11, 2027 — conformity assessment, CE marking, technical documentation. That's the heavy lift. The next 15 months are preparation time.

The ORC Working Group's pending deliverables — the vulnerability management specification, the SBOM white paper, the due diligence white paper — will land between now and the full compliance date. Track them at orcwg.org.

The European Commission's CRA implementation guidance page is being updated regularly. The Commission's FAQ has been the authoritative source for clarifications on scope and obligations.

For community infrastructure operators specifically: the CRA doesn't change what you should be doing. It gives you a regulatory framework to point at when arguing for security practices in your organization. "The EU requires vulnerability reporting within 24 hours" is a more persuasive argument than "we should have a security process." Use it.

Resources

The CRA is not a reason to stop using FOSS. It's a reason to use it more deliberately. Know what you run. Track vulnerabilities. Have a process. These are things you should do regardless. Now there's a law that says so.