Buying a CRA reporting readiness review: evidence to require

A useful Cyber Resilience Act (CRA) reporting readiness review should demonstrate how your team handles a specific case: establish product scope, assess both reporting triggers, record awareness, notify users, and complete the applicable reporting stages. Put these deliverables and their acceptance criteria in the assessment contract.

Manufacturer reporting obligations began on September 11, 2026, when the Single Reporting Platform (SRP) became operational. Your review should therefore test an executable reporting workflow against the applicable requirements and current platform instructions. European Commission: CRA reporting obligations

This guide reflects sources checked on September 21, 2026. The legal requirements come from the cited legislation. The exercise design, suggested owners, internal targets, and acceptance criteria are procurement recommendations.

Start with scope and two separate triggers

Require the assessor to apply this decision tree to the evidence and explain each conclusion:

1. Is this the manufacturer's product, and is it within CRA scope? Identify the hardware or software, affected versions, relevant components, and how it is made available on the EU market. Article 2 covers products whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network, subject to its exclusions. Record the applicable inclusion or exclusion.
2. Does the product contain an actively exploited vulnerability? Article 3(42) requires reliable evidence that a malicious actor exploited the vulnerability in a system without the system owner's permission. A scanner finding, high severity score, or authorized demonstration of exploitability does not by itself establish this trigger. Explain how the evidence establishes malicious exploitation and connects it to your product.
3. Independently, has a severe incident affected the product's security? Under Article 14(5), an incident is severe if it negatively affects, or can negatively affect, the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions; or if it has led, or can lead, to malicious code being introduced or executed in the product or its user's network and information systems. This assessment does not depend on first establishing an actively exploited vulnerability.
4. Record the result and act. If either trigger is met, initiate the corresponding reporting process and the user-communication workflow. If both are met, address both obligations. If neither is established, document the missing evidence, investigator, immediate escalation route, and a specific reassessment time. An unfinished assessment cannot suspend an obligation that has already arisen.

These tests follow CRA Articles 2, 3(42), and 14.

For web applications and services, document the product boundary explicitly. A website or SaaS label does not settle scope. A product includes qualifying remote data processing: software designed and developed by or under the manufacturer's responsibility, without which the product could not perform one of its functions. A website that does not support a product's functionality falls outside that boundary. Assess the actual architecture and commercial arrangement under Articles 2 and 3(1)–(2), with recital 12 as context. CRA scope and remote data processing

Record awareness and distinguish legal periods from internal targets

Early warnings and subsequent notifications must be submitted without undue delay, with statutory limits of 24 hours and 72 hours from awareness of the relevant actively exploited vulnerability or severe incident. The 72-hour period runs from awareness, not from submission of the early warning. CRA Article 14(2) and (4)

Assign someone to record awareness and track deadlines. Distinguish when information arrived, what it established, and when the manufacturer became aware of the reportable event. Internal approval or later executive confirmation cannot postpone that point. If evidence establishes earlier awareness, correct the chronology and deadline calculations with an explanation.

For an unresolved case, require immediate escalation when new evidence could establish a trigger, alongside a scheduled reassessment. A status such as “awaiting legal review” must not become a reason to delay an already-required notification.

Keep statutory periods and internal submission targets in separate fields. Article 14 expresses the final-report periods in days and months. Article 3 of Regulation 1182/71 distinguishes periods expressed in hours from those expressed in days or months and addresses their beginning, expiry, and relevant nonworking days. An exact final-report cutoff therefore needs a documented calculation under the applicable rules; Article 14 alone does not establish the same clock time 14 days or one month later. Regulation 1182/71, Article 3

Make user communication part of the awareness decision

Article 14(8) requires the manufacturer, upon becoming aware of the actively exploited vulnerability or severe incident, to inform affected users and, where appropriate, all users. The information must cover the vulnerability or incident and, where necessary, risk mitigation and corrective measures users can take. Where appropriate, it must use a structured, machine-readable format that is readily processed automatically. The obligation is tied to awareness; availability of a workaround is not its starting point. CRA Article 14(8)

Require a communication decision at awareness: who needs the notice, whether broader notification is appropriate, which channels will reach them, who will send it, and when. Record known facts, uncertainties, and any currently available user actions. If no validated measure is available, say so and arrange an update. Keep the user-notification workflow distinct from submissions to authorities.

As evidence, require the initial mock notice, a simulated dispatch record, and subsequent updates. The record should identify the notice version, intended recipients, channels, dispatch time, and any delivery gaps requiring follow-up. Assess the elapsed time from awareness and the reasons for any delay; merely naming a communications owner is insufficient.

A fictional decision record

The following is an invented tabletop exercise. All dates are in 2026 and all times are UTC. Submissions, messages, and publication are simulated outside production; no real users receive exercise notices.

The scenario concerns a commercial network appliance, version 4.2, sold in Slovenia and Austria. Its management API is part of the appliance software. The exercise stipulates that the product falls within Article 2 and no exclusion applies.

For exercise tracking, set internal submission targets of September 22 at 10:10 for early warnings and September 24 at 10:10 for the 72-hour notifications, measured directly from recorded awareness. The simulated submissions occur earlier. These targets do not authorize avoidable delay.

The statutory vulnerability final-report period is no later than 14 days after a corrective or mitigating measure becomes available. The statutory incident final-report period is within one month after submission of the Article 14(4)(b) incident notification. Set October 6 at 15:00 and October 23 at 09:00, respectively, as conservative internal exercise targets. These clock times are not presented as exact statutory cutoffs. Require the assessor to document the applicable legal calculation separately, including the relevant time zone and calendar rules. CRA Article 14(2)(c) and (4)(c), Regulation 1182/71, Article 3

Then change the scenario: remove the bypass evidence and introduce a compromised signing key used to distribute a malicious update. Require the team to assess the severe-incident branch independently, even if no exploited product vulnerability has been established. Repeat the user-communication decision using the revised facts.

Require every reporting stage

The matrix summarizes Article 14. Qualifications such as “if available” and “where applicable” must be reflected accurately in the records. Suggested owners are internal assignments; the manufacturer retains responsibility.

The coordinating CSIRT may also request an intermediate report under Article 14(6). Maintain the separate user-communication record required by the exercise alongside these authority-reporting records. CRA Article 14

Map the legal matrix to the current platform fields using the SRP glossary linked from ENISA's platform page. Require a field-by-field worksheet for each notification type and stage, with evidence sources and explicit unknowns. ENISA SRP: guidance and supporting resources

Test registration and handoff against current instructions

Prepare personal EU Login accounts with MFA and assign reporting responsibilities in advance. ENISA advises initiating SRP registration when a notification is needed; pre-incident SRP registration should therefore not be an acceptance criterion. Inviting a secondary representative requires a verified primary association. ENISA FAQ 9

Pending validation of the representative's manufacturer association does not prevent an initial submission. Drafts are private to their author. Closed notifications and notifications with a submitted final report cannot be edited under the guidance updated September 12, 2026. ENISA submission and update guidance

The exercise should cover both the first submission before backup access exists and a later handoff. Have the team explain registration, invitation, and access recovery using current instructions.

Require the backup to reconstruct an unfinished notification from a controlled internal evidence pack. Record which steps depend on platform permissions or CSIRT assistance. For a correction discovered after editing is locked, require an escalation procedure to obtain instructions from the coordinating CSIRT or SRP support.

Use an offline simulation or a non-production environment if one is available and authorized for training. Keep fabricated notifications out of production. Distinguish observed account readiness, simulated workflow completion, and actual production submission evidence.

Require a reasoned CSIRT selection

Under Article 14(7), the manufacturer's main establishment is determined by where decisions concerning its products' cybersecurity are predominantly made. It is not automatically the registered headquarters. If that Member State cannot be determined, use the Member State containing the manufacturer's EU establishment with the most employees.

For a manufacturer without a main establishment in the EU, apply the statutory order using available information: the Member State where the authorized representative acting for the largest number of its products is established; failing that, the importer placing the largest number on the market; then the distributor making the largest number available; and finally the Member State with the most users. CRA Article 14(7)

The manufacturer must select the correct coordinating CSIRT. Incorrect selection may invalidate the notification and require resubmission. ENISA FAQ 18

Require a short selection memorandum identifying the manufacturer, relevant establishments, decision-making evidence, any fallback applied, and the selected CSIRT. In the fictional case, sales in Slovenia and Austria alone would not establish the correct destination.

Put acceptance criteria in the contract

Accept the review only when its evidence pack demonstrates all of the following:

• A documented product boundary and separate conclusions for both reporting triggers, each linked to evidence.
• An awareness chronology and documented legal deadline calculations, with internal targets identified separately, no postponement for internal approval, and specific reassessment times for unresolved questions.
• Completed mock records for both reporting tracks through their final reports, with a field-level completeness check and clearly identified uncertainties.
• A user-communication decision recorded at awareness, identifying affected users, the rationale for any broader audience, channels, timing, known facts, uncertainties, and available user actions.
• An initial mock user notice and simulated dispatch record demonstrating timely notification after awareness, plus subsequent notices and dispatch records for material updates, including the workaround. Any delay or delivery gap has an explanation, owner, and follow-up action.
• A documented CSIRT-selection rationale and a registration plan consistent with current guidance.
• A backup handoff that works from the internal evidence pack without assuming access to another person's private draft or sharing credentials.
• A recorded mitigation decision, fix owner, user-communication owner, and follow-up dates.

Require the assessor to mark each criterion demonstrated, partially demonstrated, or not demonstrated and cite the supporting artifact. Mock submission and dispatch records establish exercise performance only. Where legitimate production records are available, assess their timestamps and statuses separately.

Keep technical validation connected to remediation. Existing web security and API security assessments can inform product impact and corrective measures. The reporting exercise must still demonstrate classification, timing, user communication, and handoff.

Turn each failed criterion into an assigned improvement with a completion date and retest. Repeat affected parts after material changes to products, personnel, or platform procedures. A tabletop review demonstrates performance against its scenario; it cannot certify every future reporting decision or guarantee that an authority will regard a notification as complete.