The previous article set out the reporting deadlines and triggers in CRA Article 14. The rules themselves are not complicated. What is genuinely hard is turning them into a process that everyone in the organisation knows how to operate. Does the vulnerability surface first in engineering, or does support hear it from a user? Who decides whether this counts as “actively exploited”? When does the 24-hour clock start? Who is responsible for filing the first notification? If these questions have never been rehearsed, then in a real vulnerability event, simply establishing “whose job is this” can consume most of the 24 hours. This article is about how that internal process should actually be designed and put into practice.
Most mature vulnerability management processes break down into the following stages.
Intake. There has to be a public, clearly identified channel for reporting vulnerabilities, so that researchers, customers and partners can all find a way to report a suspected vulnerability. Someone has to own that channel — an automated form that collects submissions with no follow-up is not enough.
Validation. Once a report arrives, confirm whether the vulnerability is real and filter out false positives.
Risk analysis. Once confirmed as real, assess the risk level. This step is not a subjective judgement call: it follows an established method that weighs impact together with likelihood of exploitation, and lands on high, medium or low. How that weighing is done in practice, and where the boundaries are drawn, is often where companies differ most — and where professional judgement matters most.
The fork. Anything assessed as high risk enters the remediation path: fix, verify that the fix actually works, report externally, distribute the update to customers, and finally carry out market verification at the customer end to confirm that the vulnerability really has been eliminated before the case can be closed. For items assessed as low risk, risk transfer is available in some circumstances — stating explicitly in the product documentation or user instructions that “in a specific and highly improbable scenario, operating in this way may create the following risk; we recommend avoiding it”. That too is a documented, defensible way of handling it.
There is one point here that goes unnoticed day to day but is routinely checked in audit: the whole process has to exist in documented form. “We have tools running” is not sufficient. There must be documentation stating how each step is carried out, who is responsible, and what the decision criteria are. The audit logic is normally to read what the documentation says first, then work backwards to verify that the company actually does it. Documentation and practice have to match for the process to survive scrutiny.
Another commonly underestimated dimension is that a single company’s risk baseline should not apply uniformly across the business. In practical terms, when a company spans several product lines, the risk each line can absorb usually differs materially. A product deployed in a critical infrastructure setting and a consumer-facing peripheral may develop vulnerabilities of identical technical severity, yet the downstream impact and the realistic likelihood of exploitation are not on the same scale — so a single risk acceptance criterion does not fit both.
Differences like these normally need to be assessed along several separate dimensions: the product’s actual deployment environment and user exposure, its class under the CRA (Default, Important or Critical), and how fixable it is once a vulnerability appears — whether an update can be pushed immediately over the air, for example, or whether the product has shipped in volume and is impractical to recall. Together these dimensions determine the basis on which a given product line decides whether it should, and whether it can, accept a particular risk in a particular scenario. The more robust approach is therefore to establish risk-grading criteria per product line rather than applying a single standard at organisational level — the latter tends to produce a looser baseline being used to measure products in high-risk settings that warrant a more conservative position.
Companies encountering Article 14 for the first time often treat “reporting to the authorities” and “notifying customers” as the same thing. They are in fact two parallel obligations, different in nature.
Reporting to the authorities goes through the single reporting platform (SRP) established by ENISA, and reaches the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment. The audience for this channel is the regulator; email, telephone and other informal channels are not recognised.
Notifying customers is a separate obligation, with its legal basis in Article 14(8). Once a manufacturer becomes aware that a vulnerability is being actively exploited, or that a severe incident has occurred, it has to inform affected users — and where appropriate all users — of the matter and, where necessary, of the corrective or mitigating measures they can take. The point of this obligation is that even where the fix is not yet complete, users must first be told what to do in the meantime. Common practice is to use over-the-air push, email notification and a security advisory on the corporate site in parallel, with content covering at minimum the mitigations available now and whether a patch has been released or when it is expected.
Sending the notification does not close the process. The company still needs a mechanism to confirm whether customers have in fact acted on it — that might be proactive follow-up, or continuous collection of feedback; the absence of further reports from the customer side after a notification is itself a form of evidence. This “market verification” step is frequently skipped, but it is exactly what the process stage described above requires in practice.
1. Reporting responsibility for third-party components does not disappear just because the finished product is out of scope. A frequent misreading in practice is that once a component has been integrated into a product that is itself governed by other legislation and excluded from the CRA, the component no longer needs to worry about the CRA. But that turns on a separate assessment of whether the component falls within CRA scope in its own right (which involves several easily-confused conditions, to be covered separately when we discuss scope). For reporting purposes, the key point is this: once reporting is triggered, responsibility does not necessarily sit with a single party — the product manufacturer and the component manufacturer may each carry their own reporting obligation, and neither can push it onto the other. For semiconductor and module makers, that means being one link in the supply chain does not stop you from being one of the parties legally obliged to report.
2. A CVD policy and Article 14 reporting are two different things — but they intersect at the critical moment. The obligation to have a coordinated vulnerability disclosure (CVD) policy comes from Article 13(8), with the substantive requirements in Annex I, Part II, point 5 — not from Article 14. A CVD policy governs the company’s day-to-day process for receiving, confirming, fixing and disclosing vulnerabilities; Article 14 is the mandatory regulatory notification that starts separately once one of those vulnerabilities is determined to be actively exploited. The two run independently most of the time, converging only when the active-exploitation threshold is crossed, and again at the fix and public advisory stage. Being clear about that division is what stops a company from assuming that running its routine vulnerability intake amounts to discharging its Article 14 reporting obligation.
3. A draft standard is a useful blueprint, but not yet evidence of compliance. There is a draft standard dedicated to vulnerability handling processes (prEN 40000-1-3) that specifies the inputs, outputs and assessment criteria for each step in considerable detail, making it well suited to building an auditable, traceable process. But it remains at draft stage and has not yet been cited in the Official Journal of the European Union (OJEU), so applying it today does not confer presumption of conformity. Treat it as a reference baseline while building the process, not as a document to point to externally as proof of conformity. Until the 40000 series is finalised, industry practice for building vulnerability handling processes is generally still based on established international standards, such as ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling).
What Article 14 really tests is whether a company can build this process for real and retain documentation that stands up to verification. That is also where most manufacturers get stuck: the difficulty is not in understanding what needs to be done, but in judging whether current practice is sufficient, whether the documentation is complete, and how to converge the differences in baseline between several product lines.
In practice, companies introducing this kind of process usually start with a gap assessment of what already exists. If there is already an in-house vulnerability management process and tooling, the first step is to check whether documentation and actual execution match, and then identify what needs strengthening. If there is nothing in place yet, a complete process framework is needed to connect step by step to the company’s own systems and internal division of responsibility. One point deserves emphasis: legal responsibility for external reporting always rests with the manufacturer. A consultant’s role is to help build the process; it cannot discharge the reporting obligation on the manufacturer’s behalf.
It is also worth noting that there is usually a gap between building the process and operating it. However complete the documentation, if no one helps rehearse it and confirm that every step really can run inside the deadline, the process can still fail when a real event arrives — and that is the part companies most often underestimate in the early stages of adoption.
You are also welcome to join the in-person seminar in Taipei on Friday 18 September, where you can put questions directly to a CRA expert from Spain and learn more about planning for 2027 compliance and estimating the time and cost of implementation. Registration: Register for the seminar
Q: How should the internal process for vulnerability reporting be set up? The basic structure is: open a public intake point for vulnerability reports → verify whether the vulnerability is genuine → grade the risk by impact and likelihood → remediate the high-risk ones and transfer the low-risk ones → verify the fix → report externally and distribute the update → validate in the field and close the case. The whole process has to be written down and put into practice before it is of any use at audit time.
Q: Is notifying the authorities the same thing as notifying customers? No. Notifying the authorities goes through ENISA’s single reporting platform (SRP); notifying customers is a separate, parallel obligation (Article 14(8)) — affected users must be told of the risk and of the mitigating measures available to them, usually through OTA, email and an announcement on the official website at the same time.
Q: Who is responsible for reporting third-party components? Once a report is triggered, responsibility may not sit with a single channel — the product manufacturer and the component manufacturer may each carry their own reporting obligations, and neither can push the duty onto the other. Even a company that is only one link in the supply chain can still be one of the parties legally required to report.
All legal provisions and dates cited in this article are based on the following official documents:
By the Secure Vectors Surveillance Inc. (SV Surveillance) × Applus+ Laboratories consulting team
* This article is regulatory commentary, not legal advice. Final compliance determinations for specific cases remain subject to official EU documents and the interpretations of the competent authorities.
