From vulnerability handling to reporting obligation: what will change on 11 September

There is a difference between a vulnerability you fix yourself, one you tell your customer about, and one you must report to a regulator. In practice those three run together constantly. From next week that difference is no longer just tidy, it is legal.

What changes on 11 September, and what does not

The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. It applies in stages. The European Commission gives two dates that matter now.

• Reporting obligations apply from 11 September 2026 (notification of actively exploited vulnerabilities and severe security incidents, including the 24-hour and 72-hour reporting stages)
• The main obligations apply from 11 December 2027 (product cybersecurity requirements, vulnerability handling, technical documentation, conformity assessment, EU declaration of conformity and CE marking)

That distinction is often left out, and it is exactly why organizations believe they still have another year. They do! for most of the product-conformity requirements. CE marking, conformity assessment, the EU declaration of conformity and technical documentation become applicable from December 2027. The reporting clock starts much earlier.

First, the question rarely asked: which role do you have?

Obligations under the regulation attach to a role. Manufacturers, importers and distributors each have different duties. If you are none of the three, the rest of this article does not apply to you.

The catch lies in translating this into the world of industrial control systems. ISA/IEC 62443 works with asset owner, product supplier, service provider and integrator. Those are useful roles, but they are not the economic operators of EU product law and they do not map onto them. An organisation that has called itself an asset owner for years may be a manufacturer under the regulation, the moment it places a product with digital elements on the EU market under its own name.

This happens more often than it sounds. A machine builder shipping a control cabinet with its own software. An integrator selling a gateway under its own brand. A supplier repackaging third-party firmware. Ask this question first, because without the answer the rest of the analysis is meaningless.

Three outcomes, and one of them has a clock

Once the role question is answered, a discovered vulnerability falls into one of three categories.

1. An internal finding. You remediate it through your own process and record what was decided, when, and by whom.
2. A notification. You inform your customer and the chain, and once the update is available you publicly disclose what was fixed.
3. A regulatory report. That goes to the national CSIRT and to ENISA, and deadlines start running.

The third category is new for most manufacturers. According to the European Commission's summary it concerns actively exploited vulnerabilities and severe incidents having an impact on security, with an early warning within 24 hours, a notification within 72 hours and a final report thereafter. Have the precise deadline per report type and the exact scope verified against Article 14 of the regulation itself; that is the operative text, not the summary.

The clock starts when you became aware. Not when you finished understanding it, and not when the patch was ready. That is where playbooks break in practice.

What your IEC 62443 programme does give you here

If you already work with IEC 62443 you are not starting from nothing. The European Commission's Joint Research Centre and ENISA mapped the requirements of the regulation against existing standards. In that analysis EN IEC 62443-4-1:2018 is mapped to four of the eight vulnerability handling requirements of Annex I Part II: remediating vulnerabilities, disclosing what was fixed, securely distributing updates, and disseminating patches without delay and free of charge.

That is substantial. It is also exactly half, and the gap is not where most people look for it. Not mapped to 62443-4-1 in that same analysis: drawing up a software bill of materials, the rhythm of tests and reviews, a coordinated vulnerability disclosure policy, and the contact address through which an outsider can reach you. For the last two the analysis points to ISO/IEC 30111 and ISO/IEC 29147, not to more 62443.

The same analysis notes that no single standard covers all Annex I requirements on its own, and that the 62443 series is explicitly scoped to industrial control systems. As soon as your product is sold elsewhere, that underpinning loses part of its force.

This is a mapping by European institutions, not a ruling by a supervisory authority. An IEC 62443 implementation does not produce CRA conformity, and an IEC 62443 certificate demonstrates nothing under the regulation. Those are two different assessments with a different legal basis.

What needs to happen this week

1. Establish, per product, which role you have. Manufacturer, importer, distributor or none of them. Write it down.
2. Name one person who may decide that something is reportable, and make sure that person is reachable outside office hours. A 24 hour deadline also runs at the weekend.
3. Check that you have a reporting contact address an outsider can find, and that somebody reads it.
4. Record how you register the moment you became aware of something. Without that moment you cannot show afterwards that you were in time.
5. Determine which of your products fall under the regulation at all. That question is factual work, not an assumption.

None of these five requires a project. They require an afternoon and a decision, and all five are free. The difference between an organisation that is ready on 11 September and one that is not sits here, not in a compliance programme.

What this resembles

This is the same question as the rest of this series, in different words. In OT we ask who carries the residual risk when we do not patch. In AI governance we ask who is allowed to stop the system. Under the Cyber Resilience Act we ask: who is the manufacturer, what has been promised, how long does that promise last, and can we show we are keeping it.

The pattern underneath is always the same: question, context, decision, owner, evidence, review. See the cornerstone article for how that question returns in all three domains, and the piece on patch, mitigate, monitor or accept for the OT variant.

Finally, and this belongs here

This article is not legal advice and demonstrates no conformity. It is a working model to have the conversation. The regulation itself is on EUR-Lex, the phasing on the European Commission page, the summary of the legislative text here, and the mapping of requirements to standards in the joint JRC and ENISA analysis. Have the application to your own products verified legally.

Practical advice

Do not start with a full CRA compliance programme this week. Start by answering five questions:

1. Which of our products fall within the scope of the CRA?
2. For each product, are we the manufacturer, importer or distributor?
3. Who decides whether a vulnerability or incident is reportable?
4. Can that person make that decision within 24 hours, including outside office hours?
5. Can we demonstrate when we first became aware of the vulnerability or incident?

If those answers are unclear, that is the first gap to address before 11 September.

The immediate CRA question this week is not: “Are we compliant?” but: “Can we identify, decide and report within the required timeframe?”

Want to go deeper on the engineering side?

If you want to go deeper on the engineering side: the PECB ISA/IEC 62443 Lead Implementer covers the product security and lifecycle this connects to.