At Riptides, we believe in standards. SPIFFE provides an elegant, open framework for defining workload identity — a lingua franca for secure, verifiable communication between non-human entities. It’s the right abstraction for the modern distributed world, where ephemeral workloads, containers, and functions all need to prove who they are before they can speak securely.
But while SPIFFE defines the “what,” SPIRE — its reference implementation — defines one possible “how.” And that’s where our paths diverge.
Where SPIRE Stops
SPIRE is a valuable project, but it was designed for a very different operational model. It runs in user space, expects applications to participate in certificate handling, and leaves much of enforcement to other layers. Applications must request, load, and renew their certificates. Migration often means updating code or sidecar integration.
In SPIRE’s approach:
- Certificates live in userspace and are accessible to the application.
- Lifecycle management (request, renewal, rotation) requires coordination with the workload.
- There’s no inherent network or process-level enforcement, identity is issued, but not actively guarded.
- Operational cost is extremely high.
This leaves a gap between identity issuance and enforcement, which made us uncomfortable. You can (almost) know who something is — but not control what it does in real time.
Another concern for us was that with SPIRE, the operational cost for teams is extremely high:
- Application-level integration pushes identity logic into workload code. It fragments implementation, burdens developers, and breaks separation of concerns.
- Sidecars and service meshes externalize identity but add weight and indirection. They depend on Kubernetes, multiply processes, and weaken identity fidelity — the certificate belongs to the proxy, not the process/workload.
Kubernetes isn’t everywhere. Proxies aren’t everywhere. The Linux kernel is. Every workload touches it — opening sockets, issuing syscalls, launching processes.
Read our post Beyond Sidecars and Proxies: Why the Linux Kernel Is the Future of Non-Human Identity for more details.
Another post dives into the risks of offloading identity to a proxy instead of the workload itself, The Hidden Risk in Service Mesh mTLS: When Your Sidecar Becomes a Trojan Horse.
And Riptides Begins
Riptides takes SPIFFE’s principles and drives them deeper, right into the Linux kernel. In our model, the private key never leaves kernel space. The entire certificate lifecycle — issuance, rotation, revocation — happens transparently and independently of the application. No changes, no SDKs, no sidecars, no user-space leakage.
For workloads, identity just exists. Secure communication happens by design, not by orchestration.
This transparency is more than convenience; it’s a security boundary shift. It eliminates an entire class of attacks targeting userspace keys or misconfigured agents. It also enables something SPIRE was never built to do: real-time policy enforcement and behavioral attestation at the point of communication.
Even when communicating with third-party systems that don’t speak SPIFFE, the workload’s SPIFFE SVID can be exchanged to a credential, token, or secret recognized by the external service. This credential is injected directly on the wire, transparently and securely, within the Linux kernel, so the workload can interact with third-party systems without ever exposing its private key or requiring manual handling.
In addition, we also leverage SPIFFE to federate identities across multiple clouds, enabling secure, consistent workload authentication and authorization across AWS, GCP, Azure, Oracle and hybrid environments, without relying on cloud-native federation alone.
Identity Is Only the Start
Riptides extends far beyond SPIRE’s identity issuance model. We combine granular workload attestation, policy enforcement, and observability into one continuous trust fabric.
- In Seamless Kernel-Based Non-Human Identity with kTLS and SPIFFE, we delved into how kernel-level TLS integration allows workloads to automatically present their SPIFFE identities for authentication and secure communication, removing the need for application-level/userspace certificate handling and enabling transparent, end-to-end encrypted interactions.
- In Workload Attestation and Metadata Gathering, we showed how our attestation pipeline collects process-level evidence, from binaries and environment metadata to node posture before a workload earns its identity.
- In On-the-Wire Credential Injection, we demonstrated how secrets and credentials can be injected directly on the wire, removing the need for applications to ever handle them.
- In Why Cloud-Native Federation Isn’t Enough, we explored how multi-cloud identity trust must go beyond federation into continuous kernel-level verification.
- And in our Observability and Telemetry series, we explored how deep kernel-level telemetry, observability and tracing provide continuous visibility into workload behavior, enabling real-time attestation, policy enforcement, and auditing across both internal and third-party communications.
In other words, Riptides doesn’t just issue identities — we enforce them. Every packet, every syscall, every credential handshake can be bound to verified identity and policy, in real time.
The Vision: SPIFFE Realized, Not Just Implemented
SPIFFE remains one of the most forward-looking identity standards in security. We use it as our trust foundation. But our mission at Riptides is to make that standard operationally invisible — to let identity, attestation, and enforcement flow together, without touching the app, without trusting the user space, and without manual intervention.
Where SPIRE stops at issuance, Riptides continues to enforcement.
Where SPIRE runs in user space, Riptides lives in the kernel.
Where SPIRE defines identity, Riptides secures communication.
That’s why we say: we don’t just implement SPIFFE — we evolve it.
If you enjoyed this post, follow us on LinkedIn and X for more updates. If you'd like to see Riptides in action, get in touch with us for a demo.