FreeBSD prepares for the EU Cyber Resilience Act: what open source must report

What the Act requires

The EU Cyber Resilience Act (CRA) sets two sets of dates. The reporting duty under Article 14 applies from 11 September 2026 ^[1]. The essential product requirements in Annex I apply from 11 December 2027 ^[2].

Article 14 requires manufacturers to report actively exploited vulnerabilities and serious incidents through ENISA's single reporting platform ^[1]. An actively exploited vulnerability is one that is being used to compromise systems in the wild. A serious incident is one that has caused, or is likely to cause, significant operational disruption or financial loss, or that affects a large number of users ^[1].

The timelines are tight. The first notification of an actively exploited vulnerability is due within 24 hours of becoming aware of it. An intermediate report follows within 72 hours, and a final report within 14 days ^[1]. For serious incidents, the manufacturer has 24 hours to send an early warning and 72 hours to submit an incident notification ^[1].

The FreeBSD Foundation's October 2026 update explains how it is preparing ^[3]. FreeBSD is an open-source operating system used in networking equipment, storage systems and embedded devices. The foundation coordinates the project and manages its security response.

How open source fits

Open-source projects generally do not place products on the market themselves. The CRA defines a manufacturer as the entity that develops or has a product manufactured and places it on the EU market under its name or trademark ^[1]. That is usually a company that builds a commercial product using open-source components, not the open-source project itself.

But the reporting duty can still apply to open-source maintainers in two situations. First, if the project itself distributes a product with digital elements under its own name, such as a pre-built image or an appliance. Second, if the project acts as a coordinating body for vulnerability handling and incident reporting on behalf of downstream manufacturers ^[3].

The FreeBSD Foundation appears to be taking the second path. It runs FreeBSD's security officer function and coordinates responses to vulnerabilities. That makes it a natural point for manufacturers using FreeBSD to route their CRA reports, and for ENISA to contact when a FreeBSD vulnerability is being actively exploited ^[3].

The reporting platform

ENISA, the EU Agency for Cybersecurity, operates the common reporting platform ^[1]. Manufacturers register once and use the platform for all CRA reports. The platform is also the point of contact for national authorities and for ENISA itself when it needs to reach manufacturers quickly ^[1].

The FreeBSD Foundation's update notes that it has been in touch with ENISA about how the reporting process will work in practice ^[3]. One detail that matters: the clock starts when the manufacturer becomes aware of the vulnerability or incident, not when someone else reports it. That puts a premium on detection, internal communication and having a plan for who sends the first notification.

What a sealed incident timeline does

When the law sets a deadline from the moment you became aware of something, the question of when that moment was can become disputed. An auditor or a supervisor may later ask why the early warning went out after 30 hours instead of 24.

Here, the thing to seal is each step of the incident as it happens: the first detection note, the decision to escalate and each report as it is sent. Sealing takes a fingerprint, not the content, so the report itself never leaves your systems. The fingerprint goes to WitniumChain, and you get a witness ID back.

If the timeline is questioned, anyone you share the sealed records with can calculate the fingerprint again and check that it matches. If it does, the record is exactly what was written at that time. Change a single character and it won't match.

That doesn't show that the report was complete, or that your response was adequate. What it shows is when each step was recorded, in a way nobody can quietly rewrite afterwards. The content stays with you. You send a fingerprint through the REST API, the SDK or the MCP server, and the first 2,000 witnesses a month are free. Read the documentation for how to integrate it.

How it would work

1. Your security team detects a vulnerability being exploited and writes the first note. You seal a fingerprint of that note.
2. The team escalates and drafts the 24-hour notification. You seal a fingerprint of the draft and, separately, of the sent version.
3. Later, if asked when you became aware, you share the sealed records. Anyone can check that they haven't changed.

What this means for you

If you manufacture products with digital elements that will be placed on the EU market after 11 September 2026, decide now who will handle CRA reporting and how they will know when the clock starts. If you use open-source components, check whether the upstream project offers coordinated reporting, and whether you need to register separately with ENISA's platform.

If you maintain an open-source project that is used in commercial products, consider whether you will take on a coordination role for CRA reporting, and if so, what that will require in terms of process and resources.

Ask: if we detected an exploited vulnerability today, could we send the first notification within 24 hours? And if the timeline were later questioned, could we show when we became aware?

What to watch

• 11 September 2026: reporting duty applies under Article 14 of the CRA ^[1]
• 11 December 2027: essential security requirements in Annex I apply, including the ability to log and monitor security-relevant events ^[2]

Sources

^[1] Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), Articles 14 and 20, Official Journal of the European Union, 20 November 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj

^[2] Regulation (EU) 2024/2847, Annex I: Essential cybersecurity requirements, https://eur-lex.europa.eu/eli/reg/2024/2847/oj

^[3] October 2026 Update: Getting Ready for the EU Cyber Resilience Act, FreeBSD Foundation, October 2026, https://freebsdfoundation.org/blog/october-2026-update-getting-ready-for-the-eu-cyber-resilience-act/