CRA reporting makes asset awareness and lookup the first priority

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Block Harbor's blog post: The EU Cyber Resilience Act's reporting duty puts asset awareness, vulnerability intake and product lookup ahead of broader compliance work.

Why it matters: This matters because product security teams need governance over affected assets, suppliers and disclosure channels before they can meet tight reporting clocks under the CRA.

Context

The reporting duty in the EU Cyber Resilience Act is a governance problem before it is a filing problem. Teams need to know whether a product is in scope, whether exploitation is credible, and which shipped versions and asset instances are affected before they can notify anyone.

Connected products often fail here because asset inventories, firmware records, supplier inputs and vulnerability reports live in separate systems. That makes rapid triage difficult even when each source is individually accurate, especially for fleets with long service lives and mixed product lines.

Key questions

Q: What should teams do first when critical vulnerabilities are not exploitable in production?

A: Start by separating findings that are actually reachable from those that only look severe in a generic scanner. Check call paths, authentication barriers, deployment exposure, and live traffic before assigning top-priority remediation. That first pass prevents teams from burning engineering time on vulnerabilities that cannot be exercised in the running environment.

Q: Why does product lineage matter for vulnerability reporting?

A: Product lineage matters because a report only belongs to the right manufacturer, product, and version if the affected component can be traced through suppliers, forks, and embedded software. A clear relationship model helps security teams map the vulnerable asset, assign ownership, and avoid misrouting reports or overlooking downstream affected products.

Q: How does coordinated vulnerability disclosure help product security teams?

A: Coordinated vulnerability disclosure gives product security teams a reliable route for receiving, validating, triaging, and fixing reports before public release. It reduces confusion over ownership, preserves exploit details during remediation, and lets the team coordinate patches, advisories, and timelines with the reporter and any affected suppliers.

Q: When should manufacturers treat a report as a regulatory notification?

A: Manufacturers should treat a report as a regulatory notification when the issue meets the legal threshold for mandatory reporting, such as a vulnerability that is actively exploited in an in-scope product or creates a serious security impact. That usually requires formal intake, escalation, evidence preservation, and legal review alongside technical triage.

Technical breakdown

How CRA reporting clocks start after active exploitation

The CRA does not treat every vulnerability as a reportable event. The trigger is awareness of active exploitation, which means there is reliable evidence that an attacker has already used the flaw without the owner’s permission. That distinction matters because the 24-hour, 72-hour and 14-day clocks begin only after the organisation knows the product is being abused. In practice, this shifts emphasis from generic vulnerability management to credible detection, intake and triage across deployed product estates. A researcher disclosure, a vendor advisory or your own telemetry can start that process, but the duty is tied to confirmed exploitation, not mere exposure.

Practical implication: Build a response path that can classify exploitation evidence quickly enough to decide whether the CRA clock has started.

Why asset lineage determines whether a report is usable

CRA notifications are only useful if the organisation can connect the flaw to the exact products, versions and deployed instances that carry it. That requires asset lineage, which is the relationship between a component, the product build that contains it, and the field assets that received that build. When firmware data, supplier records and threat findings are stored separately, the team can know a weakness exists without knowing where it lives. The result is delay, not because the data is absent, but because the relationships are missing. For industrial and connected products, lineage is the difference between a report and a lookup.

Practical implication: Maintain a product-to-asset relationship model so exploitation evidence can be mapped to affected field units without manual reconstruction.

Why coordinated vulnerability disclosure becomes part of product operations

The reporting duty is reinforced by a disclosure path that lets researchers and intermediaries reach the manufacturer before public escalation. That changes product operations because intake is no longer an ad hoc inbox problem. It becomes a governed process with routing, acknowledgement, tracking, legal review and engineering triage. Where that process is absent, researchers will use alternate channels, and the organisation loses control of timing and context. For in-scope products, disclosure governance is not a public relations issue. It is a core operating requirement that determines whether the security team hears about exploitation early enough to act. See the Vulnerability Disclosure Policy Template.

Practical implication: Stand up a monitored disclosure workflow with clear ownership, routing and evidence handling before September reporting obligations take effect.

Threat narrative

Attacker objective: The attacker aims to exploit a product flaw long enough to remain operational before the manufacturer can identify affected assets and start the CRA reporting process.

1. Entry occurs when a vulnerability in an in-scope connected product is actively exploited in the field before the manufacturer is aware of it.
2. Credential_harvested is not the main stage here; the critical step is exploitation evidence reaching the manufacturer through internal monitoring or a third party.
3. Escalation follows when the team cannot immediately map the flaw to specific product versions, suppliers and deployed assets.
4. Impact is delayed reporting, incomplete notification and slower mitigation for affected customers and operators.

Breaches seen in the wild

• United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.
• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CRA reporting is really an asset-awareness test. The rule sounds like a compliance deadline, but the operational challenge is knowing what is affected quickly enough to file credible notifications. If you cannot tie a vulnerability to specific versions, configurations and fielded machines, the clock is only part of the problem. The larger failure is that the product estate is not governable at incident speed.

Disclosure routing is now part of the product security boundary. A company that cannot receive reports cleanly will not control the tempo of response, even when researchers try to help. That is why a disclosure path is not a communications convenience but a control surface for connected products and industrial fleets. Practitioners should treat intake design as part of security operations, not a side channel.

Product lineage is the named control gap this duty exposes. The CRA rewards organisations that can answer one question fast: which shipped assets contain the vulnerable component? The organisations that struggle are usually not short of alerts; they are short of an authoritative relationship model between firmware, suppliers and deployed equipment. That gap turns reporting into manual reconstruction instead of operational lookup.

Connected products need incident governance that spans engineering, legal and customer notification. The reporting duty will force cross-functional coordination because the same evidence must support filing, remediation and user communication. Teams that keep those functions separate will move too slowly when exploitation is confirmed. The practical conclusion is straightforward: response ownership must be designed across the product lifecycle, not assembled during a crisis.

What this signals

Product lineage will become the differentiator. Teams that can resolve a finding against a live asset tree will handle CRA reporting as an operational lookup exercise, while those that cannot will spend the first hours rebuilding scope from fragmented records. The control pressure now sits on relationship data, not just on vulnerability data.

The next failure mode will be governance fragmentation between disclosure intake, engineering analysis and customer notification. Organisations that keep those functions in separate systems will meet the deadline on paper but miss the purpose of the rule, which is fast awareness and credible user warning.

For practitioners

• Build a CRA-aware disclosure intake path Create a monitored reporting channel, routing rules and acknowledgement process so vulnerability reports reach engineering, legal and communications without delay.
• Map shipped products to field assets Maintain an asset tree that links components, firmware versions, configurations and deployed machines so a report can be translated into affected units quickly.
• Classify active exploitation evidence fast Define the criteria and decision owner for starting the 24-hour, 72-hour and 14-day CRA clocks when evidence suggests a product is already being exploited.
• Prepare user notification templates Draft product and user-facing messages in advance so affected customers can be told what happened, what is impacted and what mitigation they can apply.

Key takeaways

• The CRA reporting duty is less about filing paperwork and more about proving fast awareness of active exploitation in the field.
• The hardest operational problem is translating a vulnerability report into affected products, versions and deployed assets before the clock runs out.
• Organisations need disclosure intake, lineage data and notification ownership in place before September to avoid manual reconstruction under pressure.

Related NHI Mgmt Group resources: Software Supply Chain Security Guide · Vulnerability Disclosure Policy Template · EU Cyber Resilience Act Guide

Key terms

• EU Cyber Resilience Act: A European Union law intended to raise the security baseline for hardware and software with digital elements. It requires security considerations across design, development, market placement, and maintenance, so manufacturers, importers, and distributors carry clearer responsibility for product cybersecurity throughout the life cycle.
• Product Lineage: Product lineage is the traceable relationship between a product and the components, suppliers, versions, and derivatives that make up or inherit from it. In vulnerability management, it is used to identify which legal entity, product name, and release chain owns a flaw, including embedded and downstream software.
• /.well-known/security.txt: /.well-known/security.txt is a standard location for a website's security contact information. It lets researchers find a public reporting address, encryption key, disclosure policy, and sometimes acknowledgements path, using a predictable file under the .well-known path at the site root.
• Disclosure Intake Workflow: A disclosure intake workflow is the process for receiving, validating, routing, and tracking vulnerability reports from first contact to resolution. It usually includes deduplication, severity triage, ownership assignment, evidence handling, and coordinated communication with the reporter and fix owners.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, machine identity security and secrets management, including how identity control supports operational response. It helps practitioners connect governance decisions to the wider security programme that products and supply chains depend on.