Does a CRA SBOM checklist give you a license page?

Product teams should treat 2026 to 2027 as the window to stand up component inventory, SBOM generation, vulnerability processes, and (separately) license disclosure workflows. Waiting until conformity assessment to discover you have no reviewed third-party license record creates dual fire drills.

Timelines vary by product class and implementing acts, and documentation must stay current through the support period. Confirm all dates with counsel; this page is not legal advice.

Scope turns on product classification, not company size: Products with digital elements placed on the EU market are in scope, while products already covered by sector-specific EU rules (medical devices, motor vehicles, civil aviation) and pure cloud services without a product angle are generally carved out. Installable software, firmware, connected devices, and many commercial open-source distribution models may fall in scope when sold in the EU.

Pure SaaS carve-outs exist in market understanding but require product-specific legal review.

The CRA requires an SBOM but it does not cover license disclosure. Annex I, Part II obliges manufacturers to identify and document components, including an SBOM in a commonly used, machine-readable format covering at minimum the top-level dependencies, which is component identity data, not reviewed license text.

That obligation accelerates SBOM adoption across EU-selling vendors. Teams produce CycloneDX or SPDX from CI, often for the first time, and hand files to security or compliance. The SBOM satisfies CRA component documentation. It does not automatically produce notice, attribution, or full license text for each component.

CRA cybersecurity documentation covers risk assessment, vulnerabilities, updates, and secure development. Product security, PSIRT, and legal own that work. License compliance covers intellectual property obligations in third-party software: Notice, attribution, copyleft conditions. A different workflow with human review gates.

Conflating them creates false confidence. A team can pass an internal CRA readiness review with SBOMs and patch SLAs while still failing a buyer's request for license compliance because nobody reviewed license text.

• CRA SBOM: Component identity for security and regulatory documentation.
• License disclosure: Full text and attribution for legal and procurement.
• CRA: Vulnerability reporting to authorities under defined conditions.
• License: Copyright and distribution conditions in OSS licenses.
• Same lockfile input, different outputs and different owners.

CRA expects documentation updated over the support period when vulnerabilities and components change. The same dependency drift breaks license representations if nobody re-reviews what shipped.

Multi-person teams merge package updates continuously. Without re-import and re-publish on release, your CRA SBOM and your license disclosure both describe yesterday's product. Regulatory documentation and buyer-facing records must move with the codebase.

Large customers map vendor CRA posture into their supply-chain programs, and they still paste license sections from RFP templates written before CRA existed. They ask for SBOM plus open-source license page plus attestation that the list is maintained.

CRA-trained procurement will expect durable access to compliance artifacts. That does not replace the content of license disclosure. It raises the bar for how current and accessible your records must be.

Security org: SBOM generation, vulnerability management, incident reporting, CRA conformity inputs, secure update delivery.

Compliance / legal / engineering ops: Third-party license inventory, review, publish gates, disclosure exports, buyer questionnaire answers.

Shared input: Lockfiles and SBOMs from CI. Divergent output: Security uses SBOM for CVEs; compliance uses the same import for reviewed license records.