Regulatory requirements

The Regulatory Compliance node checks an SBOM against three sets of requirements. This page summarizes what each one asks for, so the annotations the node produces make sense.

note

This is a working summary to help interpret compliance results, not legal advice. Where a decision has consequences, read the source regulation.

NTIA Minimum Elements (2021)

The United States baseline, published by the NTIA in 2021 under Executive Order 14028. Seven required data fields.

#	Field	What it means
1	Supplier Name	The entity that creates, defines, and identifies the component.
2	Component Name	The name the original supplier gave the component.
3	Version	The supplier's own version identifier.
4	Other Unique Identifiers	Look-up keys such as CPE, PURL, or SWID tags. Required if they exist.
5	Dependency Relationship	That upstream component X is included in software Y, expressible transitively.
6	Author of SBOM Data	Who produced the SBOM — not necessarily who wrote the software.
7	Timestamp	When the SBOM data was assembled.

Recommended but not required: component hashes, lifecycle phase, relationships beyond simple dependency, and license information.

CISA Minimum Elements (2025)

CISA's 2025 update expands the NTIA baseline from seven fields to eleven, promoting three previously-recommended items to mandatory.

#	Field	What it means
1	SBOM Author	The entity that generates the SBOM data.
2	Software Producer	The entity that creates and identifies the component. For open source, the project or maintaining organization. Unknown provenance must be stated explicitly.
3	Component Name	Assigned by the software producer. Multiple names permitted.
4	Component Version	The producer's version. Where none exists, the file creation date may be substituted.
5	Software Identifiers	At least one machine-processable identifier — CPE and PURL preferred. Include all that exist.
6	Component Hash	Hash value and algorithm. Omitted only when the author has no access to the original artifact.
7	License	The component's license, machine-readable where possible. Proprietary terms and unknown licenses must be stated.
8	Dependency Relationship	Enough to build a dependency graph, including pedigree for forked or backported software.
9	Tool Name	The tools used to generate the SBOM, and their data sources.
10	Timestamp	Most recent update, in ISO 8601.
11	Generation Context	Whether the SBOM was produced before build (source), during build, or after build (binary analysis).

What changed from 2021

Aspect	NTIA 2021	CISA 2025
Required fields	7	11
Component Hash	Recommended	Required
License	Recommended	Required
Generation Context	Recommended, as "Lifecycle Phase"	Required
Software Identifiers	Required if they exist	At least one always required

If you supply to US federal programmes, enabling the CISA check alongside NTIA shows what an upgrade to the 2025 baseline would require.

EU Cyber Resilience Act

The CRA (Regulation 2024/2847) requires manufacturers of products with digital elements to produce an SBOM covering at minimum the top-level dependencies of the product, in a commonly used machine-readable format, and to keep it current across the product lifecycle.

The CRA is less prescriptive than the US frameworks — it does not enumerate required fields. In practice compliance implies:

Field	Why
Component name	Required to identify components under the Article 3(39) definition.
Component version	Required to track vulnerabilities (Annex I, Part II).
Supplier or author	Required to document supply chain relationships.
Dependency relationship	Explicitly required — "top-level dependencies".
Unique identifier	Needed for unambiguous machine-readable identification.
Creation timestamp	Standard practice for a formal record.

Disclosure

Aspect	Rule
Public disclosure	Not required. Manufacturers need not publish the SBOM.
User access	If shared with users, the manufacturer must say where to obtain it.
Market surveillance	Must be provided to authorities on reasoned request.
Technical documentation	Forms part of the documentation required for conformity assessment.

Note that several details — the exact format, depth beyond top-level dependencies, and update cadence — are left to forthcoming implementing acts and standards.

How the node reports

Regulatory Compliance annotates the SBOM rather than blocking it:

• A mandatory element that is missing produces an ERROR annotation.
• A recommended element that is missing produces a WARNING annotation.

Follow it with Generate PDF Report to turn those annotations into a document, or with a Review step if a person should decide what to do about them.

Related

• Regulatory Compliance node.
• Canonical SBOM format — where these fields live internally.