Which duty already applies?
Since 11 September 2026, the CRA reporting duty has applied to manufacturers of products with digital elements within scope. It covers actively exploited vulnerabilities and severe incidents affecting product security. Most wider product obligations apply from 11 December 2027. Have product scope, exceptions and transitional arrangements assessed. Read the RDI explanation.
Using software does not itself make an organisation its manufacturer. Own-brand supply or a substantial modification can matter. This article concerns a manufacturer workflow; open-source software stewards have a different regime and application date. Check the applicable reporting regime.
Connect a signal to a product and version
For products within scope, identify owners, versions and where supported component information is maintained. A software component inventory can help locate an affected component. It does not independently establish exploitation or which customers are affected.
Let an incoming signal create a task with its source, time and known facts. A specialist assesses it and records uncertainty. Do not automatically turn every discovered vulnerability into a statutory notification: the reporting criteria require a separate decision.
Use the correct clock
On a narrow screen, scroll the table sideways. With a keyboard, focus the table and use the arrow keys.
| Stage | Deadline |
|---|---|
| Early warning | Without undue delay, no later than 24 hours after awareness. |
| Further notification | Without undue delay, no later than 72 hours after awareness. |
| Final report for an actively exploited vulnerability | No later than 14 days after a corrective measure becomes available. |
| Final report for a severe incident | Within one month of the incident notification due within 72 hours. |
NCSC reporting guidance. Internal waiting time must not move the legal deadline. Record the facts surrounding awareness and establish the correct trigger; a missing internal signature is not a reason to start the clock later.
Fictional example: one component in two versions
A fictional software manufacturer receives credible information about exploitation in a shared component. The product inventory shows two supported versions using it. The team investigates affected configurations. The case separates supported facts from unanswered questions.
Automation prepares product information, monitors tasks and reminds the appointed deputy. An authorised person assesses the reporting duty and content. Once a remedy becomes available, a separate task tracks the corresponding final report. The workflow does not claim that every customer has installed the update.
Prepare the case; do not assume a portal integration
ENISA operates the European Single Reporting Platform. Dutch NCSC guidance describes national reporting through MijnNCSC or the CRA form, forwarding and linked follow-up notifications. Confirm the correct route for the establishment and the reporter’s authority before an exercise. An internal email is not evidence of official submission. See ENISA platform guidance.
The proposed starting point is a checked draft case with manual submission. Record the returned reference and the version actually submitted. After a timeout, investigate the portal status before retrying; blind repetition can create duplicates. Do not assume an available API or guaranteed receipt.
Practise without disclosing real vulnerabilities
Use fictional products and events. Test an absent decision-maker, an incomplete inventory and an unavailable portal. Do not send the exercise to a real government reporting channel. Restrict access to exploit details and keep product secrets out of unassessed AI tools.
The CMS professional article discusses incident and vulnerability preparation. Platform information can age quickly, so current official instructions take precedence over an older checklist.
Frequently asked questions
Is a vulnerability scan enough?
No. It can provide a signal. Product scope, exploitation, impact, reporting and recovery require further assessment.
Can one case serve other regulations?
Some facts may be reused. Criteria, recipients and deadlines under rules such as the Dutch Cybersecurity Act, DORA or GDPR need separate assessment. One submission does not automatically cover every duty.
What should a first trial achieve?
A testable process: who takes ownership, what information is missing and how quickly a checked draft becomes available. Measure review effort and maintenance too. Decide what happens when the automation itself fails.
Discuss a concrete process?
Want to explore simpler ways to collect, check or transfer information? Describe one process and the systems you already use. A new tool is not always necessary. Introductory conversations are free and without obligation. Further advice and implementation are agreed separately through Korper, including scope and costs.