Cyber Resilience Act Reporting: 10 Tips for Sept 11

Short version: from 11 September 2026, Article 14 of Regulation (EU) 2024/2847 obliges manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform on a 24-hour, 72-hour and 14-day clock. The obligation reaches products you placed on the market years ago, the platform ships without an API, and picking the wrong coordinating CSIRT invalidates the notification.

This is for whoever owns product security at a company selling software, firmware or connected hardware into the EU. If your legal team has the CRA filed as a December 2027 problem, they are describing the conformity half. The reporting half starts in two days, and most of the operational work below is unglamorous inventory and timestamp discipline rather than engineering. If your release process already emits an SBOM per artifact, you are further along than you think.

Ten tips before the clock starts

1. Inventory the products you stopped selling, because they are in scope too. Article 69(3) of the Regulation extends Article 14 to every in-scope product placed on the market before 11 December 2027, with no carve-out for discontinued lines, end-of-life models or firmware nobody has touched since 2019, a reading the CRA-tracking site cyberresilienceact.eu spells out in detail. Those legacy products owe you nothing on Annex I essential requirements, conformity assessment or CE marking. They owe the report. Build one table and keep it where the incident runbook lives:

The rows with "no" in column four are the ones that will hurt, and for those a binary scan of the shipped artifact is the only component list you are going to get, so decide which scanner you point at it before the incident. Auditing an old estate against a fresh obligation table is the same exercise as repointing a control crosswalk when the IDs move: the table is cheap, and the value is in the query that finds every row you forgot.

1. Determine your coordinating CSIRT on paper before you need it. ENISA's Single Reporting Platform FAQ is blunt that selecting the wrong CSIRT designated as coordinator invalidates the notification, and the platform asks you for it at registration. The test is your main establishment, meaning where decisions about your products' cybersecurity are predominantly taken, which is frequently a different city from your registered office. Where it is genuinely unclear, the fallback chain runs through largest EU establishment, then authorised representative, then importer, then distributor, then user-base concentration. Write the reasoning down, date it, and check the Member State entry against ENISA's coordinating CSIRT list, published on 4 September 2026.
2. Create EU Login accounts with MFA today and register on the platform later. Platform access runs on personal EU Login accounts with multi-factor authentication, with one Primary Assigned Representative per manufacturer who can invite up to 20 Secondary ARs. Account creation at https://ecas.ec.europa.eu/cas/login needs no approval and takes minutes. Do it for a filer and at least one deputy now, so nobody is doing an authenticator enrolment at hour 19 of a 24-hour window.
3. Know that an unvalidated account is capped at 20 notifications. ENISA runs manufacturer validation in parallel with reporting, so a pending validation does not block your first filing, per the same FAQ. The ceiling bites later: an unvalidated AR may submit up to 20 notifications before validation becomes mandatory. For a single-product manufacturer that limit is theoretical. For a large portfolio having a bad quarter it is a queue worth clearing while nothing is on fire.
4. Compose the notification outside the platform, then transcribe it. There is no API at initial release, every field is typed by a human into a web form, and platform drafts are not visible to colleagues, so two people cannot co-author one report inside the tool. Keep a skeleton in the shared document your incident process already uses:

   notification_type:   early warning
   awareness_utc:       2026-09-14T22:41Z
   awareness_basis:     PSIRT confirmed exploitation from customer PCAP
   awareness_owner:     <name>
   product:             <name> / firmware 4.2.1 to 4.7.0
   coordinating_csirt:  <Member State CSIRT>, per main-establishment note 2026-09-05
   suspected_malicious: yes

1. Record your own awareness timestamp, because the platform records a different one. Article 14 starts the 24-hour clock when the manufacturer becomes aware, while early platform builds capture incident detection, and those two moments diverge whenever triage takes a day to conclude that exploitation is real. Keep a timestamped note of the moment your organisation formed that belief plus the evidence behind it. That note is what you show a regulator, and it is the field an auditor asks for first.
2. Ignore the platform's 72-hour counter and run your own. The counter displays a due date 48 hours after your 24-hour submission, so a report filed at hour 20 can show as overdue while you are still inside the legal window. Compute both deadlines from awareness and put them in the incident tracker:

   # GNU coreutils date; both deadlines derive from awareness, never from submission
   date -u -d '2026-09-14 22:41 UTC + 24 hours' +%Y-%m-%dT%H:%MZ   # 2026-09-15T22:41Z
   date -u -d '2026-09-14 22:41 UTC + 72 hours' +%Y-%m-%dT%H:%MZ   # 2026-09-17T22:41Z

1. Define "actively exploited" as a triage rule bound to signals you can query. Severity alone does not fire the obligation; exploitation does. Article 14(5) defines a severe incident as one that negatively affects the product's ability to protect data or functions, or that has led to malicious code being introduced or executed, so translate that into named sources a duty engineer can check inside an hour: specific EDR or WAF rule IDs covering the affected code path, telemetry or honeypot hits on the vulnerable endpoint, customer-supplied indicators, and upstream PSIRT advisories for components you ship. If the runtime signal does not exist yet, that is a tooling decision to make now rather than during triage, and the Falco, Tetragon and Tracee tradeoffs determine which of those rule IDs you can even write. A trigger definition with no query behind it produces an argument at 2 a.m.
2. Wire the user-notification duty into the same runbook. Article 14(8) requires you to inform impacted users about the vulnerability or incident and the mitigations available, and the coordinating CSIRT may notify your users itself if you fail to do so in time. Your advisory channel has become a regulated control surface. Confirm you can publish a machine-readable advisory and reach the customers running affected versions on the same day you file the early warning; if the only distribution path is a release-notes page, that gap is the expensive one to discover live.
3. Separate the reporting budget from the conformity budget, and classify products anyway. Reporting readiness is a runbook, a CSIRT determination and staffing. Conformity is Annex I engineering, technical documentation and CE marking, due 11 December 2027 for new and substantially modified products, with the Commission's CRA reporting policy page as the canonical timeline. Classify each product now under Commission Implementing Regulation (EU) 2025/2392, which fixes the technical descriptions of the important and critical categories and settles them by core functionality, since that classification decides your 2027 assessment route and costs nothing to establish today. In my experience the split matters organisationally as much as financially: the reporting work lands on the security team and the conformity work lands on product engineering, on different clocks.

The honest counterargument: a small manufacturer with one product and one EU establishment can do tips 1 through 3 in an afternoon and defer the rest until something happens. That position buys real time back, and it is defensible. It costs you the weekend coverage question, because the 24-hour window is wall clock and includes Saturdays.

Wrap-up

The habit that matters is the timestamp. Everything else here is paperwork you can produce under pressure, but the moment your organisation became aware cannot be reconstructed after the fact, and it is the single input deciding whether a report was late. Add an awareness_utc field and a mandatory awareness_basis line to your incident template this week, populate them during triage instead of during the write-up, and derive both deadlines from that field with the date -u -d one-liner above rather than from whatever the platform displays. Cheap control, and it only works if it is already running on the bad day.

Scoping a product inventory across a legacy portfolio, writing the main-establishment memo and rehearsing a filing against a platform with no API is a few weeks of work for someone who has done it before, and it is the point where reading stops being enough.