This is the fifth blog in our EU CRA Tales From the Trenches series, where we share practical lessons learned while helping manufacturers, software vendors, and connected-product companies prepare for the European Union’s Cyber Resilience Act (CRA). Throughout this series, one theme has become increasingly clear: achieving sustainable CRA compliance requires much more than building secure products. It demands visibility, governance, accountability, and lifecycle management across the entire product portfolio.
The 24-Hour Clock Starts Before Most Companies Are Ready
One of the most talked-about requirements of the European Union’s Cyber Resilience Act is the obligation to report an actively exploited vulnerability within 24 hours of becoming aware of it.
On the surface, the requirement appears straightforward. A vulnerability is disclosed. Your security team evaluates the issue. If reporting is required, the appropriate authorities are notified. In reality, that’s rarely how it works.
Before anyone can decide whether a report is required, the organization must answer a far more difficult set of questions:
- Does this vulnerability affect any of our products?
- Which product versions are impacted?
- Which software components or hardware modules are involved?
- Which customers could be affected?
- Which suppliers are involved?
- Is the vulnerability actually exploitable in our implementation?
- What mitigations already exist?
- What evidence supports our conclusions?
Only after answering these questions can an organization determine whether reporting is required and what actions must be taken.
The CRA’s 24-hour reporting requirement isn’t really testing your ability to write a report. It’s testing how well you understand your products.
The Real Challenge Is Product Intelligence
Historically, vulnerability management focused on identifying vulnerabilities, assessing severity, prioritizing remediation, and deploying patches.
The CRA changes the problem.
Organizations must now rapidly determine how a newly disclosed vulnerability impacts products across an entire portfolio—often spanning hardware, embedded software, mobile applications, cloud services, APIs, legacy products, and acquired technologies.
That requires far more than vulnerability scanning. It requires product intelligence.
When a new CVE is published or a supplier issues a security advisory, organizations need immediate answers—not days of manual investigation across engineering repositories, PLM systems, SBOM tools, supplier portals, spreadsheets, and email threads.
Unfortunately, that’s still how many organizations operate today.
The reporting requirement is not the challenge.
The lack of product intelligence is.
Why Visibility Has Become a Regulatory Requirement
Most manufacturers have never built a centralized view of their connected products. Instead, critical information is scattered across multiple business systems.
Engineering maintains design documentation. Development teams manage source code. Security teams manage vulnerabilities. Compliance teams manage regulatory evidence. Product managers track releases. Procurement manages suppliers. Support teams manage deployed versions.
Each system contains part of the picture. None contains the complete picture.
When a vulnerability is disclosed, organizations often spend valuable time simply assembling enough information to understand whether they have a problem.
The 24-hour reporting clock continues to run while that investigation takes place.
Why This Problem Continues to Grow
Several industry trends are making rapid impact analysis increasingly difficult.
Software Supply Chains Continue to Expand
Modern connected products often contain hundreds of software components originating from internal development teams, open-source projects, commercial software vendors, outsourced developers, semiconductor suppliers, and third-party libraries.
Many organizations simultaneously support multiple hardware revisions, software releases, firmware versions, and long-term support branches.
When a vulnerability is disclosed, determining exactly which products are affected becomes a complex data problem—not a security problem.
Product Portfolios Are Larger Than Ever
Manufacturers increasingly manage portfolios spanning:
- Connected hardware
- Embedded software
- Mobile applications
- Cloud platforms
- APIs
- Digital services
Each product may have different architectures, suppliers, regulatory obligations, customer deployments, and support lifecycles.
Maintaining visibility across this growing ecosystem has become an operational challenge.
Product Information Is Fragmented
Even organizations with mature engineering processes frequently struggle to answer simple questions because information exists across disconnected systems.
The engineering team knows how the product is built. Security understands emerging vulnerabilities. Compliance understands regulatory obligations. Support understands customer deployments. Product management understands product roadmaps.
Without a common system of record, assembling a complete picture requires significant manual coordination.
Vulnerabilities Never Stop Arriving
Threat intelligence changes continuously. New CVEs, supplier advisories, open-source vulnerabilities, exploit techniques, and software updates emerge every day. Organizations need the ability to continuously correlate this evolving intelligence against their products, software components, suppliers, and deployed versions—not perform manual investigations every time a vulnerability appears.
Real-World Challenges
Consider a common scenario. A supplier notifies you that a software component used within your products contains a critical vulnerability. The first question isn’t how quickly you can issue a report. The first question is:
“Where do we use that component?”
Can you immediately identify every affected product?
Every affected version? Every customer deployment? Every associated SBOM? Every supplier relationship? Every existing mitigation?
Many organizations cannot. Instead, engineers begin searching repositories, reviewing historical documentation, contacting development teams, and comparing software versions manually. Hours—or even days—can disappear before the organization understands whether it is actually affected.
The reporting requirement isn’t slowing them down. Their lack of product intelligence is.
Best Practices for Meeting the 24-Hour Requirement
Organizations making significant progress toward CRA readiness are investing in capabilities that improve product intelligence across the enterprise.
Maintain Comprehensive Product Profiles
Every connected product should have a current digital record containing architecture, software versions, components, suppliers, owners, documentation, and lifecycle status.
Maintain Accurate SBOMs
Software Bills of Materials provide critical visibility into software dependencies. SBOMs should exist for every supported product version and remain current throughout the product lifecycle.
Continuously Correlate Vulnerabilities
Threat intelligence should be continuously evaluated against product inventories, software components, supplier information, and SBOMs to rapidly determine product impact.
Establish Clear Governance
Organizations should define ownership for vulnerability analysis, engineering response, regulatory reporting, customer communications, and executive decision-making before incidents occur.
Practice Before It Matters
Tabletop exercises help organizations identify visibility gaps long before a real reporting deadline arrives.
Every organization should be able to quickly answer:
- Are we affected?
- Which products are impacted?
- What evidence supports our conclusion?
- What actions must we take?
Common Pitfalls
Organizations commonly struggle because they:
- Assume generating the report is the difficult part.
- Maintain incomplete or outdated SBOMs.
- Store product information across disconnected systems.
- Lack visibility into supplier dependencies.
- Never test their reporting workflows before an actual incident.
In almost every case, the problem is not incident response capability.
It is incomplete product intelligence.
Action Items for Manufacturers and Software Vendors
Organizations preparing for CRA should begin by strengthening the foundations that support rapid decision-making.
Priority activities include:
- Maintain complete product inventories.
- Identify product owners and escalation contacts.
- Improve SBOM management processes.
- Strengthen software supply chain visibility.
- Integrate vulnerability intelligence with product information.
- Define regulatory reporting workflows.
- Regularly exercise reporting readiness through tabletop scenarios.
Organizations that invest in product intelligence today will be significantly better positioned to satisfy tomorrow’s reporting obligations.
How OmniTrust Certify Can Help
Meeting the CRA’s 24-hour reporting requirement begins long before a vulnerability is discovered.
It begins with understanding your products.
OmniTrust Certify provides a collaborative System of Record for Cyber Risk and Regulatory Conformity, bringing together the information organizations need to understand, govern, and continuously assess connected products throughout their lifecycle.
Using Certify, organizations can:
- Build and maintain living Product Profiles for every connected product or system.
- Maintain product architecture, documentation, software components, suppliers, and supporting evidence in a centralized repository.
- Perform baseline Cyber Risk Assessments (TARAs) and maintain them as products evolve.
- Assess products against multiple regulatory frameworks, including the EU CRA, using a common product profile and shared evidence.
- Track documentation gaps, remediation activities, engineering decisions, and compliance evidence through collaborative Human-in-the-Loop workflows.
- Generate consistent reports, audit packages, and executive dashboards that provide visibility across product portfolios.
When new vulnerabilities emerge, organizations already have the product intelligence needed to rapidly determine affected products, understand regulatory obligations, coordinate engineering and compliance teams, and demonstrate the evidence supporting their decisions.
Rather than treating CRA reporting as a stand-alone activity, Certify helps organizations establish a repeatable lifecycle process that continuously strengthens cyber risk management, regulatory readiness, and operational visibility across their connected product portfolio.
Summary
The EU CRA’s 24-hour reporting requirement is often viewed as a reporting challenge. It isn’t. It is a product intelligence challenge.
Organizations that know their products, maintain current software inventories, understand their supply chains, and continuously govern cyber risk throughout the product lifecycle will be able to make informed decisions quickly and confidently when new vulnerabilities emerge. Those that rely on fragmented documentation, disconnected systems, and manual investigations will find the reporting deadline becomes the least of their problems.
In the era of connected products, product intelligence is no longer simply good engineering practice. It is becoming a fundamental requirement for regulatory compliance.
