When the CRA Article 14 clock starts, a PDF is not a plan

CRA Article 14 is not a vulnerability-handling playbook. It is a reporting clock: from awareness of an actively exploited vulnerability or a severe incident affecting the security of a product with digital elements, manufacturers must submit an early warning within 24 hours, a fuller notification within 72 hours, then a final report — through ENISA’s Single Reporting Platform (SRP) to the relevant CSIRT. If your “plan” is a PDF in a drive, you will lose the first hour finding who owns awareness. Start free if you need path evidence you can export when the clock starts; keep the Article 14 checklist open beside you.

What CRA Article 14 actually is (and is not)

Article 14 is reporting. Manufacturers notify actively exploited vulnerabilities and severe incidents that affect the security of products with digital elements. You report once through the CRA Single Reporting Platform; the notification goes to the CSIRT of your main establishment and, unless exceptional circumstances apply, is made available to ENISA.

The clocks, from awareness (Commission CRA reporting page):

• Early warning — Within 24 hours of becoming aware
• Notification — Within 72 hours of becoming aware (general information + initial assessment)
• Final report — Actively exploited vulnerability: no later than 14 days after a corrective measure is available. Severe incident: within one month of the 72-hour notification

Article 14 is not Annex I Part II vulnerability handling (intake, SBOM, triage, remediation, disclosure). That is a different job with different work. See the Annex I Part II checklist when you mean handling — not when you mean the reporting clock.

Manufacturer Article 14 reporting obligations apply from 11 September 2026. The CRA’s main essential cybersecurity requirements apply from 11 December 2027. Open-source software stewards’ related reporting under Article 24(3) applies from 11 December 2027. Re-check the Commission page when you update this post; do not treat these dates as tribal knowledge.

This is operational guidance for teams building a runbook. It is not legal advice, and it does not decide whether your product is in scope.

Why the first hour after awareness decides the rest

The clock starts at awareness, not at “when Legal opens the ticket.”

In practice, awareness often looks like: a researcher ping, a dependency alert marked exploited, a customer report, a SOC escalation. Someone in Slack says “this looks bad.” Then the archaeology begins. Who is the manufacturer contact for SRP? Whose laptop has the CSIRT account? Which PDF has the fields? Was the agent that touched the component denied, or did it succeed?

Buyers and regulators both ask what you knew and when. If you spend the first hour hunting owners, you compress the remaining 23 hours of early warning into a scramble — and people start drafting Annex I handling notes as if they were the Article 14 filing. Handling still matters. It is not the early warning.

A night the PDF failed (anonymized)

A manufacturing product-security team got the signal on a Sunday near 02:00: an actively exploited component in a shipped product line. The “CRA plan” was a PDF in a shared drive — last updated for a readiness workshop. It named roles that no longer matched the org chart. SRP access lived with one person on PTO. Agent and CI logs that might show whether an automated workflow had pulled or exercised the bad path were scattered across three systems with no single export.

They spent the first hours reconstructing awareness: when did we know, who knew, what did we do. Triage of the fix ran in parallel — and kept getting pasted into the wrong document as “the Article 14 response.” By the time early warning went out, the team had a painful lesson: the reporting clock needed a named awareness owner, a timestamp, a filing path, and evidence of what the product path did — not a slide that said “we have a process.”

(Generic vignette. No customer named.)

What “good” looks like: awareness owner, SRP path, exportable logs

Before the next Sunday:

1. Named awareness owner (and backup) who can declare “we are aware” and start the clock in writing.
2. Awareness timestamp — how you record it, where it lives, who can attest to it.
3. SRP runbook — who logs into ENISA’s Single Reporting Platform, which CSIRT relationship you use, what goes in early warning vs 72-hour notification vs final. Field list: Article 14 security evidence checklist.
4. Exportable path evidence — when agents, tools, or gateways sit on the product path, you need logs you can pull: what ran, what was allowed or denied, when. That supports “what we knew / what we did.” It does not replace counsel on scope.
5. A bright line — Article 14 filing is one track; Annex I handling is another. Same incident can trigger both. Do not merge the documents.

Where UnitOne Gateway fits (evidence on the path — not legal scope)

UnitOne Gateway sits in your network on the agent path. For Article 14-style evidence work, the useful claim is narrow: Gateway can keep exportable runtime logs — agent identity, tool or MCP call, allow/deny, timestamps, correlation ids — so you are not reconstructing awareness from Slack alone.

Gateway does not determine whether you are a manufacturer in scope, whether a vulnerability is “actively exploited” under the CRA, or whether a filing is complete. It does not make you “CRA certified.” It is path evidence you can hand to the people who own the SRP runbook.

If you need that path in your VPC / VNet / project: Start free.

Article 14 vs Annex I Part II (one screen, two jobs)

• Article 14 — Job: Reporting. Channel: ENISA SRP → CSIRT (+ ENISA). Clocks: 24h / 72h / final (see clocks above). Wrong substitute: a handling PDF labeled “Article 14”. UnitOne link: Article 14 checklist.
• Annex I Part II — Job: Vulnerability handling. Channel: Your intake → triage → fix → disclose process. Clocks: Handling duties (support period, essential requirements timing). Wrong substitute: an early warning with no fix path. UnitOne link: Annex I Part II checklist.

A Sunday 02:00 runbook

Executable when someone says “this looks actively exploited” or “severe incident on the product.”

1. Declare awareness — Named owner writes time (UTC), source of signal, product/version in the shared incident channel. That timestamp starts your internal clock.
2. Open the right track — Article 14 reporting doc + Annex I handling doc as two threads. Do not paste fix notes into the early warning draft as if they were the filing.
3. Pull path evidence — Export gateway / agent / tool allow-deny logs for the window around the signal. Note gaps (“unknown” / off-path) explicitly.
4. SRP early warning (≤24h) — Owner or delegate files through ENISA SRP per your runbook. Use the checklist for fields.
5. 72-hour notification — Initial assessment + general information. Still reporting, not a completed remediations essay.
6. Keep handling moving separately — Intake, SBOM/context, triage, fix, disclose under Annex I Part II. Link the handling checklist.
7. Final report on the right clock — Vulnerability: no later than 14 days after a corrective measure is available. Severe incident: within one month of the 72-hour notification. (Commission)
8. Inform users as your counsel and Article 14(8) duties require — do not invent the legal bar in Slack; escalate.

If step 1 has no named owner, stop and assign one before you debate root cause.

Common questions

Is Article 14 the same as vulnerability handling under the CRA?

No. Article 14 is reporting through ENISA’s SRP on fixed clocks from awareness. Annex I Part II is vulnerability handling (intake, inventory/SBOM, triage, remediation, disclosure). You may need both for one event. Do not file handling notes as if they were the early warning.

When do manufacturer Article 14 duties apply?

Manufacturer reporting obligations under Article 14 apply from 11 September 2026. Main essential cybersecurity requirements apply from 11 December 2027. Confirm on the Commission CRA reporting page. Scope for your products is a legal question — this post does not decide it.

What is the 24 / 72 / final sequence?

From awareness: early warning within 24 hours; notification within 72 hours; then a final report — for actively exploited vulnerabilities, no later than 14 days after a corrective measure is available; for severe incidents, within one month of the 72-hour notification. All via the SRP to the relevant CSIRT.

Does an SBOM satisfy Article 14?

No. An SBOM supports handling and context. Article 14 requires timely notifications through the SRP. An inventory file does not start or stop the reporting clock.

How does a gateway help without deciding legal scope?

A gateway on the agent path can export runtime decisions (who/what/when/allow-deny) so awareness and response are evidenced. It does not determine CRA scope, active exploitation, or filing completeness. Narrow claim only — then Start free if you want that path evidence in your network.

Start free if you need exportable path evidence when the clock starts. Keep the CRA Article 14 security evidence checklist open for the reporting track, and the Annex I Part II vulnerability handling checklist for the different job of handling.

Primary sources cited in-body: Commission CRA reporting, ENISA SRP FAQ.