CRA September 2026 reporting checklist — preparation for the 24-hour rule

The Cyber Resilience Act enters its first substantive enforcement phase on 11 September 2026, when Article 14 reporting obligations become mandatory. From that date, manufacturers of products with digital elements must submit a three-tier report cascade to ENISA whenever they become aware of an actively exploited vulnerability or a severe incident.

This article is a checklist for manufacturers preparing for the September 2026 milestone — the operational, technical, and contractual work that must be in place before the first 24-hour clock starts.

For the full operational mechanics of the reporting cascade, see CRA ENISA 24-hour reporting. For the full CRA timeline, see CRA timeline and reporting obligations.

Checklist — operational readiness

☐ Scope analysis — confirm which products are in scope

CRA Article 3(1) defines "products with digital elements" broadly. Document for each of your product lines:

• Whether the product is in scope of CRA
• The basis for the scope determination (in-scope per Article 3(1) / excluded under Article 2 / sector regulation applies)
• The applicable conformity assessment route (standard / important Class I / important Class II / critical)

Out-of-scope claims need supporting evidence in the Technical File — typically a reference to a sector regulation that takes precedence (MDR, Type Approval for vehicles, EASA for aviation).

☐ Internal escalation path — documented and tested

When a customer support ticket, internal security finding, or external researcher report describes a potential reportable event:

• Who classifies it as a potential CRA-reportable event?
• What triage criteria distinguish a routine bug from an "actively exploited vulnerability" or "severe incident"?
• Who has authority to confirm the classification and trigger the 24-hour notification?
• What is the out-of-hours escalation contact for the classification decision-maker?
• What is the legal entity that signs the notification?

Document the escalation as a flowchart in the Technical File post-market surveillance section. Test it quarterly with a tabletop exercise.

☐ ENISA platform account — established and authorised

ENISA will operate a single reporting platform from 11 September 2026 per CRA Article 16. Before the application date:

• Monitor the ENISA CRA implementation page for platform launch announcement
• When the registration mechanism is published, register the manufacturer (and EC REP, where applicable) early
• Identify the individuals authorised to file reports on the manufacturer's behalf
• Document the platform credentials in a secure shared location (not on a single individual's laptop)
• Test the platform's report submission workflow before the first incident

☐ CSIRT contact — identified and rehearsed

Per CRA Article 14(1), reports go to the CSIRT designated as single point of contact in a member state — typically the member state where the manufacturer is established. Identify yours:

• Slovakia: CSIRT.SK
• Germany: BSI CERT-Bund
• France: CERT-FR (ANSSI)
• Czechia: GovCERT.CZ
• Other member states: see NIS2 national CSIRT designations

Pre-establish a relationship:

• Contact the CSIRT to confirm out-of-hours contact protocols
• Verify the secure communication channel (PGP key, encrypted email, dedicated platform)
• Document the contact in the post-market surveillance section of the Technical File

☐ Coordinated vulnerability disclosure policy — published

CRA Annex I Part II item (5) requires an enforced CVD policy. Before September 2026:

• Publish a CVD policy on the manufacturer's public website
• Publish a .well-known/security.txt file per RFC 9116
• Document acknowledgement and remediation SLA commitments
• Identify the inbound researcher communication channel
• Train internal stakeholders on safe-harbour communication with researchers

☐ SBOM infrastructure — operational

CRA Annex I Part II item (1) requires a machine-readable SBOM. Before September 2026:

• Generate SBOMs in CycloneDX or SPDX format for every product
• Integrate SBOM generation into CI pipelines
• Maintain historic SBOMs alongside historic firmware versions
• Monitor SBOMs against NVD, GitHub Security Advisories, and vendor advisory feeds continuously

See SBOM CycloneDX vs SPDX for tooling and format detail.

☐ Vulnerability monitoring — continuous

Per CRA Annex I Part II items (2) and (4):

• Daily check of SBOM-listed components against NVD, GitHub Security Advisories, and supplier advisories
• Automated alerting on new CVEs affecting components in the SBOM
• Triage workflow that classifies disclosed CVEs by exploitability in product context (VEX-style assertions)
• Documented patch SLA per severity (industry common practice: Critical < 7 days, High < 30 days, Medium < 90 days)

☐ Severe incident detection — monitoring in place

For non-vulnerability incidents (cyberattacks affecting product manufacturing or maintenance, supply chain compromise):

• SIEM or log aggregation covering production environments
• Customer support escalation path for security-incident-shaped complaints
• Public-internet monitoring of brand-related threat actor activity (forums, marketplaces)
• Insurance / IR retainer for incident response surge capacity

☐ Personal data assessment — GDPR Article 33 parallel path documented

A CRA-reportable incident may also be a GDPR-reportable personal data breach. Document the parallel workflow:

• Who assesses whether personal data was compromised?
• Decision tree for whether a GDPR 72-hour notification is required
• Contact for the member-state Data Protection Authority

The two notifications go to different recipients under different legal bases. Both can apply to the same incident.

☐ Templates and pre-filled forms

Prepare templates in advance:

• 24-hour early warning notification template
• 72-hour incident notification template
• Final report template
• Internal incident log template (with timestamps for "awareness", "classification", "first notification")
• VEX statement template for affected SBOM components

When the 24-hour clock starts, the team should be filling content into a template, not designing the template under time pressure.

☐ Tabletop exercise — completed and documented

Before 11 September 2026, run at least one tabletop exercise simulating:

• A CSIRT report of in-the-wild exploitation against your product
• Internal triage, classification, and escalation
• Early warning preparation and submission rehearsal
• 72-hour notification preparation
• Final report preparation post-patch availability
• Parallel CVD coordination with the hypothetical reporting researcher
• Customer communication
• Public advisory drafting

Document the exercise findings in the post-market surveillance section of the Technical File. Iterate.

☐ Insurance review

Verify cyber liability and professional indemnity coverage for:

• Regulatory fines under CRA Article 64
• Defence costs in member-state proceedings
• IR retainer activation
• Customer notification and credit monitoring costs (if personal data is affected)

Many existing policies pre-2024 do not contemplate CRA fines. Update or extend coverage.

Common preparation gaps

From the Inovasense practice working with manufacturers preparing for September 2026:

• No documented "awareness" timestamp. When the 24-hour clock starts is the most defensible point — but only if the manufacturer's internal triage log records when awareness occurred.
• CSIRT relationship not pre-established. Trying to identify your member-state CSIRT contact during an active incident burns hours.
• No 24/7 escalation path. The 24-hour clock can start at 19:00 on a Friday. If the next available decision-maker is Monday morning, 60 of the 24 hours are already gone.
• CVD policy exists but does not commit to a researcher acknowledgement SLA. Annex I Part II item (5) requires the policy to be enforced; commitments without SLAs are unenforceable.
• SBOM frozen at first release. Without per-release SBOM updates, identification of affected versions during an incident is manual archaeology.
• No platform rehearsal. Filing a CRA report for the first time during an active 24-hour clock is high-stress; rehearsing with the live (or sandbox) platform pre-incident reduces error rate dramatically.

How Cenitia helps with September 2026 readiness

Cenitia provides:

• Automated SBOM ingestion from CI pipelines (CycloneDX or SPDX)
• Continuous monitoring of SBOMs against NVD and vendor advisories
• VEX statement template generation per affected CVE
• 24-hour, 72-hour, and final report templates pre-populated with manufacturer and product details
• Out-of-hours alerting on inbound CSIRT communications and high-severity CVE matches
• Tabletop exercise script generation for internal rehearsal

For manufacturers needing operational consulting on the September 2026 workflow setup, including CSIRT engagement and tabletop facilitation, our parent company Inovasense provides services.

Frequently asked questions

When does the CRA Article 14 reporting obligation become enforceable?

11 September 2026, per Article 71(2) of the Cyber Resilience Act. From that date onwards manufacturers must submit a three-tier report cascade — 24-hour early warning, 72-hour notification, and final report within 14 days of corrective measure availability — to ENISA via a single reporting platform for actively exploited vulnerabilities and severe incidents in products with digital elements placed on the EU market.

Do I need to have everything in this checklist done before 11 September 2026?

Yes for the operational items — workflow, escalation, platform account, CVD policy, monitoring, and the test rehearsal. The substantive Annex I conformity obligations come into force on 11 December 2027, so manufacturers have an additional 15 months for product-level engineering work. But the reporting workflow itself must be operational from 11 September 2026 because the 24-hour clock can start at any moment.

What if I am not in scope of CRA on 11 September 2026?

If your product is not a 'product with digital elements' as defined in CRA Article 3(1), the reporting obligation does not apply. The scope is broad — almost any commercial connected hardware or software product is in scope. If you are uncertain, perform the scope analysis early and document the conclusion in your Technical File. Member-state authorities can request the documentation supporting an out-of-scope claim.

How is the September 2026 ENISA platform account established?

ENISA will publish the platform access procedures in advance of 11 September 2026. The typical pattern under EU regulatory infrastructure: organisations register via a member-state identification mechanism (eIDAS-compliant electronic identity for EU-established organisations; equivalent attestation for EC REPs of non-EU manufacturers). Manufacturers should monitor the ENISA CRA implementation page for the platform launch announcement.

What happens if I am not ready on 11 September 2026?

Failure to comply with Article 14 reporting obligations carries fines under Article 64 of up to €10 million or 2% of global annual turnover (whichever is higher). Member-state market surveillance authorities can also order product withdrawal, recall, and import bans. Not being ready is not a defence — the obligation is binary on the application date.

Does the September 2026 obligation apply to existing products already on the market?

Yes. Article 14 reporting applies to any product with digital elements placed on the EU market that the manufacturer becomes aware of being subject to active exploitation or severe incident — including products placed on the market before September 2026 still in active support. This is distinct from the Annex I substantive conformity obligations, which apply only to products placed on the market from 11 December 2027 onwards.

Related from the Library

• CRA timeline and reporting obligations — pillar context for all CRA milestones
• CRA ENISA 24-hour reporting — operational detail of the cascade
• CRA Annex I explained — the December 2027 obligations
• SBOM CycloneDX vs SPDX — the SBOM infrastructure the reporting depends on
• CRA vs NIS2 overlap — parallel NIS2 reporting

Further reading

• Cyber Resilience Act Articles 14 and 16
• CRA Article 71 — transitional provisions
• ENISA CRA implementation page
• RFC 9116 — security.txt format
• ENISA Good Practices for Incident Response

Last reviewed: 30 June 2026. Cited regulations watched continuously by Cenitia — when one amends, this article is flagged for update.