An intrusion into a manufacturer’s enterprise does not become a CRA severe incident merely because it is serious to the company. The CRA question is whether the event affects, or is capable of affecting, the security of a product with digital elements under the Article 14(5) tests.
The same underlying event can still create other reporting, contractual, or operational duties. The purpose of this triage is to add a product-security view without replacing the enterprise incident process.
Draw the product dependency path
Start with the compromised asset and trace every controlled path to a product. Useful nodes include source repositories, build workers, signing services, update distribution, product backends that form part of the product, release storage, support tooling, and privileged product-administration systems.
For each path, record whether access was possible, attempted, or observed. Identify the product versions and functions that depend on the asset. Do not infer product impact from network proximity alone, and do not infer no impact because customer devices were not directly accessed.
Test the two severity branches
For the first branch, identify the sensitive or important data and functions the product is expected to protect. Evaluate availability, authenticity, integrity, and confidentiality separately. Record both observed negative effects and technically supported capabilities to cause them.
For the second branch, assess whether the event led or could lead to malicious code being introduced or executed in the product or in a user’s network and information systems. Preserve signing logs, build provenance, release hashes, access records, and distribution evidence. State what remains unknown.
Keep the evidence product-specific. A compromised corporate mailbox and a compromised release-signing key may share one incident number but have very different CRA analyses.
Run two linked workstreams
The enterprise incident commander should own containment and recovery. A product-security lead should own the product-boundary and Article 14 assessment. Link their records with the same event anchor, but give each workstream its own questions, approver, external recipients, and clocks.
Set a short reassessment cadence while evidence is changing. A preliminary “no demonstrated product path” conclusion should name the checks still running and the fact that would reverse it. If product impact reaches a severe test, record awareness and begin the CRA reporting sequence without waiting for the enterprise investigation to close.
Preserve the negative case too
When the event remains outside the CRA severe-incident definition, retain the asset map, product dependency analysis, queried logs, decision time, approver, and reopen conditions. Avoid the vague conclusion “corporate only”; explain why no supported path affected or could affect the relevant product protections.
This split gives responders a practical result: one incident can be managed as a whole while the product-security decision remains explicit, reviewable, and tied to the evidence that actually matters under Article 14.
Continue this workflow with the severe-incident test and the CRA and GDPR triage.