SBOM update frequency under CRA: release-based maintenance and historic retention

The most common question we get from hardware teams preparing for the CRA is deceptively simple: "How often do we need to update the SBOM — monthly, quarterly, per release?" The regulation gives no calendar answer. What it gives is a per-product obligation: every product version you place on the EU market must have an SBOM, vulnerabilities must be handled effectively for the support period, and the whole paper trail must survive for at least a decade.

In practice that translates to a release-based maintenance model — one SBOM per firmware version, snapshotted into the technical file at conformity assessment, with continuous CVE monitoring layered on top. This guide walks through the regulatory anchors, the retention math, and the operational pattern most manufacturers will land on. If you are still getting oriented on the broader file, start with Annex I explained and the CRA timeline and reporting obligations.

What the CRA actually says about SBOMs

The SBOM obligation lives in Annex I, Part II point (1) of Regulation (EU) 2024/2847. The verbatim wording is that manufacturers must "identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product."

Three things are doing work in that sentence:

• "At the very least the top-level dependencies" — the regulatory floor is top-level, but most teams go deeper because that is where vulnerability triage actually happens. CycloneDX and SPDX both support deep dependency trees; pick one and stay consistent. We unpack the trade-off in SBOM: CycloneDX vs SPDX for hardware.
• "Commonly used and machine-readable format" — this rules out proprietary spreadsheets or PDFs. CycloneDX JSON or SPDX JSON are the obvious choices.
• "Identify and document" — the SBOM is paired with a vulnerability identification capability. The SBOM alone is not enough; you need to be able to match components to CVEs in your monitoring pipeline.

The same Annex I Part II also requires manufacturers to disseminate security updates without delay and free of charge once issues are identified. That ties the SBOM directly to the vulnerability handling regime — the SBOM exists so you can answer "which of my fielded products are affected by this CVE" within hours, not weeks.

Recital 77 of the consolidated EUR-Lex text reinforces the design intent: "manufacturers should identify and document components contained in the products with digital elements, including by drawing up an SBOM."

Why "per release" is the defensible cadence

The CRA does not name a frequency. So why does every serious compliance program land on "one SBOM per released firmware version"? Because of how three other obligations interact.

Article 13(8) — support period. Article 13(8) is explicit: "the support period shall be at least five years. Where the product with digital elements is expected to be in use for less than five years, the support period shall correspond to the expected use time." During that whole window, manufacturers shall ensure "that vulnerabilities of that product, including its components, are handled effectively". You cannot handle vulnerabilities effectively without an SBOM that matches the firmware actually running in the field.

Per-version reality. Different firmware versions have different dependency graphs. If you ship 1.4.2 with libfoo 2.1.0 and 1.5.0 with libfoo 2.3.1, those are two different attack surfaces. A single rolling SBOM that always reflects "latest" is useless for the field unit that is still on 1.4.2 — and you are obligated to handle its vulnerabilities until end of support.

Conformity assessment freezes a snapshot. When you sign the EU Declaration of Conformity for a specific firmware version, you are attesting that that build meets Annex I. The SBOM that backs that attestation must be the SBOM for that build. If you later update firmware, you need to either re-assess (and snapshot a new SBOM) or document why the change is not substantial under conformity assessment module rules.

The operational consequence is straightforward: tie SBOM generation to your CI pipeline so a new build artefact and a new SBOM are produced together, then archive both. We cover the technical file mechanics in Technical File 101.

The 10-year retention rule and historic SBOMs

This is where many manufacturers underestimate the obligation. Article 13(13) reads: "Manufacturers shall keep the technical documentation and the EU declaration of conformity at the disposal of the market surveillance authorities for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer."

For a product with a 5-year support period that goes on sale in 2027 and is last placed on the market in 2030, the retention clock runs until 2040. For each firmware version sold during that window, the corresponding SBOM is part of the technical documentation set and must be retrievable for the same 10-year period.

Article 13(18) extends the same logic to user-facing information and instructions, which must also be kept "at the disposal of users and market surveillance authorities for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer." If your user-facing security advisory refers to specific firmware versions, those SBOMs need to be there to back it up.

Operationally this means:

• Every firmware version that was ever placed on the EU market gets its SBOM filed.
• SBOMs are never overwritten — they are versioned alongside the firmware.
• Archive format must remain readable for 10+ years. CycloneDX JSON and SPDX JSON are safe bets; proprietary formats are not. For broader retention guidance see technical file retention requirements.
• Storage must be queryable by market surveillance authorities on request, so a write-once cold archive that takes weeks to restore is risky.

Continuous monitoring vs. release-based regeneration

A common confusion: "release-based SBOM updates" does not mean "monitor for vulnerabilities only at release." Those are two different cadences.

SBOM regeneration: per release. A new SBOM is produced when the build pipeline produces a new firmware version intended for the market.

CVE matching: continuous. Against the SBOM of the firmware currently deployed in the field, you run daily (or near-real-time) matching against CVE feeds. When a hit lands on a component in the live SBOM, Annex I Part II point (8) requires that security patches or updates are disseminated without delay and free of charge.

This split matters because the CRA reporting obligations under Article 14 start applying from 11 September 2026 — earlier than the main obligations. The 24-hour ENISA notification clock starts the moment you become aware of an actively exploited vulnerability; you cannot wait for the next release to find out. We cover the timing in detail in CRA ENISA 24-hour reporting and the September 2026 reporting checklist.

How this maps to the timeline

The dates that matter for SBOM planning:

• 10 December 2024 — the CRA entered into force.
• 11 June 2026 — Chapter IV applies; Notified Bodies for the CRA start being notified under Article 71.
• 11 September 2026 — Article 14 reporting obligations apply. Even before the main SBOM obligation bites, you may already be in a situation where you need to report an actively exploited vulnerability, which is hard to do without an SBOM in place.
• 11 December 2027 — main obligations apply, including Annex I Part II and the SBOM requirement.

Working backwards from December 2027, a sensible runway is to have release-tied SBOM generation in CI by mid-2027 at the latest, and continuous CVE monitoring earlier — by September 2026 — so the reporting capability is already wired up when Article 14 kicks in. See CRA December 2027 readiness for the full sequence.

What the fines look like

Article 64(2) sets the top fine ceiling for non-compliance with the essential cybersecurity requirements in Annex I and the obligations set out in Articles 13 and 14 — which is where the SBOM obligation and its vulnerability handling counterpart live — at "EUR 15 000 000 or, if the offender is an undertaking, up to 2,5 % of [its] total worldwide annual turnover."

Article 64(3) sets EUR 10 000 000 or up to 2% for non-compliance with other obligations (covering a broader list of articles), and Article 64(4) sets EUR 5 000 000 or up to 1% for "the supply of incorrect, incomplete or misleading information to notified bodies and market surveillance authorities in reply to a request". That "incorrect or misleading information" ceiling is the one to watch if you ever have to answer a market surveillance request with a stale or reconstructed SBOM rather than the original.

Common mistakes

• Rolling SBOM only. Maintaining a single "current SBOM" that mutates with every commit. This fails the per-version reality of field units and creates a gap for older firmware still under support.
• PDF or spreadsheet SBOMs. Annex I Part II point (1) requires "commonly used and machine-readable format". PDF is not it.
• Top-level only on principle. The floor is top-level, but transitive components are where most exploited CVEs live. Going deeper is operationally necessary even if not strictly mandated.
• Forgetting Annex VII linkage. The SBOM is part of the technical documentation set referenced in Annex VII. It is not a side artefact — it lives inside the Technical File.
• No retention plan. Generating SBOMs but storing them in a build cache that gets purged after 90 days. The 10-year clock from Article 13(13) is unforgiving.
• Treating SBOM as a one-time conformity assessment deliverable. It is a living obligation tied to vulnerability handling for the entire support period.

How Cenitia helps

Cenitia generates a per-firmware-version SBOM in CycloneDX or SPDX directly from your build pipeline, links it to the corresponding Declaration of Conformity, and stores the full historic chain so the 10-year Article 13(13) retention is automatic. When a CVE matches a component in any of your historic SBOMs — not just the latest — the platform flags which firmware versions and which fielded products are affected, with the citations pre-drafted for an Article 14 report if needed.

We watch the CRA, the harmonized standards, and ENISA guidance continuously. When the regulation amends or a new harmonized standard is published, every affected SBOM-related document and DoC in your account is flagged for review — including the historic ones still inside the 10-year window.

Frequently asked questions

Does the CRA prescribe a fixed SBOM update frequency such as monthly or quarterly?

No. The CRA does not name a fixed interval. Annex I Part II point (1) requires manufacturers to draw up an SBOM covering at least top-level dependencies in a machine-readable format, and Article 13(8) requires effective vulnerability handling for the support period. In practice this means a new SBOM per released firmware version, plus continuous CVE monitoring against the live SBOM — but no calendar-based cadence is mandated by the regulation itself.

Do I need to keep old SBOMs after a firmware update, or can I overwrite them?

Keep them. Article 13(13) requires the technical documentation and the EU Declaration of Conformity to be kept at the disposal of market surveillance authorities for at least 10 years after the product is placed on the market, or for the support period — whichever is longer. Since each SBOM is bound to a specific firmware version that was placed on the market, every historic SBOM belongs in the technical file for that retention window.

What is the minimum support period that drives my SBOM maintenance obligation?

Article 13(8) third subparagraph sets the support period at a minimum of five years, unless the product is expected to be in use for less than five years, in which case the support period corresponds to the expected use time. Vulnerability handling — and therefore SBOM-driven monitoring — runs for that whole window.

Does Annex I Part II require an SBOM for every component, or only top-level?

Annex I Part II point (1) sets the floor at top-level dependencies: "covering at the very least the top-level dependencies of the product". Most teams go deeper because transitive components are where most CVEs live, but the regulatory minimum is top-level.

When do the SBOM and vulnerability handling obligations actually start applying?

The CRA entered into force on 10 December 2024. The main obligations — including Annex I Part II vulnerability handling and the SBOM requirement — apply from 11 December 2027. Reporting obligations under Article 14 apply earlier, from 11 September 2026. Notified body provisions (Chapter IV) apply from 11 June 2026.

What are the fines if I cannot produce a current SBOM when asked?

Article 64(2) sets administrative fines of up to EUR 15 000 000, or for undertakings up to 2.5% of total worldwide annual turnover, for non-compliance with the essential cybersecurity requirements set out in Annex I and the obligations set out in Articles 13 and 14 — which includes the SBOM obligation. Other obligations sit at EUR 10 000 000 / 2% (Article 64(3)), and supplying incorrect, incomplete or misleading information to notified bodies and market surveillance authorities sits at EUR 5 000 000 / 1% (Article 64(4)).

Related from the Library

• CRA Annex I explained
• SBOM: CycloneDX vs SPDX for hardware
• Technical File 101
• Technical file retention requirements
• CRA timeline and reporting obligations

Further reading

• Regulation (EU) 2024/2847 — consolidated text on EUR-Lex
• CRA Annex I — essential requirements (third-party compilation)
• CRA Article 13 — manufacturer obligations
• CRA Article 64 — administrative fines
• CRA Article 71 — entry into force and application dates
• European Commission — Cyber Resilience Act policy page

Last reviewed: 5 July 2026. Cited regulations watched continuously by Cenitia — when one amends, this article is flagged for update.