How to version and timestamp an SBOM document under the 2026 elements

Give every SBOM an SBOM Version that changes whenever the SBOM data for a component changes, and a timestamp of the latest update. CISA's 2026 text says a timestamp should follow RFC 9557, and that semantic versioning, if used, should start with major version 1.

SBOM Version

The 2026 elements add SBOM Version as a new field. Definition: an identifier designated by the SBOM author to specify a change in the SBOM document from a previous version, or to show it is the first version.

Points from the text:

• The version applies to each component name and component version pair. Your product 4.2 has its own SBOM version history.
• Semantic versioning may be used. If so, "the major version of a published SBOM following these minimum elements should be 1." Use minor and patch numbers for content changes, so the next minor is 1.1 and the next major is 2.
• If you use an identifier such as a serial number to tell versions apart, CISA points to RFC 9562 for unique identifiers.
• Update the version whenever you edit data about the target component.

SBOM Timestamp

The timestamp is the record of the date and time of the most recent update to the SBOM data. Each version of an SBOM has a new timestamp. The text says the content "should adhere to RFC 9557," the internet date and time format with additional information. In practice that means an unambiguous date, time and offset, not a free text date.

When to bump what

• First SBOM for a release: SBOM Version 1.0, timestamp is the generation time.
• Corrected a wrong license: a minor version change and a new timestamp.
• Rebuilt with the same inputs: decide and document your rule, and give it a new timestamp.
• New product release: a new SBOM that starts at 1.0 for that component version, with a new timestamp.

The rebuild case is a judgement. CISA does not rule on it, so write your own rule and apply it the same way every time.

Why it matters to readers

CISA says each software version or update should have an associated SBOM, and an author who discovers new details or corrects errors should issue a revised one. Without version and timestamp, a reader cannot tell which copy is current. Tools that ingest SBOMs also use these fields to decide which file replaces which.

A small policy you can adopt

1. One SBOM per released build.
2. Corrections get a minor bump and a new timestamp.
3. Keep old versions available, so a customer can see what changed.
4. Record who approved a correction.

For regeneration frequency, see how often to regenerate an SBOM. For the equivalent rules in VEX files, see VEX document versioning and timestamps.

Try it yourself

Click through it at your own pace, or open it full screen.

Open the inventory and picture each list as one version of an SBOM, with its own timestamp.

Quick check

Sources

• CISA 2026 Minimum Elements for an SBOM

Last reviewed: 19 October 2026.