EU Cyber Resilience Act's first obligations hit software makers September 11

What happens on September 11

The EU's Cyber Resilience Act (CRA) begins enforcing its first obligations on September 11, 2026, and according to a widely shared dev.to overview of the regulation, two mandatory reporting duties take effect that day: developers must report actively exploited vulnerabilities found in their products, and they must report severe security incidents affecting their users.

The timelines are compressed. Per the dev.to post, an early warning must reach ENISA, the EU's cybersecurity agency, within 24 hours, a full incident notification within 72 hours, a final report within 14 days once a fix is available for vulnerabilities, and within one month for severe incidents. Missing those windows puts a company in breach of EU law.

The scope is broader than it looks

The CRA is described as the EU's first horizontal cybersecurity law for digital products: not sector-specific and not voluntary. Apps, libraries, firmware, IoT devices, SaaS, desktop software and frameworks are all in scope if they are sold in the EU. The only exemptions are products already covered by other EU rules — medical devices, vehicles, aviation and marine equipment.

Crucially, the reporting duties apply to products already on the market, not just software shipped after the deadline. The author argues this is the fine print most legal teams missed: because the full CRA requirements do not bite until December 2027, many assumed there was plenty of time. If software is deployed in the EU today and an exploited vulnerability surfaces next month, the 24-hour clock still applies.

That implies having in place, right now, a process to detect actively exploited vulnerabilities, a triage workflow to determine whether something meets the reporting threshold, a designated person able to file with ENISA's Single Reporting Platform, coordination between security, legal and product teams, and documentation of every decision, which regulators can request.

The open source question

The dev.to piece highlights a carve-out that is narrower than many assume. Open source developed and distributed without commercial intent — hobby projects, community-maintained libraries where nobody earns money — is exempt. Open source with commercial involvement is not: if a company maintains a library and offers paid support, consulting or a commercial edition, the CRA treats it as a manufacturer, with the same reporting and conformity obligations. The post names open-core companies such as Elastic, MongoDB and HashiCorp as fully in scope, along with any company shipping commercial software that bundles open source dependencies.

What December 2027 brings

The full requirements arrive in December 2027. According to the source, Annex I Part I sets product requirements: secure-by-default design, no known exploitable vulnerabilities at release, secure out-of-the-box configuration, protection against unauthorized access, data confidentiality and integrity, a minimal attack surface, incident logging and monitoring, and security updates for the entire support period. Annex I Part II adds process requirements: a vulnerability handling process covering intake, triage, fixes and disclosure, a software bill of materials (SBOM) for every product, ten years of technical documentation retention, and CE marking.

Conformity assessment scales with product class: self-assessment for most products, third-party audit for categories the regulation labels important, such as password managers, VPNs and identity systems, and mandatory EU certification for critical products like industrial controllers and certain infrastructure.

Practical steps

Before September 11, the post recommends confirming whether you sell to EU customers — the CRA applies regardless of where a company is based — setting up vulnerability intake and triage, registering with ENISA's reporting platform, and documenting an incident response process.

Before December 2027, it suggests generating SBOMs with tools like Syft, CycloneDX or SPDX, auditing security defaults such as default passwords and unnecessary open ports, reviewing update mechanisms, and determining the applicable conformity route. Open source maintainers should check whether sponsorships, paid support, consulting or dual licensing bring them in scope, publish a security policy such as SECURITY.md, and understand that downstream commercial products may depend on their vulnerability handling for compliance.

Why it matters

The dev.to author frames the CRA as the EU doing for product security what GDPR did for privacy, with a 24-hour reporting window tighter than GDPR's 72-hour breach notification. For developers, security shifts from best practice to a legal requirement with concrete deliverables: SBOMs become mandatory, vulnerability handling needs a documented process rather than a fix-it-when-we-get-to-it attitude, and threat models and security decisions must be written down and retained for a decade. Companies that began preparing in 2025 are described as in decent shape; those starting now have about a week to stand up a reporting pipeline and roughly 15 months to overhaul development practices. One caveat: the details above come from a single community post, so teams should verify specifics against the regulation text (2024/2847) and the European Commission's implementation guidance before acting.