The new CRA guidance in practice: five product decisions manufacturers should document now

European Commission CRA guidance (C(2026) 5252): product boundary and remote data processing, product risk, substantial modification, support period and reporting obligations from 11 September 2026. Five decisions with evidence for manufacturers.

September 9, 2026

preview-image for CRA guidance 2026: five product decisions

On 27 July 2026, the European Commission published guidance on the application of the Cyber Resilience Act (CRA) . The 84-page annex to C(2026) 5252 works through 67 examples, use cases and flowcharts, and it answers many of the questions manufacturers have been asking since Regulation (EU)2024/2847 was adopted. Microenterprises and SMEs receive particular attention. The timeline itself does not move: the reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026, the remaining main obligations from 11 December 2027. Our CRA page has an overview of scope, product classes and deadlines.

The guidance is a practical interpretation aid and is not binding. It shows how the Commission reads the regulation, and it does not replace a product-specific risk assessment, a conformity assessment or legal advice.

The same pattern repeats across the 84 pages. Product teams tend to want a blanket answer: “the cloud is excluded”, “a minor release is uncritical”, “a CVE is reportable”. The guidance declines to give one. It pushes each question back to the facts of the specific product and to a documented rationale for the conclusion. That is why the questions that keep coming up in architecture reviews, release boards and PSIRT meetings are variants of a single task: establishing the product boundary, the lifecycle and the evidence reliably, product by product.

This post is therefore organised around five decision records that should now exist in a product organisation. They give the next product, architecture or release meeting a concrete agenda.

The running example is a fictional but realistic product: a commercially offered monitoring and control solution with desktop and mobile apps, a cloud service for onboarding and configuration, over-the-air updates (OTA), storage at a third-party provider, and several supported and older versions in the field.

Decision 1, product boundary: is the cloud part automatically outside the CRA?

The guidance answers this question with the concept of remote data processing. A remote data processing solution counts as part of the product when three conditions are met together (guidance, paras. 178 to 202):

data is processed at a distance,
without this processing, the product could not perform one of its functions, not only its core function, and
the software was designed and developed by the manufacturer, or under the manufacturer’s responsibility.

Applied to the example product: the manufacturer’s own cloud service for onboarding and configuration will likely satisfy all three elements, so it has to be analysed as part of the product. The same reasoning covers the manufacturer-operated OTA update service. Who operates the software is not the deciding factor; a manufacturer’s application running on third-party infrastructure (IaaS/PaaS) can be remote data processing too. The generic storage solution of a third-party provider is a different case, because it is normally not software developed by the manufacturer. The storage solution remains a security-relevant dependency, though, and has to be assessed like any component, with due diligence proportionate to the risk. Cellular or Wi-Fi connectivity is in the first instance a communication channel, not automatically remote data processing. And a manual alternative to a remote function does not automatically take that function out of the analysis.

Decision record in practice: a one-page map of the remote functions. Per function: how the product behaves without it, who is responsible for the software, the data flow, third-party dependencies, the security measures implemented, and where the technical documentation is held.

Decision 2, product risk: can the customer simply accept the residual risk?

In enterprise risk management, a defined risk appetite is legitimate and useful. The CRA risk assessment answers a different question, and the guidance is explicit about it (paras. 156 to 163): residual risk has to be measured against an appropriate level of cybersecurity for the product, with regard to its intended purpose, reasonably foreseeable use, conditions of use, the users and assets affected, and the expected time of use. Cost considerations, commercial strategy or internal risk tolerance on their own do not establish that a risk has been adequately addressed.

None of that makes operating environments and user guidance irrelevant. A protected deployment environment can form part of the intended purpose, provided it is real and documented, and the product and user documentation actually support secure operation. A vague disclaimer that shifts an unresolved design problem to the customer, by contrast, does not hold. In the example product, the note “operate in trusted networks only” does not replace authentication on the control interface. It can complement a documented deployment assumption whose residual risk has been assessed, which is a far narrower claim.

Decision record in practice: a risk-to-control register. Per entry: the threat, the product function or interface affected, the deployment assumption taken from the intended purpose, the technical or organisational measure, evidence of effectiveness such as a test result, the residual-risk decision and the related user information. Methodically, a product-focused threat and risk assessment is the usual way to build this.

Decision 3, security delta: can a small release even be “substantial”?

Whether a change is a substantial modification within the meaning of the CRA depends on its effect. The version number does not settle it, and neither does the amount of code touched. The question is: does the change affect conformity with the essential cybersecurity requirements in Annex I Part I, or does it change the intended purpose for which the product was assessed (guidance, paras. 90 and 103 to 113)? A small convenience feature such as a persistent login or a diagnostics export can introduce a new interface, expose new tokens or data, or add a new dependency, and it can matter for exactly that reason. An ordinary security update that reduces risk and leaves the intended purpose unchanged is generally not a substantial modification.

The practical consequence is a review of the security-relevant delta before each release. This review is expressly not an automatic legal verdict, and it does not mean that every update requires a new conformity assessment:

Which interfaces, data flows, privileges, execution environments or dependencies did the release change?
Which new abuse scenarios, or material changes in likelihood and impact, follow from that?
Is the product’s threat and risk assessment still accurate?
Which deltas need to be captured in tests and technical documentation?
Is there anything that justifies escalation to the legal department or the conformity owners?

Whatever the outcome, the risk assessment and the technical documentation have to remain accurate, complete and up to date.

Decision record in practice: a security delta assessment attached to the release, containing the updated threat model, the component delta (SBOM), test results, the approval decision and the documentation delta.

Decision 4, support period: are five years always enough, and may the old version then be retired?

In the guidance, the support period becomes a lifecycle decision (paras. 125 to 131):

Five years are a floor, not an automatic maximum, unless the expected time of use is demonstrably shorter. Products expected to be used for longer need a longer support period.
The end of support has to be clear at the time of purchase, at least as month and year. Where technically feasible, users should be notified when it expires.
A substantially modified software version needs a support period of its own.
Ending vulnerability remediation for an earlier version, the route via Article 13(10) CRA, requires that users can move to the latest version free of charge and without additional costs. New hardware, an infrastructure replacement or fundamental changes to the operating environment are such additional costs. Ordinary testing and configuration effort is not.

For the example product this means that the question “can we migrate version 3 customers to version 5 and retire version 3?” is more than a sales decision. Answering it requires an evidenced migration and compatibility assessment and, in the individual case, legal review before support commitments are ended.

Decision record in practice: a version and support register. Per version: end of support, what was communicated at the time of purchase, the update delivery channel, the migration path with an assessment of costs and prerequisites, and a named owner for legacy versions.

Decision 5, reporting: does a component CVE start the 24-hour clock?

Not automatically. The guidance separates the vulnerability fact in a component from the product-specific reporting facts (paras. 209 to 224). From 11 September 2026, two things have to be reported: actively exploited vulnerabilities contained in the manufacturer’s product, and severe incidents having an impact on the security of the product. That is a narrower standard than “all critical CVEs”.

A suspicious signal, such as a published CVE for a component in the manufacturer’s own SBOM, has to be assessed without delay. “Awareness” in the sense of the reporting deadlines arises once the initial assessment establishes with a reasonable degree of certainty that active exploitation exists in the manufacturer’s own product, or that a severe incident has compromised its security. From that moment the staged deadlines run: 24 hours for the early warning, then 72 hours, then the final report. The BSI sharpened the threshold in its “CRAsh-Kurs” webinar of 8 September 2026 with two counter-examples: a published exploit without observed exploitation does not make a vulnerability actively exploited, and a ransomware incident at a customer is not automatically a severe incident if it cannot affect the security of the product. For third-party components, three questions are decisive. Is the vulnerable code contained in the product? Is it reachable there? And is it actually being exploited there? Where exploitation in the manufacturer’s own product is not given, there is no reporting obligation in that respect. Voluntary reporting remains possible, and vulnerability-handling duties as well as informing the component maintainer can still apply.

A point that is often overlooked: the reporting obligations also apply to products already on the market. Under Article 69(3) CRA, Article 14 covers all in-scope products placed on the market before 11 December 2027, that is, both products in the field today and those that will follow until December 2027. For these legacy products, the remaining requirements of the regulation only apply once they undergo a substantial modification after 11 December 2027 (Article 69(2)). The reporting obligations also persist after the support period has ended. The vulnerability-handling obligations in Annex I Part II, by contrast, are tied to the support period.

The central reporting platform (SRP): submission route, registration, notification fields

ENISA operates the Single Reporting Platform (SRP) , the central platform through which CRA notifications flow. ENISA’s FAQ and guidance documents (as of 8 September 2026) settle the points that matter most for preparation:

A notification is submitted once via the platform: to the CSIRT designated as coordinator for the Member State of the manufacturer’s main establishment and, as a rule, simultaneously to ENISA. The coordinator CSIRT passes the notification on to other relevant CSIRTs and market surveillance authorities where needed.
The platform is reachable at portal.cra-srp.enisa.europa.eu . Notifications are submitted in the role of Assigned Representative, the person who reports on behalf of the manufacturer; a second person can be invited as a backup.
Designated representatives sign in via EU Login. The coordinator CSIRT validates their authority after first access, in parallel with reporting, so the validation does not block a submission. ENISA advises starting registration and validation only when a specific notification is due; according to the BSI, registration and submission take a few minutes.
According to ENISA, no API is planned at this stage. The FAQ describes the data fields expected per stage (24 hours / 72 hours / final report).

The ENISA material complements the guidance with the submission route. It does not replace the product-specific analysis of whether a reportable case exists at all. Preparation can be modest and still concrete: name the owners for reporting access and representation, and map the internal PSIRT case file against the published notification fields.

Decision record in practice: a PSIRT case file, covering the intake and source of the signal, product and version with support status, the analysis of the component, the affected functionality and its reachability, evidence of exploitation or incident, the timestamp of “reasonable certainty”, the remediation and mitigation decision, user information, and the routing decision between CRA and, where relevant, NIS-2 reporting channels .

Side note: “open source” is not one answer

Here, too, the guidance replaces a label with an analysis (section 3 of the guidance). Free and open-source software within the meaning of the CRA requires publicly available source code and the corresponding licence freedoms, so a repository that is open only to paying customers does not meet that definition. Responsibility lies with those who actually control development, releases and distribution; merely contributing code or holding commit rights does not by itself make someone responsible. A monetised variant, whether a paid version, open core, or FOSS used to monetise other products or services, can be assessed differently from the free community version. The statement “our community edition is free, so the CRA cannot be relevant for us” does not simply survive this analysis. Anyone distributing or stewarding open-source components should document release control and the commercial model, and have edge cases of classification reviewed legally.

The next step: walk through one representative product

Start with one representative product instead of the whole portfolio, and produce the five decision records: the remote-function map, the risk-to-control register, the security delta assessment, the version and support register, and the PSIRT case file. The open items will then show far more precisely where architecture work, lifecycle planning, a PSIRT exercise or a legal classification is missing.

We are happy to support this work: a joint product security workshop along the five decisions, a product-focused threat and risk assessment , and technical validation through penetration tests and embedded security assessments . For questions of CRA applicability and product classification, we cooperate with a lawyer specialised in IT and cyber regulation; there are details on our CRA page .

Contact us for a free initial consultation if you would like to walk through the five decisions for one of your products.

The European Commission’s guidance is a practical, non-binding interpretation aid. This post translates it into questions for product and security decisions; it replaces neither the product-specific risk assessment and conformity assessment nor legal review.