# Regulatory Compliance (/docs/operational-model/use-cases/regulatory-compliance)

The EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) sets cybersecurity requirements for products with digital elements sold in the EU. It makes SBOMs and structured vulnerability handling part of the legal baseline for manufacturers. This page maps the obligations to the artifacts and workflows in this framework. It is not legal advice, and the Official Journal text and the Commission's guidance take precedence.

*Last reviewed October 2026.*

## Timeline [#timeline]

| Date              | What applies                                                                                     |
| ----------------- | ------------------------------------------------------------------------------------------------ |
| 10 December 2024  | The regulation entered into force                                                                |
| 11 June 2026      | Rules for notified conformity assessment bodies apply                                            |
| 11 September 2026 | Manufacturers must report actively exploited vulnerabilities and severe incidents                |
| 11 December 2027  | All remaining obligations apply, including the essential cybersecurity requirements and the SBOM |

Reporting is already in force. Producers that do not yet have a way to receive reports, triage them and notify authorities within the deadlines should start with the [Vulnerability Disclosure workflow](/docs/operational-model/workflows/vulnerability-disclosure).

## What manufacturers must do [#what-manufacturers-must-do]

* **Release without known exploitable vulnerabilities.** A product may not be placed on the market with a known exploitable vulnerability.
* **Document components and vulnerabilities.** Annex I, Part II requires an SBOM in a commonly used, machine-readable format that covers at least the top-level dependencies.
* **Handle vulnerabilities throughout the support period.** The support period is at least five years, unless the product is expected to be used for a shorter time. Security updates stay available for at least ten years or for the support period, whichever is longer.
* **Run coordinated vulnerability disclosure.** Publish a policy, provide a contact address, and publish information about fixed vulnerabilities once an update is available.
* **Report to authorities.** Actively exploited vulnerabilities go to the designated CSIRT and ENISA: early warning within 24 hours, a notification within 72 hours and a final report 14 days after a corrective measure is available.
* **Keep technical documentation.** The SBOM is part of it. It is given to market surveillance authorities on request and is not published.

## Where SBOM and VEX fit [#where-sbom-and-vex-fit]

| Obligation                                        | Artifact                         | Framework pages                                                                                                                       |
| ------------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Identify and document components                  | SBOM                             | [Generate SBOMs](/docs/operational-model/workflows/generate-sboms), [SBOM requirements](/docs/content-requirements/sbom-requirements) |
| Keep the SBOM current for the support period      | SBOM per release                 | [Release Management](/docs/operational-model/use-cases/release-management)                                                            |
| State whether a vulnerability affects the product | VEX                              | [VEX and VDR](/docs/content-requirements/vex-vdr)                                                                                     |
| Disclose fixed vulnerabilities                    | VDR, advisory                    | [Vulnerability Disclosure](/docs/operational-model/workflows/vulnerability-disclosure)                                                |
| Report exploited vulnerabilities                  | Report to CSIRT and ENISA        | [Vulnerability Disclosure](/docs/operational-model/workflows/vulnerability-disclosure)                                                |
| Report upstream to component maintainers          | Machine-readable fix information | [Vulnerability Disclosure](/docs/operational-model/workflows/vulnerability-disclosure)                                                |

## How much SBOM is enough [#how-much-sbom-is-enough]

The regulation sets a floor of top-level dependencies. That floor is lower than what most consumers need to assess exposure, because a vulnerability in a transitive dependency ships in the product like any other.

The framework's [maturity levels](/docs/operational-model/core-concepts/maturity-levels) describe the difference. Level 1 documents declared components and meets the baseline. Level 2 adds transitive dependencies, provenance and supplier identifiers. German BSI TR-03183-2 is a widely referenced source for the detailed content expected in practice, and it is listed in [External Resources](/docs/external-resources).

## Security updates and substantial modifications [#security-updates-and-substantial-modifications]

A security update that fixes a vulnerability without changing the product's intended purpose is generally not a substantial modification. It does not trigger a new conformity assessment, so there is no reason to delay a patch for that purpose. A change that alters the intended purpose or core functionality can be a substantial modification.

## Others in the supply chain [#others-in-the-supply-chain]

* **Importers and distributors** must check that manufacturers have met their obligations before placing products on the market.
* **Open source stewards** have lighter obligations, mainly a cybersecurity policy and cooperation with authorities. Manufacturers that integrate open source components remain responsible for the due diligence on them.
* **Consumers** are covered by NIS2 when they operate essential or important services. NIS2 requires supply chain risk management, which depends on knowing what software is in use. See the [Consumer guide](/docs/roles/consumer).

## Consequences of non-compliance [#consequences-of-non-compliance]

Fines can reach EUR 15 million or 2.5 percent of worldwide annual turnover for breaches of the essential requirements, whichever is higher. Other breaches carry lower ceilings. Authorities can also order corrective action or withdraw a product from the market.

## Common pitfalls [#common-pitfalls]

* **Treating the SBOM as a one-off submission.** An SBOM produced once for the technical file and never updated stops describing the product after the next release.
* **Waiting for December 2027.** Reporting has applied since September 2026, and the vulnerability handling needed for it also supports the SBOM and update obligations.
* **Having no contact point.** Authorities and researchers need an address to reach. Publish it before an incident.
* **Ignoring upstream.** Fixing a vulnerability in a third-party component without telling its maintainer leaves the obligation unmet.

## References [#references]

* [EU Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act), European Commission
* [CRA overview](https://sbom.se/en/cra/overview), SBOM.se
* [ORCWG CRA Hub](https://github.com/orcwg/cra-hub), community FAQ and resources