What must I do by 11 September 2026?
Be able to report. Article 14 applies from 11 September 2026, and it is the first CRA obligation with real teeth [1]. Nothing else in the Regulation is due yet — not CE marking, not the technical file — but this one is, and its clock is measured in hours.
What has to be reported
Two things.
An actively exploited vulnerability in your product: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report within 14 days after a corrective measure is available [2].
A severe incident having an impact on the security of the product: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month [3].
"Actively exploited" has a specific meaning: reliable evidence that a malicious actor has exploited the vulnerability in a system without the system owner's permission [4]. It is not every vulnerability you find, and it is not a theoretical proof of concept.
Where reports go
Notifications are submitted through the ENISA single reporting platform, to the CSIRT designated as coordinator in the Member State concerned [5]. ENISA updated its Assigned Representative guidance for the platform on 9 September 2026 — user registration, notification submission and interface functions — and has published a user manual, a glossary, guidance on particularly exceptional circumstances and the list of coordinating CSIRTs; from 11 September 2026 notifications are submitted through the platform [6].
You also have to inform impacted users about the incident or vulnerability, and where appropriate about corrective measures they can take [7].
The five-item readiness list
A contact address a researcher can find. You need a single point of contact for users to report vulnerabilities and to receive information about them [8]. Publish it where someone looking for it will actually look.
A disclosure policy. Manufacturers have a coordinated vulnerability disclosure policy in place [9]. It says what you will do with a report and how fast.
A named decider. Someone must be able to say "this is actively exploited" and start the clock [4]. Twenty-four hours from awareness is not enough time to also work out who is allowed to make that call [2].
Platform access arranged in advance. Discovering the reporting platform during an incident is the failure mode this list exists to prevent [5] [6].
A user-notification path. Know how you would tell affected customers, before you need to [7].
Why the deadline is real
Fines run to EUR 15,000,000 or 2.5% of worldwide annual turnover, whichever is higher, for breaches of the essential requirements and the core manufacturer obligations, with lower tiers for other breaches [10].
The more immediate pressure for most small vendors is commercial rather than regulatory: enterprise customers have begun sending supplier questionnaires that ask exactly these questions, and they arrive well before any market surveillance authority does [9].
What this does not require
It does not require CE marking, a declaration of conformity, or a completed technical file. Those belong to full application, which is later [1]. Reporting readiness is a smaller and more tractable piece of work, which is precisely why it has an earlier date.
What to do next
Run your own product through the checker — it takes under a minute and gives you a dated, citable result you can send to a customer.
Sources
- Article 14 (reporting obligations of manufacturers) applies from 11 September 2026. Art. 71(2) — EUR-Lex ↩
- Actively exploited vulnerability: early warning within 24 hours of awareness; notification within 72 hours; final report within 14 days after a corrective or mitigating measure is available. Art. 14(1)–(2) — EUR-Lex ↩
- Severe incident having an impact on the security of the product: early warning within 24 hours; incident notification within 72 hours; final report within one month after the incident notification. Art. 14(3)–(4) — EUR-Lex ↩
- Actively exploited vulnerability (Art. 3(42)): reliable evidence that a malicious actor has exploited it in a system without the system owner's permission. A severe incident having an impact on the security of the product (Art. 14(5)) is one that negatively affects or is capable of negatively affecting the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led or is capable of leading to the introduction or execution of malicious code. Art. 3(42), Art. 3(44), Art. 14(5) — EUR-Lex ↩
- Notifications are submitted through the ENISA single reporting platform to the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment; a manufacturer without an EU establishment uses the Member State of its authorised representative, or where the product is made available. Art. 14(7), Art. 16 — EUR-Lex ↩
- ENISA single reporting platform: the Assigned Representative guidance pages (user registration; notification submission and update; interface functions) were updated on 9 September 2026, alongside guidance on particularly exceptional circumstances under the third subparagraph of Article 16(2), an AR user manual, an SRP glossary, terms and conditions and the list of CSIRTs designated as coordinators; from 11 September 2026 manufacturers are required to submit Article 14 notifications through the platform. ENISA — EUR-Lex ↩
- After becoming aware of an actively exploited vulnerability or severe incident, the manufacturer informs impacted users, and where appropriate all users, without undue delay, including risk-mitigating and corrective measures. Art. 14(8) — EUR-Lex ↩
- The manufacturer provides a single point of contact for users to report vulnerabilities and to receive information about vulnerabilities. Art. 13(17), Annex I Part II(6) — EUR-Lex ↩
- Manufacturers have a coordinated vulnerability disclosure policy in place and a contact address for reporting. Annex I Part II(5)–(6) — EUR-Lex ↩
- Fines up to EUR 15,000,000 or 2.5% of total worldwide annual turnover, whichever is higher (essential requirements in Annex I; obligations in Arts. 13 and 14); up to EUR 10,000,000 or 2% (other listed obligations, incl. Arts. 18–23, 28, 30, 31, 32); up to EUR 5,000,000 or 1% (incorrect, incomplete or misleading information to notified bodies or authorities). Microenterprises and small enterprises are not fined for missing the 24-hour early-warning deadline; open-source software stewards are not subject to fines. Art. 64(2)–(4), (10) — EUR-Lex ↩
Changes
- — Facts Table v2026.09.4 (F-038 re-check against the ENISA SRP page): F-038 — status rewritten to the 9 September 2026 guidance state; 2026-09-09 Facts Table v2026.09.3 (A-08 Official Journal read): F-002 — cite corrected to Art. 71(2); F-038 — status rewritten to the ENISA-page-supported claim (guidance dated 3 and 14 August 2026; operational by 11 September 2026); F-042 — cite corrected to Art. 13(17); F-033 — cites corrected to Art. 64(2)–(4), (10)
Related
- Does the CRA apply to open-source software I maintain?
Unmonetised open source is not placed on the market and is outside the Regulation. Stewards who systematically support commercial-use projects have a lighter regime. Companies that integrate your code are manufacturers of their products.
- What are the alternatives to CRACheck for Cyber Resilience Act compliance?
CRACheck, CRA Toolkit and OpenRegulatory Formwork all address Cyber Resilience Act compliance. CEMarque's difference is a deterministic, citation-first checker with permanent public verdicts — the fastest comparison is running your own product through it, free.
- Does the CRA require a coordinated vulnerability disclosure policy?
Yes. Every manufacturer must have a coordinated vulnerability disclosure policy in place, a contact address for reports, a single point of contact for users, and a practice of publishing fixed vulnerabilities.
- Does the CRA apply to free or ad-supported apps?
Charging nothing does not put you outside the Regulation. What matters is whether the product is supplied in the course of a commercial activity, and advertising, data and freemium funnels all count.
CEMarque encodes Regulation (EU) 2024/2847 and the European Commission's published guidance as of 10 September 2026 (Facts v2026.09.4). It is not legal advice. Verify obligations for your product with qualified counsel where the stakes require it.