Cyber Resilience Act: the first deadline is not December 2027. It is 11 September 2026

The first enforceable obligation under the Cyber Resilience Act does not begin in December 2027. It begins in just a few weeks. It also applies to products that have been on the market for years. And for many manufacturers, the challenge will not be the report itself, but the process that has to take place before it. Adapted from the source text.

When companies discuss the Cyber Resilience Act, one date is mentioned more than any other: 11 December 2027. That is when the regulation starts to apply in full – CE marking, technical documentation and conformity assessment.

Article 14, however, starts to apply on 11 September 2026. And unlike the rest of the CRA, it does not apply only to new products. Under Article 69(3), the reporting obligations also extend to products with digital elements that were placed on the EU market before 11 December 2027.

If you planned to start preparing for the CRA next year, Article 14 changes that timeline. If you first want to determine whether your product falls within the scope of the CRA, start with our complete overview of the regulation.

What is subject to the reporting obligation

Article 14 establishes two separate reporting obligations, both of which apply to the manufacturer. Not to the customer and not to the operator. Importers and distributors that become aware of a problem must inform the manufacturer. They do not file the report themselves, and the 24-hour deadline does not transfer to them.

• Actively exploited vulnerability – a vulnerability in your product for which there is reliable evidence that an attacker has exploited it in a system without the owner's consent.
• Severe incident affecting the security of the product – for example, the compromise of a development, production or distribution environment that allows an attacker to inject malicious code into the distribution channel or the signing chain. This is not an incident affecting a customer. It is an incident affecting the manufacturer that increases the risk to users of the product.

In certain cases, similar obligations also apply to open-source software stewards under Article 24, to the extent of their involvement in the development of the affected products.

What does not trigger the obligation

A security researcher's finding, a proof of concept or a high CVSS score does not automatically trigger an obligation under Article 14. The regulation distinguishes between a vulnerability that exists and a vulnerability that is actively being exploited.

The decisive factor is reliable evidence of exploitation, not the severity of the vulnerability itself.

An ordinary vulnerability reported through your CVD channel and fixed through the standard patching process does not have to be reported.

At first glance, this may sound like a relief. In practice, however, it is the most demanding part of the entire obligation. Determining whether a vulnerability is being actively exploited requires technical expertise and the ability to analyse and interpret the available evidence.

The obligation to inform users

Reporting to the authorities is not the only obligation, and this is one of the requirements that often gets overlooked in discussions about the CRA.

Once a manufacturer becomes aware of an actively exploited vulnerability or a severe incident, it must also inform affected users without undue delay and, where appropriate, users more broadly about the issue and any measures they can take to mitigate the risk.

In practice, this means that the report itself is only one part of the process. You also need a communication channel for customers and a prepared message explaining what happened and what users should do.

How reporting through the ENISA platform works

A report is submitted only once through the Single Reporting Platform, which is established and operated by ENISA under Article 16. A single submission is sent simultaneously to the coordinating CSIRT and to ENISA, so manufacturers do not have to contact national authorities separately in every Member State where their products are available.

When submitting a report, manufacturers indicate the Member States in which the affected product is available. The coordinating CSIRT then forwards the information to the relevant CSIRTs in those countries.

The relevant CSIRT is the one in the Member State of the manufacturer's main establishment, meaning the place where decisions related to the cybersecurity of the product are primarily made. If that cannot be determined, the relevant CSIRT is identified based on the establishment with the largest number of employees in the EU. Manufacturers that do not have a main establishment in the Union are subject to specific rules defined by the regulation. Depending on the circumstances, the rules governing authorised representatives may also apply.

In exceptional circumstances, further dissemination of a notification to other CSIRTs may be delayed at the manufacturer's request if there are justified cybersecurity-related grounds. This is something manufacturers should understand in advance rather than trying to figure it out during an incident.

The practical point most articles overlook

At the time of writing, the platform was not yet operational. ENISA has confirmed that it will be fully functional by 11 September 2026. Testing is already under way, and the first guidance materials were published during the summer of 2026. The public address of the platform is expected to be announced before it goes live.

One conclusion follows from this: the platform is not what you should be waiting for.

The internal process that will feed the platform can be built today, and that process is what will determine whether your organisation can meet the 24-hour deadline. ENISA currently states that access to the platform will be based on an EU Login account, which can be created in advance.

Why 24 hours is more than an administrative deadline

A 24-hour reporting window may seem generous at first glance. In practice, however, manufacturers must complete several steps within that period, and each of them requires both technical and organisational decisions.

1. Identify that something has happened. Information may come from monitoring, threat intelligence, a customer or a security researcher. Without a coordinated vulnerability disclosure (CVD) policy and a functioning point of contact, organisations often become aware of incidents too late.
2. Verify that the issue affects a specific product. Which versions are affected? Is the vulnerable library actually part of the product? Without an up-to-date SBOM, answering these questions can become a time-consuming exercise.
3. Determine whether the vulnerability is actively being exploited. The key question is not the severity of the flaw but the existence of reliable evidence of exploitation. Making that determination requires technical expertise.
4. Decide whether the event must be reported. Many companies still have no clearly defined ownership for this decision. Should it be made by engineering, product management, legal or executive management?
5. Prepare the report and inform users. Filing the report is only part of the process. Customer communication and mitigation guidance must be prepared as well.

Step 3 is the critical one. To determine whether a vulnerability is being actively exploited, you need visibility into what is happening inside your product. Distinguishing an existing vulnerability from actual exploitation is a technical task, not a compliance exercise.

What we see during product testing

In our experience with IoT penetration testing, almost every device we assess contains at least one high or critical vulnerability. The most common findings include hard-coded credentials in firmware, unencrypted communication with cloud services, exposed debugging interfaces and update mechanisms that do not verify digital signatures.

We described these findings in greater detail in our article on smart plug security.

Until 11 September 2026, these are simply technical findings. From that date onward, a finding for which you obtain reliable evidence of active exploitation starts the 24-hour reporting clock.

Exceptions to the penalty rules

A violation of Article 14 falls within the highest penalty tier under the CRA – up to EUR 15 million or 2.5 % of worldwide annual turnover. The regulation does, however, provide two narrow exceptions.

• Microenterprises and small enterprises cannot be fined for failing to meet the 24-hour early warning deadline. This does not apply to the 72-hour notification, the final report or the reporting obligation itself.
• Open-source software stewards are not subject to administrative fines under the regulation. Their obligations under Article 24, however, remain unchanged. 

What to have in place by September

• A list of products in scope. Which products are made available on the EU market? Which versions are still in circulation? Which products are no longer being developed but are still being sold?
• Clearly defined responsibilities and an escalation path. Who decides whether an incident must be reported? Who submits the report? Who acts as a substitute? How are incidents handled outside business hours?
• A CVD policy and a single point of contact. The channel through which information reaches your organisation in the first place. It should not rely exclusively on automated tools.
• An SBOM covering at least top-level dependencies. Not for documentation purposes, but to help you quickly determine whether a specific vulnerability affects your product.
• Vulnerability triage and the ability to verify exploitation. Who determines whether a vulnerability is being actively exploited, and what evidence supports that conclusion?
• Prepared reporting and communication processes. Access to the platform should be created in advance, reporting templates should be prepared, and user communication procedures should already be in place.
• Rehearse the process. A single tabletop exercise built around the scenario "A vulnerability in our product is being actively exploited" will reveal more about your level of preparedness than a documentation audit.

Frequently asked questions

Do we have to report a security researcher's finding?

No, if it is only a finding. The obligation under Article 14 is triggered by reliable evidence that a vulnerability is being actively exploited. A finding, a proof of concept or a high CVSS score does not automatically trigger a reporting obligation.

Does the obligation apply to our older products?

Yes. The reporting obligations also apply to products that were placed on the market before 11 December 2027, provided they are still being made available on the EU market.

Do we report, or does our distributor?

You do. The obligation under Article 14 rests with the manufacturer. Importers and distributors that become aware of a vulnerability are required to inform the manufacturer, but they do not submit the report themselves.

What if the ENISA platform is unavailable on the day of the incident?

The deadlines are defined by the regulation and start running from the moment you become aware of the event. That is why it makes sense to create access in advance, prepare the report content and follow ENISA's official guidance regarding the platform.

We are a small business. Do we still have to report?

Yes. Microenterprises and small enterprises are not subject to fines for missing the early warning deadline. The reporting obligation itself, however, applies to them in exactly the same way as it does to all other manufacturers.

We are established outside the EU. Does Article 14 still apply?

Yes. If your products are made available on the EU market, the reporting obligations still apply. The CRA follows the product rather than the manufacturer's location. The regulation also establishes specific rules for manufacturers without a main establishment in the European Union.

Conclusion

The difference between the two CRA deadlines is simple: December 2027 is about demonstrating compliance, while September 2026 is about being able to respond.

If you can meet the second requirement, you will already have completed a significant part of the first. Product inventories, SBOMs and vulnerability management processes are essential for both.

For a complete overview of obligations, product categories and implementation deadlines, see our article on the Cyber Resilience Act.

If you would like an independent assessment of your product's security and its readiness for CRA requirements, get in touch. We test firmware and hardware interfaces, mobile, web and API interfaces, cloud backends, authentication and update mechanisms, as well as vulnerabilities in third-party components.

Legal notice: This article is provided for informational purposes only and does not constitute legal advice.