CRA Harmonised Standards in 2026: What the Delay Means for Your SBOM and Vulnerability Handling
| Interlynk
The CRA's harmonised standards are delayed, but your SBOM and vulnerability-handling obligations are not. Here is the current state of play and what to do while the standards catch up.
Overview
The EU Cyber Resilience Act is in force and well into its implementation phase. The reporting obligations have applied since 11 September 2026, and the full essential requirements with CE marking apply on 11 December 2027. In between sits the machinery that is supposed to make compliance predictable: the harmonised standards that give manufacturers a presumption of conformity. That machinery is running behind.
As of October 2026, no CRA harmonised standard has been cited in the Official Journal, and the drafting deadlines have already slipped once. It is tempting to read a standards delay as breathing room. For the parts of the CRA that matter most to software teams, the SBOM and vulnerability-handling obligations, it is not. Those requirements do not depend on a finished standard, the reporting clock is already running, and the work to meet them takes months.
This post lays out where the standards actually stand and what to do while they catch up.
Where the CRA Stands in October 2026
A quick orientation, because the dates do the arguing.
Chapter IV, covering the notification of conformity-assessment bodies, began applying on 11 June 2026. The reporting obligations followed on 11 September 2026: manufacturers must now notify actively exploited vulnerabilities and severe incidents to ENISA and their national CSIRT, and ENISA's single reporting platform is live.
Full application lands on 11 December 2027. From that date, products placed on the EU market must meet the essential requirements and carry the CE mark.
The essential requirements themselves are set in the regulation, in Annex I. They are the fixed point in all of this. The harmonised standards do not create those requirements. They provide one well-trodden route to demonstrating you have met them.
The Standards Delay
In July 2026, the Commission published a draft amendment to the standardisation request behind the CRA, mandate M/606, proposing to push the drafting deadlines back by about two months. Under the proposal, the first core horizontal standards, covering secure development and vulnerability handling, move to 31 October 2026 from 30 August, the product-specific vertical standards move to 31 December 2026 from 30 October, and a further set of horizontal standards is expected in October 2027.
Treat these as proposed revised dates rather than settled ones, and confirm the amendment's status before planning around them.
Two points matter more than the exact dates. First, these are deadlines for standards bodies to deliver drafts to the Commission, not the dates a standard becomes usable for compliance. A delivered draft still has to be assessed and then cited in the Official Journal before it does anything for you. Second, the vertical product standards, developed by ETSI, are still moving through public enquiry, with comment windows closing through mid-November 2026. The picture is one of active drafting, not finished work.
What the Presumption of Conformity Actually Requires
Here is the mechanism that the delay affects, and the reason it is less dramatic than it sounds.
Under Article 27, a manufacturer gets a presumption of conformity only for requirements covered by a harmonised standard whose reference has been published in the Official Journal. No CRA standard has reached that point. Until one does, there is no cited standard to presume conformity against, which has a practical consequence for how some products demonstrate compliance.
For important products in Class I, the self-assessment route in Article 32 depends on applying a harmonised standard, a common specification, or a qualifying European cybersecurity certification scheme that covers the essential requirements. A harmonised standard is only one of those bases, so the absence of a cited standard constrains that route without automatically forcing every Class I manufacturer into third-party assessment. Where none of those bases is available for a product, a third-party conformity-assessment route may be required instead.
If your products fall into an important or critical category, confirm your classification and your intended conformity route now, because the answer shapes your timeline, cost, and evidence. Watch both the Official Journal and the Commission's CRA standardisation page for the citation that actually changes your options.
Why the Delay Does Not Pause Your SBOM Work
A missing standard changes how you prove conformity. It does not change what the regulation asks you to build.
The CRA's essential requirements already tell you to identify and document the components in your products. Annex I, Part II, point 1 calls for a software bill of materials in a commonly used, machine-readable format that covers at least the top-level dependencies. Part II also requires you to handle vulnerabilities without delay, including through security updates, and to have coordinated vulnerability disclosure in place.
None of that is waiting on EN-numbered standards. The standards will describe how to do it in a way that earns the presumption of conformity, but the obligation to do it is in the regulation today.
This is where the "at least the top-level dependencies" wording is worth reading carefully. It is a floor, not a target. An SBOM that stops at top-level dependencies will satisfy the literal minimum and still miss most of what an attacker can reach, because the vulnerable component is usually somewhere deeper in the tree. The teams that treat the CRA minimum as the goal will produce compliant SBOMs that do not actually support vulnerability handling, which is the other obligation sitting right next to it.
The work that is standard-agnostic, and therefore safe to do now, is the substantive work: product risk assessment, accurate SBOM generation, technical documentation, and a functioning vulnerability-handling and reporting process. Doing it early is the only way to be ready, because none of it can be stood up in the weeks before December 2027.
Reporting Is Already Live
The one CRA obligation that offers no waiting room at all is reporting. Since 11 September 2026, an actively exploited vulnerability in your product triggers a notification duty to ENISA and your national CSIRT, on a tight clock, through the ENISA platform.
Meeting that duty under pressure depends on knowing, quickly, whether a newly disclosed vulnerability is present and exploitable in a shipped product and which versions are affected. That is an SBOM question and a vulnerability-exploitability question before it is a reporting question. A maintained SBOM paired with exploitability assessments, recorded as VEX, is what lets you answer in hours instead of reconstructing the analysis from scratch when the clock is already running.
The inventory and the assessments support the analysis. You still need a process that decides when Article 14 is triggered, assigns ownership, and files the notification on time.
What To Do Now
While the standards are finalised, the productive moves are the ones that will hold regardless of the final text:
Build an accurate SBOM for every product in scope, and go past the top-level-dependency floor to the transitive components where real exposure lives.
Stand up a vulnerability-handling process and wire it to the ENISA reporting path that is already active.
Keep exploitability assessments current so a new CVE does not become a fire drill.
Review the ETSI vertical drafts and submit comments before the enquiry windows close, if your products are affected.
Confirm your product classification and intended conformity route.
Track the Official Journal rather than the drafting calendar, since the citation is the moment your options change.
Where Interlynk Fits
Interlynk works on the two pieces of this that are hardest to get right and most time-consuming to build.
The first is generation. lynkctl produces build-aware SBOMs for embedded and firmware software, capturing the vendored, static, and SDK components that a top-level-dependency manifest never records. That depth is what turns a CRA-minimum SBOM into one that can actually support vulnerability handling.
The second is operation. The Interlynk platform ingests SBOMs and CBOMs, evaluates them for completeness and quality, risk-assesses components against vulnerability data, manages VEX assertions, and notifies stakeholders when exposure changes. That is the capability the Article 14 reporting duty quietly assumes you already have.
The platform works on the SBOM and CBOM it is given, keeping generation and evaluation cleanly separated.
The Bottom Line
The CRA's harmonised standards are late, and that matters for the mechanics of demonstrating conformity. It does not change the substance of what the regulation asks software teams to do, and it does not pause a reporting obligation that is already in force.
The manufacturers who come through the next fourteen months well will be the ones who treated the delay as time to get the foundational work right: complete SBOMs, real vulnerability handling, a live reporting path. The standards will arrive and describe the preferred way to prove it. The work they describe is work worth starting now.
Sources
Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal
cyberresilienceact.eu, "Current State of Play and Timeline (2026)"
cyberresilienceact.eu, "CRA standardisation deadlines pushed back two months"
About Interlynk. Interlynk helps teams generate, manage, and operationalize SBOMs across the software supply chain. lynkctl produces build-aware SBOMs for embedded and firmware software, capturing vendored, static, and SDK components with precise identifiers. The Interlynk platform ingests SBOMs and CBOMs, evaluates them for completeness and quality, risk-assesses components, manages VEX assertions, and notifies teams when exposure changes.
This article is informational and does not constitute legal or compliance advice. The CRA's implementation, standards, and official guidance are evolving; confirm current requirements, deadlines, and your product classification against the primary sources and your own counsel.