CYBER RESILIENCE ACT · ARTICLE 14
Article 14 reporting support for actively exploited vulnerabilities and severe incidents affecting products with digital elements.
OSTRAI supports manufacturers from initial reportability assessment through deadline control, notification preparation, ENISA Single Reporting Platform submission, impacted-user communications, regulatory coordination and post-notification follow-up.
Where appropriate, an authorised OSTRAI professional can act as the manufacturer’s Assigned Representative within the ENISA reporting platform.
LIVE SINCE11 September 2026
Explore Cyber Resilience Act AdvisoryCURRENT APPLICATION
CRA reporting obligations for manufacturers apply from 11 September 2026, before the CRA applies in full.
Mandatory notifications are submitted through the ENISA CRA Single Reporting Platform.
11 September 2026 · Article 14 reporting applies
Actively exploited vulnerabilities + severe incidents
ENISA CRA Single Reporting Platform
The reporting regime also applies to relevant in-scope products placed on the Union market before 11 December 2027.
ARTICLE 14 THRESHOLDS
A vulnerability contained in a product with digital elements for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner.
Vulnerability ≠ Actively exploited vulnerability
A vulnerability identified through good-faith testing, research or ordinary security review is not automatically subject to mandatory Article 14 reporting merely because it exists.
A severe incident having an impact on the security of the product with digital elements.
The Article 14 threshold includes situations where the incident:
Reportability requires legal and technical classification against the CRA threshold.
IMPORTANT DISTINCTION
A product-security issue capable of exploitation. Can engage CRA product and vulnerability-handling obligations. Does not automatically trigger mandatory Article 14 reporting.
Reliable evidence indicates malicious exploitation has occurred. Can trigger Article 14 mandatory reporting.
Do not collapse CRA product-compliance vulnerability concepts into the Article 14 reporting threshold.
INITIAL TRIAGE
Security event / vulnerability signal
NO →Assess other applicable cybersecurity / regulatory regimes.
YES ↓
VULNERABILITY ↓
YES →Potential Article 14 actively exploited vulnerability.
NO →No mandatory Article 14 AEV reporting on that basis. Assess vulnerability-handling and possible voluntary-reporting implications.
OR: INCIDENT ↓
YES →Potential Article 14 severe incident.
NO →No mandatory Article 14 severe-incident reporting on that basis. Assess other CRA or sectoral obligations.
Document the decision
IF REPORTABLEStart Article 14 workflow
AWARENESS
Article 14 deadlines are measured from the manufacturer becoming aware of the actively exploited vulnerability or severe incident.
Operationally, this makes the awareness timestamp a critical part of the reporting file.
Signal received
Initial assessment begins immediately
Reasonable degree of certainty that the Article 14 threshold is met
Awareness timestamp documented
Article 14 deadline control
The relevant awareness point is not necessarily the completion of a full technical investigation or internal approval process.
The assessment should focus on when the manufacturer, following its initial assessment, has reached a reasonable degree of certainty that:
OSTRAI can help structure the reportability assessment and contemporaneous record of the reporting decision.
ACTIVELY EXPLOITED VULNERABILITY
AWARENESS ↓
24 hours
Without undue delay and in any event within 24 hours of awareness.
72 hours
Without undue delay and in any event within 72 hours of awareness.
Final report
No later than 14 days after a corrective or mitigating measure is available.
SEVERE INCIDENT
AWARENESS ↓
24 hours
Without undue delay and in any event within 24 hours of awareness.
72 hours
Without undue delay and in any event within 72 hours of awareness.
Final report
Within one month after submission of the 72-hour incident notification.
ONGOING REPORTING
Where necessary, the CSIRT designated as coordinator may request an intermediate report on relevant status updates concerning the actively exploited vulnerability or severe incident.
ARTICLE 14(8)
After becoming aware of an actively exploited vulnerability or severe incident, the manufacturer must inform impacted users and, where appropriate, all users of the relevant vulnerability or incident.
Where necessary, users must also be informed about risk-mitigation and corrective measures they can deploy.
CRA SRP
The CRA Single Reporting Platform is developed, operated and maintained by ENISA for CRA vulnerability and incident reporting.
For mandatory Article 14 reporting, the manufacturer submits through the electronic endpoint of the relevant CSIRT designated as coordinator, while the notification is made available through the EU reporting architecture.
Manufacturer or Assigned Representative
ENISA Single Reporting Platform
CSIRT designated as coordinator + ENISA
Other relevant CSIRTs · where applicable
Market-surveillance interface · where relevant
The SRP is designed to avoid separate duplicate CRA notifications to multiple national authorities for the same reporting event.
ENISA PLATFORM SUPPORT
The ENISA Single Reporting Platform uses the role “Assigned Representative” for an individual authorised to submit mandatory CRA notifications on behalf of a manufacturer.
Where appropriate, an authorised OSTRAI professional can act as the manufacturer’s Assigned Representative in the SRP.
Support the manufacturer / OSTRAI representative association and current SRP operational requirements.
Where appropriate under the current ENISA platform, support the manufacturer’s Primary / Secondary Assigned Representative structure and continuity arrangements.
Prepare and submit Early Warning, 72-hour Notification and Final Report stages on behalf of the manufacturer.
Maintain and update notifications as the investigation develops.
Coordinate reminders, reporting stages and follow-up actions.
The manufacturer remains legally responsible for ensuring its CRA reporting obligations are fulfilled.
DIFFERENT REPRESENTATIVE ROLES
ENISA SRP
CRA ARTICLE 18
A manufacturer may use OSTRAI for SRP Assigned Representative support independently of whether it has or later appoints OSTRAI as its Article 18 Authorised Representative.
ARTICLE 14(7)
YES ↓
The relevant Member State is where decisions related to the cybersecurity of the manufacturer’s products are predominantly taken.
If that cannot be determined: use the Member State where the manufacturer has the establishment with the highest number of employees.
NO ↓
The Article 14(7) hierarchy must be assessed based on the manufacturer’s actual EU structure.
CROSS-BORDER STRUCTURE
Where a manufacturer operates through multiple EU entities, importers, distributors or representative arrangements, the correct CSIRT endpoint should be determined before submission.
Where the Article 14(7) authorised-representative criterion is legally relevant, the CRA refers to the representative acting on behalf of the manufacturer for the highest number of that manufacturer’s products with digital elements.
ARTICLE 16
CRA notifications can contain highly sensitive technical and security information.
Article 16 provides mechanisms addressing dissemination in exceptional cybersecurity circumstances.
The decision to delay dissemination remains with the relevant CSIRT under the applicable CRA framework.
PEC
The current ENISA SRP includes a Particular Exceptional Circumstances mechanism in the 72-hour notification workflow for actively exploited vulnerabilities.
Invoking PEC does not itself determine the outcome. The relevant CSIRT remains responsible for the dissemination decision.
READINESS
OSTRAI can help manufacturers establish a CRA reporting playbook before an event occurs.
Internal thresholds for escalating potential AEVs and severe incidents.
Who determines when Article 14 awareness has been reached?
Security · engineering · product · legal · regulatory · executive.
Identify evidence needed for 24-hour, 72-hour and final-report stages.
Pre-establish workflows for impacted-user notification.
Plan the Assigned Representative operating model, platform responsibilities and continuity arrangements in advance.
Under current ENISA operating guidance, manufacturers should not assume that full SRP registration and manufacturer-association validation should be completed pre-emptively before any reporting event.
The operational registration / association process should be handled in accordance with the current ENISA platform guidance when a notification needs to be submitted.
Platform procedures can evolve and should be checked against the latest ENISA guidance at the time of reporting.
Determine the likely Article 14(7) reporting endpoint.
Maintain a defensible record of reportability and notification decisions.
YOUR REPORTING SUPPORT
Assess the issue against the Article 14 threshold.
Confirm whether the affected product falls within CRA scope.
Establish the relevant awareness record and reporting timeline.
Identify the relevant Article 14(7) reporting endpoint.
Prepare the first mandatory stage.
Prepare the vulnerability or incident notification.
Coordinate the final reporting package.
Assigned Representative / platform support where agreed.
Support CSIRT requests and status updates.
Prepare and coordinate impacted-user notifications.
Assess sensitivity and exceptional dissemination issues.
Coordinate cybersecurity, engineering, product and legal inputs.
Manage subsequent questions and communications.
Support regulatory implications of corrective measures, updates and product changes.
INITIAL INTAKE
Correct legal entity.
Affected product / product family.
Affected versions and configurations.
Existing scope analysis, if available.
Potential vulnerability or incident.
When and how the issue first arose.
Current understanding of when the Article 14 threshold may have been reached.
Logs · telemetry · exploit evidence · forensic information · vulnerability analysis.
Evidence supporting or contradicting active exploitation.
Affected data · functions · users · systems · services.
Where the product is known to have been made available.
Main establishment · importer · distributor · user footprint.
Actions already taken.
Status of patch / corrective measure.
Communications already issued or prepared.
Existing ENISA account / Assigned Representative status if applicable.
Security · engineering · product · legal · regulatory · communications.
COORDINATION
CRA REPORTING COORDINATION
ENISA SRP / CSIRT
POST-NOTIFICATION
CROSS-REGULATORY INCIDENT RESPONSE
A CRA notification does not automatically satisfy reporting obligations arising under other legal regimes.
OSTRAI can support coordinated regulatory analysis and notification strategy across applicable frameworks.
TRANSITION
The Article 14 reporting regime applies to products with digital elements within CRA scope even where they were placed on the Union market before 11 December 2027.
This is separate from the broader transitional position for substantive CRA product requirements.
FOSS
Manufacturer Article 14 reporting applies from 11 September 2026.
The CRA reporting obligations applicable to open-source software stewards under Article 24(3) apply from 11 December 2027.
Where FOSS roles, commercial activity or stewardship status are unclear, that position should be assessed separately.
ARTICLE 15
Article 15 provides for voluntary reporting of vulnerabilities, cyber threats, incidents and near misses in the circumstances specified by the CRA.
Mandatory Article 14 reporting and voluntary Article 15 reporting should not be confused.
Operational availability and submission routes should be assessed against the current ENISA / CSIRT reporting framework.
OPERATIONAL CONTINUITY
According to current ENISA guidance, where the SRP is temporarily unavailable, manufacturers should submit through the platform once service is restored.
Where immediate communication is considered necessary in the meantime, the designated CSIRT may be contacted directly, but the CRA notification must still be submitted through the SRP once available.
Platform procedures can evolve. OSTRAI follows current ENISA operating guidance when supporting live notifications.
WHY OSTRAI
Reporting threshold, awareness and deadline analysis.
Operational support for the CRA Single Reporting Platform.
Authorised submission and update support where agreed.
Reporting understood within the wider CRA product-compliance architecture.
Ability to identify overlapping regulatory notification issues.
Reporting can connect into vulnerability handling, technical documentation, corrective action and market surveillance.
NEED AN EU REGULATORY REPRESENTATIVE?
OSTRAI also supports manufacturers preparing for CRA Article 18 Authorised Representative arrangements, with statutory mandates taking effect from 11 December 2027.
Assigned Representative support in the ENISA reporting platform and Article 18 authorised representation are distinct services.
NEED BROADER CRA SUPPORT?
For scope, product classification, cybersecurity risk assessment, Annex I compliance, technical documentation, conformity assessment, standards, vulnerability handling and market access.
QUESTIONS & ANSWERS
11 September 2026 for manufacturers of products with digital elements within CRA scope.
No.
Mandatory Article 14 vulnerability reporting concerns actively exploited vulnerabilities.
A vulnerability is not automatically reportable merely because it exists or is technically exploitable.
A vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner.
No.
Article 14 mandatory incident reporting concerns severe incidents having an impact on the security of the product with digital elements and meeting the CRA threshold.
An Early Warning must be submitted without undue delay and in any event within 24 hours of the manufacturer becoming aware of the reportable actively exploited vulnerability or severe incident.
A more developed vulnerability or incident notification must be submitted, unless the relevant information has already been provided.
No later than 14 days after a corrective or mitigating measure becomes available.
Within one month after submission of the 72-hour incident notification.
OSTRAI can support the manufacturer in assessing the facts against the CRA reporting thresholds and documenting the resulting regulatory position.
The manufacturer remains responsible for fulfilling its Article 14 obligations.
Yes, where appropriately authorised and set up within the ENISA Single Reporting Platform.
An authorised OSTRAI professional can provide Assigned Representative support and submit or update notifications on behalf of the manufacturer.
The manufacturer remains legally responsible for ensuring the reporting obligation is fulfilled.
No.
The ENISA Assigned Representative is an operational Single Reporting Platform role.
The Article 18 Authorised Representative is a separate statutory EU representative role.
No.
OSTRAI can provide CRA reporting and Assigned Representative support independently of an Article 18 representative mandate.
Article 14(7) determines the relevant CSIRT designated as coordinator based on the manufacturer’s EU establishment and, where necessary, the statutory fallback structure.
OSTRAI can assess the reporting nexus before submission.
CRA mandatory reporting is submitted through the Single Reporting Platform.
The relevant CSIRT / ENISA architecture then handles dissemination under the CRA.
This does not eliminate separate reporting obligations that may arise under other legislation.
The CRA and the Single Reporting Platform contain confidentiality and dissemination safeguards.
In exceptional circumstances, the CRA provides mechanisms concerning delayed dissemination.
The relevant CSIRT remains responsible for applicable dissemination decisions.
Yes.
Where the legal conditions may be relevant, OSTRAI can support assessment, justification and completion of the relevant reporting workflow.
The decision on dissemination remains with the competent CSIRT.
Current ENISA guidance should be followed.
At present, ENISA indicates that the notification should be submitted through the SRP once it becomes available again. Where immediate communication is considered necessary, the designated CSIRT may be contacted in the meantime, but the SRP submission is still required once the platform is restored.
Article 14 also requires the manufacturer to inform impacted users and, where appropriate, all users of the relevant vulnerability or incident and, where necessary, applicable mitigation or corrective measures.
Yes, where those products fall within CRA scope.
Article 14 has a separate transitional rule and already applies.
Yes.
OSTRAI can help establish CRA reporting criteria, escalation procedures, reporting-nexus analysis, evidence workflows, user-communication processes and an operational reporting playbook.
Potentially.
A single event can engage multiple legal reporting regimes.
The applicable obligations must be assessed separately and coordinated where necessary.
CRA REPORTING & ENISA PLATFORM SUPPORT
OSTRAI supports manufacturers with CRA Article 14 reportability assessment, deadline control, notification preparation, ENISA Single Reporting Platform support, Assigned Representative services, impacted-user communications and regulatory follow-up.
Whether preparing for future events or responding to an active vulnerability or incident, we help coordinate the legal, regulatory and operational reporting workflow.