- September 11, 2026 · Article 14 enters applicationArticle 14 has applied since September 11, 2026
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.Article 14 has applied since 11 September 2026. Manufacturers must now be able to report actively exploited vulnerabilities and severe product-security incidents under the CRA, within 24 hours of becoming aware. 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 manufacturersReporting obligation in force since this date
Expert briefing · 16 min
Article 14 is in applicationSince 11 September 2026, in-scope manufacturers have had 24 hours to file an early warning.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.For this page, the key date is 11 September 2026, when Article 14 reporting obligations started applying. The next milestone is 11 December 2027.
10 December 2024CRA entered into force.11 June 2026Provisions on notification of conformity assessment bodies started applying.11 September 2026Reporting goes liveReporting is live
Article 14 reporting obligations apply, and the ENISA Single Reporting Platform is used for submissions.Article 14 reporting obligations have applied since this date, and the ENISA Single Reporting Platform is used for submissions.11 December 2027Next milestone
Main 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 notifySince 11 September 2026, manufacturers have had 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.The platform is reached through the URL published on ENISA's SRP page, and registration runs through EU Login. If you are not registered yet, every step below still applies, only now the clock is running.
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. It is the Member State where decisions about the cybersecurity of your products are predominantly taken. If that cannot be determined, it is the Member State where your EU establishment has the most employees. If you have no main establishment in the Union, the article sets an order to work through: your authorised representative, then your importer, then your distributor, then the Member State with the most users of your products. ENISA published the list of CSIRTs designated as coordinators on 4 September 2026, so once you have the Member State you can now name the team and record its contact details.
Can be done todayStep 3Get submit-on-behalf validated
If a representative will file for you, the coordinating CSIRT validates that permission. Registration runs on an EU Login account with multi-factor authentication enabled, and there is one primary authorised representative per manufacturer, who registers by selecting the coordinating CSIRT and providing the manufacturer's details. Secondary representatives join by invitation from the primary. Validation happens after your first access and runs in parallel with the reporting process, so it does not stop you submitting while it is pending. The procedure and the processing time vary between CSIRTs and are each CSIRT's own responsibility, so there is no single EU-wide turnaround to plan against.
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
- Title
- Summary
- Name of the manufacturer or open-source software steward
- Product name, and the product version
- The date and time you became aware, of the actively exploited vulnerability or of the incident
- 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 still the point: eight short fields, and every one of them is something you already know at the moment you become aware. The 24-hour filing is an act of assembly, not authorship, provided the template exists before the clock starts.
Run your own clock, not ENISA's
The platform shows reminder counters, and in this release the 72-hour counter starts from the moment you submitted the 24-hour early warning, not from the moment you became aware. If you filed the early warning quickly, the platform can show your notification as overdue while you are still inside the 72 hours the regulation actually gives you. ENISA says this logic will be updated in a future release, and that the counters do not replace the duty to comply with Article 14.
For actively exploited vulnerabilities there is no final report counter at all, because that deadline runs from the date a corrective or mitigating measure becomes available and the platform has no way to know that date. For severe incidents the counter shows one month after the 72-hour notification. Your evidence log is the authoritative clock. The platform's counter is a reminder.
Four more things worth knowing about the platform
- There is no API at launch. You can automate everything upstream, inside your own systems, but the submission itself is a person in a web form, at every stage, for every product. Plan the rota, not just the template. ENISA says API functionality may be considered in a future phase.
- Voluntary reporting is not available on day one.Voluntary reporting is still not available. From 11 September the platform accepts mandatory notifications only.The platform accepts mandatory notifications only. The functionality for voluntary reporting under Article 15 comes at a later stage.
- If the platform is unavailable, wait and submit once it is back. You may contact your coordinating CSIRT directly in the meantime if you judge that immediate communication is necessary, but the notification must still be submitted through the platform afterwards. Contacting the CSIRT does not discharge the obligation.
- There is a helpdesk, and ENISA describes it as being especially for SMEs. It runs alongside the helpdesk support provided by the coordinating CSIRTs, at cra-srp-helpdesk@enisa.europa.eu. Note also that validation of a representative is not optional indefinitely: there is a ceiling on how many notifications a non-validated representative can file before validation becomes mandatory.
Where these facts come from
Every statement in this section is taken from a document ENISA has published. They are listed here rather than buried in a sidebar, because on this subject the source matters as much as the summary.
Single Reporting Platform
Authorised representative guidance
- User registrationUpdated 3 Aug 2026
- Notification submission and updateUpdated 3 Aug 2026
- Interface functionsUpdated 14 Aug 2026
ENISA studies and tools
Our recommendation
Steps 1, 2 and 4 can be completed today, in full, before the platform is even reachable.Steps 1, 2 and 4 can be completed in an afternoon, whether or not you have registered yet. Step 2 changed on 4 September: with the coordinating CSIRT list published, you can determine the Member State from Article 14(7) and then name the team and its contact rather than leaving a placeholder. 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.Step 3 is the one to do now rather than 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 7 September 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 availableStarting from behindWhat is achievable before 11 SeptemberWhat is achievable in four weeks
A common question from teams starting late is whether it is still worth beginning. It is.Article 14 is in application, and teams that are not ready still ask whether it is worth starting now. 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.Starting with the first list and returning to the second is a legitimate sequence. It is materially better than operating under Article 14 with nothing tested.Why Red Alert LabsOur credentials on CRA Article 14
- ISO/IEC 17025 accredited evaluation laboratory (ITSEF) under the EUCC scheme, up to the substantial assurance level
- 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 secured17025ISO/IEC accredited evaluation laboratoryEUCCScheme, up to substantial assurance level2023Campus Cyber white paperExpert 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 deadlinenow that the obligation is live. 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.