“As far as we know” is an uncomfortable phrase to take into an audit.

An intellectual property protection manager used those words to describe certificate visibility before adopting a more centralized approach. Later, the team could identify its certificate usage and enter audits with greater confidence. That perspective comes from Forrester’s July 2025 DigiCert-commissioned study. While it's a certificate-management example rather than evidence of CRA readiness, the underlying challenge is familiar: How confidently can your team account for what it manages?

It captures a problem that matters for CRA reporting. When a relevant vulnerability or incident becomes known, a manufacturer needs to establish which products are affected and who is responsible for the response. Uncertainty about the inventory consumes time that the response team needs for investigation.

That question takes on new urgency under the EU Cyber Resilience Act (CRA). When a relevant vulnerability or incident becomes known, manufacturers need to establish which products are affected, who owns the response, and what evidence supports their decisions. Uncertainty about the inventory consumes time the response team needs for investigation.

The CRA's reporting obligations for manufacturers of in-scope products began September 11, 2026. Under European Commission guidance, actively exploited vulnerabilities and severe incidents affecting product security require an early warning within 24 hours of awareness and a full notification within 72 hours.

Those deadlines make the handoffs worth testing now. A completed policy won't tell you whether the person receiving a vulnerability report can reach the engineer who knows which release contains the affected component.

Begin with a product you already ship

For a tabletop exercise, choose one in-scope product and an illustrative vulnerability report involving one of its components. Do not start with an invented company-wide crisis. A single product can expose enough gaps.

Ask the team to identify the affected versions, currently supported releases, and who owns the technical assessment. If the component came from a supplier, retrieve the supplier's contact information and the evidence they're expected to provide. Record what the team can establish, what remains uncertain, and who will resolve it.

A software bill of materials (SBOM) can help locate the component. But it doesn't, on its own, establish whether the vulnerability is exploitable in your product or whether it meets the legal reporting threshold. That requires a technical assessment and a reporting decision.

This is where the exercise should slow down. What matters is understanding how new information changes the assessment. Preserve the evidence and record when it became available. Avoid reducing the process to a form everyone assumes someone else can complete.

Give the decision and the submission an owner

In the exercise, identify who evaluates the reporting trigger, who authorizes the notification, and who can submit it. Include a backup. Someone being on leave should not force the team to discover access arrangements under pressure.

The European Commission distinguishes between reporting milestones. For actively exploited vulnerabilities, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For severe incidents, it's due within one month of the 72-hour notification. Manufacturers use the Single Reporting Platform, with notifications directed to the relevant CSIRT and made available to ENISA under the applicable rules.

Keep those distinctions in the response procedure. A new vulnerability finding does not automatically mean active exploitation or a severe incident. Your product-security and legal owners should establish the applicable scope and reporting triggers before the team needs to rely on the procedure.

Run the exercise without filing a real notification. Confirm that authorized team members know how the submission process works and what information each stage requires. Note any gaps in access, coverage, or decision authority.

Follow the corrective action back to the product

Once the team has a fix or other corrective measure, connect it to the affected product versions. Record the approval, identify the released artifact, and preserve evidence of its integrity. Determine how customers will receive the change and how the organization will track deployment, where possible.

Signing helps recipients verify the origin and integrity of a release. But it doesn't establish that the fix resolves the vulnerability, that every customer installed it, or that the reporting obligation is complete. Each requires its own evidence.

For products that can't be updated immediately, document the supported mitigations and how they'll be communicated. Field service, customer support, and engineering need consistent information. A customer asking whether a particular unit is affected shouldn't receive a different answer depending on which team picks up the case.

The product record should connect the original report, assessment, decision, notifications, and corrective action. The goal is to retrieve a defensible account later without having to piece it together from disconnected messages.

Leave the rehearsal with a short repair list

Measure how long it took to identify affected versions and assemble the information for an early warning. Record where a handoff stalled and whether the designated backup could continue the process. These are internal readiness measures, not substitutes for the legal deadlines.

Assign an owner to each gap that slowed the exercise. Questions worth resolving include who maintains the product-component mapping, what evidence a supplier must provide, and who can authorize a notification when the usual owner is unavailable. Repeat the affected part of the rehearsal after making the change.

Start with one shipped product and one report-to-response walkthrough. It's a manageable way to find out whether the evidence your policy assumes is available to the people who need it.

The phrase from the customer audit account offers a useful test. When your team identifies which products are affected, can it point to the records behind that answer?

Sources

1. Forrester’s Total Economic Impact of DigiCert ONE. July 2025. Commissioned by DigiCert. Anonymous interview evidence is distinct from the modeled composite organization.
2. European Commission’s CRA reporting guidance. Updated September 11, 2026. Manufacturer reporting triggers, deadlines and Single Reporting Platform.