EU Cyber Resilience Act: The 24-Hour Communications Plan

What changes on 11 September 2026?

From 11 September 2026, manufacturers within scope of the EU Cyber Resilience Act must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements on a defined timetable. The clock is connected to when the manufacturer becomes aware of the event, so a company needs one defensible awareness record before security, legal, product and communications teams begin writing separate versions of the story.

The European Commission’s CRA reporting obligations overview sets out an early warning within 24 hours and a fuller notification within 72 hours. For an actively exploited vulnerability, a final report is due no later than 14 days after a corrective or mitigating measure becomes available; for a severe incident, the final report is due no later than one month after the 72-hour notification.

This does not require every regulatory detail to be copied into a press statement. A secure filing for the relevant Computer Security Incident Response Team and ENISA, an actionable customer notice, a partner briefing and a media response have different audiences and disclosure risks. They should draw from the same verified fact ledger, but they should not share the same access level or publication trigger.

The first communications decision is therefore not whether to draft a release. It is who can start the event record, who decides whether the Article 14 threshold may be met, and who owns each subsequent deadline. The discipline described in FL PR’s guide to building shared objectives across PR and search work has a useful operational parallel here: one agreed source of truth prevents teams from reporting incompatible versions of an event.

Which events can start the 24-hour clock?

The 24-hour path is intended for reliable evidence of an actively exploited vulnerability in an in-scope product or a severe incident affecting that product’s security. A routine bug, an unverified social post, a theoretical weakness with no reliable evidence of exploitation or a service complaint with no security impact does not automatically meet the same threshold.

The official text of Regulation (EU) 2024/2847 defines the relevant roles and provides the legal framework in Articles 14 to 17. A manufacturer still needs qualified legal and security advice to determine whether a particular product is in scope, whether the evidence supports active exploitation or severe impact, and which Member State and CSIRT relationships apply.

An initial assessment should record six fields before anyone offers public reassurance:

• Product identity: the affected device, software, remote processing component, version and support period.
• Awareness time: the exact date, time, time zone and source of the reliable evidence.
• Event class: suspected active exploitation, severe security incident, another vulnerability or a non-security outage.
• Verified impact: what is known about availability, authenticity, integrity or confidentiality.
• Market link: where the affected product has been made available and which entity acts as manufacturer.
• Decision owner: who can confirm the reporting route and who can approve a customer action.

A weakness originating in a third-party component should not be dismissed as the supplier’s communications problem. ENISA’s current Single Reporting Platform frequently asked questions treats third-party components as a distinct reporting issue and points organisations to the Commission’s implementation material for interpretation. The manufacturer should assess the impact in its own product while avoiding blame before the dependency and evidence have been confirmed.

Uncertainty can be recorded without turning it into a conclusion. “The team is assessing whether exploitation has occurred” accurately describes an open question; “customers are safe” is a much stronger claim that needs evidence across affected versions and environments. FL PR’s discussion of verifiable authority across public information is relevant to the communications discipline: repetition cannot repair a claim that was not supported when it was issued.

How should the 24-hour, 72-hour and final records differ?

The 24-hour submission is an early warning, the 72-hour submission is a structured notification, and the final report is the corrective and learning record. They are not three lengths of the same statement; each version should preserve what was known at that point and show why facts or decisions changed.

During the first 24 hours, the manufacturer may not yet know the complete root cause or every affected release. The record should nevertheless establish the product connection, awareness time, known market reach and available evidence without avoidable delay. ENISA’s CRA Single Reporting Platform resource centre brings together current user guidance, the field glossary and instructions for Assigned Representatives.

The 72-hour file should provide a clearer description of the product, the general nature of the exploitation or incident, the known severity and impact, mitigation already taken and steps users can take. The final record should document the corrective measure and resolution, with root-cause analysis where available. Every revision needs an owner, timestamp, supporting artefact and clear distinction between verified fact, working assessment and unresolved question.

A practical internal timetable can use four checkpoints:

• 0–2 hours: create the event record, preserve the first reliable evidence and assign the security and legal decision owners.
• 2–12 hours: test Assigned Representative access, confirm the EU Login account and identify the coordinating CSIRT route.
• 12–24 hours: complete the early-warning fields, classify sensitive material and save evidence of submission.
• 24–72 hours: update impact, mitigation, user action and public-message decisions as the investigation matures.

As accessed on 7 September 2026, ENISA states that the first release of the platform will not provide an API for notification submission. A manufacturer can automate internal evidence collection, reminders and review controls, but it should not assume that the final regulatory filing will leave its own incident system automatically. A rehearsal must test the real representative account and interface, not merely a completed spreadsheet.

How should regulatory and public communications be separated?

A regulatory notification should contain the security information required by the framework, while a public update should contain the verified information a customer, partner or journalist needs to make a safe decision. Combining both into one document can expose sensitive exploitation details or leave the formal notification too vague to serve its purpose.

The restricted file may contain version identifiers, evidence of exploitation, technical impact, mitigation work, geographic availability and, where relevant, CVE or EUVD information. The public notice should prioritise the affected product, the user action, an available fix or workaround, the support channel and the next update time. An unresolved exploit path, security-control detail or information that could increase risk should not be published simply because it appears in the regulator file.

Public communication is not triggered only by press interest. If a customer must install an update, disconnect a product, change a credential or stop using a particular version to reduce risk, an accessible notice may be necessary before a complete forensic account exists. If the company decides not to communicate publicly, it should still record the decision time, evidence, responsible person and condition that would trigger a review.

The customer-facing message can use five stable blocks:

• What has been confirmed, and which product or version is affected?
• What safe action should the user take now?
• What correction or mitigation has the manufacturer made available?
• What remains under investigation, and what detail cannot yet be released?
• When and where will the next verified update appear?

A Türkiye-based company should not send a literal translation of one domestic statement to distributors, enterprise buyers and consumers across Europe. Product facts must remain stable, but legal terminology, support routes, time zones, accessibility needs and stakeholder questions vary by market. FL PR’s work on coordinating international PR with durable search information supports a useful principle: localise the decision support, not the underlying fact.

What should a manufacturer have ready before the deadline?

Before 11 September 2026, a manufacturer should have a scope map, working representative access, one event ledger, separate regulatory and public templates, and a rehearsed approval chain. A policy document alone is not readiness; the people, credentials and escalation paths must work during an out-of-hours scenario.

Start with an inventory of products with digital elements made available in the EU, active versions, support periods and material third-party components. For each product family, name the product-security owner, legal contact, proposed Primary and Secondary Assigned Representatives, customer-support lead and authorised spokesperson. Record substitutes and access methods as well as the primary names.

A readiness review should expect nine concrete outputs:

• A current scope decision for each product family and entity role.
• An awareness-time field that preserves date, time zone, evidence source and editor.
• Separate initial assessment questions for active exploitation and severe incidents.
• Tested EU Login and SRP access for the appropriate Assigned Representatives.
• Named owners and deputies for the 24-hour, 72-hour and final submissions.
• Restricted storage and change history for confidential regulatory evidence.
• Modular notices for customers, partners, support staff and media teams.
• Stable URLs for security advisories, updates and product-support information.
• An archive that links submission receipts, public versions and the post-event review.

The final test should begin outside normal office hours and use an invented but plausible product event. A workable team can identify the owner and awareness time within two hours, confirm representative access within 12 hours, review an early-warning draft before the first deadline and prepare a separate customer action without copying restricted details. Any failed access or unresolved approval becomes a remediation item rather than a reason to declare the exercise successful.

Security advisories and corrective notices can later become the institutional record used by customers, search engines and answer systems. FL PR’s analysis of how search supports durable PR information is useful here as an information-governance practice, not a visibility promise. Old notices should point to the current remedy, material changes should be dated, and the canonical update should remain easier to find than copied or outdated versions.

This guide is not legal advice for a particular manufacturer or product. Scope, reporting thresholds, the responsible CSIRT, data-protection duties and the timing of public disclosure should be checked against current EU and national rules with qualified advisers. Communications owns the clarity and traceability of the message; it does not replace the security or legal determination behind it.

Frequently Asked Questions

These answers summarise the main timing and communications decisions in the CRA product-security reporting workflow.