--- title: "Cyber Resilience Act Reporting: 24-Hour Playbook" canonical: https://wavect.io/blog/cyber-resilience-act-reporting-playbook-2026/ language: en description: "Prepare CRA vulnerability reporting for September 2026 with a 24-hour workflow, evidence architecture, ownership model, drills, and implementation plan." image: "https://wavect.io/img/blog/headers/header_cyber-resilience-act-reporting-playbook-2026.png" --- [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 min read · 24 Aug 2026 Last reviewed August 24, 2026 [**Next**](/blog/eu-battery-passport-software-architecture-2027/) # Cyber Resilience Act Reporting: The 24-Hour Playbook for September 2026 TL;DR CRA vulnerability reporting starts on 11 September 2026. Manufacturers need one durable incident record that supports the 24-hour early warning, 72-hour notification, and final report. Define awareness and decision authority, connect vulnerability intake to product versions and support records, preserve verified facts and uncertainty separately, retain submission receipts, and rehearse the handoffs before the duty applies. **From 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in a product with digital elements must start a staged report through ENISA's Single Reporting Platform. The operational sequence is an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report after corrective measures are available.** This is an engineering playbook, not legal advice. It focuses on the reporting workflow that product teams must make executable before the first CRA obligations apply, rather than repeating a broad compliance summary. ## What changes on 11 September 2026? | Checkpoint | Regulatory trigger | Engineering action | | --- | --- | --- | | **24 hours** | Early warning after awareness of active exploitation | Open one report, preserve the awareness timestamp, affected markets, and initial severity | | **72 hours** | Vulnerability notification | Add technical assessment, exploitation evidence, mitigations, and affected versions | | **Final report** | No later than 14 days after a corrective or mitigating measure is available | Record root cause, remediation, rollout, and user communication | ## Who owns the reporting clock? A single incident commander should own the clock, but the evidence must come from product, security, support, legal, and communications. Awareness is a business event, not merely the moment a CVE receives a number. Define who may declare awareness and record that decision in an append-only incident timeline. - Route researcher, customer, CSIRT, bug-bounty, monitoring, and supplier reports into one intake queue. - Store product identifiers, versions, countries, exploitation indicators, reporter contact, and first-observed time as structured fields. - Keep the same internal incident ID across the 24-hour, 72-hour, and final submissions. ## What should the reporting architecture contain? Build an evidence pipeline, not a form-filling ritual. The platform adapter should read from an incident record that remains useful when the external form or API changes. Separate verified facts from hypotheses, assign an owner to every unknown, and retain the submission receipt. - A tamper-evident timeline with UTC timestamps and actor identity. - A product and version inventory connected to SBOM, release, and support-period records. - A disclosure decision log, customer-notification draft, and redacted evidence bundle. - A rehearsal environment with a synthetic exploited-vulnerability scenario. ## How do you avoid over-reporting and missed reports? Use a two-gate triage. Gate one asks whether the issue affects a product with digital elements in scope. Gate two asks whether reliable information indicates active exploitation or a severe incident. Uncertainty does not justify silence: escalate it against the regulatory clock and document the basis for the decision. - Do not wait for perfect attribution, a public CVE, or a completed root-cause analysis before starting triage. - Do not expose unnecessary vulnerability detail in broadly visible channels. - Test absence coverage: weekends, staff leave, supplier notifications, and compromised monitoring. ## A six-week CRA reporting implementation plan 1. Week 1: map products, manufacturers, importers, distributors, support periods, and accountable people. 2. Week 2: define awareness, severity, active exploitation, decision authority, and legal escalation. 3. Week 3: implement the incident schema, evidence store, access controls, and immutable audit trail. 4. Week 4: connect vulnerability intake, asset inventory, release data, and customer communication. 5. Week 5: rehearse the 24-hour and 72-hour handoffs with a realistic tabletop exercise. 6. Week 6: close gaps, approve the runbook, and schedule quarterly drills through December 2027. ## CRA reporting FAQ ### When do CRA vulnerability-reporting duties start? The Article 14 reporting obligations apply from 11 September 2026. Most other CRA obligations apply from 11 December 2027. ### Does the 24-hour report require a finished root-cause analysis? No. It is an early warning. Preserve known facts, clearly label uncertainty, and enrich the same report at the later checkpoints. ### Where are reports submitted? ENISA operates the CRA Single Reporting Platform. Manufacturers should prepare access, roles, and an internal evidence workflow before the duty starts. ### Is a vulnerability scanner enough? No. Scanners can supply signals, but scope, exploitation, awareness, market impact, remediation, and communication require an accountable cross-functional process. ## Final thoughts Treat the 24-hour deadline as an architecture constraint. A rehearsed evidence pipeline, explicit decision rights, and one durable incident record are more valuable than a last-minute reporting template. ## Primary sources 1. [European Commission CRA reporting page](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting). Official dates and staged reporting overview 2. [ENISA Single Reporting Platform](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp). Official platform scope and readiness information 3. [European Commission CRA guidance announcement](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation). Final guidance published for the September 2026 reporting start ## You may also like.. [**Software maintenance cost benchmark** Budget the engineering capacity needed for security fixes, dependencies, observability, and support.](/blog/software-maintenance-cost-benchmark-dach-saas/) [**Wavect vs development agencies** Compare delivery models before assigning compliance-critical engineering work.](/compare/wavect-vs-dev-agencies/) AI governance and regulation ## Continue through this cluster Security, policy, compliance and operating controls for responsible AI adoption. [Start with the cornerstone**EU AI Act Cost for a 5-Person Startup**](/blog/eu-ai-act-compliance-cost-startup/) - [EU Product Liability for Software: Evidence Checklist](/blog/eu-product-liability-software-evidence-2026/) - [AI Bill of Materials: CycloneDX vs SPDX](/blog/ai-bill-of-materials-cyclonedx-spdx-2026/) - [LLM Pseudonymization Gateways: Does the Prompt Leave GDPR Scope?](/blog/llm-pseudonymization-gateway-gdpr-2026/) - [Semantica Review 2026: Can It Explain Every AI Agent Decision?](/blog/semantica-ai-agent-decision-provenance/) - [AI Agent Contract Signing: eIDAS QES Integration Guide](/blog/ai-agent-eidas-signature-integration/) Inbox, without the noise ## Follow the work that matters to you Get a short email when we publish something new. Follow the whole blog or only the problems you care about. [**Back**](/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/) [Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt 8 min read · 24 Aug 2026 Last reviewed August 24, 2026 [**Next**](/blog/eu-battery-passport-software-architecture-2027/) New posts by email × × Get new posts by email A short email when we publish. Free, no tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/blog/cyber-resilience-act-reporting-playbook-2026/#webpage", "@type": "WebPage", "dateModified": "2026-08-24", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-24", "url": "https://wavect.io/blog/cyber-resilience-act-reporting-playbook-2026/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "CRA vulnerability reporting starts on 11 September 2026. Manufacturers need one durable incident record that supports the 24-hour early warning, 72-hour notification, and final report. Define awareness and decision authority, connect vulnerability intake to product versions and support records, preserve verified facts and uncertainty separately, retain submission receipts, and rehearse the handoffs before the duty applies.", "articleBody": " Blog overview/Business and regulation/AI governance and regulation Cyber Resilience Act Reporting: The 24-Hour Playbook for September 2026 TL;DR CRA vulnerability reporting starts on 11 September 2026. Manufacturers need one durable incident record that supports the 24-hour early warning, 72-hour notification, and final report. Define awareness and decision authority, connect vulnerability intake to product versions and support records, preserve verified facts and uncertainty separately, retain submission receipts, and rehearse the handoffs before the duty applies. From 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in a product with digital elements must start a staged report through ENISA's Single Reporting Platform. The operational sequence is an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report after corrective measures are available. This is an engineering playbook, not legal advice. It focuses on the reporting workflow that product teams must make executable before the first CRA obligations apply, rather than repeating a broad compliance summary. What changes on 11 September 2026? CheckpointRegulatory triggerEngineering action 24 hoursEarly warning after awareness of active exploitationOpen one report, preserve the awareness timestamp, affected markets, and initial severity72 hoursVulnerability notificationAdd technical assessment, exploitation evidence, mitigations, and affected versionsFinal reportNo later than 14 days after a corrective or mitigating measure is availableRecord root cause, remediation, rollout, and user communication Who owns the reporting clock? A single incident commander should own the clock, but the evidence must come from product, security, support, legal, and communications. Awareness is a business event, not merely the moment a CVE receives a number. Define who may declare awareness and record that decision in an append-only incident timeline. Route researcher, customer, CSIRT, bug-bounty, monitoring, and supplier reports into one intake queue.Store product identifiers, versions, countries, exploitation indicators, reporter contact, and first-observed time as structured fields.Keep the same internal incident ID across the 24-hour, 72-hour, and final submissions. What should the reporting architecture contain? Build an evidence pipeline, not a form-filling ritual. The platform adapter should read from an incident record that remains useful when the external form or API changes. Separate verified facts from hypotheses, assign an owner to every unknown, and retain the submission receipt. A tamper-evident timeline with UTC timestamps and actor identity.A product and version inventory connected to SBOM, release, and support-period records.A disclosure decision log, customer-notification draft, and redacted evidence bundle.A rehearsal environment with a synthetic exploited-vulnerability scenario. How do you avoid over-reporting and missed reports? Use a two-gate triage. Gate one asks whether the issue affects a product with digital elements in scope. Gate two asks whether reliable information indicates active exploitation or a severe incident. Uncertainty does not justify silence: escalate it against the regulatory clock and document the basis for the decision. Do not wait for perfect attribution, a public CVE, or a completed root-cause analysis before starting triage.Do not expose unnecessary vulnerability detail in broadly visible channels.Test absence coverage: weekends, staff leave, supplier notifications, and compromised monitoring. A six-week CRA reporting implementation plan Week 1: map products, manufacturers, importers, distributors, support periods, and accountable people.Week 2: define awareness, severity, active exploitation, decision authority, and legal escalation.Week 3: implement the incident schema, evidence store, access controls, and immutable audit trail.Week 4: connect vulnerability intake, asset inventory, release data, and customer communication.Week 5: rehearse the 24-hour and 72-hour handoffs with a realistic tabletop exercise.Week 6: close gaps, approve the runbook, and schedule quarterly drills through December 2027. Useful service paths: Software QA See it in production: Bond Analytics Platform Decide it first: How to choose a software development agency CRA reporting FAQ When do CRA vulnerability-reporting duties start? The Article 14 reporting obligations apply from 11 September 2026. Most other CRA obligations apply from 11 December 2027. Does the 24-hour report require a finished root-cause analysis? No. It is an early warning. Preserve known facts, clearly label uncertainty, and enrich the same report at the later checkpoints. Where are reports submitted? ENISA operates the CRA Single Reporting Platform. Manufacturers should prepare access, roles, and an internal evidence workflow before the duty starts. Is a vulnerability scanner enough? No. Scanners can", "articleSection": "Regulation", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "European Commission CRA reporting page", "url": "https://digital-strategy.ec.europa.eu/en/policies/cra-reporting" }, { "@type": "WebPage", "name": "ENISA Single Reporting Platform", "url": "https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp" }, { "@type": "WebPage", "name": "European Commission CRA guidance announcement", "url": "https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation" } ], "dateModified": "2026-08-24", "datePublished": "2026-08-24", "description": "CRA vulnerability reporting starts on 11 September 2026. Manufacturers need one durable incident record that supports the 24-hour early warning, 72-hour notification, and final report. Define awareness and decision authority, connect vulnerability intake to product versions and support records, preserve verified facts and uncertainty separately, retain submission receipts, and rehearse the handoffs before the duty applies.", "headline": "Cyber Resilience Act Reporting: 24-Hour Playbook", "image": "https://wavect.io/img/blog/headers/header_cyber-resilience-act-reporting-playbook-2026.svg", "inLanguage": "en", "keywords": "Cyber Resilience Act, Vulnerability Reporting, Product Security", "mainEntityOfPage": { "@id": "https://wavect.io/blog/cyber-resilience-act-reporting-playbook-2026/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/blog/cyber-resilience-act-reporting-playbook-2026/", "wordCount": 1006 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/blog/overview/", "name": "Blog overview", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/blog/topics/business-regulation/", "name": "Business and regulation", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/blog/clusters/ai-governance/", "name": "AI governance and regulation", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/blog/cyber-resilience-act-reporting-playbook-2026/", "name": "Cyber Resilience Act Reporting: 24-Hour Playbook | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "The Article 14 reporting obligations apply from 11 September 2026. Most other CRA obligations apply from 11 December 2027." }, "name": "When do CRA vulnerability-reporting duties start?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. It is an early warning. Preserve known facts, clearly label uncertainty, and enrich the same report at the later checkpoints." }, "name": "Does the 24-hour report require a finished root-cause analysis?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "ENISA operates the CRA Single Reporting Platform. Manufacturers should prepare access, roles, and an internal evidence workflow before the duty starts." }, "name": "Where are reports submitted?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. Scanners can supply signals, but scope, exploitation, awareness, market impact, remediation, and communication require an accountable cross-functional process." }, "name": "Is a vulnerability scanner enough?" } ] } ```