Open Standards and Zero Trust on Commodity Hardware

Open standards like SPIFFE and SPIRE provide strong isolation guarantees, building a foundation for zero trust.

Confidential computing has long promised hardware-enforced workload isolation and zero trust execution environments. The idea that workloads could process sensitive data while remaining isolated even from the infrastructure that runs them has reshaped the way many enterprise security teams think about trust. For years, we have accepted that data should be encrypted at rest and in transit, but data in use has remained exposed to the platform beneath it. Confidential computing proposes to close that gap.

What has slowed adoption is not a lack of interest but a reliance on specialized and expensive hardware. Trusted execution environments demand specific CPUs, constrained instance types, and operational trade-offs that place them out of reach for many real-world deployments. The result is a growing mismatch between the threat models enterprises care about and the tools they can practically deploy.

At the same time, something important is happening in open source. A set of identity and isolation primitives is quietly maturing into an infrastructure layer that looks a lot like the public key infrastructure that underpins the modern web. Instead of encrypting sessions between browsers and servers, these systems establish cryptographic identities for workloads themselves.

Let’s look at how those building blocks come together, why workload identity is becoming central to zero trust architectures, and how systems like Edera use open standards to deliver many of the benefits of confidential computing without requiring new hardware

SPIFFE and Workload Identity in Zero Trust Architectures

To understand where this is going, it helps to define a few terms. Workload identity is the idea that software should be able to prove what it is and where it is running, independent of network location or static credentials.

Workload attestation is the process of verifying those properties before granting identity. Zero trust is the assumption that no implicit trust exists based on network position, and that every interaction must be authenticated and authorized. Confidential computing, in its strictest sense, aims to ensure that workloads remain isolated and verifiable even from the host platform.

SPIFFE, the Secure Production Identity Framework for Everyone, is a specification that addresses workload identity directly. It defines how workloads are identified, how those identities are represented, and how they can be verified across distributed systems. A SPIFFE ID is a structured identifier bound to a trust domain and a specific workload. It is not a secret and is not tied to an IP address or a long-lived credential. Instead, it becomes meaningful only when paired with a cryptographic document known as an SVID, or SPIFFE Verifiable Identity Document.

An SVID binds a SPIFFE ID to a key pair and a signing authority. This allows workloads to authenticate to each other using short-lived credentials that can be rotated automatically. From the perspective of a developer or operator, this looks familiar. It mirrors the way certificates work on the web, but the subject is a workload rather than a domain name.

The important distinction is that SPIFFE does not dictate how trust is established. It defines the interface and the format, leaving attestation to the underlying platform. That flexibility is what makes it so powerful. SPIFFE can sit above cloud-provider metadata, operating-system signals, or, in our case, a hypervisor-rooted trust model.

How SPIRE Enables Runtime Workload Attestation

SPIRE is the reference implementation of the SPIFFE specification. Where SPIFFE defines what workload identity looks like, SPIRE defines how it is issued and managed in practice. It introduces two main components: a SPIRE Server and SPIRE Agents.

The SPIRE Server acts as the root of trust. It holds the signing keys for the trust domain and enforces registration policies that define which workloads are allowed to receive which identities. The SPIRE Agent runs on each node and performs two related tasks. First, it proves the identity of the node itself through node attestation. Then it performs workload attestation on behalf of processes running on that node.

Node attestation determines whether a machine should be trusted to host workloads in the first place. Workload attestation answers whether a specific process meets the criteria to receive a given identity. Crucially, workloads never carry secrets with them. They request an identity from the local agent at runtime and receive an SVID only if attestation succeeds. Those identities are short-lived and automatically rotated, dramatically reducing the blast radius of compromise.

This separation is what allows SPIRE to fit cleanly into zero trust models. Trust is established explicitly, continuously, and based on verifiable properties rather than assumptions about the environment.

Combining Hypervisor-Based Isolation with Workload Identity

Edera approaches isolation from a different starting point. Instead of sharing a kernel across workloads, Edera runs applications inside zones that behave like lightweight virtual machines. Each zone has its own kernel and is isolated by a type-1 hypervisor with a small trusted computing base. This removes the shared kernel from the trust boundary and eliminates an entire class of container escape attacks.

In this model, zones become the natural unit of trust. A zone is not just a scheduling construct but a security boundary. That makes it an ideal foundation for workload identity. The challenge is proving to a remote party that a workload is actually running inside such a zone.

This is where SPIFFE and SPIRE fit. By rooting node attestation in the hypervisor itself, Edera can use the hypervisor as the underlying platform authority. The hypervisor can vouch for the existence and integrity of zones, while standard workload attestation mechanisms operate inside those zones without modification. Key material and sensitive services like the SPIRE Server can themselves run inside hardened zones, further reducing exposure.

The result is a system where workloads receive cryptographic identities only if they are running inside verified isolated environments. Data can be encrypted directly to those identities, and policies can be enforced based on where and how code is executing, not just who wrote it.

This architecture delivers something subtle but important. It provides remote attestation of isolation properties without relying on specialized hardware enclaves. The guarantees come from strong isolation and verifiable identity rather than opaque hardware features. In practice, this covers a large set of real-world threat models that enterprises care about today.

From Open Standards to Production-Grade Isolation

Open standards like SPIFFE and SPIRE provide the identity layer for zero trust systems. But identity without strong isolation is incomplete.

Edera extends these open standards into production infrastructure by rooting workload attestation in a type-1 hypervisor. Instead of relying on a shared kernel, each workload runs inside a dedicated zone with its own isolated kernel. The hypervisor becomes the foundation of trust, and SPIFFE identities are issued only to workloads running inside verified isolation boundaries.

This architecture delivers:

• Cryptographically verifiable workload identity
• Hypervisor-enforced isolation with no shared kernel state
• Remote attestation of execution context
• Compatibility with existing Kubernetes workflows via runtime class

By combining open identity standards with hardened runtime isolation, Edera enables secure multi-tenancy on commodity hardware—without requiring specialized confidential computing CPUs.

Zero trust becomes enforceable at the workload level, not assumed at the infrastructure layer.

Why this matters now

Enterprise security teams are increasingly forced to reason about workloads rather than hosts. Microservices, multitenant clusters, and AI systems that process sensitive data keep eroding traditional boundaries. At the same time, the cost and complexity of hardware-based confidential computing remain a barrier.

Open standards like SPIFFE and implementations like SPIRE offer an incremental path forward. They allow organizations to adopt zero trust principles at the workload level, establish cryptographic identities, and build policy around verifiable execution contexts. Systems like Edera show how strong isolation and identity can work together to approximate the benefits of confidential computing using commodity infrastructure.

This is not an argument against hardware enclaves. Those technologies will continue to matter for the most sensitive threat models. But it is an argument for paying attention to the broader evolution of workload identity. Just as it quietly became foundational to the web, workload identity is becoming foundational to modern distributed systems.

Understanding how attestation, zones, zero trust, and identity intersect will be critical over the next few years. The pieces are already here. The opportunity now is to learn how they fit together and to build systems that can earn trust rather than assume it.

FAQ

What is SPIFFE?

SPIFFE (Secure Production Identity Framework for Everyone) is an open standard for workload identity that assigns cryptographically verifiable identities to software workloads.

How does SPIRE relate to SPIFFE?

SPIRE is the reference implementation of SPIFFE. It handles node and workload attestation and issues short-lived identity documents (SVIDs).

Can zero trust be achieved without confidential computing hardware?

Yes. By combining strong workload isolation (such as hypervisor-based zones) with open standards like SPIFFE and SPIRE, organizations can enforce zero trust principles without relying on specialized CPUs.

What is workload attestation?

Workload attestation is the process of verifying that a workload meets defined security conditions before it is granted a cryptographic identity or provided with sensitive data to process.

‍A version of this blog was previously published on The New Stack on January 26, 2026.