Contents
Cybersecurity
CISO-as-a-service consulting: posture, remediation roadmap, ongoing support.
Discover →
CyberAgent
Continuous vulnerability assessment and SBOM generation: scanning, mapping onto requirements, documented evidence ready to hand over.
Discover CyberAgent →
DataGovern
Governance of compliance documentation: policies, evidence and registers kept together and up to date.
Discover DataGovern →
What came out on 27 July
The European Commission has published its first official guidance on applying the Cyber Resilience Act. There are two acts: communication C(2026) 5252 and its annex, which carries the guidance itself. Alongside them sits a separate implementation FAQ document.
The legal basis is Article 26 of Regulation (EU) 2024/2847, which tasks the Commission with issuing guidance to help economic operators apply the regulation. A first version went out for feedback in March; this is the adopted text.
Two features matter more than the content itself. The guidance is not binding: it is the Commission’s interpretation, and in a dispute the regulation text and the harmonised standards remain decisive. And it explicitly addresses microenterprises and SMEs, with 67 practical examples and flowcharts aimed at organisations without in-house counsel.
The five knots it unties
1. Scope: which products are covered
The CRA covers products with digital elements connected to a device or a network: routers, modems, connected home products, smartwatches, operating systems, firewalls, VPNs, browsers, antivirus software, password managers. The guidance goes into the two cases that generated the most questions, remote data processing solutions and open source software.
On software it clarifies a point worth holding on to, because it changes every development team’s calendar: the regulation applies when a version is first made available on the Union market. Multiple installations of the same version count as a single placing on the market.
2. Substantial modification: when conformity restarts
This is the concept that decides whether a new release is an update or a new product in the regulation’s eyes. A modification is substantial when it affects compliance with the cybersecurity requirements, when it changes the risk level or when it changes the original intended purpose.
The examples the guidance gives are concrete: adding a remote connectivity feature introduces new attack vectors, so it is substantial; changing encryption protocols in a way that affects compliance, likewise. A security fix that touches none of the three conditions is not.
3. Support period: the minimum is not the rule
Here the common reading needs correcting. The support period is at least five years, but the guidance clarifies that it must be aligned with the product’s expected lifetime: five years is the floor, not the value to declare by default. If a product has a reasonably longer life cycle, support follows it. If it has a demonstrably shorter one, the period can be shorter.
The operational corollary is heavy: every substantially modified version needs a newly declared support period. Anyone shipping often has to keep a register of which version is supported until when, and be able to state it to an authority.
4. Reporting: what you notify and how fast
The windows were already in the regulation and stay as they were: for an actively exploited vulnerability, an early warning within 24 hours, notification within 72 hours, a final report within 14 days of a corrective measure becoming available. For severe incidents the final report is due within a month. Notifications go to the national CSIRT and to ENISA.
The part that tends to be underestimated: the obligation covers products already placed on the market, not just new ones.
5. Risk assessment: what has to be documented
The manufacturer must carry out a cybersecurity risk assessment, identify the applicable constraints and implement appropriate measures. The guidance spells out what is expected to be written down, which in practice is what separates a company that is ready from one that will have to reconstruct everything backwards.
The calendar as it stands today
The regulation has been in force since December 2024 and applies in stages. The milestones behind and ahead:
- 28 November 2025: implementing act on the technical descriptions of important and critical products.
- 11 December 2025: delegated act on CSIRT notifications.
- 11 June 2026: rules on conformity assessment bodies and notifying authorities apply. Already passed.
- 27 July 2026: the Commission’s first set of guidance. The news this piece starts from.
- Q3 2026: first standardisation deliverables, horizontal and vertical.
- 11 September 2026: the reporting obligations kick in. This is the next real deadline, six weeks out.
- Q4 2026: delegated act on the EUCC presumption of conformity.
- 11 December 2026: Member States must have notified a sufficient number of bodies.
- 30 October 2027: further standardisation deliverables.
- 11 December 2027: full application, essential requirements and technical documentation included.
What to do now
For a company placing products with digital components on the European market, this is the useful sequence over the next six weeks.
1. Establish whether you are in scope, and for which products. This is not a rhetorical question: the guidance exists because the answer was not obvious, especially for software and services with remote processing. Write the result down, product by product, because everything else builds on it.
2. Stand up the reporting channel before 11 September. You need a process, named roles and a runbook, because 24 and 72 hour windows cannot be improvised on a Friday evening. Teams that already run NIS2 flows start ahead: the mechanism is the same, as we saw with NIS2 and SMEs.
3. Declare support periods and keep the register. Product by product and version by version, with the end-of-support date and the reasoning behind it.
4. Define what counts as a substantial modification for you. Three criteria applied to your release cycle, written once, so the decision is not relitigated with every release.
5. Start the SBOM now, even though it is due at the end of 2027. The dependency inventory is what makes it possible to answer within 24 hours when one of those dependencies really is exploited: it serves point 2 long before it serves the technical documentation. We argued the why in the CRA, SBOM and reporting, and the numbers on the vulnerability load now arriving are in 432 Linux kernel CVEs in two days.
If you build on or maintain open source
Article 24 of the CRA introduces the open source steward: legal persons providing sustained support to free software intended for commercial activities. The regime is light-touch (a documented cybersecurity policy, vulnerability handling and disclosure, cooperation with authorities) and stewards are not subject to administrative fines. Individual volunteer developers stay out of scope.
The July guidance returns to open source among the scope questions to clarify, which signals that this remains the regulation’s most delicate area. Anyone building products on open source components, which is nearly everyone, still carries the manufacturer’s obligations for the finished product, regardless of where the code came from.
What we think
Non-binding guidance with 67 examples is more useful than its status suggests. In a regulation where breaching the essential requirements costs up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher (Article 64), the value of a Commission document saying “this case is in, this one is out” is that it moves the discussion from a defensible interpretation to a position aligned with the people who wrote the rules. It is not a guarantee, it is an advantage in a dispute.
The point we think is underrated is the support period. The common reading is “five years and done”; the guidance says align it with the product’s expected lifetime and redeclare it at every substantial modification. For anyone selling long-lived devices, that is a multi-year maintenance commitment to be budgeted, not a box to tick.
The part no document solves for you is still the inventory. Without knowing what runs and with which dependencies, 24-hour reporting is not executable and the 2027 SBOM will be archaeology. This is the ground our tools work on: CyberAgent for continuous scanning and SBOM generation, DataGovern for holding the documented evidence together. As we always say, neither produces automatic compliance: they cut the manual work and make the part you have to demonstrate repeatable, while formal responsibility stays yours.
Six weeks to the first deadline with real obligations. Anyone starting in September starts six weeks late: CISO consulting is mostly there so you do not find that out on 12 September.
Sources
- European Commission: Commission publishes new guidance to support businesses’ implementation of the Cyber Resilience Act
- European Commission: the C(2026) 5252 documents and annex
- European Commission: Cyber Resilience Act implementation page and timeline
- Regulation (EU) 2024/2847 on EUR-Lex
- Punto Informatico: Cyber Resilience Act, the EU Commission publishes the guidance