Software Supply Chain Security Compliance: What Each Regulation Actually Demands

Five regimes now impose software supply chain obligations on connected-product manufacturers. They ask for nearly the same evidence and disagree about how deep it has to go.

Two things happened in 2026 that pulled in opposite directions, and most teams only registered the first.

On January 23, the US Office of Management and Budget rescinded the memoranda requiring federal agencies to collect a secure software development attestation before using your software. On July 29, CISA replaced the 2021 SBOM baseline with one carrying seventeen data fields instead of seven.

Software supply chain security compliance did not get lighter this year. One obligation moved from a government-wide form into individual contracts, and the technical bar for the underlying artifact went up.

Below is which regulations impose the obligation and when, what the two 2026 changes actually did, and where the legal minimum and the market expectation have come apart.

What Software Supply Chain Security Compliance Requires

Software supply chain security compliance is the set of legal and contractual obligations attaching to third-party and open-source code inside a product you place on a market. Not the code you wrote. The code you shipped without writing.

Across every regime below, three demands recur.

• A component inventory. Documented, machine-readable, kept current for as long as you support the product.
• Due diligence over third-party components. Evidence that you assessed what you integrated, including free and open-source components.
• Vulnerability handling with a clock. A process to find, triage, and remediate flaws in those components, and in most regimes an obligation to notify someone within a fixed window.

The artifact is the same each time. What differs is how deep the inventory goes, who receives it, and how fast. For the underlying practice rather than the obligations, see our guide to software supply chain security.

Which Regulations Require Software Supply Chain Security

No single law is called the software supply chain regulation. Five separate instruments reach a connected-product manufacturer, and only two of them do it directly.

The CRA and 524B attach to the product and gate market access. NIS2 and federal procurement reach you as a supplier, through the contracts your customers write to satisfy their own obligations.

What Changed in 2026

Rescinding a mandate is not the same as removing the work.

OMB Memorandum M-26-05, issued January 23, 2026, rescinded M-22-18 and M-23-16 and with them the requirement that federal agencies obtain a secure software development self-attestation before using your software. The memo characterizes those policies as having imposed "unproven and burdensome software accounting processes that prioritized compliance over genuine security investments."

Read the next paragraph of the memo. Agencies still maintain a complete inventory of software and hardware, still develop assurance policies matching their risk determinations, may still use CISA's attestation form, and may adopt contract terms requiring a current SBOM on request.

One common form became a per-agency negotiation. Sell to five agencies and you may now answer five sets of terms instead of filing one document.

Six months later the artifact changed. On July 29, 2026, CISA and seventeen partner agencies published the 2026 Minimum Elements for a Software Bill of Materials, replacing the 2021 NTIA baseline. Ten fields are new: component hash value and hash algorithm, component license, SBOM author signature, data format name and version, tool name and version, SBOM version, and generation context.

CISA is explicit that the minimum elements do not create new requirements by themselves. They set what buyers and regulators will ask for, which matters more than what any of them can compel.

The Legal Floor and the Market Baseline Have Separated

An SBOM can satisfy the Cyber Resilience Act and still fail the expectation of the customer requesting it.

CRA Annex I Part II(1) requires an SBOM covering "at least the top-level dependencies" of the product. CISA's 2026 revision retired its old Depth element, which also stopped at top-level dependencies, and replaced it with Coverage: all components including transitive ones, with no minimum depth. The stated reason is that the 2021 definition reflected the tooling available in 2021 rather than the depth a security decision needs.

Nobody is rushing to close the gap. Article 13(24) empowers the European Commission to specify the format and elements of the CRA SBOM by implementing act, and none has been adopted [verify before publishing]. Into that vacuum have moved CISA's elements and BSI TR-03183-2, which supplies the field mappings the regulation does not.

One new field deserves particular attention. SBOM Generation Context asks the author to declare the lifecycle phase at which the document was produced. CISA's own worked example distinguishes an SBOM generated from source code, identified as "before build," from one a binary analysis tool generates "after build."

A question you could previously leave unanswered is now a disclosure. A recipient reading "before build" learns the document records what your build system intended to include.

CISA's validation guidance goes further, telling organizations seeking to confirm the accuracy and completeness of SBOM data that they may use binary analysis tools to detect components not listed in the SBOM. Our CRA SBOM and technical documentation guide covers the filing mechanics.

Key Takeaways and Where to Start

• Five regimes, one artifact. CRA, 524B, NIS2, federal procurement, and R155 all resolve to a component inventory you can defend. Depth, recipient, and clock differ.
• The CRA floor is top-level dependencies. The 2026 CISA baseline is every component, transitive included, with no minimum depth.
• The federal attestation mandate is gone, the work is not. M-26-05 moved it into per-agency contract terms.
• Ten new SBOM fields since July 29, 2026. An SBOM built to the 2021 elements has no hashes, licenses, signature, or generation context.
• The CRA has not specified SBOM fields. Article 13(24) allows it, nothing has been adopted, so buyer expectations set the bar.

One first move. Open the SBOM you would file today and check for a component hash, a license identifier, and a generation context. If generation context would read "before build," you have documented your intent rather than your product.

Three questions worth putting to your team this month:

1. Which SKUs could produce a complete component inventory, transitive dependencies included, inside a week?
2. When a customer sends NIS2 flow-down clauses, who answers them, and against what evidence?
3. If an agency made a current SBOM a contract term tomorrow, what would we send?

We build that inventory from the shipped firmware image rather than the build manifest, no source code required, and export SPDX and CycloneDX with the 2026 fields populated. To see it against your own device, request a walkthrough.

FAQ

What is software supply chain compliance?

Software supply chain compliance is meeting the legal and contractual obligations attached to third-party and open-source code inside a product. In practice: document components in a machine-readable inventory, exercise due diligence over what you integrate, handle vulnerabilities in those components on a defined clock, and retain the evidence for an authority to inspect.

Which regulations require software supply chain security?

For connected-product manufacturers: the EU Cyber Resilience Act, FDA Section 524B for cyber devices, NIS2 through customer contracts, UNECE R155 for vehicle type approval, and US federal procurement terms, which vary by agency since OMB M-26-05. The CRA and 524B gate market access directly. The others reach you as a supplier.

Is an SBOM legally required?

Yes, in two places. CRA Annex I Part II(1) requires one for products with digital elements sold in the EU, and FDA 524B(b)(3) requires one in premarket submissions for cyber devices. US federal civilian procurement no longer mandates one government-wide, though individual agencies may require it by contract.

How do SBOMs support software supply chain compliance?

An SBOM is the evidence base every other obligation runs on. You cannot exercise due diligence over components you never enumerated, answer a 24-hour reporting clock without knowing which products contain the affected component, or demonstrate vulnerability handling to an assessor without showing what you were handling.

Do the CISA 2026 SBOM minimum elements apply to us?

Not as law. CISA states the minimum elements create no new requirements and instead refine how organizations generate and request SBOMs. Their force is commercial. Buyers and frameworks that pointed at the 2021 NTIA baseline are migrating to this one, and procurement questionnaires follow.

Does the CRA specify what fields an SBOM must contain?

Not yet. Annex I Part II(1) requires a machine-readable format covering at least top-level dependencies and says nothing about fields. Article 13(24) empowers the Commission to specify format and elements by implementing act. Until one is adopted, CISA's elements and BSI TR-03183-2 are the practical reference.