Hardware Security Needs Its Own SBOM Moment

For years, software security had a fairly simple blind spot. Organisations knew which applications they depended on, but they didn’t necessarily know what was inside them. An application could contain hundreds of third-party libraries and dependencies, each carrying its own vulnerabilities, licensing issues and supply-chain risks. 

Software Bills of Materials (SBOMs) grew partly from the need to change that. They didn’t make software trustworthy on their own. What they did was make composition visible. Once you can identify what a system contains, you have a much better chance of asking useful questions about where those components came from and whether you still trust them. 

Hardware hasn’t quite reached the same point. An organisation might know it bought a particular server, accelerator, network appliance or storage device. But that finished product can contain processors, memory, firmware, intellectual property and other components that have passed through several organisations before reaching the data centre. 

The brand on the box only tells part of the story. That gap is becoming harder to ignore. On 1 September 2026, the US National Institute of Standards and Technology (NIST) published IR 8615, calling for more coordinated, evidence-based hardware security across the semiconductor lifecycle. 

Its priorities include provenance, traceability, component verification, attestation and stronger procurement requirements. Hardware may be approaching its own SBOM moment. But simply giving hardware another bill of materials won’t be enough. 

The bigger challenge is working out how organisations can move from trusting hardware because a supplier says they can, to having evidence that explains why that trust is justified.

Software Changed What We Expect From Supply Chain Security

The biggest contribution SBOMs made to software security wasn’t the creation of another inventory format. It was the expectation behind them. Organisations increasingly expect to be able to identify the components inside software, connect them to known risks and ask suppliers for information that would once have remained largely invisible. 

That shift is still unfinished. The European Union Agency for Cybersecurity’s SBOM Adoption State of Play 2026 found organisations broadly investing in SBOM generation and automation, driven partly by requirements under the EU Cyber Resilience Act. But adoption and mature implementation aren’t the same thing. 

Software has already shown why that distinction is important. A component list has limited value if it’s incomplete, outdated or difficult to use when a vulnerability appears. Supply chain transparency only becomes useful when the information is accurate enough to support decisions. That gives hardware security a useful lesson to start from. 

The goal isn’t simply to reproduce the SBOM model in another format. It’s to create enough visibility into hardware composition that organisations can begin asking better questions about the products beneath their critical systems. And those products themselves are becoming more complicated.

Hardware Is Becoming Harder To Treat As A Single Trusted Product

A server looks like one thing once it arrives in a rack. The supply chain behind it looks very different. The Organisation for Economic Co-operation and Development (OECD) describes the semiconductor supply chain as highly complex, globally distributed and tightly interconnected. 

Its 2025 mapping found that semiconductor trade dependencies more than doubled between 2012-14 and 2020-22, while different stages and important inputs remain concentrated across particular regions and suppliers. At the same time, the architecture inside advanced hardware is changing. 

Chiplets allow different functions that might once have been built into a more monolithic chip to exist as separate dies inside the same package. Those chiplets can potentially come from different vendors and use different manufacturing processes. The Universal Chiplet Interconnect Express (UCIe) standard is being built specifically to support this kind of interoperable ecosystem. 

Its specifications are designed to let manufacturers mix and match chiplet components across multiple vendors, with later versions adding lifecycle management, testing and telemetry across multi-chiplet systems. That flexibility is useful. It can support more specialised processors, faster development and the high-performance hardware needed for AI and other demanding workloads. 

But it also changes the unit of trust. If one finished product contains components from several suppliers, built and integrated through different stages of the semiconductor ecosystem, asking whether you trust the manufacturer becomes a much bigger question than it first appears. Hardware provenance starts to become part of the answer.

An HBOM Can Tell You What Is Inside

A Hardware Bill of Materials (HBOM) is a structured record of the hardware components contained within a product. Depending on the level of detail available, it can include information about components, suppliers, manufacturers and parts of the manufacturing or assembly process. This isn’t a hypothetical idea waiting for the industry to invent it. 

The US Cybersecurity and Infrastructure Security Agency (CISA) published its Hardware Bill of Materials Framework for Supply Chain Risk Management in 2023. The framework is designed to give suppliers and purchasers a more consistent way to exchange hardware-component information so buyers can assess security, compliance and availability risks. 

That gives an HBOM a fairly obvious enterprise role. If a vulnerability, supplier issue or geopolitical disruption affects a particular component, knowing whether that component exists inside your hardware is considerably more useful than simply knowing which finished products you bought. The wider BOM ecosystem is also moving beyond software. 

Standards such as CycloneDX already support different types of component and supply-chain information rather than treating the software bill of materials as the final boundary of the idea. But there’s a limit to what any inventory can tell you. Knowing what should be inside a device isn’t the same as proving what is actually there. 

Nor does a list tell you whether a component is authentic, whether its firmware has changed or whether the device is still operating in the state you originally trusted. That’s where the SBOM analogy starts to run out.

But Hardware Assurance Needs More Than A Component List

It helps to think about hardware assurance as a chain rather than a document: Composition → Provenance → Identity → Attestation → Lifecycle assurance. Composition is the starting point. It tells you which important components should be present. 

An HBOM can provide much of that visibility, particularly when suppliers use consistent formats and provide enough detail for purchasers to understand what they’re buying. Provenance goes further. It asks where those components came from and what happened to them before they reached you. 

That can include the organisations involved in design, manufacturing, assembly, testing and integration. NIST IR 8615 specifically identifies provenance and traceability across the semiconductor lifecycle as areas where stronger standards are needed. Then there’s identity. 

If an organisation is going to rely on information about a particular component, it needs a reliable way to establish that the physical component it received is the one the evidence describes. Cryptographic identities and hardware roots of trust can help create that link. Hardware attestation takes the question into the device itself. 

Rather than relying only on a record of what was supplied, attestation allows a system to provide cryptographic evidence about its identity, software or firmware state and other security-relevant measurements. The final stage is lifecycle assurance. Trust established when equipment leaves a factory can’t simply be frozen there forever. 

Firmware changes. Vulnerabilities appear. Components move between environments. Ownership changes. Eventually, hardware is retired. The useful question therefore becomes less about whether an HBOM exists and more about whether organisations can maintain enough evidence to keep making informed trust decisions as the hardware changes.

Hardware Trust Doesn't End When The Device Arrives

Hardware has a physical form, which can make it feel more permanent than software. But much of the security behaviour of modern equipment depends on firmware and other code that can change long after the product has been manufactured. 

Processors, accelerators, storage devices, network hardware and other components may all receive firmware or configuration updates during their working lives. A device that passed every procurement check on day one can therefore become something slightly different over time. 

This is where firmware security and hardware-rooted attestation start to connect the supply chain with day-to-day operations. The Open Compute Project’s Caliptra initiative provides one example of where this is heading. Caliptra is an open root-of-trust architecture aimed at data-centre system-on-chip devices such as CPUs, GPUs, DPUs and TPUs. 

Its design uses hardware-rooted measurements to support integrity checks around configuration and mutable code. The idea isn’t that every enterprise needs to understand the inner workings of Caliptra. The broader point is more useful. 

Device integrity can increasingly be supported by evidence generated from the hardware itself, rather than relying only on paperwork created earlier in the supply chain. That changes what ongoing assurance can look like. 

Hardware security becomes less like checking a product once before approving the purchase and more like maintaining a chain of confidence through deployment, updates, operational changes and eventual retirement. It also means procurement decisions have consequences long after procurement teams have finished making them.

Procurement Is Becoming Part Of The Security Control

Security teams can monitor and verify a great deal once technology enters the enterprise. What they can’t easily do is recreate supply-chain evidence that never existed in the first place. If a supplier can’t identify critical components, provide useful provenance information or support appropriate verification, the customer may have very little technical leverage to manufacture that transparency later. 

NIST’s latest secure-hardware work treats procurement as part of the answer. IR 8615 calls for stronger economic incentives, including procurement requirements that encourage verifiable components and more secure, provenance-enabled semiconductor ecosystems. CISA’s HBOM framework was also designed with purchasers in mind. 

It recommends HBOMs as one of several tools organisations can use when evaluating hardware supply-chain risk, while acknowledging that interoperability and wider industry maturity still need work. This starts to bring hardware supply chain security out of the semiconductor factory and into enterprise governance. 

CISOs, infrastructure leaders, architects and procurement teams don’t need to become chip designers. They do need a shared understanding of what evidence they expect suppliers to provide for critical hardware, and how much assurance is proportionate to the role that equipment plays. 

A commodity peripheral and a processor running sensitive workloads don’t necessarily justify the same level of scrutiny. The consequence of getting the trust decision wrong should help determine how deep the evidence needs to go.

What Should Enterprises Expect From Hardware Assurance?

There isn’t yet one universal hardware-assurance model that every organisation can simply adopt. The standards work is still developing, and different environments will have different risk thresholds. But the evidence emerging around HBOMs, provenance and attestation gives enterprise teams a useful way to structure the conversation. 

For critical hardware, five questions can help expose where trust is still based largely on assumption:

• Composition: Can we establish which important components the product actually contains?
• Provenance: Can suppliers provide meaningful evidence about where those components came from?
• Identity: Can critical devices or components be authenticated and connected to the evidence provided about them?
• State: Can the integrity of important firmware, configuration or device state be verified after deployment?
• Lifecycle: Can that evidence remain useful as hardware changes, vulnerabilities emerge and the device eventually leaves service?

These aren’t five different security projects. They describe different layers of the same trust problem. An HBOM without provenance may tell you what something is called without telling you enough about where it came from. Provenance without reliable identity can leave uncertainty about whether the evidence applies to the component in front of you.

Identity without attestation says little about whether its state has changed. Looked at together, the questions give enterprises a more practical way to assess component traceability and assurance without waiting for the entire hardware standards ecosystem to settle first. 

They also reveal where the real SBOM lesson sits. Visibility is useful, but only when organisations can turn it into a better decision.

Final Thoughts: Hardware Trust Is Becoming Something Enterprises Need To Prove

SBOMs helped change the way software security thinks about trust. They made it increasingly difficult to accept an application as one opaque object when so much of its security depended on the components hidden inside it. Hardware is moving towards a similar challenge. 

Chiplets, specialised processors and globally distributed semiconductor supply chains are making advanced hardware more composable at the same time that enterprises are becoming more dependent on it. NIST’s September 2026 work suggests standards bodies are now looking much more seriously at how provenance, verification and continuous assurance can keep pace. 

A hardware bill of materials can be an important part of that shift. It gives organisations something they often don’t have today: a clearer view of what exists inside the technology they’ve bought. But the real destination is larger. 

Enterprises increasingly need to know not only what their critical hardware contains, but why they should trust those components, whether the evidence still applies after deployment and what happens when that trust changes. Software’s SBOM moment was ultimately about making hidden dependencies visible enough to interrogate. 

Hardware’s version may be about making trust itself more visible. As semiconductor standards and enterprise infrastructure continue to evolve, EM360Tech will keep following how that shift moves from emerging assurance models into the practical decisions security, architecture and procurement teams make every day.