5 things the EU Commission’s new CRA (Cyber Resilience Act) implementation guidelines just clarified - and what each one means if your team is engineering, not compliance.
Here’s a bet: of the five points the European Commission’s new CRA implementation guidelines clarify, your team’s working assumption is wrong on three. Not because your team is careless - because the regulation itself was ambiguous, people landed on different reasonable answers, and for fifteen months, everyone has been operating on educated guesses.
On 3 March 2026, the Commission published the draft CRA implementation guidelines (Regulation EU 2024/2847). Public consultation closed 31 March. The guidelines are not yet formally adopted, but with consultation closed, they now carry strong guidance value - and they are the first CRA document where Brussels starts being specific. Substantial modification. Digital distribution scope. Support period anchoring. Classification cascading. ENISA reporting cadence. Five points. Three of which probably contradict what your team currently assumes.
This article is for the engineering manager, CTO or founder at a 30-, 50-, or 200-person company building connected products - where engineering is the centre of gravity and there’s no dedicated compliance function on staff. (If you need the basics first - what CRA is, who it applies to, what penalties look like, the full FAQ - start here: codelab.eu/cra.)
Below
The five things the Commission clarified, what each one of them actually means for the work waiting on your desk this quarter, and a 90-day plan to act on them before 11 September 2026 - when ENISA vulnerability reporting becomes mandatory. The regulation introduces clear obligations for manufacturers and software providers, including the need to maintain accurate software inventories, demonstrate control over third-party components, and address vulnerabilities throughout the product lifecycle. For organisations working with embedded systems, these requirements are particularly complex due to long product lifecycles, limited visibility into legacy code, and extensive use of third-party components.
In this article, you will learn:
Five things the CRA implementation guidelines clarified - and what each means starting from zero
Of the five, three consistently catch teams off-guard in the gap assessments we run: digital distribution scope (#1), substantial modification (#2), and ENISA reporting cadence (#5). The other two - support period anchoring (#3) and classification cascading (#4) - are usually closer to right than wrong, but worth re-checking against the new wording.
1. Every digital distribution channel counts as “placing on the market”
Download, OTA update, remote-mounted firmware, app store distribution, side-loaded plug-ins - all count. There is no quiet exception for software distributed without packaging. Free, community or open source builds are not categorically exempt either; the line follows monetisation, not licensing.
What this means starting from zero: you have more “release events” than you probably realise. Every OTA channel, every staging environment any customer touches, and every sideload instruction in your documentation is a separate placing event for the same product.
Starter action this week: ask your release engineer or DevOps lead for a one-page inventory of all the ways firmware leaves the company. That single document is something most teams don’t have, and it’s the foundation for everything else.
2. A substantial modification = a new product
If a product placed on the market before 11 December 2027 undergoes a substantial modification after that date, it is treated as new - full obligations, full documentation, full conformity assessment. The Commission flags the kinds of changes that typically qualify: modifications to the network stack or external interfaces, new communication protocols, changes to boot or attestation mechanisms, and material expansion of the attack surface.
What this means starting from zero: your “legacy products are out of scope” assumption is conditional. The conditioning happens at the next significant firmware release. If your 2028 roadmap includes any of the changes above for a pre-2027 product, you will need a new conformity assessment for that release.
Starter action this month: List every product on your firmware roadmap for 2027 and 2028. For each planned release, flag whether it could plausibly count as a substantial modification.
3. Support period is declared per version, anchored to actual lifetime
The default 5-year minimum often quoted earlier is a benchmark, not a uniform rule. The Commission makes this explicit: the security support period must reflect the product’s foreseeable lifetime. Each software version should have its own declared end-of-support date. For industrial products with 10-15-year lifecycles, this can extend the obligation; for consumer-connected products with 3-5-year cycles, it can shorten it, but the duration must be justified in writing.
What this means starting from zero: you need to write down, per product family and per version, how long you intend to ship security updates - and why. The “why” is the new part. Most SMEs don’t have this written down anywhere today.
Starter action: draft a one-page support-period policy. Even rough language is better than none.
4. Classification follows primary function, not the loudest component
If your product contains a component that would be classified as “important” on its own, the whole product does not automatically inherit that classification. The Commission’s rule: classification follows the primary function of the product as a whole. Good news for complex embedded systems - but the rationale for the classification must appear in the technical file. What this means starting from zero: you’ll need to write a short paragraph explaining why your product is “default,” “important,” or “critical” - referencing primary function and addressing why embedded modules don’t promote the whole product. This is documentation, not engineering.
Starter action: for your top-revenue product, draft two paragraphs: what its primary function is, and which CRA class you believe applies and why. If it’s wrong, the gap assessment will catch it. If it’s right, it goes straight into the technical file.
5. ENISA reporting starts 11 September 2026 - 24 / 72 / 14
From 11 September 2026, manufacturers must report actively exploited vulnerabilities through the ENISA Single Reporting Platform: 24 hours for early warning, 72 hours for full notification, 14 days for the final report after fix deployment. National CSIRTs will not duplicate the intake - there is one platform, one workflow, one SLA. The Commission confirmed these timelines without softening.
What this means starting from zero: you need a person, a process and a runbook before September. Not a “security team” - a documented escalation path with named roles, on-call coverage including weekends and holidays, and a pre-mapped data set ready to submit on the platform. Most SMEs don’t have this; that’s normal, and it’s the most time-sensitive thing on this list.
Starter action: Decide today who will receive the call if a CVE affecting your product becomes public on a Sunday morning. If the answer is “no one” or “well, probably one of us,” you have your first documented gap.
The SBOM problem - and why “we generate one in CI” may not be enough
Of all CRA obligations, SBOM is the one where most embedded teams overestimate their readiness. Generating an SBOM is straightforward - modern build systems can produce one in SPDX or CycloneDX format with a few lines of CI configuration. The problem is whether the SBOM is accurate.
Open source code arrives in embedded firmware through more channels than the build system knows about: vendored libraries copied into the repository years ago, utility functions for crypto or parsing pasted in without a dependency declaration, forks of upstream projects with local modifications, and code that came in through a contractor before SBOM was a compliance term. A manifest scanner sees none of this.
For CRA the difference matters because the SBOM has to be defensible under audit. “We generate one in CI” is a great starting point, but if a regulator or - more likely - an OEM customer asks for evidence that your SBOM matches what’s actually in your firmware, manifest-level coverage may not survive the question.
Codelab’s CRA Secure Pipeline uses source-level SCA via SCANOSS - matching code against a knowledge base of more than 100 billion open source files - to close the gap between what the build system declares and what the firmware actually contains.
SCANOSS contributes the open source intelligence layer of the pipeline: continuous scanning for undeclared components, licence conflict detection, cryptographic algorithm identification, vulnerability detection, and SBOM generation in both SPDX and CycloneDX formats. The result is a verifiable, regulation-ready bill of materials at the source level, not just at the manifest.
The Pipeline is designed for on-premise deployment for regulated and IP-sensitive environments, or as SaaS offering, with a typical rollout of around six weeks.
Where to start - a 90-day plan
If you take nothing else from this article, take the sequence. CRA is a continuous practice with a fixed starting point, the same regardless of company size, product complexity or current security posture. The destination is an industrialised CRA practice where evidence is produced automatically as you build software, rather than assembled at release time.
Days 1–14
Get a written baseline
A structured gap assessment: executive summary, detailed findings, prioritised remediation roadmap.
Days 15–60
Stabilise: fix the highest-risk gaps
September minimum: documented vulnerability handling, a named PSIRT role, a pre-mapped ENISA reporting workflow.
Days 60–90
Industrialise: pipeline & evidence
Shift from spot-fixing to infrastructure that produces CRA evidence continuously, as a by-product of development.
Days 1–14: get a written baseline
Start with a structured gap assessment that maps your current state against the regulation in writing. The output: an executive summary, detailed findings, and a prioritised remediation roadmap. This is the document you show your board and your customers, and it scopes everything that follows.
Days 15–60: stabilise - fix the highest-risk gaps before September
From the gap assessment, you will have a prioritised list. The September 2026 deadline is narrow in scope - it is about vulnerability reporting - so the highest-priority items are almost always: a documented vulnerability handling procedure, a named PSIRT role with out-of-hours coverage, and a pre-mapped ENISA reporting workflow. Fixing those is the September minimum. SBOM, classification rationale and support-period documentation come next but are not blocked by September.
Days 60–90: industrialise - pipeline, SBOM, evidence as a continuous practice
By day 60 the priority shifts from spot-fixing gaps to building infrastructure that produces CRA evidence continuously, without the team having to remember. This is where most embedded manufacturers we work with stop trying to build it themselves - not because the components are exotic, but because pre-integrating them, hardening them for on-prem deployment, configuring CI/CD templates that enforce the right quality gates, and producing audit-ready evidence packages takes specialist DevSecOps capacity that SMEs rarely keep on staff.
A working CRA pipeline at SME scale typically covers six things: source control with enforced quality gates (so a release that fails security checks cannot ship), automatic SBOM generation in SPDX and CycloneDX formats on every build, source-level snippet capable Software Composition Analysis catching what manifest-only scanners miss (vendored libraries, copy-pasted functions, embedded forks - see the table above), licence conflict detection on third-party components, immutable audit logs that survive a regulator’s request three years after release, and audit-ready evidence packages produced as a by-product of normal development, not as a separate documentation project.
Built from scratch this is months of integration work and a permanent maintenance burden. Bought as a pre-integrated stack - in our case the CRA Secure Pipeline, deployed on-prem in around six weeks - it is a one-time setup followed by predictable maintenance. The decision isn’t whether you need this infrastructure (after September 2026 you do); it’s whether you build it or buy it.
What the technical file actually needs to contain
The Commission’s CRA implementation guidelines didn’t change the artefact list - but they did sharpen what each artefact has to demonstrate. The operational core of a CRA technical file is built around a documented cybersecurity risk assessment tied to design decisions, an accurate SBOM maintained continuously across product versions, a vulnerability handling procedure with named roles and out-of-hours coverage, a classification rationale that survives questioning (see point 4), a support-period declaration with written justification (see point 3), and a conformity assessment record. To these the guidelines add a substantial-modification log (see point 2) and explicit user information about security updates and end-of-support communication. None of this is week-one work. You map it in a gap assessment, then close gaps in priority order - the September deadline targets the vulnerability handling procedure specifically; the rest sequences toward December 2027.
The five things to remember
Print this page and tape it next to your kanban board - or keep it as a one-screen cheat sheet for planning sessions. It has a second use: OEM procurement questionnaires increasingly ask about CRA readiness, and these five points are the outline your answers should map to. Suppliers who can quote them back with evidence stay on shortlists; suppliers who cannot get replaced.
Why this matters before December 2027
The five clarifications above set the documentation work for the next 18 months, but the operational urgency for most SMEs is shorter and comes from OEM customers rather than EU regulators. Those customers have compliance teams, have read the regulation, and are cascading the obligations down the supply chain: questionnaires that used to ask about ISO 9001 and CE certification now ask about SBOMs, vulnerability handling and CRA-readiness timelines. If your component goes into a CRA-regulated product, the OEM is on the hook unless you can produce evidence that your part is compliant, and procurement will eventually drop suppliers who cannot.
The destination: an industrialised CRA practice
By December 2027, every product with digital elements you place on the EU market needs to produce, on demand, an accurate SBOM, a documented vulnerability-handling procedure with evidence that it has been followed, a defensible classification rationale, a justified support period, and a continuous trail of conformity assessment records. Doing that manually, release after release, year after year, is not realistic for a team without a dedicated compliance function. Doing it through an industrialised pipeline that produces the evidence as a by-product of how you build software is.
The CRA Secure Pipeline. Codelab’s pre-integrated DevSecOps stack - built on GitLab, SonarQube and SCANOSS - produces automatic SBOM generation, source-level snippet capable Software Composition Analysis, licence conflict detection, immutable audit logs and audit-ready evidence packages. Deployed on-prem (important for IP-sensitive industries and air-gapped networks where SaaS isn’t an option), or in the cloud, in roughly six weeks, on a fixed-price engagement. Source-level snippet capable scanning for SBOM & CBOM is contributed by our partner SCANOSS - matching code snippets against more than 100 billion open source files. Catching what manifest-only scanners miss.
The recommended starting point: a 1-week CRA Compliance Check
Before deploying infrastructure, get a written baseline. Our CRA Compliance Check is a fixed-price gap assessment delivered in one week: we map your products, processes and existing artefacts against the regulation, and deliver an executive summary, detailed findings, and a 30 / 60 / 90-day remediation roadmap with prioritised actions. You keep the report whether or not you continue to Pipeline deployment.
It exists for one practical reason: deploying a CRA pipeline against an undefined gap is guesswork. The Compliance Check turns the deployment into a fitted engagement - your highest-risk gaps known, your priorities sequenced, your Pipeline configuration scoped to what the assessment found.
Settle the bet
Which three did you get wrong?
“Bring your product list. In 30 minutes I will show you which of the five clarifications change your roadmap, and what closing each gap takes before 11 September.”
Sławomir Kukurenda · Lead Project Manager / Business Development, Codelab
He wrote this article. He also takes the calls.
What we would propose runs on the stack described above: Codelab’s own CRA portfolio (Compliance Check, Secure Pipeline, Secure Bootloader) with source-level scanning technology from our partner SCANOSS, matching your code against 100+ billion open source files.
Schedule a call with Sławomir →
30 minutes, no obligation. Full CRA portfolio and FAQ: codelab.eu/cra
This article is based on the European Commission’s draft CRA implementation guidelines and official EU sources available at publication. The draft is not yet formally adopted and some interpretation points may evolve. The statutory dates do not: reporting obligations start on 11 September 2026, and full application begins on 11 December 2027. Verify current Commission and ENISA materials before making compliance decisions.