Applying SCITT to Hardware, IoT Device, and Cloud Compute Resource Supply Chains

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 8 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

SCITT [RFC9943] provides building blocks for registering signed supply-chain statements in Transparency Services and for verifying those statements later. Although SCITT started from software supply-chain problems, real computing systems often contain software, firmware, hardware, identity, deployment, and runtime evidence together.¶

An IoT device is not only a software package. It is a physical device with hardware components, firmware, bootloaders, operating system images, application containers, device identities, update policies, and operational state. A cloud compute resource is also not only a software image. It can include a VM image, hardware root of trust, confidential-computing environment, accelerator allocation, cloud-region policy, runtime attestation result, and operator authorization.¶

SCITT can help by making statements about these objects transparent and verifiable. SCITT does not need to define the internal format of every evidence type. It can register statements from manufacturers, software suppliers, cloud providers, auditors, device operators, and verifiers. A relying party can later verify receipts and evaluate the evidence under its own policy.¶

This document collects use cases and explains how to keep this work within a clear scope. It is intended to support future discussion of two possible building blocks:¶

• object binding and statement relationships; and¶

• composite verification over statement graphs.¶

2. Working Group Context

Recent SCITT discussions show both interest and caution for hardware and graph use cases. The OCP case study showed that software and firmware provenance can be expressed with SCITT and that similar questions arise for hardware components, HBOM data, device identity, end-of-life state, and circular-economy evidence.¶

The same discussion also made the scope question clear. Hardware supply-chain assurance can be outside the present charter if the WG tries to define hardware rules. However, hardware-related statements can still be carried as SCITT statements when another profile or venue defines their payload meaning and trust policy.¶

The IETF 122 discussion is also relevant. It noted that several organizations can make statements about the same subject, and that SCITT can link things by subjects and statements even though this is not inherent in the basic common layer. It also raised the value of statements about statements and reliable locators.¶

This document uses those points as design guidance. It does not ask SCITT to become a hardware standards body. It uses hardware, IoT, and cloud cases to show where a generic statement and graph layer may be useful.¶

3. Scope Position

This document is careful about the SCITT scope. Hardware supply-chain details can be outside the current charter if the WG tries to standardize them as a hardware assurance system. At the same time, statements about hardware can be registered and verified as SCITT statements when the payload format and trust policy are defined elsewhere.¶

Therefore, this document does not propose that SCITT define hardware assurance. It proposes that SCITT can provide transparency for signed statements about hardware, firmware, devices, and cloud resources, in the same way that SCITT can provide transparency for signed statements about software.¶

The important boundary is this:¶

• SCITT can say that a statement was signed, registered, and linked to other statements.¶

• Domain profiles decide what the statement means and who is allowed to make it.¶

• A relying party decides whether the evidence is enough for its decision.¶

4. Non-Goals

This document does not:¶

• define how to design secure IoT hardware;¶

• define manufacturing assurance requirements;¶

• define HBOM, CBOM, SBOM, VEX, attestation evidence, or cloud configuration schemas;¶

• define how a verifier decides whether an attested measurement is acceptable;¶

• define a universal hardware or cloud-resource registry;¶

• define a global device identity infrastructure;¶

• prevent authenticated issuers from making false claims;¶

• replace RATS, TCG, TPM, DICE, EAT, CoRIM, cloud-provider attestation, or existing BOM formats; or¶

• define procurement or compliance best practices.¶

5. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses the terms defined in SCITT [RFC9943] and RATS [RFC9334].¶

Hardware Component:

A physical component such as a chip, sensor, board, secure element, module, accelerator, or peripheral.¶

Device Instance:

A specific physical device, such as an IoT gateway, sensor, controller, or embedded system.¶

Device Class:

A product model, configuration, or type shared by several Device Instances.¶

Cloud Compute Resource:

A cloud-provisioned resource such as a virtual machine, container worker, managed node, GPU allocation, accelerator resource, or serverless execution context.¶

Confidential-Computing Environment:

A trusted execution environment, confidential VM, enclave, or similar execution environment that can produce attestation evidence or results.¶

Lifecycle Evidence:

Statements that describe a protected object during design, manufacturing, provisioning, deployment, operation, update, audit, repair, transfer, retirement, or decommissioning.¶

Device Lifecycle Evidence Graph:

A statement graph that connects lifecycle evidence for a Device Instance or Device Class.¶

TODO: Align these terms with TCG, RATS, cloud-provider, OCP, and existing IETF terminology.¶

6. Relationship to Existing Work

7. Use Case 1: Device-to-Cloud Firmware Provenance

A device manufacturer produces a device with firmware and identity material. A component or platform vendor produces an SBOM for firmware. An audit report is recorded. A metadata service or signing service produces a signed certificate or statement. A final device or data center operator can verify receipts and check that the expected evidence exists.¶

SCITT can help by registering statements for:¶

• device identity created during manufacturing;¶

• firmware SBOMs from component or platform vendors;¶

• firmware signing and release statements;¶

• audit reports;¶

• update authorization statements;¶

• attestation results from devices or verifiers; and¶

• receipts showing that these statements were registered.¶

This use case is close to firmware and software supply-chain transparency. It also shows why hardware identifiers and device identity may appear in SCITT statements.¶

8. Use Case 2: Extending Provenance from Firmware to Hardware

Hardware supply-chain provenance can include hardware identifiers, component source, device identity, identity management, end-of-life state, repair state, and circular economy information. A hardware bill of materials can describe the hardware composition of a device, while firmware and software statements describe the software that runs on it.¶

SCITT can register statements that refer to HBOM or hardware provenance data. It should not define the HBOM format itself.¶

Example statements include:¶

• a manufacturer statement for a device class;¶

• a component supplier statement for a hardware component;¶

• a device identity statement for a device instance;¶

• an auditor statement about a manufacturing or assembly step;¶

• a repair statement;¶

• an end-of-life or transfer statement; and¶

• a statement that links a device instance to firmware and software evidence.¶

The value of SCITT here is not that it knows whether a hardware claim is true. The value is that the claim is signed, registered, and can be linked to other claims and receipts.¶

9. How SCITT Can Represent a Lifecycle Graph

A lifecycle graph can be represented without changing the basic SCITT registration model.¶

One possible pattern is:¶

1. Each evidence item is a SCITT Signed Statement.¶

2. Each statement is registered with a Transparency Service and receives a receipt.¶

3. A relationship statement or graph manifest links the statements.¶

4. The graph manifest can itself be registered as a SCITT Signed Statement.¶

5. A verifier checks statements, receipts, and graph edges under its policy.¶

This pattern lets different parties issue their own statements. A component supplier can issue a component statement. A manufacturer can issue a device identity statement. A software supplier can issue an SBOM statement. A RATS Verifier can issue an attestation result. An auditor can issue an audit statement.¶

The graph can be discovered in different ways. A deployment can use locators in statements, a graph manifest, a subject-based index, or an auxiliary service. The SCITT Reference API does not need to become a full graph API for this use case.¶

TODO: Decide which discovery pattern should be described as the main example and which should remain non-normative.¶

10. Use Case 3: Device Lifecycle Evidence Graph

An IoT device can be described by evidence over time. A Device Lifecycle Evidence Graph can connect those statements.¶

Device Instance
 ├─ manufacturedFrom  -> Hardware Component Statement
 ├─ provisionedWith   -> Device Identity Statement
 ├─ runsFirmware      -> Firmware SBOM or Firmware Signature Statement
 ├─ updatedBy         -> Firmware/software Update Authorization Statement
 ├─ measuredBy        -> RATS Attestation Result
 ├─ affectedBy        -> Vulnerability Status Statement
 ├─ mitigatedBy       -> Patch, Rollback, or Configuration Statement
 ├─ repairedBy        -> Repair Statement
 └─ decommissionedBy  -> End-of-Life Statement

The graph does not need a single monolithic payload. Each statement can be issued by the party that is responsible for it. A composite verifier can later check whether the graph has the evidence required by a policy.¶

This graph is not meant to be stored as one large payload. It can be built from separate statements and relationship statements. Earlier SCITT discussion raised the same idea through "statements about statements" and through reliable locators that can be used as pointers. The graph model in this document follows that direction.¶

11. Use Case 4: Cloud Compute Resource Integrity

A cloud compute resource can involve several layers:¶

• cloud image or container image;¶

• host hardware platform;¶

• hypervisor or node software;¶

• confidential-computing environment;¶

• GPU or accelerator allocation;¶

• region or data residency constraint;¶

• tenant identity;¶

• deployment authorization; and¶

• runtime attestation result.¶

SCITT can register statements about these layers. For example, a cloud provider can issue a statement about a VM image and its host platform. A verifier can issue an attestation result. A tenant or deployment controller can issue an authorization statement for a workload. An auditor can issue an audit result.¶

A composite verification profile can then check whether:¶

• the workload image matches the authorized digest;¶

• the runtime attestation result is recent;¶

• the confidential-computing environment is acceptable;¶

• the resource is in an allowed region;¶

• the accelerator firmware is covered by an accepted statement; and¶

• no statement revokes or conflicts with the evidence set.¶

12. Use Case 5: Device Repair, Transfer, and End of Life

Devices can change hands, be repaired, or be retired. These events matter for supply-chain trust, especially for industrial IoT and enterprise hardware. These definitions are useful for meeting the industry's need for maintenance on a 10-year basis.¶

SCITT can register statements for:¶

• repair events;¶

• replacement of a hardware component;¶

• re-provisioning of identity material;¶

• transfer of device ownership;¶

• end-of-support status;¶

• end-of-life status; and¶

• secure disposal or recycling status.¶

This document does not define the operational policy for these events. It only shows that they can be represented as lifecycle statements and linked into a graph.¶

13. Scope Questions

Question: Does this document ask SCITT to publish hardware assurance rules?¶

Answer: No. It describes how SCITT statements and receipts can be used for hardware-related evidence. Hardware assurance rules, HBOM formats, and device identity policy should be defined elsewhere.¶

Question: If hardware supply chain is out of scope, why discuss hardware at all?¶

Answer: Because SCITT statements can carry or refer to hardware-related payloads. The useful SCITT question is not "how should hardware be built?" The useful SCITT question is "how can a signed hardware-related statement be registered, linked, and verified with other statements?"¶

Question: Should graph relationships be put in the payload or header?¶

Answer: This document does not decide that. It lists possible placements: payloads, protected metadata if later defined, graph manifest statements, or auxiliary services. A profile must say which placement is authoritative.¶

Question: Does a device lifecycle graph prove that the device is safe?¶

Answer: No. It helps a relying party see which statements exist and how they relate. The relying party still applies its own policy.¶

14. Common Evidence Types

The following evidence types appear across the use cases:¶

• manufacturing statement;¶

• component provenance statement;¶

• device identity statement;¶

• firmware SBOM statement;¶

• hardware BOM statement;¶

• cloud image statement;¶

• deployment authorization statement;¶

• update authorization statement;¶

• RATS Attestation Result statement;¶

• vulnerability status statement;¶

• audit result statement;¶

• repair statement;¶

• transfer statement; and¶

• decommissioning statement.¶

TODO: Decide which evidence types should be examples only and which should be registered in a future object-binding or relationship vocabulary document.¶

15. Scope Boundary Examples

The following table gives examples of what belongs in SCITT and what should stay outside SCITT.¶

16. Possible Future Work

This document motivates two possible follow-on drafts.¶

First, a Protected Object Binding draft can define how a statement refers to a software, firmware, hardware, device, or cloud object. It can also define a small relationship vocabulary.¶

Second, a Composite Evidence Verification draft can define how a verifier asks for a graph-level decision and how the verifier reports missing, stale, or conflicting evidence.¶

Both follow-on drafts should keep payload definitions out of scope unless a separate charter or venue says otherwise.¶

17. Privacy Considerations

Hardware and cloud evidence can reveal sensitive information. Device identifiers can identify customers. Graph edges can reveal suppliers, cloud regions, tenants, repair history, or operational dependencies.¶

Deployments should avoid placing directly identifying information in public logs. They can use pseudonymous identifiers, salted commitments, encrypted payloads, access control, or selective disclosure. The chosen method should still allow the intended verifier to check the required evidence.¶

18. Security Considerations

The main risk is over-reading SCITT evidence. A valid receipt does not prove that a hardware claim is true. It proves that a signed statement was registered and that the receipt verifies under the relevant profile.¶

Relying parties must still decide:¶

• which issuers are trusted for each statement type;¶

• which statements are required;¶

• how fresh each statement must be;¶

• how conflicts are handled;¶

• how revocation or supersession is handled; and¶

• whether a domain-specific payload is acceptable.¶

Other risks include:¶

• linking the wrong device instance to a statement;¶

• treating a device class statement as a device instance statement;¶

• accepting old attestation results;¶

• accepting a hardware statement from an unauthorized issuer;¶

• exposing sensitive graph data; and¶

• assuming that SCITT replaces RATS or hardware root-of-trust mechanisms.¶

19. IANA Considerations

This document has no IANA actions.¶

20. References

Open Questions

• Should SCITT define generic object binding, or should each domain profile define its own binding?¶

• Should relationship metadata live in payloads, protected headers, graph manifests, or auxiliary services?¶

• Should SCRAPI remain focused on registration and receipt retrieval while graph discovery is handled by later auxiliary services?¶

• Which use cases require WG action, and which should be handled by other WGs or standards bodies?¶

• How should this document describe hardware use cases if the current charter does not allow the WG to publish a hardware-specific standards-track item?¶

Design Notes for Future Revisions

This revision treats hardware and cloud compute as use cases for SCITT statements, not as a request for SCITT to define hardware or cloud assurance. That distinction is important for charter discussion.¶

This revision also adds the IETF 122 points on multi-party statements, statements about statements, reliable locators, and the limits of the basic common layer. These points support the Device Lifecycle Evidence Graph without requiring SCRAPI to become a graph API.¶

Acknowledgments

The author thanks the SCITT WG participants for discussion of OCP hardware assertions, generic APIs, graph building over opaque payloads, and the boundary between SCITT and domain-specific hardware or cloud profiles. The OCP case study helped identify the need to discuss hardware identifiers, device identity, HBOM provenance, end-of-life information, and circular-economy evidence without turning SCITT into a hardware assurance framework.¶

Author's Address