Identity

This section introduces the concept of workload identity and explains how it is implemented within the Nitride Platform.

Workload Identity in Confidential Computing

In confidential computing, a workload identity is a cryptographically verifiable representation of a running software component. It allows the workload to prove its integrity, origin, and runtime environment to external parties. This is essential for building trust in zero-trust architectures, especially when executing sensitive workloads in untrusted cloud environments.

In Nitride the workload identity is constructed from four foundational components: platform, firmware, workload, and metadata. Together, these elements form the Trusted Computing Base (TCB), enabling a comprehensive and verifiable trust model for enclave-based workloads.

Platform

The platform forms the hardware root of trust. It includes the platform security processor (such as AMD SEV or Intel TDX) and its Trusted Computing Base (e.g. the security processor OS), along with a certificate chain rooted in the hardware vendor. This allows external verifiers to authenticate the physical origin and security properties of the underlying compute infrastructure.

For example, in an AMD SEV-based system, the platform identity is anchored in the AMD Endorsement Key and associated certificates.

Firmware

The firmware establishes the first software root of trust by measuring the early boot process. This typically includes Unified Extensible Firmware Interface (UEFI) components such as ovmf.efi and ovmf.vars. These measurements are securely captured by the platform security processor or a vTPM-equivalent, ensuring that the system’s firmware has not been tampered with before launching the enclave. In Enclaive’s architecture, this creates a verifiable chain from hardware to software.

Workload

The workload itself is composed of the guest operating system and the application code running inside the enclave. Enclaive performs cryptographic measurements of these components during launch, extending the TCB with workload-specific fingerprints. For instance, a minimal guest Linux OS and a containerized web service can be measured by hashing their binaries and configuration. This ensures that only expected, pre-approved workloads are permitted to run and be attested.

Metadata

The final component, metadata, adds contextual signals from the cloud service provider. This information is typically retrieved via a metadata API, such as AWS Instance Metadata Service (IMDS) or Azure’s equivalent. Metadata may include details like the instance type, geographic region, tenant ID, or custom tags. Although not part of the enclave itself, this cloud-provided data enriches the workload identity by enabling policy checks based on deployment context—for example, ensuring that a workload runs only in a specific jurisdiction or under a trusted project ID.

By combining these four components—platform, firmware, workload, and metadata—Nitride constructs a rich, layered workload identity. This identity is cryptographically attestable and can be presented to external systems for verification. It enables fine-grained access control, automated policy enforcement, and secure integration in multi-cloud or hybrid environments. Through this approach, Enclaive helps organizations achieve high assurance for sensitive workloads without sacrificing the flexibility and scalability of modern cloud computing.