Draft Commission guidance on the Cyber Resilience Act

Have your Say – European Commission · Initiative 16959

Draft Commission guidance on the Cyber Resilience Act

GISAD – Global Institute for Structure relevance, Anonymity and Decentralisation · Statement

Core thesis: A guidance makes the law readable – it does not replace the measurement in operation. Sixty-seven examples create clarity, but concept-fidelity does not arise from examples; it arises from measurement outside the manipulable area. Anyone who reads the guidance as a licence for self-declaration has understood the Cyber Resilience Act backwards.

What has been decided

On 3 March 2026, the Commission published its draft guidance on the application of the Cyber Resilience Act (Regulation (EU) 2024/2847) under Article 26 CRA, open for feedback until 31 March 2026 – more than 85 contributions were submitted. The final guidance was published on 27 July 2026 as Commission Communication C(2026) 5252 with an annex of more than 80 pages, containing 67 practical examples, use cases and flowcharts, written with microenterprises and SMEs in mind. The guidance is non-binding; only the Court of Justice can interpret the Regulation authoritatively.

  • Scope: remote data processing solutions are assessed functionally, not by commercial labels; a dedicated section addresses free and open-source software, distinguishing non-commercial development from commercial products.
  • Classification: „important“ and „critical“ follow the product’s core functionality – mislabelling cannot avoid stricter assessment.
  • Support periods: five years is a minimum, not a default; the expected lifetime decides.
  • Substantial modification: update size is not a proxy – the risk profile decides.
  • Open-source feedback themes: dual-track models, transitive SBOMs, the status of forges exercising de facto control, the contractual cascade reaching community projects outside the scope, and the lack of procurement tools for public administrations (Article 5(2)).

Context: CRA reporting obligations have applied since 11 September 2026 via ENISA’s Single Reporting Platform; the main obligations apply from 11 December 2027. Notified bodies have only been operational since June 2026, and their capacity is limited.

GISAD’s assessment

1. Readability is not verification. The examples are a genuine service, especially for small companies. But conformity must be checked in operation – event-driven, sample-based, outside the manipulable area. The guidance describes how the Commission reads the law; it cannot certify that a product lives up to it.

2. The open-source cascade must be stopped. CRA obligations must not flow back through contractual cascades to community projects that lie outside the Regulation’s scope. Open-source contributions are not tax-free volunteer work. The steward regime (Article 24) needs an interpretation that strengthens small structures rather than drowning them – and whoever operates a forge with de facto control over development workflows must be treated by their role, not their self-description. The consequence: European development infrastructure – forges, registries, CI/CD at Stage B – instead of dependence on US platforms with CLOUD Act exposure.

3. Transitive SBOMs – readability without cosmetics. Listing only first-level dependencies would be a step backwards. Open code makes the structure readable – but readable is not owned. Supply-chain transparency must capture the full depth, otherwise the SBOM becomes a fig leaf.

4. Procurement is the missing enforcement motor. The stakeholder feedback is right: public administrations lack the tools to integrate CRA requirements into procurement (Article 5(2)). Public money, public code – the public sector as anchor customer makes guidance effective before products reach the market; market surveillance alone arrives too late.

5. Support periods: security must not become a paywall. Restricting remediation to the latest version is acceptable only where upgrades are genuinely free of cost and obstacles. The limit must be drawn at vulnerable groups: security updates for devices used by older people and those with limited digital access are participation infrastructure.

6. Functional analysis is structural thinking – but the cloud remains invisible. Assessing remote processing by function rather than label is right. Yet the guidance examines the product, not its operating environment: a CRA-compliant product running on US hyperscalers remains exposed to the CLOUD Act. A provenance note (Stage B) belongs in the guidance’s practical application.

7. Timing: deadlines do not protect, structure protects. With notified body capacity limited and demand concentrating before December 2027, a bottleneck near the deadline will produce paper compliance rather than security. Early, staged assessments beat last-minute certificates.

Conclusion: GISAD welcomes the guidance as what it is: a manual for reading the law. What turns reading into security remains the same as ever – structure: verified operation instead of self-declaration, open-source stewardship that protects rather than burdens, and a public sector that buys its way to resilience.

GISAD – Global Institute for Structure relevance, Anonymity and Decentralisation · Registered in the EU Transparency Register, No. 244298340978-40

Sources: EU Commission, Initiative 16959 · Commission guidance on the Cyber Resilience Act (C(2026) 5252)