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. Following runtime attestation, Aembit issues SPIFFE SVIDs (both JWT-SVID tokens and X.509-SVID certificates) via its Credential Providers, evaluates access policy, and manages short-lived credentials for target services, covering the gap between workload identity issuance and workload access enforcement. Aembit and SPIRE can complement each other in enterprise environments that need both.
Aembit does not replace SPIFFE / SPIRE but it allows organizations to use SPIFFE without deploying a SPIRE server.
Aembit issues SPIFFE-compliant SVIDs (both JWT-SVID tokens and X.509-SVID certificates) through its dedicated Credential Providers following runtime attestation of the client workload. Upon verifying the workload through a Trust Provider, Aembit evaluates the configured access policy and delivers short-lived credentials or SPIFFE SVIDs 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 complimentary by design because they work on different layers of the same problem.
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 Aembit performing runtime attestation, evaluating access policies, and issuing short-lived SPIFFE SVIDs or target credentials directly to client workloads without requiring a self-managed SPIRE deployment. Organizations that need to enforce least-privilege across workloads, not just attest their identity, benefit from this unified access and credential delivery layer.
Get started in minutes, with no sales calls required. Our free- forever tier is just a click away.
