An open standard (SPIFFE) and its reference implementation (SPIRE) for issuing cryptographic workload identity — in the form of X.509 SVIDs or JWT SVIDs — across heterogeneous environments, used as a foundational identity layer by several enterprise platforms and service mesh implementations.
How do workloads across heterogeneous environments different clouds, bare metal, on-premises prove their identity to each other cryptographically, without static credentials? SPIRE issues X.509 SVIDs and JWT SVIDs to workloads based on node attestation and workload attestation, providing a portable identity fabric that works across Kubernetes, VMs, and physical infrastructure. That is the right solution for the identity issuance layer. The gap appears at the access layer above it. SPIFFE defines how a workload proves what it is. It does not define what that workload is allowed to access, under what conditions, or how credentials for target services get delivered. There is no policy enforcement plane, no conditional access controls, and no last-mile credential injection in the SPIFFE/SPIRE model. Aembit operates at that access layer. It can consume SPIFFE SVIDs as workload identity attestations, evaluate access policy, and issue short-lived credentials for the target service covering the gap between workload identity issuance (SPIRE’s job) and workload access enforcement (Aembit’s job). The two tools are complementary by design and are frequently deployed together in enterprise environments that need both.
Aembit does not replace SPIFFE / SPIRE. SPIRE handles cryptographic workload identity issuance across heterogeneous environments, a problem Aembit was not designed to solve.
Aembit accepts SPIFFE SVIDs as workload identity attestations. When a workload presents its SPIRE-issued JWT SVID to Aembit, Aembit verifies the identity claim against the SPIFFE trust bundle, evaluates the access policy configured for that workload, and issues a short-lived credential for the target service — whether that target is a cloud API, a SaaS tool, a database, or an on-premises system.
This means organizations that have deployed SPIRE for workload identity issuance do not need to replace it. Aembit adds the access governance and credential delivery layer on top of SPIRE’s identity fabric, closing the gap between a workload knowing its identity and being able to use that identity to reach the services it needs.
SPIFFE / SPIRE and Aembit are designed for different layers of the same problem and are complementary by design.
SPIRE handles the identity issuance layer: attesting nodes and workloads through platform-specific plugins (Kubernetes, AWS, GCP, on-premises), issuing X.509 SVIDs and JWT SVIDs, rotating them automatically, and federating trust across SPIFFE trust domains. This is the foundation — the cryptographic proof that a given workload is what it claims to be.
Aembit handles the access enforcement layer above it: given that a workload has proven its identity (via SVID or any other attestation mechanism), what is it allowed to access? Under what conditions? Aembit evaluates that question at the moment of every access request and issues the appropriate short-lived credential for the target service. It also adds the enforcement features that SPIFFE has no concept of: posture checks, time-of-day constraints, geographic controls, and audit trails with workload-level attribution.
The natural deployment model is SPIRE providing the identity fabric and Aembit consuming SPIRE-issued SVIDs as attestation inputs, adding access policy and credential delivery on top. Organizations that need to enforce least-privilege across workloads — not just attest their identity — need both layers.
Get started in minutes, with no sales calls required. Our free- forever tier is just a click away.
