Preparing a manufacturer's CRA vulnerability workflow: intake, evidence and reporting clocks

Goal

Status as of 25 October 2026. Prepare a manufacturer's vulnerability workflow so evidence, product ownership and reporting deadlines can be retrieved during an incident. Re-check Article 14, Annex I and the current ENISA SRP instructions when updating the workflow. This is a proposed preparation protocol, not a claim that an organisation has passed a compliance assessment.

Article 14 reporting has applied since 11 September 2026. Article 71 sets 11 December 2027 for the wider requirements, including the vulnerability handling duties in Annex I. Preparations for those later duties can support reporting now, but their dates must remain distinct. Commission reporting guidance.

Prerequisites

Identify the manufacturer's relevant products, their responsible engineering teams, a reporting owner and a substitute. Provide a restricted incident record, access to release and component information, and a channel for affected-user communications. These are proposed organisational arrangements. Confirm the appropriate coordinating CSIRT against Article 14(7), rather than selecting one merely because its language is convenient.

Steps

1. Connect intake to a named owner. Prepare the coordinated vulnerability disclosure policy and reporting contact described in Annex I, Part II. An optional RFC 9116 security.txt can point researchers to them: use HTTPS at /.well-known/security.txt, include required Contact and Expires fields, and link the policy through Policy. Keep the file and destinations current. RFC 9116, sections 2, 3 and 5.

2. Create a case record immediately. As a practical record design, separate receipt time, the evidence received, the time awareness of a reportable event arose, the decision owner and subsequent revisions. Preserve the original evidence and explain changes to the assessment. Internal approvals should not silently reset the awareness timestamp.

3. Map the issue to releases. Maintain a software bill of materials (SBOM) alongside product and release identifiers. Annex I, Part II(1) requires a commonly used machine-readable format covering at least top-level dependencies when that requirement applies. This protocol proposes linking those records to shipped releases, so the affected-product list can be reconstructed. An SBOM is an inventory, not proof of exploitation.

4. Assess the statutory triggers separately. Under Article 3(42), active exploitation requires reliable evidence that a malicious actor exploited the vulnerability without the system owner's permission. Compare severe incidents with both criteria in Article 14(5). Record the evidence and unresolved questions; a severity score alone cannot establish active exploitation. Steps 1, 3 and 4 draw on the regulation.

5. Maintain the deadline record. Schedule the 24-hour and 72-hour stages from awareness, while retaining the requirement to act promptly. Track the vulnerability final report from availability of a corrective or mitigating measure, and the incident final report from submission of the incident notification. Store receipts, submitted versions and authority requests together.

6. Prepare platform access and communications. ENISA requires personal EU Login accounts with multifactor authentication. Its October FAQ recommends initiating SRP registration when a notification is needed; prepare EU Login access beforehand. Maintain affected-user communication alongside authority reporting. ENISA SRP FAQ, question 9.

7. Rehearse internally. Use a fictional product case and draft reports outside the live reporting platform. Have the substitute locate the evidence, reconstruct deadlines and explain the recipient selection. Record missing inputs and repeat the failed handover after correcting them.

Expected result

A reviewer can follow one case from intake through product mapping, trigger assessment, submission and user communications without reconstructing the timeline from scattered messages.

Limits and test basis

No rehearsal or field result is claimed. The proposal combines the regulation, Commission guidance, ENISA's FAQ updated 15 October 2026 and RFC 9116. Neither a published contact file nor a successful rehearsal proves compliance; product scope and disputed trigger assessments still need qualified review.