CRA coordinated vulnerability disclosure & PSIRT — the setup playbook

This playbook fires for any manufacturer placing a product with digital elements on the EU market — the party carrying the Article 13 obligations of the Cyber Resilience Act (Reg. (EU) 2024/2847). It fires continuously, not on an incident: the trigger is the moment a third party *can* reach you with a vulnerability report, and the moment one of your shipped products has a flaw being exploited in the wild.

What is not in scope here: the mechanics of submitting the Article 14 report itself — that is the CRA Article 14 reporting playbook — and the full conformity-assessment and CE-marking track, covered by the CRA definition entry. This is the disclosure and PSIRT machine that produces the reports, not the report submission.

Clock 1 — the researcher's disclosure timeline. Someone external found the bug and intends to publish. You have a coordination window measured in days, and it starts the instant they reach you — which only works if there is somewhere to reach.

Clock 2 — the Article 14 reporting clock. From awareness: 24 hours to an early warning, 72 hours to a notification, 14 days to a final report once a corrective measure is available for an actively-exploited vulnerability (one month for a severe incident). The clock runs from awareness and nothing pauses it (Commission CRA reporting page). Filing goes once through the ENISA Single Reporting Platform to the CSIRT of your main establishment, with ENISA notified in parallel.

The trap is the calendar. Article 13's CVD-policy and single-point-of-contact obligations formally bind on 11 December 2027, but the Article 14 reporting obligation that consumes your intake output is live from 11 September 2026 — fifteen months earlier. If you build the intake to the 2027 date, awareness of your first actively-exploited flaw will arrive as a public tweet, with the 24-hour clock already running.

Goal: make it impossible for a report to have nowhere to land. Checklist:

• Publish a coordinated vulnerability disclosure policy at a stable URL (Annex I Part II). State scope, a safe-harbour statement, expected acknowledgement and fix timelines, and a secure contact (PGP key or equivalent). ENISA's coordinated vulnerability disclosure material is the neutral reference for structure.
• Provide a single point of contact for vulnerability reports (Annex I Part II) — a monitored security@ mailbox plus a security.txt (RFC 9116) file at /.well-known/security.txt.
• Create EU Login accounts now for the primary filer and at least one deputy. Single Reporting Platform registration runs through EU Login and the account can be created in advance — do not discover the sign-up flow at hour 20 of a live incident.
• Identify the receiving CSIRT of your main establishment (or your Article 18 authorised representative's location) and record it in the runbook.
• Classify each product — default, important, or critical under Commission Implementing Regulation (EU) 2025/2392 — before an incident, not during one; the class decides the filing path.
• Draft skeleton 24h / 72h / final templates and store them where the on-call engineer can reach them at 02:00.

When a report lands, the PSIRT runs a fixed sequence, and the first two steps are the ones auditors and regulators care about:

• Acknowledge and timestamp. Send receipt to the reporter and open a tracked case with a timestamp. This timestamp is your awareness anchor for Article 14 and must survive audit unedited.
• Assess exploited vs exploitable. Is it a real vulnerability in a product you placed on the market, and is it being actively exploited? Active exploitation — exploited in the wild, not merely exploitable — is the Article 14 trigger for the 24-hour early warning. Getting this classification wrong in either direction is the expensive mistake: over-file and you flood the CSIRT; under-file and you miss a statutory deadline.
• Scope with the SBOM. A flaw in a shared component — a logging library, a TLS stack — may touch several of your products. The current machine-readable SBOM (Annex I Part II) is what turns one report into the correct list of affected products in minutes rather than days.
• Assign a CVE through your CNA, or request one; CVE.org documents the CNA process. The CVE id is the shared handle across the researcher, the SRP filing, and your public advisory.
• Decide and record. Does this cross the Article 14 threshold? If yes, the 24-hour clock is already running from the acknowledge timestamp — hand off to the Article 14 reporting playbook and file.

• Agree an embargo and a coordinated disclosure date with the reporter, aligned to your security-update availability. FIRST's vulnerability-coordination guidance is the neutral reference for the etiquette when a researcher and a vendor have to synchronise.
• Address the vulnerability without delay through a security update (Annex I Part II). The update must be free and remain available for the declared support period.
• Publish an advisory once the fix or workaround is available (Annex I Part II). Do not conflate 'we shipped a patch' with 'we disclosed' — the public advisory is a separate, required artefact, and shipping the fix quietly does not satisfy it.
• Feed the closure evidence into the Article 14 final report, due no later than 14 days after a corrective measure is available for an actively-exploited vulnerability.

Ordered by which gate consumes it first:

• Published CVD policy URL + security.txt — the first thing a market-surveillance assessor checks; it proves the intake exists.
• Intake case log with acknowledge timestamps and chain-of-custody — proves *when* awareness started for each report, the anchor for every Article 14 clock.
• Product classification record (default / important / critical) tied to the SRP filing path.
• Current machine-readable SBOM (CycloneDX or SPDX) per shipped product, kept build-on-build — the scoping instrument.
• CVE records and the advisory register — the fixed-vulnerability disclosures.
• Security-update availability and signing records — the free-updates-for-the-support-period proof.
• Receiving-CSIRT designation + EU Login registration — proves you can actually file.

A CVD intake is reactive by construction: it waits for a researcher's email or for the wire to light up with an exploited-in-the-wild CVE, at which point the 24-hour clock is already running. The proactive half is finding your own defects first and filing them into the same triage queue. This is where an AI generative pentest earns its place — Zero Hunt's 10-agent swarm writes per-target exploits against your own product surface, and change-triggered campaigns re-test on every build, so a defect lands in your PSIRT queue as an internal finding with ECDSA-signed, chain-of-custody evidence (a Trust Center export) before an outsider ever sees it — which is exactly the documented internal-discovery record Annex I Part II expects.

Observed across product teams walking into the September 2026 deadline:

• No intake at all, so the first you hear of a bug is the researcher's public tweet — the 24-hour Article 14 clock is already spent and you are filing late on day one.
• Treating Article 13 as a December-2027 problem while the Article 14 reporting obligation it feeds has been live since 11 September 2026.
• No current SBOM, so a shared-component vulnerability becomes a multi-day scoping exercise instead of a query — and the 72-hour notification lists the wrong affected products.
• No CNA relationship and no pre-agreed embargo etiquette, so coordination collapses into a race with the researcher and the disclosure happens on their timing, not yours.
• Conflating 'we fixed it' with 'we disclosed it' — the public advisory (Annex I Part II) is a distinct required artefact; a quiet patch does not close the obligation.
• No weekend or holiday on-call — a Friday-evening actively-exploited report burns the 24-hour window before anyone is looking at the mailbox.

The CRA intake does not stand alone. When the same product is operated by an essential or important entity, an actively-exploited flaw can also be a significant incident under NIS2 Title 13 (24h/72h/1-month) and, for financial-sector operators, under DORA — same underlying evidence base, different filings, so build the record once and export per regime.

The disclosure etiquette itself maps cleanly onto ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling): if your PSIRT already runs to those standards, the CRA obligations are largely a documentation and single-reporting-platform overlay rather than a new process. The one genuinely new element for most teams is the statutory clock: 29147 and 30111 describe good practice, but Article 14 puts a 24-hour wall-clock deadline on the front of it — which is why the acknowledge timestamp in Phase B is the single most audited artefact in the whole machine.