Skip to content
Book a call
🇩🇪 Deutsch 🇬🇧 English 🇫🇷 Français
Flagships
Perstat Uptime monitoring, incident management and status pages for teams who promise availability. NextPKI Find, renew and manage certificates, whoever issued them. Databurg Audit-proof compliance documentation for companies with reporting duties.
Trust & crypto
sqlclient A native database client for macOS. Local, with no detour via someone else's servers. FoldMail An email client with encryption that is meant seriously, S/MIME and OpenPGP. Claro An app for separated parents: handovers, arrangements and costs in one place.
Bundle of the month
Reliability Bundle

Perstat + NextPKI as a single billed package. NIS2 evidence and certificate lifecycle from one cockpit.

Learn more
Learn
Blog Release notes, compliance news, roadmap. Careers
Trust
Legal & privacy DPA, sub-processor list.
Bundle of the month
Reliability Bundle

Perstat + NextPKI as a single billed package. NIS2 evidence and certificate lifecycle from one cockpit.

Learn more
Products Perstat NextPKI Databurg sqlclient FoldMail Claro
Imprint
Language
🇩🇪 Deutsch 🇬🇧 English 🇫🇷 Français
Book a call
Skip to content
Compliance & Product Security

The Cyber Resilience Act: What 11 September 2026 Means for Makers of Digital Products

09.06.2026 · 3 min read

The first binding CRA obligations apply from 11 September 2026. What reporting actively exploited vulnerabilities, SBOMs and security by design mean in practice for manufacturers, importers and distributors.

In about three months a regulation turns into operational reality. From 11 September 2026 the first binding obligations of the Cyber Resilience Act (Regulation (EU) 2024/2847) take effect, and they happen to be the ones that demand the most process: reporting actively exploited vulnerabilities and severe security incidents. The remaining product and conformity obligations follow with full application on 11 December 2027.

Anyone who manufactures, imports or distributes products with digital elements in the EU should therefore treat September not as a distant date, but as the day a working reporting path has to exist.

What begins on 11 September 2026

The CRA requires manufacturers to report an actively exploited vulnerability or a severe security incident through a staged procedure. An early warning goes to the responsible CSIRT and to ENISA within 24 hours, a fuller notification follows within 72 hours, and a final report comes later. This runs through a single European reporting platform.

The distinction from NIS2 matters: there, an affected entity reports incidents in its own operations. Under the CRA, the manufacturer reports a vulnerability in its product, regardless of which customer is affected by its exploitation. Both regimes can apply at once, and they call for different reporting paths.

What is added by December 2027

The reporting duty is only the first building block. With full application, the CRA demands demonstrable security across the entire product lifecycle:

  • Security by design: security is part of development, not a later add-on. This includes secure default settings and an attack surface kept as small as possible.
  • Software Bill of Materials (SBOM): manufacturers must know and document the components and dependencies they ship. Without this inventory, a new vulnerability leaves the simple question unanswered: is my product affected?
  • Vulnerability management and updates: security updates must be provided for at least five years, or for the expected lifetime of the product if that is shorter.
  • CE marking: from December 2027, products with digital elements may no longer be placed on the EU market without CRA conformity.

There is no exemption for small and medium-sized enterprises. Anyone making or importing covered products falls under the regulation regardless of size.

What this means in practice

The reporting duty from September is organisationally harder than the short deadline suggests. Twenty-four hours to an early warning is no time to start clarifying who is responsible. It requires a named owner in advance, a documented process, and the technical ability to detect an incident promptly at all.

This is where two topics that are often handled separately come together: detecting (monitoring and security posture) and evidencing (a traceable record of who reported what and when). Anyone who has already built both for NIS2 or ISO 27001 can build on it. In our Perstat module this pattern of continuous monitoring and auditable evidence is built in, but the regulatory requirement stands independently of any tool: without reliable detection, every reporting deadline runs empty.

What is worth doing now

Three steps pay off before September. First, clarify which of your own products count as “products with digital elements” and thus fall within scope. Second, set up the reporting process for actively exploited vulnerabilities, with clear ownership and the 24-hour, 72-hour and final-report deadlines. Third, begin building an SBOM, because it is the precondition for being able to say at all, in an emergency, whether you are affected.

The 11th of September 2026 marks not the end of preparation, but the start of the obligation. The work behind it, detection and documentation, cannot be caught up in 24 hours.

Back to the blog

Datargo Datargo

Datargo GmbH, Frankfurt am Main. We build and operate our own software products on our own infrastructure in the European Union.

EU hosting, Frankfurt GDPR-native Made in Germany
Products
  • Perstat
  • NextPKI
  • Databurg
  • sqlclient
  • FoldMail
  • Claro
Company
  • Contact
  • Careers
  • Blog
  • Status page
Legal
  • Imprint
  • Privacy
© 2026 Datargo GmbH. All rights reserved.
Germany · English

Datargo® and Databurg® are registered trademarks of Datargo GmbH. All other product names, logos, and trademarks mentioned are the property of their respective owners.