Filing an Article 14 Report
Audience. Whoever is on call when an actively exploited vulnerability or a severe security incident is confirmed. Read this before you need it, not during.
Outcome. Three filings made on time, each recorded with its ENISA reference and an immutable snapshot of exactly what was sent.
Why it matters. CRA Article 14 gives you 24 hours for an early warning and 72 hours for a full notification, from the moment you become aware. These are statutory deadlines and they apply from 11 September 2026.
Time required. The 24-hour filing takes about 15 minutes once the prerequisite in Step 1 is done. Doing Step 1 during an incident wastes time you do not have.
Read this first
The portal does not transmit anything to any authority.
It prepares your notification package and records what you filed. You take that package to ENISA's Single Reporting Platform, submit it there yourself, then come back and record that you did.
Anyone who assumes the app files on their behalf will watch a deadline pass while believing they complied. Every screen in this procedure states the two steps explicitly. Believe them.
The division of labour is:
- The portal does. Assemble the payload, validate the obligatory fields per stage, compute deadlines, freeze an immutable snapshot of what was generated, record the filing time and reference, and write the audit trail.
- You do. Log in to the ENISA SRP, submit the package, and record the reference the platform gives you.
Step 1. Configure the destination CSIRT, in advance
Open Settings, then the General tab, and find Establishment and Article 14 reporting.
Set your place of establishment and the Member State of main establishment. This determines the CSIRT that receives your notifications under Article 14(7).
When it resolves, the panel names the CSIRT and shows the contact and how it was derived.
If it does not resolve, you get one of two warnings and they mean different things.
- "No designated CSIRT could be determined." You have not set a Member State. Set one.
- "We do not yet hold a CSIRT contact for XX." We have no record for that Member State. Enter your national CSIRT's Article 14 contact in the Designated CSIRT override field.
Until one of those is resolved, report generation is blocked outright. That is the single most likely thing to stop you at hour zero, and it takes two minutes to fix today.
While you are here, set Member States where products are made available. These prefill the early warning so the CSIRT can disseminate to the affected states.
Step 2. Start the clock on the right event
Two things reach this workflow.
A researcher report that turns out to be actively exploited. Open it in Submissions and set the classification in Step 3.
An incident you detect yourself. Use Report an incident on the submissions board.
The field that matters most here is "When did you become aware?". Article 14 deadlines run from that moment, not from when you opened the form. Record it accurately even if it is embarrassing.
Tick "Suspected unlawful or malicious act" if applicable. It is required in the early warning under Article 14(4)(a).
Step 3. Classify, which is what triggers the obligation
Open the submission and find Severity and Art.14 Obligations.
Set Report classification to one of:
- Actively Exploited Vulnerability (Art.14 §1-2)
- Severe Security Incident (Art.14 §3-5)
- Both
For a vulnerability, tick "Actively exploited in the wild". The panel marks it Triggers Art.14. Nothing generates until this is set, and the block is deliberate: Article 14 applies to actively exploited vulnerabilities, not to every report you receive.
For an incident, severity must be HIGH or CRITICAL. Article 14 incident reporting covers severe incidents only.
Once it triggers, the three stages appear with their deadlines and a countdown.
| Stage | Article | Deadline |
|---|---|---|
| Early Warning | 14(2)(a) or (4)(a) | 24 hours |
| Full Notification | 14(2)(b) or (4)(b) | 72 hours |
| Final Report | 14(2)(c) or (4)(c) | 14 days (vulnerability) or 1 month (incident) |
The incident final report uses a calendar month, per Regulation 1182/71 Article 3(2)(c), so the same day of the following month. It is not 30 days.
Step 4. Draft the early warning
Select Open report on the Early Warning row.
The drawer has a tab per stage and one shared draft. Fill a field once and it carries forward.
Fields marked REQUIRED block generation for that stage. Fields marked If available only warn. The footer keeps a running count, so "1/2 obligatory fields filled for this stage" tells you exactly where you are.
From the submission record lists values pulled from the submission itself, each marked Filled or not. Those are not editable here. Change them in the panels on the submission page and they flow through.
The 24-hour stage needs very little: a title, and the product, which comes from the submission. That is deliberate. The early warning exists to raise the flag fast, not to explain everything.
Step 5. Generate the package
With the obligatory fields filled, select Generate and download JSON.
Two things happen. A JSON file downloads. An immutable snapshot is stored, so what you filed is provable later.
Re-downloading returns the original snapshot byte for byte. Regenerate creates a new one, and you should only use it if the assessment genuinely changed before you filed.
Step 6. File it on the ENISA SRP, yourself
Take the downloaded JSON to ENISA's Single Reporting Platform and submit it there.
This is the step the portal cannot do for you. Nothing has reached any authority yet.
The platform notifies your designated CSIRT coordinator and ENISA simultaneously under Article 16.
Step 7. Record the filing
Return to the drawer. Under "Filed this package on the ENISA SRP? Record it to complete the stage", enter the reference the platform gave you and select Mark as filed.
This stamps the filing time, writes the audit event, and stops the clock for that stage.
The stage now shows FILED with its reference. The others stay PENDING with their own clocks.
Record the reference even though the field is optional. It is the only link between your evidence and the authority's record of receipt.
Step 8. The 72-hour notification
Same drawer, 72h Notification tab.
This stage requires substance the early warning did not. For a vulnerability, the nature of the vulnerability and the exploit, corrective measures taken, and measures users can take. For an incident, the nature of the incident, when it was detected and occurred, and an initial assessment.
Then repeat Steps 5 through 7. Generate, file on the SRP, mark as filed.
Step 9. The final report
Same drawer, Final Report tab.
For a vulnerability the clock starts when a corrective measure becomes available, so set "Date corrective or mitigating measure available". Until that date exists the final report deadline stays pending rather than counting down.
Then Steps 5 through 7 once more.
Step 10. Restricted dissemination, where justified
If wider circulation would make things worse, tick Request restricted dissemination (Art.14(8)) and give a justification.
This is a request to the authority, not a switch you control. Use it where disclosure would increase risk, and say why.
Step 11. Human-readable record, optional
Generate ENISA Report produces a markdown document covering manufacturer details, CSIRT routing basis, timeline and an SRP filing checklist.
Useful for a management briefing or a legal file. The JSON package is what you actually submit.
Completion checklist
Per submission that triggers Article 14.
- Establishment and Member State set, and a designated CSIRT resolved
- "When did you become aware?" recorded accurately
- Report classification set, and Article 14 confirmed as triggered
- Early warning generated, filed on the SRP, and marked as filed within 24 hours
- SRP reference recorded for the early warning
- 72-hour notification generated, filed, and marked as filed
- Corrective-measure availability date set once known
- Final report generated, filed, and marked as filed
- Restricted dissemination requested where justified
- Audit log reviewed, showing generation and filing for each stage
What blocks generation
In the order the checks run, so you can diagnose from the message alone.
| Message | Cause |
|---|---|
| Requires the Pro plan | Package generation is a paid feature |
| Only applies to actively exploited vulnerabilities | Classification not set, see Step 3 |
| Applies to severe incidents only | Incident severity below HIGH |
| No designated CSIRT is configured | Member State not set, see Step 1 |
| No CSIRT contact on record for XX | Member State has no record, use the override |
| Obligatory SRP fields are missing | Fields listed in the drawer are unfilled |
| Generate the report package before marking it as filed | Filing attempted with no snapshot |
Plan differences worth knowing before an incident
- Free. No deadline banner, no board badge, no package generation. Not viable for Article 14.
- Pro and above. Package generation, deadline banner, board countdown badge.
- Enterprise. Adds automated deadline alerts by email and webhook, at 72, 12 and 6 hours before, plus a breach alert.
Only Enterprise gets told automatically. On any lower tier, somebody has to be watching.