- September 11, 2026 · Article 14 enters application
CRA Article 14
Readiness
ProgramBe ready before 11 September 2026. From that date, manufacturers must be able to report actively exploited vulnerabilities and severe product-security incidents under the CRA. Red Alert Labs helps you design, document, test, and operate the vulnerability handling and reporting chain required to meet this new obligation.
Watch the 16-minute expert briefing11 September 2026First direct CRA reporting obligation for manufacturers
Expert briefing · 16 min
Time remaining until Article 14 applies--Days--Hours--Minutes--Seconds11 September 2026, the first direct CRA reporting obligation for manufacturers.Key datesCRA timeline at a glance
The CRA timeline spans several legal and operational milestones. For this page, the key date is 11 September 2026, when Article 14 reporting obligations start applying.
10 December 2024CRA entered into force.11 June 2026Provisions on notification of conformity assessment bodies started applying.11 September 2026Reporting goes live
Article 14 reporting obligations apply, and the ENISA Single Reporting Platform is used for submissions.11 December 2027Main CRA obligations apply, including essential requirements, conformity assessment, CE marking, and technical documentation.2028 onwardEnforcement and market surveillance mature, and manufacturers operate CRA as business as usual across lifecycle and updates.How we helpFive ways to get ready for Article 14
From initial gap assessment to ongoing post-market monitoring. Each track can be engaged independently or as part of a structured programme.
CRA Readiness Assessment
A structured four-step engagement that gives you a clear pathway to CRA conformity. This is where most manufacturers start.
- 1 Foundation Assessment: product scoping, classification, and a defined pathway to conformity based on the outcome.
- 2 Readiness Assessment: risk assessment and gap analysis against CRA Article 14 reporting obligations, Annex I vulnerability handling requirements, SBOM expectations, and third-party supplier management.
- 3 Documentation Support: delivered as templates, co-authoring, or turnkey, depending on your team's capacity.
- 4 Technical Verification: conceptual and functional testing, plus documentation verification.
VDP and Vulnerability Handling Process Implementation
Design and roll-out of a Vulnerability Disclosure Policy and the internal handling process that supports it. Includes intake, triage, severity classification, coordinated disclosure, and the evidence trail Article 14 reporting will require.
Core deliverableCRA Training
Targeted training for product, security, legal, and communications stakeholders. Covers Article 14 scope, notification content, the 24-hour and 72-hour milestones, final-report deadlines by trigger, and the operational decisions teams need to make under each. Delivered as workshops or as a structured curriculum.
Team readinessPost-Market Vulnerability Management
Ongoing operational support across three components: Process Design and Setup, Ecosystem Monitoring and Triage, and Impact Analysis and Remediation. Built to keep your reporting chain working after the policy documents are signed and the deadline has passed.
Retainer availableCyberPass
Our AI-assisted compliance automation platform. CyberPass supports evidence management, control mapping, and recurring assessment tasks across CRA, EUCC, and related schemes. Available to clients across the four service tracks above.
Automation platformThe regulationArticle 14 in plain language
Article 14 applies to manufacturers of products with digital elements placed on the EU market. From 11 September 2026, manufacturers must be ready to notify actively exploited vulnerabilities contained in their products and severe incidents having an impact on the security of those products.
Notifications must be submitted via the single reporting platform established by ENISA and made simultaneously accessible to the relevant CSIRT designated as coordinator and to ENISA.
The process follows a staged approach: an early warning within 24 hours, a more complete notification within 72 hours, and a final report. The final-report deadline depends on the trigger: for actively exploited vulnerabilities, it is due no later than 14 days after a corrective or mitigating measure is available; for severe incidents, it is due within one month after the 72-hour incident notification.
Importantly, Article 14 also applies to in-scope products already placed on the EU market before the CRA becomes fully applicable, so manufacturers should not wait until 2027 to prepare their reporting chain.
Manufacturers must also inform impacted users, and where appropriate all users, of the vulnerability or incident and of any corrective or risk-mitigation measures they can deploy.24hEarly warning
Initial notification after becoming aware of an actively exploited vulnerability or severe product-security incident.
72hVulnerability or incident notification
More complete information on the product, exploit or incident, impact, sensitivity, and corrective or mitigating measures.
FinalFinal report
Deadline depends on the trigger. For actively exploited vulnerabilities: no later than 14 days after a corrective or mitigating measure is available. For severe incidents: within one month after the 72-hour incident notification.
Getting on the platformHow to get access to the ENISA Single Reporting Platform
ENISA has now published the practical detail. The platform will be reached through a dedicated public URL, published on ENISA's SRP page before the platform goes live. Registration itself runs through EU Login, and most of the preparation can be done today.
Step 1Create your EU Login account
Manufacturers, open-source software stewards, and authorised representatives register using an EU Login account. ENISA confirms it can be created in advance, at ecas.ec.europa.eu, so this does not wait for the platform to open.
Can be done todayStep 2Identify your coordinating CSIRT
Article 14(7) sets out how to work this out, based on your main location of establishment, or that of your authorised representative if you are not established in the EU. You can apply that rule today. ENISA will publish the list of CSIRTs formally designated as coordinators at a later stage, so confirm the named body when it appears.
Rule available todayStep 3Get submit-on-behalf validated
If a representative will file for you, the coordinating CSIRT validates that permission. ENISA states this happens after your first access to the platform, running in parallel with the reporting process, and it does not affect your ability to submit.
At first platform accessStep 4Build your evidence template
ENISA has published the full data field table by reporting stage. Map your internal evidence log to those exact fields so the 24-hour filing is an act of assembly, not authorship.
Can be done todayWhat the 24-hour filing actually asks for
ENISA has published the full field table by reporting stage, and the 24-hour set is smaller than most teams expect. Only these are obligatory at the early warning:
- Notification type, vulnerability or incident
- Notification level, in this case 24h
- Name of the manufacturer or open-source software steward
- Product
- Title
- For incidents only, whether unlawful or malicious acts are suspected
Member States where the product is available is obligatory only if you hold that information. Reporting times and reporter identity are filled automatically and are not visible to you at all. Everything heavier, the nature of the exploit, measures taken, severity, impact and patch detail, is not due until 72 hours or the final report.
Which is the point: the 24-hour filing is an act of assembly, not authorship, provided the template exists before the clock starts.
Our recommendation
Steps 1 and 4 can be completed today, in full, before the platform is even reachable. Step 2 you can work out today from the rule, then reconfirm against ENISA's designated-coordinator list once it is published. Step 3 cannot be finished until the platform opens, but it can be first in the queue on the day it does rather than something you discover during an incident.
ENISA is clear that the representative validation runs in parallel and does not block a submission. We would still not want to be meeting an account setup, a CSIRT contact, or a validation step for the first time with a 24-hour clock already running. Preparation costs an afternoon now. It costs considerably more later.
Based on ENISA's published SRP guidance, reviewed 27 July 2026. ENISA is still updating this guidance, so check the ENISA SRP page for anything newer.
Where teams commonly stallThree gaps we observe most often
Drawn from our work with manufacturers over the last several years. These are observations, not judgements.
1No Vulnerability Disclosure Policy
Researchers and customers have no defined channel to report findings, and the organisation has no documented intake process to receive them.
2No tested escalation and reporting chain
A policy may exist on paper, but no one has walked a real or simulated incident through it end to end, against the Article 14 clocks, with legal and communications involved.
3Not prepared to use the ENISA platform
The platform requires named submitters, structured information, and supporting evidence. Most teams are not set up to produce these on a 24-hour timeline.
Scope in the time availableWhat is achievable before 11 September
A common question from teams starting late is whether it is still worth beginning. It is. What changes is scope, not viability. The lists below are written for a focused four-week effort, so they will differ if you have more or less time than that.
Achievable in a focused four-week effort
- A documented trigger decision tree and triage procedure. The internal logic for deciding whether a reported vulnerability activates Article 14 is definable in a short engagement. If you do not have this, build it first.
- A named notification owner, EU Login ready. One role, documented, with a deputy, an EU Login account, and the understanding to file an early warning within 24 hours.
- Basic user communication templates. Reviewed and approved templates for the most common disclosure scenarios. Not exhaustive, but functional under pressure.
Not reliably achievable in that window
- A fully tested escalation chain across all products, including legal, communications, and supplier notification workflows. This takes longer to build and verify than four weeks allows if it does not exist today.
- A platform dry run against a live incident scenario, with all stakeholders present and the evidence log populated in real time.
Starting with the first list and returning to the second after September is a legitimate sequence. It is materially better than arriving at 11 September with nothing tested.Why Red Alert LabsOur credentials on CRA Article 14
- EUCC-accredited ITSEF (conformity assessment body)
- Preparing for Notified Body status under the CRA
- Co-author of the Campus Cyber Vulnerability Management White Paper (Ayman Khalil, COO)
- We contribute to the EU bodies shaping the CRA
550+Connected products securedEUCCAccredited ITSEF2023Campus Cyber white paperCRANotified Body (in preparation)Expert briefingWatch the expert briefing
A 16-minute walkthrough of Article 14: what it requires, where manufacturers most commonly stall, and what to prioritise before the deadline. Hosted by Isaac Dangana, Technical Lead at Red Alert Labs.
This briefing features an AI-generated digital twin of Isaac Dangana, produced by Red Alert Labs to deliver it with consistent quality.
Get the Readiness PackIsaac DanganaTechnical Lead, Red Alert LabsFree resourceCRA Article 14 Vulnerability Disclosure and Reporting Readiness Pack
Available now
A 56-page operational reference for product and compliance teams, delivered as an interactive web edition with the full PDF inside. Designed to be used as a working document by teams building or testing their reporting chain.
- Article 14 trigger decision tree and scope checklist
- 24h / 72h / final-report workflow with deadline logic by trigger
- RACI matrix: product, security, legal, compliance, support, executive
- Editable VDP body, ISO 29147 aligned, with RFC 9116 security.txt sample
- Evidence log template for ENISA submission readiness
- User communication and supplier notification templates
- ENISA SRP registration steps and worked example
Get the Readiness Pack
Available now. Register and the interactive pack opens straight away, with the access link emailed to you as well. The full PDF is inside. No login required.