All Compliance and ISO 27001 Coding Mammoth Semonto MijnLijn

The CRA Reporting Clock Starts on 11 September. Have You Rehearsed Your First 24 Hours?

From 11 September 2026, in-scope manufacturers must report certain security problems as soon as possible and no later than 24 hours after becoming aware of them.

Woolly mammoth rehearsing the CRA reporting timeline with 24-hour, 72-hour, and final-report checklists

Jelle De Laender
9 September 2026

From Friday, 11 September 2026, the Cyber Resilience Act's reporting obligations apply.

You must report as soon as possible and no later than 24 hours after becoming aware of a reportable vulnerability or incident. You cannot wait until the investigation is complete or the problem is solved.

This deadline applies when an in-scope manufacturer becomes aware of an actively exploited vulnerability or a severe incident affecting the security of its product. At that point, some facts will still be unknown. Report what you know, continue the investigation, and add more detail in the next report.

Most other CRA requirements start on 11 December 2027. This includes requirements such as a software bill of materials (SBOM), a coordinated vulnerability disclosure (CVD) policy, and a single point of contact for vulnerability reports. The Article 14 reporting duties start earlier, on 11 September 2026.

A CVD policy and a working security contact are still useful today. They often provide the first warning that something is wrong, so include them in your preparation if you already have them.

ENISA's Single Reporting Platform FAQ says the platform will become operational on 11 September. The European Commission also updated its CRA implementation FAQ on 4 September 2026. These updates provide enough practical detail to test your process now.

Note: This article provides general operational information, not legal advice. CRA applicability depends on the product, how it is made available, your economic role, and the facts of the event.

The essentials

Article 14 reporting applies from 11 September 2026.
It applies to manufacturers of products with digital elements that fall within the CRA's scope.
The two triggers are an actively exploited vulnerability and a severe security incident.
Send an early warning as soon as possible and no later than 24 hours after becoming aware.
Send a fuller notification within 72 hours of becoming aware.
The final-report deadline depends on whether you are reporting a vulnerability or an incident.
ISO 27001 can support the process, but certification does not prove CRA compliance.

First check whether the CRA applies

Before opening the reporting form, check the product and your role.

Ask four questions:

Is this a product with digital elements? This can include software, connected hardware, components, and some remote data processing.
Is it made available on the EU market? Record the legal entity, route to market, and countries where it is offered.
Does it connect directly or indirectly to a device or network? Software or hardware is not automatically in scope merely because it contains digital elements.
Are we the manufacturer? Manufacturers, importers, distributors, authorised representatives, and open-source software stewards have different roles. The Article 14 duties discussed here apply to manufacturers.

Specific exclusions and sector rules can change the answer. Record who made the scope decision, why, and when it must be reviewed again.

What about SaaS?

A pure standalone SaaS service is generally not itself a product with digital elements. Downloadable software can be in scope when it is offered on the EU market and meets the CRA's connection test. Examples include a native app, desktop agent, browser extension, CLI, SDK, or self-hosted build.

A cloud backend can also be in scope as remote data processing when a product depends on it to perform a function. Connected hardware can be in scope too. Hardware without a relevant connection may not be.

"We are SaaS" is not a scope conclusion. Document what you offer, who offers it, how it reaches the EU market, and whether it is a standalone service or part of an in-scope product.

Older products may also need to be reported

Products placed on the market before 11 December 2027 are not automatically excluded from reporting. If such a product is within scope, its manufacturer can still have an Article 14 reporting duty.

Your inventory may therefore need to include older releases and supported product generations. The duty applies when you become aware of a reportable vulnerability or incident on or after 11 September 2026, even if the vulnerability or product is older.

Not every security problem must be reported

Article 14 has two mandatory reporting triggers:

Actively exploited vulnerability: there is reliable evidence that someone maliciously exploited the vulnerability without the system owner's permission.
Severe security incident: the incident harms, or could harm, the product's ability to protect sensitive or important data or functions. It also qualifies if malicious code was, or could be, introduced or executed in the product or a user's systems.

A newly discovered vulnerability is not automatically reportable. A vulnerability found by an ethical hacker or test laboratory is not an actively exploited vulnerability unless there is reliable evidence of malicious exploitation. An internal label such as "high priority" does not by itself make an incident severe under the CRA.

Record why you decided that an event was or was not reportable. ENISA says voluntary reporting will not be available when the platform launches.

The three reporting stages

You are not expected to know everything within 24 hours. The first report is an early warning. You add more information within 72 hours and complete the record in the final report.

CRA Article 14 reporting timeline

Stage and deadline	What to provide
Early warning As soon as possible and no later than 24 hours after awareness	Identify the manufacturer, affected product and event type. Record when you became aware and add the EU countries where the product has been made available, if known. For a severe incident, say whether unlawful or malicious acts are suspected.
Notification As soon as possible and no later than 72 hours after awareness	Add your initial assessment, available impact information, mitigations and actions users can take. State how sensitive you consider the reported information to be. Correct or expand the early warning.
Final report: actively exploited vulnerability Within 14 days after a corrective or mitigating measure becomes available	Describe the vulnerability, its severity and impact, any known malicious actor, and the available corrective or mitigating measure.
Final report: severe incident Within one month after the 72-hour notification	Describe the severity and impact, the threat or likely root cause, and the measures taken or still in progress.

Record the exact time when you became aware, what was known at that moment, who assessed it, and what they decided. That recorded timestamp must drive your deadline, not the platform counter.

ENISA warns that the platform's 72-hour counter may show a deadline 48 hours after the early warning was submitted, rather than 72 hours after awareness. It may therefore show "overdue" before the legal deadline. Treat platform counters as reminders and calculate your own deadlines from the recorded awareness time.

Run a 24-hour rehearsal

Choose a realistic incident, start a timer, and make the team prepare a mock early warning using the information it can actually access.

1. Choose a scenario

Use a product that may be in scope. Simulate malicious exploitation or a potentially severe incident. Include an uncertain fact, a third-party component, and an unavailable decision-maker.

2. Record the awareness time

Start one decision log immediately. Record the awareness time, available evidence, assumptions, decisions, owners, approvals, communications, and reporting actions. Do not overwrite earlier information when the facts change.

3. Activate the owners

Name at least:

an incident commander;
a product owner who can identify affected products and versions;
a security lead who assesses exploitation, severity, impact, and mitigations;
a CRA decision owner who confirms scope and the reporting decision;
a Primary Assigned Representative who can submit the report;
a backup Assigned Representative;
a communications owner for affected-user information.

The communications owner should decide which affected users need to be told about the problem and the steps they can take. In some cases, all users may need to be informed. Rehearse this in parallel with the platform reporting, not after it.

4. Check access to the reporting platform

Assigned Representatives use personal EU Login accounts with multi-factor authentication. One Primary Assigned Representative can invite up to 20 Secondary Assigned Representatives. ENISA advises people to create their EU Login accounts in advance, but to register the manufacturer only when a notification is needed.

Name the representatives, test their EU Login and MFA, and document who may approve a submission. Do not use a shared account. At launch, there is no API, so a person must submit through the CRA Single Reporting Platform.

5. Identify the correct coordinating CSIRT

The coordinating CSIRT will usually be in the EU country where the manufacturer makes its main product-cybersecurity decisions. Other rules apply when that location cannot be identified or when the manufacturer has no main EU establishment.

Decide this before an incident. ENISA warns that selecting the wrong coordinator can invalidate a notification and require a new submission. Record your reasoning and check ENISA's current list of coordinating CSIRTs.

6. Prepare a mock early warning

Use ENISA's SRP glossary as a checklist. Confirm that your team can find:

the manufacturer and reporting owner;
the affected product, version, component, and support status;
the awareness time and source;
the event type and evidence behind that classification;
the EU countries where the product is available, when known;
CVE and EUVD identifiers, when available;
current information about severity, impact, exploitation, and threats;
mitigations and actions users can take;
unknowns, assumptions, approvals, and follow-up deadlines.

Some information will be unknown during the first 24 hours. That is acceptable. The team must be able to state what it knows, what it does not know, and what it will investigate next.

7. Plan the next reports

Before ending the exercise, assign an owner and deadline for the 72-hour notification. Also record the correct final-report deadline. For a vulnerability, it runs from the availability of a corrective or mitigating measure. For a severe incident, it runs from the 72-hour notification.

If the platform is unavailable

ENISA says to submit when the platform becomes available again. If immediate communication is necessary, the manufacturer may contact its designated CSIRT directly. That contact does not replace the platform submission.

Your runbook should explain how to record an outage, who decides whether to contact the CSIRT, and who submits through the platform when it returns.

How ISO 27001 helps

A mature ISO 27001 ISMS already gives you useful building blocks: clear roles, incident response, evidence collection, legal-requirement tracking, corrective action, and lessons learned.

Extend your existing incident process with the CRA scope decision, reporting trigger, awareness time, platform fields, Assigned Representatives, coordinating CSIRT, user communications, and deadlines. Avoid creating a separate process that the team has never used.

ISO 27001 supports CRA readiness. It does not prove CRA compliance.

Your ISMS does not decide whether a product is in scope, interpret Article 14, select the right authority, or guarantee a legally complete report.

This is the same management-system advantage discussed in The AI Act Doesn't Replace ISO 27001. Existing governance gives you a head start, not a legal shortcut.

Your preparation checklist

List products that may be in scope, including supported older products.
Document your role and scope decision. Seek qualified legal advice for uncertain cases.
Name a Primary and backup Assigned Representative and test their EU Login accounts and MFA.
Identify the correct coordinating CSIRT and record why it is correct.
Map your incident record to the current SRP fields.
Run one timed scenario from awareness to a mock early warning.
Fix missing access, evidence, ownership, and approval routes.

The goal is simple: spend the first 24 hours assessing and responding, not searching for product records, reporting access, owners, or evidence.

Need help turning governance into an operating runbook?

At Coding Mammoth, we help SaaS and software companies build practical ISO 27001 governance, incident-response processes, and evidence trails that work under pressure. If the CRA exposes a gap in ownership or incident readiness, we can help strengthen the operational process while you obtain legal advice for product-specific CRA decisions.