Supply Chain Integrity, Transparency, and Trust Working Group N. Aoki Internet-Draft The Graduate University for Advanced Studies (SOKENDAI) Intended status: Informational 7 July 2026 Expires: 8 January 2027 Applying SCITT to Hardware, IoT Device, and Cloud Compute Resource Supply Chains draft-nobuo-scitt-hardware-iot-cloud-use-cases-00 Abstract This document describes how SCITT can be applied to supply chains that include hardware components, IoT devices, firmware, cloud compute resources, confidential-computing environments, accelerators, and related operational evidence. It gives use cases and scope guidance. It also explains how SCITT can work with RATS, COSE, TCG technologies, SBOM, HBOM, CBOM, and cloud attestation systems without replacing those technologies. This document is informational. It does not define hardware assurance rules, cloud assurance rules, device identity systems, manufacturing requirements, or payload formats. Its purpose is to show where SCITT statements and receipts can provide transparency for heterogeneous supply-chain evidence, and where other standards or domain profiles should remain responsible. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://aoki- n1.github.io/draft-nobuo-scitt-hardware-iot-cloud-use-cases/draft- nobuo-scitt-hardware-iot-cloud-use-cases.html. Status information for this document may be found at https://datatracker.ietf.org/doc/ draft-nobuo-scitt-hardware-iot-cloud-use-cases/. Discussion of this document takes place on the SCITT Working Group mailing list (mailto:scitt@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/scitt/. Subscribe at https://www.ietf.org/mailman/listinfo/scitt/. Source for this draft and an issue tracker can be found at https://github.com/aoki-n1/draft-nobuo-scitt-hardware-iot-cloud-use- cases. Aoki Expires 8 January 2027 [Page 1] Internet-Draft SCITT Hardware and Compute July 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Working Group Context . . . . . . . . . . . . . . . . . . . . 4 3. Scope Position . . . . . . . . . . . . . . . . . . . . . . . 4 4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 6. Relationship to Existing Work . . . . . . . . . . . . . . . . 6 6.1. SCITT . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. RATS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.3. TCG, TPM, DICE, and Hardware Roots of Trust . . . . . . . 7 6.4. SBOM, HBOM, CBOM, and VEX . . . . . . . . . . . . . . . . 7 7. Use Case 1: Device-to-Cloud Firmware Provenance . . . . . . . 7 8. Use Case 2: Extending Provenance from Firmware to Hardware . 8 9. How SCITT Can Represent a Lifecycle Graph . . . . . . . . . . 8 10. Use Case 3: Device Lifecycle Evidence Graph . . . . . . . . . 9 11. Use Case 4: Cloud Compute Resource Integrity . . . . . . . . 10 Aoki Expires 8 January 2027 [Page 2] Internet-Draft SCITT Hardware and Compute July 2026 12. Use Case 5: Device Repair, Transfer, and End of Life . . . . 10 13. Scope Questions . . . . . . . . . . . . . . . . . . . . . . . 11 14. Common Evidence Types . . . . . . . . . . . . . . . . . . . . 12 15. Scope Boundary Examples . . . . . . . . . . . . . . . . . . . 12 16. Possible Future Work . . . . . . . . . . . . . . . . . . . . 13 17. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 18. Security Considerations . . . . . . . . . . . . . . . . . . . 14 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 20.1. Normative References . . . . . . . . . . . . . . . . . . 15 20.2. Informative References . . . . . . . . . . . . . . . . . 15 Open Questions . . . . . . . . . . . . . . . . . . . . . . . . . 16 Design Notes for Future Revisions . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 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. Aoki Expires 8 January 2027 [Page 3] Internet-Draft SCITT Hardware and Compute July 2026 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. Aoki Expires 8 January 2027 [Page 4] Internet-Draft SCITT Hardware and Compute July 2026 * 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. Aoki Expires 8 January 2027 [Page 5] Internet-Draft SCITT Hardware and Compute July 2026 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 6.1. SCITT SCITT provides the transparency and accountability layer for signed statements. In the use cases in this document, SCITT registers and verifies statements about hardware, firmware, device identity, cloud resources, and runtime evidence. SCITT does not need to understand each payload. A hardware statement can use an HBOM payload. A firmware statement can use an SBOM payload. A runtime statement can use a RATS Attestation Result. SCITT can provide registration and receipt verification around those payloads. 6.2. RATS RATS defines roles such as Attester, Verifier, and Relying Party. It defines a model for producing and evaluating evidence about a computing environment. SCITT can be used after or around that process. For example, a RATS Verifier can issue an Attestation Result and register it as a SCITT statement. A relying party can later verify that the result was signed and registered. SCITT should not define the meaning of the attested measurements. That remains with RATS profiles, platform profiles, and verifier policy. Aoki Expires 8 January 2027 [Page 6] Internet-Draft SCITT Hardware and Compute July 2026 6.3. TCG, TPM, DICE, and Hardware Roots of Trust Hardware roots of trust can provide device identity and measurements. These technologies can help create statements about device identity, boot state, firmware state, and platform configuration. SCITT can make those statements transparent. It does not replace the hardware root of trust or the protocol that produces evidence. TODO: Add exact references for TPM, DICE, CoRIM, and other relevant TCG work. 6.4. SBOM, HBOM, CBOM, and VEX BOM formats describe components, dependencies, vulnerabilities, or hardware composition. These formats are payloads from the SCITT point of view. SCITT can register statements carrying or referring to these payloads, but SCITT does not need to define the payload formats. TODO: Add references and examples for SPDX, CycloneDX, HBOM, CBOM, and VEX once the draft chooses the examples to include. 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. Aoki Expires 8 January 2027 [Page 7] Internet-Draft SCITT Hardware and Compute July 2026 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. Aoki Expires 8 January 2027 [Page 8] Internet-Draft SCITT Hardware and Compute July 2026 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. Aoki Expires 8 January 2027 [Page 9] Internet-Draft SCITT Hardware and Compute July 2026 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. Aoki Expires 8 January 2027 [Page 10] Internet-Draft SCITT Hardware and Compute July 2026 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? Aoki Expires 8 January 2027 [Page 11] Internet-Draft SCITT Hardware and Compute July 2026 *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. Aoki Expires 8 January 2027 [Page 12] Internet-Draft SCITT Hardware and Compute July 2026 +================+==========================+====================+ | Topic | SCITT role | Other responsible | | | | work | +================+==========================+====================+ | Firmware SBOM | register and receipt a | SBOM format and | | | signed statement | tooling | +----------------+--------------------------+--------------------+ | HBOM | register and receipt a | HBOM format and | | | signed statement | hardware domain | +----------------+--------------------------+--------------------+ | TPM quote | carry or refer to an | TCG, RATS, | | | attestation result | platform profile | +----------------+--------------------------+--------------------+ | Cloud region | register and link the | cloud provider and | | claim | signed claim | policy profile | +----------------+--------------------------+--------------------+ | Device | register statements and | manufacturer, TCG, | | identity | link evidence | device profile | +----------------+--------------------------+--------------------+ | False hardware | preserve signed evidence | issuer governance | | claim | and audit trail | and legal process | +----------------+--------------------------+--------------------+ | Composite | provide evidence and | relying-party | | decision | result structure | policy | +----------------+--------------------------+--------------------+ Table 1 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. Aoki Expires 8 January 2027 [Page 13] Internet-Draft SCITT Hardware and Compute July 2026 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. Aoki Expires 8 January 2027 [Page 14] Internet-Draft SCITT Hardware and Compute July 2026 19. IANA Considerations This document has no IANA actions. 20. References 20.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . 20.2. Informative References [I-D.ietf-scitt-receipts-ccf-profile] "CCF Profile for COSE Receipts", n.d., . [I-D.ietf-scitt-scrapi] "Supply Chain Integrity, Transparency, and Trust (SCITT) Reference APIs", n.d., . [I-D.nobuo-scitt-composite-evidence-verification] "Composite Evidence Verification for SCITT Statement Graphs", n.d., . [I-D.nobuo-scitt-protected-object-binding] "SCITT Statement Relationship and Protected Object Binding", n.d., . Aoki Expires 8 January 2027 [Page 15] Internet-Draft SCITT Hardware and Compute July 2026 [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9335] Uberti, J., Jennings, C., and S. Murillo, "Completely Encrypting RTP Header Extensions and Contributing Sources", RFC 9335, DOI 10.17487/RFC9335, January 2023, . [RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, . [TODO-OCP-SAFE] "TODO - OCP S.A.F.E. Program", n.d., . [TODO-SBOM-HBOM-CBOM] "TODO - Add SBOM, HBOM, CBOM, VEX, SPDX, and CycloneDX references as appropriate", n.d., . [TODO-TCG] "TODO - Add Trusted Computing Group references such as TPM, DICE, CoRIM, and related profiles", n.d., . 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? Aoki Expires 8 January 2027 [Page 16] Internet-Draft SCITT Hardware and Compute July 2026 * 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 Nobuo Aoki The Graduate University for Advanced Studies (SOKENDAI) Japan Email: n_aoki@ieee.org Aoki Expires 8 January 2027 [Page 17]