CRA update, August 2026: Commission guidance lands, ENISA SRP prep, six weeks to reporting

Two substantial things landed in the last week of July: the European Commission’s first official guidance on applying the CRA, and ENISA’s preparation pack for the Single Reporting Platform. With the 11 September 2026 reporting deadline now roughly six weeks away, both matter more than the usual monthly drip.

Here is what changed, and the parts that should alter what you do this month.

1. The Commission published its first official CRA guidance (27 July 2026)

On 27 July the Commission published practical guidance on applying the CRA, issued as Communication C(2026) 5252 with a detailed annex. It runs to roughly 80 pages and is built around 67 worked examples, with specific attention to microenterprises and SMEs.

It is issued under Article 26 and is non-binding. That word does less work than it looks like it does: market surveillance authorities across all 27 member states will take their interpretive cue from this document, so in practice it is the closest thing to an answer key you are going to get before enforcement starts.

Four areas where it genuinely clarifies things:

Scope: two useful exclusions

The guidance covers standalone software, hardware with embedded software, standalone hardware (integrated circuits, motherboards), and components supplied separately but intended to operate together.

Two exclusions are worth knowing:

• Software that executes remotely and is merely accessed by the user is not a product with digital elements on that basis alone.
• Websites are not products with digital elements. They are only caught where they support the functionality of a product with digital elements, which is to say where they qualify as remote data processing.

Commercially licensed source code is in scope. Code in a public repository without commercial intent generally is not.

Open source: a sharper commercial-activity test

Free and open-source software triggers obligations only where it is supplied in the course of commercial activity. The guidance frames that as charging a price, monetising through a platform, or requiring personal data processing for reasons other than exclusively improving the security, compatibility or interoperability of the software.

Voluntary donations do not cross the line, unless they become a de facto condition for accessing the software or its updates.

The part that creates new work: manufacturers who integrate FOSS into their products must exercise due diligence, report vulnerabilities upstream, and share security fixes. That is an active obligation, not a passive one, and plenty of compliance programmes do not currently account for it. Our open source and the CRA explainer covers the underlying roles.

Substantial modification: the test is now written down

Article 3(30) has been the source of endless argument. The guidance articulates the test: a modification is substantial where it affects compliance with the essential requirements, or shifts the intended purpose beyond the original risk assessment.

For software specifically, the questions are whether an update introduces new threat vectors, enables new attack scenarios, materially alters the risk profile, or changes the potential impact of previously identified attack scenarios. Routine repairs and identical spare parts typically do not trigger it.

The useful clarification: a security update that does not change intended purpose and does not introduce new risks is not a substantial modification, even where it involves significant technical change. That should settle a lot of internal debates. If you are relying on the pre-2027 grandfathering carve-out, this test is what ends it, and we covered the mechanics in are pre-2027 products grandfathered.

Support period: five years is a floor, not a default

A lot of teams have read the five-year support period as the answer. The guidance is explicit that it is a minimum. Products expected to remain in use longer must have correspondingly longer support periods, determined by reasonable user expectations and the nature of the product.

For iteratively released software, a manufacturer may stop remediating earlier versions once users can upgrade free of charge without additional costs. “Additional costs” is defined as burdens beyond what is normal for software updates: mandatory new hardware purchases, infrastructure replacement, or fundamental changes to the operating environment.

2. ENISA’s Single Reporting Platform: still not live, but the documentation arrived

The platform remains pre-operational and is scheduled to be operational by 11 September 2026, the date the reporting obligations begin. The public access URL has not been published yet.

What did arrive, on 31 July, is the preparation pack: an SRP factsheet, two user guidance documents covering registration and notification submission, and an expanded FAQ. A webinar is planned roughly two weeks before go-live.

Four operational details in there change how you should prepare.

EU Login is the prerequisite, and you can do it today

Manufacturers and authorised representatives must register using an EU Login account, which can be created in advance at ecas.ec.europa.eu. This is the single most actionable thing available before the deadline, and it costs you nothing to do now.

There will be no API at launch

ENISA has confirmed that no application programming interfaces will be provided at this stage. Reporting is manual web-portal submission only.

If your incident-response plan assumed you could pipe notifications out of your existing tooling, that plan needs rewriting. The 24-hour clock will be met by a human filling in a web form, which has real implications for out-of-hours rotas and who holds the credentials. We went into what that changes operationally in no API at launch.

CSIRT validation does not block your first submission

Validation that a representative may report on behalf of a manufacturer happens after first access, in parallel with the reporting process, and does not affect your ability to submit.

ENISA’s own advice runs against the usual instinct: register and initiate validation when you actually need to submit a notification, rather than everyone piling in early and overwhelming CSIRT workloads. Worth noting if your instinct was to get everyone registered in August.

The data-field template is published

ENISA has set out which fields are obligatory, optional and conditional at each of the 24-hour, 72-hour and final stages.

One nuance that is easy to overstate, so to be precise: Product Type and Product Category are optional at the 24-hour stage and conditional by the 72-hour and final stages. So classification is not a hard blocker on your first emergency notification. But you will need it settled within 72 hours of a report, under pressure, which in practice means settling it now rather than treating it as a December 2027 exercise.

If you have not classified your products yet, our free compliance check walks through it in a couple of minutes.

Also worth knowing: voluntary reporting functionality only switches on after 11 September, the list of national CSIRT coordinators is still unpublished, and the notification template carries an EUVD ID field alongside CVE ID.

3. Two pieces of secondary legislation worth citing

These were adopted late in 2025 and get less attention than they deserve.

Commission Implementing Regulation (EU) 2025/2392 was adopted 28 November 2025, published 1 December 2025, and entered into force 21 December 2025. It establishes the technical descriptions for the important and critical product categories in Annexes III and IV, covering everything from identity-management systems and embedded browsers to secure elements and virtual network adapters.

It also codifies a point that resolves a lot of classification anxiety: integrating a component that would itself fall into an important or critical category does not automatically push the containing product into the higher conformity assessment route. What matters is whether the product as a whole meets the description.

Commission Delegated Regulation (EU) 2026/881 was adopted 11 December 2025. It sets out when a receiving CSIRT may delay or withhold dissemination of a notification on security grounds, including where a mitigation such as a security update will be available within 72 hours, or where there are doubts about a receiving CSIRT’s ability to maintain confidentiality.

The practical consequence: where you mark one of those conditions in a 72-hour notification, ENISA receives only partial information until the CSIRT releases the full notification.

4. Harmonised standards: still nothing in the Official Journal

Standardisation request M/606 covering 41 standards was accepted by CEN, CENELEC and ETSI in 2025, and drafting continues. The core horizontal standards are expected around 30 August 2026, with product-specific standards following near 30 October 2026 and the remainder into 2027.

Until a standard is actually cited in the Official Journal, the Article 27 presumption of conformity is not available for any product category. This matters if your plan was “Module A with full application of harmonised standards” for a Class I product: that route does not exist yet in practice, which pushes more products toward notified bodies, of which none have been designated. We covered that bottleneck in the July update.

What to do this month

• Create your EU Login account now. It is free, it takes minutes, and it is a hard prerequisite for reporting on 11 September.
• Rewrite your reporting runbook for manual submission. No API means a named human, with credentials, available inside 24 hours, including weekends.
• Settle your product classification. You need it by the 72-hour stage of any notification, and Implementing Regulation 2025/2392 now gives you the technical descriptions to do it properly.
• Read C(2026) 5252 against your own assumptions, particularly on support periods and substantial modification. If you assumed five years was the answer, check whether your product’s expected lifetime says otherwise.
• If you integrate FOSS, add upstream vulnerability reporting and fix-sharing to your process. That is a new active obligation for most teams.

Sources

• European Commission: Commission publishes new guidance to support timely Cyber Resilience Act implementation (27 July 2026)
• ENISA: Single Reporting Platform (SRP), FAQ and user guidance updated 31 July 2026
• European Commission: CRA reporting obligations
• European Commission: CRA implementation
• EUR-Lex: Commission Implementing Regulation (EU) 2025/2392
• EUR-Lex: Commission Delegated Regulation (EU) 2026/881
• EU Login account creation
• Hunton: European Commission issues guidance on the Cyber Resilience Act
• Jones Day: EU Cyber Resilience Act, 24-hour reporting duties start 11 September 2026
• Lewis Silkin: EU Cyber Resilience Act guidance now out