TL;DR: ENISA’s SBOM Adoption State of Play 2026 surveyed 334 organisations and found that 74% have at least partially automated SBOM generation, yet only 7% say they have closed the gap between creating SBOMs and actually using them for vulnerability and licence management, according to Aikido’s summary of the report. The real problem is not producing inventory, but operationalising it across suppliers, formats, and remediation workflows.
At a glance
What this is: This article argues that SBOM programmes are maturing in generation but stalling at consumption, with most organisations still unable to turn SBOM data into vulnerability and licence decisions.
Why it matters: For IAM, NHI, and broader security teams, the lesson is that evidence collection alone does not create governance unless it is wired into remediation, supplier assurance, and runtime decision-making.
By the numbers:
- ENISA’s SBOM Adoption State of Play 2026 surveyed 334 organisations, according to Aikido.
- 74% have at least partially automated SBOM generation, according to Aikido.
- Only 7% say they have closed the gap between generating SBOMs and using them, according to Aikido.
- 39% generate SBOMs at build time, according to Aikido.
Context
Software Bill of Materials adoption has moved past the question of whether organisations can produce inventory and into the harder question of whether anyone uses that inventory to make security decisions. In practice, SBOM governance fails when generation, supplier intake, vulnerability matching, and licence workflows remain separate.
That matters to practitioners because an SBOM is only useful when it becomes a control input, not a compliance artefact. The identity angle is indirect but real: supplier access, trusted third-party software, and build provenance all depend on knowing what is being consumed, by whom, and under what assurance model.
Key questions
Q: Why do SBOM programmes fail even when generation is automated?
A: Automation solves only the creation step. Programmes still fail when component data is incomplete, identifiers are inaccurate, or vulnerability matching is too noisy to trust. In that state, teams cannot confidently triage exposure, so the SBOM never becomes a usable input to remediation or procurement decisions.
Q: When should teams prioritise SBOM consumption over better generation coverage?
A: Once generation is reliable enough to support consistent release processes, the next gain usually comes from improving intake, normalisation, and workflow integration. A perfect SBOM that nobody uses adds less value than a slightly imperfect one that reliably reaches vulnerability management and procurement decisions.
Q: What are the signs that SBOM governance is not working well enough?
A: Common warning signs include missing dependencies, stale component inventories, release packages that do not match the recorded bill of materials, and no clear owner for updates when vulnerabilities are disclosed. If the SBOM cannot be trusted during an audit or incident, it is not functioning as a control.
Q: How should organisations handle supplier software when SBOMs are incomplete or absent?
A: Treat incomplete or missing SBOMs as an assurance gap, not a paperwork issue. Escalate supplier review, require usable machine-readable artefacts, and apply compensating controls such as tighter dependency monitoring and contract conditions until the supplier can provide evidence that your tools can actually consume.
Technical breakdown
Why SBOM generation does not equal SBOM governance
An SBOM is a structured inventory of software components, but inventory alone does not create control. Generation typically happens at build time or release time, while governance depends on downstream systems being able to ingest the SBOM, normalise component identifiers, match vulnerabilities, and route findings into remediation or legal review. When those steps are disconnected, teams accumulate files without creating decision velocity. The result is a documentation layer that satisfies procurement or audit questions while leaving operational risk unchanged.
Practical implication: Treat SBOM production as the start of a workflow, not the finish, and validate that each SBOM actually feeds vulnerability and licence decisions.
Why supplier SBOM intake breaks the control chain
Supplier-provided SBOMs are only useful if they are delivered consistently, in a common format, and with enough component depth to support matching. If suppliers omit SBOMs, send them rarely, or provide incomplete and proprietary representations, the consuming organisation inherits uncertainty instead of visibility. That is especially problematic for transitive dependencies, where the real exposure often sits below the first layer a buyer expects to inspect. In governance terms, third-party software becomes a trust boundary that is poorly evidenced and weakly machine-readable.
Practical implication: Require SBOM intake criteria in supplier assurance and reject artefacts that cannot be consumed by your vulnerability workflow.
How format and identifier quality shape usable SBOMs
SBOM value depends on component identity quality. Vulnerability matching fails when names, package URLs, CPEs, or version fields are incomplete or inconsistent, and licence analysis fails when the bill of materials lacks accurate component attribution. Format standardisation matters because machine-readable SBOMs only help when teams can compare like with like across suppliers and build systems. This is why format choice, identifier accuracy, and dependency depth are governance issues, not formatting preferences. Poor data quality turns supply chain transparency into a false sense of assurance.
Practical implication: Standardise on one consumable SBOM format and enforce minimum field quality before the artefact is admitted into security operations.
NHI Mgmt Group analysis
SBOM adoption is now a consumption problem, not a creation problem. The market has largely accepted that SBOMs should exist, but that does not mean they are being used to drive vulnerability or licence decisions. The governance failure is the gap between artefact production and operational action, which leaves security teams with inventory that does not change behaviour. Practitioners should measure SBOM maturity by whether it reduces decision latency, not by how many files are generated.
Third-party software visibility is an assurance problem, not just a procurement problem. If suppliers do not provide consumable SBOMs, buyers cannot reliably extend software assurance beyond their own build pipelines. That intersects with identity governance because trusted software is effectively a delegated trust relationship, and delegated trust without machine-readable evidence is brittle. The practitioner conclusion is to treat supplier SBOM requirements as part of third-party risk governance, not a narrow compliance add-on.
SBOM quality debt accumulates where formats, identifiers, and depth are inconsistent. Incomplete component records, weak identifier alignment, and shallow dependency coverage all reduce the utility of an SBOM long before anyone opens the file. This is the same pattern seen in other governance disciplines: evidence that cannot be operationalised creates overhead instead of control. The practical conclusion is that quality gates must sit on the intake path, not after an incident.
Software supply chain transparency needs the same discipline as identity governance. A control is only real when the data it depends on can be trusted, consumed, and acted upon repeatedly. That is why SBOMs should be tied to vulnerability management, licensing review, supplier assurance, and build provenance as a single control chain. The practitioner lesson is to design for closed-loop use, not for artefact collection.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
SBOM governance fails when evidence does not become enforcement. Teams should expect 2026 to expose a bigger gap between compliance artefacts and operational control, especially where supplier intake, vulnerability matching, and remediation ownership sit in different processes. That is a workflow problem, not a tooling problem.
Software supply chain transparency now depends on machine-readable trust signals. If a supplier cannot provide consumable SBOMs, buyers cannot reliably integrate those components into security operations. For practitioners, the issue is no longer whether SBOMs are available in principle, but whether they are actionable in practice.
Supplier exposure is now part of the control story: 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs. That underscores a broader governance point: third-party trust needs continuous evidence, not one-time assurance.
For practitioners
- Define SBOM intake criteria for suppliers Require a common machine-readable format, minimum dependency depth, and usable component identifiers before supplier artefacts enter your workflow.
- Wire SBOMs into vulnerability triage Ensure component matching, false-positive handling, and remediation ownership are connected so that SBOMs trigger action rather than archive growth.
- Set data-quality gates for SBOM ingestion Reject SBOMs that lack complete component names, versions, or identifiers needed for vulnerability and licence analysis.
- Add SBOM requirements to third-party assurance Make SBOM delivery, update cadence, and format compliance part of supplier security reviews and contract language.
Key takeaways
- SBOM adoption is advancing at the generation stage, but many organisations still cannot turn that inventory into vulnerability or licence decisions.
- The biggest gap is not whether SBOMs exist, but whether suppliers, formats, and workflows let security teams use them consistently.
- Practitioners need to measure SBOM success by closed-loop consumption, not by the volume of SBOM files produced.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Supplier SBOM gaps mirror third-party software trust problems and weak assurance boundaries. |
| NHI-02 — Secret Leakage | Poor SBOM visibility weakens how teams track exposed components and dependency risk in third-party code. | |
| Recommendation — Enforce supplier evidence requirements and reject third-party artefacts that cannot be consumed reliably. Map SBOM intake to exposure detection so vulnerable components are identified before release. | ||
| NIST CSF 2.0 | GV.SC-01 — Supply Chain Risk Management Processes | The article is fundamentally about governance of software supply chain evidence and supplier control. |
| Recommendation — Embed SBOM requirements into supply-chain risk processes and verify that suppliers meet them. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Supplier SBOM delivery is a service-provider assurance issue with direct operational impact. |
| Recommendation — Use service-provider management to require consumable SBOMs and track exceptions. | ||
| MITRE ATT&CK | TA0001;TA0006 — Initial Access; Credential Access | The article cites supply chain attack pressure that often begins with trusted component or dependency compromise. |
| Recommendation — Map supplier and dependency risk to initial access and credential access paths in threat detection. | ||
Key terms
- Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
- SBOM consumption: SBOM consumption is the process of using component inventory data to drive security and compliance decisions. It only has value when the information is linked to vulnerability management, procurement, release governance, and supplier assurance rather than archived as static evidence.
- Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
- Supplier assurance: Supplier assurance is the practice of verifying that a third party can support the security and compliance claims it makes. For identity systems, that means checking certification scope, control evidence, and operational responsibility before trusting the platform in production.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity controls to the wider security workflows that make governance operational.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org