12 September 2026
The Cyber Resilience Act has reached an important new phase. Since 11 September 2026, manufacturers of products with digital elements can be subject to mandatory reporting obligations for actively exploited vulnerabilities and severe security incidents. ENISA’s Single Reporting Platform, or SRP, is now operational.
That development has created a very understandable question among software developers and manufacturers: if the portal is open, should every company now register itself and its products?
The answer is not necessarily. In fact, ENISA’s current guidance points in the opposite direction. Manufacturers are advised to initiate the Assigned Representative registration and validation process when they actually need to submit a specific notification, rather than registering in advance simply because the platform is available.
That distinction is important, because the SRP is not a general CRA product register and it is not a portal for declaring that a company has started its CRA compliance programme.
The SRP is a reporting platform, not a product registration system
One of the most common misunderstandings around the CRA is that manufacturers must now “register their products with ENISA”. That is not the purpose of the Single Reporting Platform. The SRP exists primarily so manufacturers can report certain cybersecurity events, in particular actively exploited vulnerabilities and severe incidents affecting the security of a product with digital elements. The platform became operational at the same time as the CRA’s Article 14 reporting obligations became applicable.
Registering an Assigned Representative therefore does not mean that a product has been registered as CRA compliant. It does not mean that a CE marking has been issued, that the manufacturer has completed its conformity assessment, or that the product has been declared free of vulnerabilities.
Those are separate matters.
A manufacturer may be actively preparing for CRA compliance while having no reason to submit anything through the SRP.
ENISA does not ask manufacturers to pre-register without a reason
ENISA’s current guidance makes this especially clear. Manufacturers and open-source software stewards are advised to start the registration and validation process when they need to submit a specific notification, rather than pre-registering in advance.
That approach is possible because the SRP is designed to allow a notification to be submitted even while the Assigned Representative-to-manufacturer relationship is still being validated. In practical terms, a company can prepare internally without creating an unnecessary registration simply to demonstrate that it is taking the CRA seriously.
For boards of directors, this changes the governance question. The relevant question is not simply, “Are we registered with ENISA?”
A better question is, “If we had a reportable event tomorrow, would we be able to recognise it, escalate it, register the appropriate representative and meet the reporting deadline?”
That is a much more meaningful measure of readiness.
Not every vulnerability needs to be reported
Another point that deserves clarification is the difference between a vulnerability and a reportable vulnerability.
A developer may discover a weakness during a penetration test, code review, internal audit or routine vulnerability-management process. The existence of that weakness does not automatically mean that a mandatory CRA notification has to be submitted.
The CRA reporting trigger is specifically concerned with vulnerabilities that are actively exploited, as well as severe security incidents affecting the product.
A vulnerability that has been identified internally still needs to be assessed, documented and remediated. It may also require customer communication, depending on the circumstances. But it does not automatically become an SRP notification simply because it exists.
This distinction is important because good vulnerability management should lead to the discovery of weaknesses. A company should not be placed in the position of believing that every internal finding is automatically a regulatory incident.
A data breach can change the situation very quickly
The position changes when there is evidence that a vulnerability has actually been exploited, particularly where this results in unauthorised access, loss of confidentiality, loss of integrity or another serious security impact. Imagine, for example, that a commercial application contains an access-control flaw. An attacker exploits that flaw and gains access to confidential customer information. The manufacturer now has to assess immediately whether it is dealing with an actively exploited vulnerability, a severe incident, or both.
If the CRA reporting threshold is met, the reporting clock starts from the moment the manufacturer becomes aware of the event.
The CRA reporting process can require an early warning within 24 hours, followed by a more detailed notification within 72 hours. A final report follows later, depending on whether the case concerns an actively exploited vulnerability or a severe incident.
This is why a manufacturer that does not pre-register should still be operationally ready to do so. “We did not register in advance because ENISA did not require pre-registration” is a reasonable position. “We had no idea how to register when an incident occurred” is a very different matter.
What should the board of directors decide now?
Boards should avoid reducing CRA readiness to a portal-registration exercise. Their responsibility is broader.
The board should first understand whether the company places products with digital elements on the EU market and whether those products are likely to fall within the CRA. From there, the company should establish a structured conformity programme covering product scope, classification, cybersecurity risk assessment, vulnerability management, secure development, software dependencies, support obligations and technical documentation.
At the same time, the organisation should define its incident and vulnerability escalation process. Someone must be responsible for deciding whether an event is potentially reportable. The company should also know who would act as its Primary Assigned Representative and ensure that this person can access EU Login with multi-factor authentication.
The goal is not to create paperwork for its own sake. The goal is to ensure that when a serious issue arises, the company does not spend the first twelve hours debating who is responsible, which product version is affected or where the reporting portal can be found.
For boards, one practical governance statement could be:
The company has initiated its Cyber Resilience Act conformity and vulnerability-management programme. As of the date of this decision, the company is not aware of an actively exploited vulnerability or severe security incident requiring notification under Article 14 of the CRA. In line with current ENISA guidance, the company will therefore not initiate SRP registration solely for pre-registration purposes. The company will, however, maintain operational readiness to register its Assigned Representative and submit a notification without undue delay should a reportable event arise.
That wording is considerably stronger than simply stating, “We decided not to register.”
It shows that the absence of registration is a conscious and documented governance decision based on the purpose of the platform, rather than an absence of preparation.
Non-NIS2 companies can still have CRA obligations
There is another area where confusion is likely to arise.
A company can be outside the scope of NIS2 as an entity while still being a manufacturer subject to the Cyber Resilience Act. The two legal frameworks have different purposes and different triggers. A smaller software developer, for example, may not qualify as an essential or important entity under NIS2. That does not automatically mean that the software it places on the market falls outside the CRA.
If that software contains an actively exploited vulnerability or suffers a severe security incident within the meaning of the CRA, the manufacturer may still have a mandatory reporting obligation. The reverse is also true. Being a CRA manufacturer does not automatically turn a company into a NIS2-regulated entity.
Boards should therefore avoid treating CRA and NIS2 as if they were the same compliance framework.
Does a non-NIS2 company have to report every vulnerability to the CCB?
For Belgian companies, this question is particularly relevant.
A company that is not subject to the mandatory NIS2 incident-reporting regime does not suddenly become obliged to report every internally discovered vulnerability to the Centre for Cybersecurity Belgium.
The CCB does provide voluntary reporting mechanisms, including for incidents, cyber threats and vulnerabilities. Belgium also has a coordinated vulnerability disclosure framework. These channels can be highly useful, but they should not be confused with a mandatory CRA Article 14 notification.
Where a manufacturer has an actively exploited vulnerability or a CRA severe incident, the mandatory reporting route is the CRA Single Reporting Platform. The platform then makes the report available to the relevant national CSIRT and ENISA in accordance with the CRA framework.
So the key question is not simply whether a company is subject to NIS2. The correct question is which legal reporting regime applies to the event in question. Do you want to register a vulnerability thers in Belgium only one pathway:
https://ccb.belgium.be/cert/vulnerability-reporting-ccb
In the Netherlands:
https://www.ncsc.nl/en/services/report-a-vulnerability
Your customer may be subject to NIS2 even if you are not
Software suppliers also need to consider the position of their customers.
A developer may be outside the scope of NIS2 while supplying software to a hospital, public authority, energy company, transport operator, managed service provider or another organisation that is subject to NIS2. A single incident can therefore create different obligations for different parties.
The software manufacturer may need to assess whether the event is reportable under the CRA. The customer may separately have to determine whether the same event constitutes a significant incident under NIS2.
That means supplier-to-customer communication becomes a critical part of incident readiness.
If a supplier discovers that a vulnerability in its product has been exploited, it may need to inform affected customers quickly enough for those customers to meet their own legal obligations. For regulated customers, late or incomplete supplier communication can create a compliance problem even when the supplier itself is not a NIS2 entity.
GDPR may apply at the same time
Cybersecurity incidents do not fit neatly into one regulatory box.
A vulnerability is not automatically a personal-data breach, but the exploitation of a vulnerability may result in one. Where personal data is affected, GDPR obligations need to be assessed independently from CRA and NIS2 obligations.
If the software provider acts as a processor, it may have to notify its customer, acting as controller, without undue delay. Where the provider is itself the controller, it may have a direct obligation to notify the competent data-protection authority if the GDPR threshold is met.
A serious incident can therefore trigger several parallel assessments.
The CRA focuses on product cybersecurity. NIS2 focuses on the security and continuity of regulated entities and services. GDPR focuses on the protection of personal data.
The same technical event may fall under all three frameworks, but the reporting triggers, deadlines and responsible parties are not identical.
There is no need to report that you have “started your CRA roadmap”
Manufacturers preparing for the CRA may be tempted to submit something simply to show that they are taking action.
That is unnecessary.
The SRP is not designed as a portal where companies announce that they have started a conformity programme, created an SBOM, launched a risk assessment or begun preparations for CE marking.
Those activities belong in the company’s governance records, conformity-assessment process and technical documentation.
A well-prepared company should be able to demonstrate what it has done if questioned by a competent authority. That is very different from sending an incident notification when no incident exists.
The real question is whether you are report-ready
The opening of the SRP should therefore be viewed as the start of an operational reporting phase, not as a mass-registration exercise.
Manufacturers should know who will act as their Assigned Representative, how to escalate a potential vulnerability or incident, how to identify affected product versions and customers, and how to distinguish between an ordinary vulnerability and an actively exploited one.
They should also know how quickly the board, security team, development team and legal or data-protection functions can work together when an event occurs.
- A company does not need to be registered in advance to be prepared.
But it does need to know what it will do when the clock starts.
11 September 2026 is only one milestone
The CRA reporting obligations are now operational, but the broader conformity regime continues to develop toward the main application date of 11 December 2027. Manufacturers therefore need to manage two workstreams in parallel. The first is immediate reporting readiness. A reportable vulnerability or incident can already create obligations today.
The second is product conformity readiness. Manufacturers need to use the period leading up to December 2027 to complete their risk assessments, technical documentation, vulnerability-management processes, software component controls and other applicable CRA requirements.
Confusing these two workstreams can lead to the wrong outcome: companies may rush to register with ENISA even though there is nothing to report, while at the same time failing to build the internal processes they will actually need when an incident occurs.
The message for boards and manufacturers
The fact that the ENISA Single Reporting Platform is open does not mean that every developer or manufacturer should immediately register.
Current ENISA guidance supports a more considered approach. If there is no actively exploited vulnerability and no severe security incident to report, a manufacturer does not need to register merely to show that it has started working on CRA compliance.
That does not mean doing nothing.
Boards should formally acknowledge the CRA, launch the appropriate conformity programme, identify reporting responsibilities, establish vulnerability and incident procedures, and make sure the organisation can react quickly if a reportable event occurs.
The most important question is therefore not:
“Have we registered?”
It is:
“If something happens tomorrow, are we ready?”
That is the difference between administrative activity and actual CRA readiness.
This article provides general regulatory and cybersecurity governance information and does not constitute legal advice. CRA scope, product classification, manufacturer status and reporting obligations should always be assessed against the specific facts of the organisation and product concerned.
If you need expert advisory on CRA and help to create a clear board statement and CRA roadmap and framework giving your development team correct guidance so they can focus on the product reach out To Danny Zeegers and Harry van der Plas and Karin Printemps
It saves money and resources chosing the one true pathway
Read our Book START2 CRA avalable @ https://harryvanderplas.com/
