A vulnerability report arrives on a Friday afternoon. Security starts investigating. Engineering is trying to work out which versions are affected. Someone asks whether the product is still sold in the EU. Then legal asks a slightly more uncomfortable question: when did we first know this was being exploited? That question has become considerably more urgent.
Since 11 September 2026, manufacturers covered by the Cyber Resilience Act (CRA) have been required to report actively exploited vulnerabilities and severe security incidents affecting products with digital elements. The ENISA Single Reporting Platform is now live to handle those notifications.
The rest of the CRA's main cybersecurity requirements don't apply until 11 December 2027. But Cyber Resilience Act reporting has already moved from something organisations can prepare for to something they may have to do tomorrow. And once a manufacturer becomes aware of a reportable event, the first deadline can be just 24 hours away.
Which creates a problem. Vulnerabilities rarely arrive neatly packaged with every technical, product and legal question already answered. Reporting now has to work while those answers are still being found.
CRA Reporting Starts Before The Investigation Is Finished
When something serious happens, the natural instinct is to investigate it first. Confirm what happened. Understand the impact. Work out which products are affected. Decide how to fix it. Then, once everyone understands the situation, report it. The CRA doesn't necessarily give manufacturers that luxury.
An actively exploited vulnerability is one where there's reliable evidence that a malicious actor has exploited the vulnerability without the system owner's permission. Severe incidents affecting the security of a product can also trigger reporting requirements. Once the manufacturer becomes aware, the clock starts.
An early warning must be submitted within 24 hours, followed by a fuller notification within 72 hours. For actively exploited vulnerabilities, a final report is then required no later than 14 days after a corrective or mitigating measure becomes available. Severe incidents follow a different final deadline, within one month of the 72-hour notification.
That structure tells us something important about the process. Organisations aren't expected to know everything immediately. The reporting model allows information to develop as the investigation does. What they do need is enough reliable information to recognise when the reporting threshold may have been reached and start moving.
That changes the question from “How quickly can we investigate a vulnerability?” to “How quickly can we investigate, assess and make a defensible reporting decision at the same time?”
The Reporting Decision Crosses Several Teams
Security might be the first team to know something has happened, but it probably can't answer every question the CRA creates. Security can assess the vulnerability and evidence of exploitation. Engineering may know which versions contain the affected code. Product teams can identify the products involved and where they're available.
A supplier may hold crucial information about a vulnerable third-party component. Legal and compliance teams then need enough of that evidence to assess the organisation's reporting obligations. The notification itself also needs information about the affected product, vulnerability or incident and any mitigation already available.
Once submitted, it goes to the designated Computer Security Incident Response Team (CSIRT), which can then share it with relevant CSIRTs in other Member States where the product is available. ENISA receives the information as part of the same coordinated process.
So the first 24 hours can't become a relay race where one team finishes its work before handing everything to the next. Some of these jobs need to happen at the same time. That requires clear ownership before anyone is trying to make decisions under pressure.
A Reporting Process Needs Clear Decision Points
Most organisations already have some combination of vulnerability management, product security, incident response and legal processes. The CRA doesn't make those disappear. It creates a point where they need to connect. A practical vulnerability reporting process should make that connection explicit.
People need to know what decision comes next, who owns it and what information they need to make it.
1. Establish what has happened
Start with what you actually know.
- Where did the information come from?
- Is there evidence of active exploitation, or only evidence that the vulnerability exists?
- Does the event meet the criteria for a severe security incident?
- Which details have been confirmed, and which are still assumptions?
The timing needs the same discipline. Recording when the organisation became aware of the event creates a clear reference point for the reporting timeline instead of leaving teams to reconstruct it later from emails, tickets and chat messages. This isn't about completing the technical investigation before anyone moves.
It's about establishing a reliable starting point so the right people can begin working from the same information.
2. Identify what is affected
Knowing that a vulnerability exists isn't the same as knowing your exposure to it. The organisation needs to connect the technical finding to actual products and versions. That can mean tracing components and dependencies, identifying the relevant product owner, checking where products have been made available and contacting suppliers when part of the answer sits outside the business.
Existing product inventories and software bills of materials (SBOMs) can help here, but only as sources of information. The important capability is being able to move quickly from “this component is vulnerable” to “these are the products we need to investigate”. Without that connection, even good vulnerability intelligence can leave the organisation searching for basic product information while the reporting clock continues.
3. Decide whether reporting is triggered
Eventually, someone has to make the call. That decision shouldn't depend on whoever happens to be available when the vulnerability appears. Organisations need a defined escalation path that brings together the technical evidence, affected-product information and legal interpretation required to determine whether CRA Article 14 applies.
The reasoning should also be documented. A decision not to report can be just as important to record as a decision to submit, particularly when the evidence is incomplete and the assessment may change as new information arrives. Clear decision authority prevents another common problem: everyone contributes to the assessment, but nobody is quite sure who can actually say yes or no.
4. Submit and keep building the evidence
Once reporting is required, someone still has to get the notification out. ENISA's Single Reporting Platform uses Assigned Representatives to submit notifications for manufacturers. Users authenticate through EU Login with multi-factor authentication, while the relevant CSIRT validates their authority to report for the manufacturer.
The platform supports Primary and Secondary Assigned Representatives, giving organisations a way to avoid relying entirely on one person. Interestingly, ENISA currently advises manufacturers to begin registration when they need to make a specific notification rather than registering pre-emptively. That makes internal preparation even more important.
Organisations can still decide who'll take the role, who'll provide backup, what information they'll need and how the reporting process will be coordinated before a real notification is required. And submission isn't the end of the investigation. The 24-hour warning starts the regulatory process.
The 72-hour notification adds more information, while later reporting captures the corrective or mitigating measures and what the organisation ultimately learnt about the event.
Test The Process Before A Real Vulnerability Does
A workflow can look perfectly sensible in a policy document and fall apart the first time five teams need to use it at once. There are signs that this gap between having security practices and having mature operational processes is already a problem.
ENISA's 2026 SME CRA Survey found that incident response and product lifecycle management was the weakest of the five product-security domains it assessed, with an average maturity score of 2.61 out of five. Among microcompanies surveyed, 36 per cent had no incident response plan, while just two per cent said their plans were tested and regularly reviewed. T
he research focused on SMEs, so those figures shouldn't be treated as representative of every manufacturer. But ENISA reached a useful conclusion from them: organisations need practical guidance on when and how to report vulnerabilities, including how to use the Single Reporting Platform.
A tabletop exercise can expose the weak points before the deadline is real. Give the team a plausible actively exploited vulnerability and start the clock. Then ask:
- Who records when the organisation first became aware?
- Who decides whether the exploitation evidence is reliable enough to escalate?
- How quickly can you identify affected products and versions?
- Who decides whether Article 14 reporting is required?
- Can security, product and legal work at the same time?
- Who'll act as the Assigned Representative when a report is needed?
- Who takes over if that person isn't available?
- How quickly can you get information from suppliers?
- Where are decisions, evidence and changes to the assessment recorded?
- Can the process actually produce the required early warning within 24 hours?
If any answer begins with “we'd probably ask...”, you've found something worth defining before the next exercise.
Reporting Readiness Depends On Information Flow
Even a well-designed internal process can only move as quickly as the information feeding it. That becomes especially obvious when third-party components are involved. Your security team may know there's active exploitation. Your product team may know which products could contain the component.
But if nobody can establish which version is present or get reliable vulnerability information from the supplier, the reporting decision gets harder. ENISA's 2026 research into SBOM adoption shows how important this information has become. Seventy-six per cent of respondents rated receiving vulnerability status or exploitability claims from suppliers as either critical or important.
When asked how they'd prefer to receive those claims, 44 per cent chose automated delivery and 40 per cent selected a standardised API. The same research identified data quality, supplier SBOM availability and quality, vulnerability matching, and process ownership and governance among the barriers organisations face.
In other words, having the data somewhere isn't enough. It needs to be accurate, accessible and connected to a process that knows what to do with it. The same principle applies internally. Vulnerability intelligence has to reach product owners. Product information has to reach security and legal teams.
Reporting decisions need to reach the person responsible for submission. And all of it needs to happen while the technical picture is still changing.
Final Thoughts: CRA Readiness Is An Operational Capability
The Cyber Resilience Act's reporting requirements don't mean organisations need to solve every technical question within 24 hours. The staged reporting process recognises that investigations take time. What organisations do need is a reliable way to establish what they know, identify what they don't, assess whether reporting has been triggered and get the right people working on the problem quickly.
From there, the evidence can become more complete as the investigation develops. That's what makes CRA readiness less about having another compliance policy and more about building an operational capability. Security, engineering, product, legal, suppliers and reporting owners all hold different parts of the answer.
The process has to connect them before the clock is running. For security leaders, the useful question now isn't whether the organisation knows about the CRA. It's whether the vulnerability reporting process would actually work tomorrow morning.
And EM360Tech will continue exploring how security teams are turning changing regulatory requirements into practical processes that strengthen cyber resilience without slowing the business down.
Comments ( 0 )