The EU Cyber Resilience Act’s reporting duties started on 11 September 2026. Thirty days later, manufacturers of covered digital products on the EU market need a working response process. Most of the CRA’s broader product requirements apply from 11 December 2027, but Article 14 reporting is already in force. European Commission
An advisory may name a library your customers have never heard of. Your engineering team knows it by a package name. Your support team knows the product by its model number. Someone has to connect those records to the versions that shipped, assess whether the reporting trigger is met, and get an authorized person into ENISA’s Single Reporting Platform.
That work is easier when the records already exist. A software bill of materials, release history, and maintained product inventory give the response team a starting point. A contact list tells them who can decide and who can file.
The early warning begins a reporting process. Further investigation follows. Waiting for a complete fleet inventory can put the first deadline at risk.
Start with what shipped
For a device manufacturer, the useful chain runs from component to build to product version, then to the markets and devices that may be affected.
A software bill of materials (SBOM) helps identify builds containing a named component. It needs to be tied to a release, not left as an unattached scan result. Release records connect that build to product models and versions. Distribution and device records help establish where the product was made available and where an update needs to go.
These records answer different questions. Article 14’s early warning asks, where applicable, for the Member States in which the manufacturer knows the product has been made available. That is market availability. Exact installed-device location and fleet counts can help the investigation and response, but they are not prerequisites for filing. Sales and distributor records may be useful evidence. ENISA’s current glossary also calls for product names and versions at the early-warning stage. CRA Article 14(2)(a), page 38, ENISA SRP Glossary
Keep the distinction clear: identify affected releases as quickly as possible, report the information available, and continue refining the scope. Device inventory then helps target remediation and check its progress.
Two triggers, different final-report clocks
Article 14 covers two events: an actively exploited vulnerability contained in your product, or a severe incident affecting its security.
“Actively exploited” requires reliable evidence of exploitation by a malicious actor without the system owner’s permission. A high CVSS score or a public proof of concept alone does not establish that trigger. They help prioritize investigation. CRA Article 3(42), page 31
Article 14(5)(a) treats an incident as severe when it harms, or could harm, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. Its wording includes:
“it negatively affects or is capable of negatively affecting the ability of a product … to protect … sensitive or important data or functions”
CRA Article 14(5)(a), page 39 · Saved source page
Article 14(5)(b) provides a separate test: an incident is severe if it has led, or could lead, to the introduction or execution of malicious code in the product or a user’s network and information systems. The first test does not require malicious conduct. CRA Article 14(5)(b), page 39
The Commission’s published July 2026 draft guidance interprets awareness through an immediate initial assessment that establishes a reasonable degree of certainty that a qualifying event occurred. Start the assessment promptly and report as the facts develop; a complete investigation is not a prerequisite. Commission draft guidance, section 9.1, paragraphs 213–215, printed pages 74–75
Both reporting tracks require an early warning without undue delay and within 24 hours of awareness, followed by a fuller notification without undue delay and within 72 hours. Their final-report deadlines start from different events, as the graphic shows: availability of a corrective or mitigating measure for a vulnerability, and submission of the 72-hour notification for a severe incident.
These are maximum deadlines. For a vulnerability, an effective workaround may start the final-report clock before a firmware patch is released. Creating an internal release package or completing deployment across a fleet is a separate event. Record when the relevant measure actually became available. CRA Article 14, pages 38–40
Three scope points belong in the response procedure:
- Older products can still be reportable. Article 14 can cover in-scope products placed on the market before the broader requirements apply, including products beyond their support period. Continued reporting does not itself impose a new obligation to resume support or reconstruct an SBOM for every legacy build.
- Earlier awareness matters. There is no retrospective filing requirement for active exploitation the manufacturer already knew about before 11 September. Learning of exploitation after that date can trigger reporting even if the vulnerability was known earlier.
- An integrated component needs a product-specific assessment. Paragraph 218 of the Commission’s published July 2026 draft guidance says reporting is not mandatory if the flaw cannot be exploited in your product or has not been exploited in it. The guidance is nonbinding. Preserve the evidence behind that assessment and escalate uncertainty promptly.
Commission draft guidance, paragraphs 210, 217 and 218
Your users have a separate communication need. Article 14(8) requires manufacturers to inform impacted users, and where appropriate all users, in a timely manner, including relevant corrective or mitigating measures where necessary. Filing with authorities does not complete that task. CRA Article 14(8), page 40
The readiness gap is uneven
The public research points to preparation gaps, but it does not establish a single market-wide compliance rate.
UpGuard examined 2,374 phone and tablet models from 276 manufacturers in the EU’s EPREL database, using data collected in August 2026. Only 14% of those manufacturers had a publicly discoverable baseline vulnerability-reporting route, covering 23% of the models examined. Yet vendors with such routes represented an estimated 94% of phone market share and 86% of tablet market share.
The gap was concentrated among smaller vendors. The study measured public discoverability, not a demonstrated ability to assess exploitation or file within 24 hours. A findable security contact is useful evidence of preparation; it cannot establish full CRA compliance. UpGuard’s original study
ENISA’s SME survey found SBOM use among 35% of its 194 respondents. Its voluntary, self-selected sample was explicitly not representative of the wider EU SME population. The finding is still useful: many respondents lacked a tool that helps connect an external component warning to shipped software. ENISA SME CRA Survey Report
For readers outside Europe, Linux Foundation Research found that 72% of its US and Canadian respondents were unfamiliar with the CRA. That describes the respondents, not all North American manufacturers. Businesses that manufacture, or have products manufactured, and market them under their own name or trademark need to assess the manufacturer obligations when serving the EU market. Selling through a distributor does not by itself remove that role. Linux Foundation report, CRA Article 3(13), page 29
The chart brings those measures together while preserving their different populations. The manufacturer-count and market-share figures are both needed to understand the reporting-route gap.
Who actually files
Mandatory notifications go through ENISA’s Single Reporting Platform. You submit through one platform to the designated coordinating CSIRT and, generally, ENISA. The coordinator handles onward dissemination. Exceptional restrictions on sharing do not extend your filing deadline. European Commission reporting guidance
Confirm the coordinator before an incident. For an EU establishment, Article 14(7) focuses first on where product cybersecurity decisions are predominantly taken, with employee count as a fallback. Manufacturers without an EU main establishment follow a sequence involving their authorised representative, importer, distributor, and ultimately users. Check the applicable step rather than choosing a convenient country. CRA Article 14(7), pages 39–40
Access is personal. Each reporter needs an EU Login account with multi-factor authentication. ENISA advises registering on the SRP when a notification is needed; the accounts and authentication can be prepared beforehand. The platform’s “Assigned Representative” role is distinct from the CRA’s legally defined “authorised representative.” ENISA registration guidance
The current FAQ allows one Primary Assigned Representative and up to 20 Secondary representatives. A verified Primary must invite the backups. Pending verification does not prevent filing; an unverified association permits up to 20 notifications for that manufacturer. Name backups now and document how they will obtain access. ENISA FAQ, question 9
In a post published on 23 September, Aikido Security’s Jens Gellynck said Belgium’s CSIRT took three business days to verify his Assigned Representative association. He also recommended backup authentication devices. This is one company’s onboarding experience. ENISA allows notifications while verification is pending, so manufacturers can file before that process is complete. Aikido’s firsthand account, ENISA FAQ
Plan for a human to submit through the interface: the initial SRP release has no API. Internal automation can gather evidence and prepare the content. It still needs a named person with access and authority to file. ENISA FAQ, question 15
Where product solutions can help
Full disclosure: I work at DigiCert. Software Trust Manager and Device Trust Manager can help with four practical needs in a product-security response.
When you need to identify affected builds
An advisory names a component. Your team needs to determine which product versions contain it. Software Trust Manager’s scan findings and SBOMs help identify components and reported vulnerabilities in a build. Keeping those records tied to releases gives the response team evidence it can use to scope the investigation. Software composition analysis, SBOM project and release records
When you need to check and sign the update
Once engineering has prepared a fix, Software Trust Manager can support rescanning and code signing before distribution. Scan results can feed configured release checks that block a build when chosen risk thresholds are exceeded. This gives your team a way to apply its release policy and sign the update it intends to distribute. Risk-policy settings, Software Trust Manager overview
When you need to reach affected devices
Device Trust Manager can deploy updates to selected groups of managed devices, with installation and rollback handling. Your release, distribution, and device records connect an affected build to the products, markets, and device groups that need attention. Devices need a configured management and update path for that deployment to work. Device Trust Manager overview, deployment management
When you need to verify update progress
Device Trust Manager reports per-device deployment outcomes, helping the team follow up on failed or pending updates. Reconcile those outcomes with current inventory or on-device checks to verify which versions are running and which devices still need attention. DTM deployment and verification workflow
The manufacturer’s response team retains responsibility for assessing exploitation, making the reporting decision, informing users, and submitting the SRP notifications. These product capabilities support the evidence gathering and remediation work around that decision.
Run the test before the next advisory
I would start with six concrete tasks:
- Assign the technical assessment, reporting decision, filing, and user-communication owners, including out-of-hours cover.
- Prepare personal EU Login accounts, MFA and recovery devices; document Primary and Secondary AR access.
- Confirm the coordinating CSIRT and current reporting fields, then prepare stage templates and an independent deadline record.
- Test the monitored security contact from outside the company. Agree how incoming reports reach the response team.
- Connect SBOMs and release records to product versions and market records. Reconcile device inventory where it is used to target updates.
- Exercise the update and user-notification process, including deployment failures and devices that cannot be reached.
Then run a timed tabletop. A credible exploitation signal arrives at 16:00 on Friday. The response team assesses it promptly. At 17:00, the team establishes reasonable certainty that a reportable event has occurred. The early warning is due without undue delay and no later than 17:00 Saturday.
Can the team identify the affected product versions, state the EU markets it knows are involved, reach an authorized reporter, and file? Can it preserve what it knew, when it knew it, and why it made the reporting decision?
Use the exercise to find missing records and access gaps. Fix those before the next advisory arrives.
Operational reference
These details belong in the runbook. Platform guidance is current as of 11 October 2026 and should be checked before use. The cited Commission guidance text is the July 2026 draft, whose content was approved on 27 July. The accompanying communication reserved formal adoption for later. Commission communication, page 2
- Drafts and handoffs: drafts are private to their author. Associated ARs can continue submitted notifications subject to permissions; closure or final reporting locks the notification. Test the handoff. ENISA AR manual v1.1
- Deadline display: ENISA warns that the current 72-hour counter uses early-warning submission plus 48 hours. Calculate the legal deadline from awareness independently. ENISA FAQ, question 26
- Platform outage: follow ENISA and the designated CSIRT’s current procedure, then submit through the restored SRP. Ireland’s NCSC describes an email fallback during an ENISA-declared outage and requires later SRP submission; email while the platform is operating does not satisfy that procedure. Ireland NCSC, ENISA FAQ, question 25
- Exceptional sharing: particularly exceptional circumstances can limit ENISA’s initial access to full details at the 72-hour vulnerability stage. Coordinator-delayed onward dissemination is a separate mechanism. Neither postpones filing. ENISA PEC guidance
- Penalties and application dates: Article 64 includes Article 14 in the eventual maximum bracket of €15 million or 2.5% of preceding-year worldwide turnover, whichever is higher. The CRA’s general enforcement and penalty provisions apply from 11 December 2027. Micro and small manufacturers have a specific exemption from fines for missing the 24-hour deadline. Any earlier national sanction requires its own legal basis. CRA Article 64, pages 64–65, Article 71(2), page 67, Commission FAQ
- Later functionality: Article 15 voluntary reporting awaits a future SRP phase. Open-source steward reporting under Article 24(3) applies from 11 December 2027. ENISA FAQ, questions 27 and 29