SPIFFE and Workload Identity for Device Fleets
SPIFFE (Secure Production Identity Framework for Everyone) was designed for cloud-native workload identity — Kubernetes pods, VMs, serverless functions. But the underlying model — short-lived, automatically rotated, platform-attested identity — maps directly to the device fleet problem. The question is whether SPIFFE's architecture can extend from data centres to factory floors, edge gateways, and constrained devices.
This guide examines what works, what doesn't, and where the hybrid boundary between SPIFFE and traditional device PKI lies.
Related: Implementation Guide (pillar) · Machine Identity & Zero Trust · mTLS Architecture · Private CA Comparison
SPIFFE fundamentals for device teams
SPIFFE defines a standard identity format (SPIFFE ID: spiffe://trust-domain/path) and a standard document that proves it (SVID — SPIFFE Verifiable Identity Document, typically an X.509 certificate). SPIRE is the reference implementation: a server that issues SVIDs and agents that run on each node, attesting workloads and delivering SVIDs to them.
For cloud workloads, this eliminates long-lived secrets — SVIDs are short-lived (minutes to hours) and automatically rotated. For devices, the same pattern applies but the attestation mechanism must change: cloud workloads attest via cloud provider metadata (AWS IID, GCP IIT), while devices attest via hardware-backed credentials — TPM quotes, SE challenge-response, or platform integrity measurements.
PKI Health Radar
Drag the sliders to assess your current posture — scores update instantly.
Trust domain architecture for mixed environments
A device fleet that communicates with cloud services needs identity interoperability. SPIFFE trust domain federation solves this: the device fleet's SPIRE server and the enterprise cloud SPIRE server federate their trust domains, allowing SVIDs from either domain to be verified by the other.
- Cloud trust domain:
spiffe://cloud.example.com/...— standard SPIRE deployment in Kubernetes, attesting pods and services. - Device trust domain:
spiffe://devices.example.com/...— SPIRE server (cloud or on-prem) issuing SVIDs to edge agents and devices. - Federation: Both domains exchange trust bundles. A cloud service can verify a device's SVID; a device can verify a cloud service's SVID. mTLS between cloud and device fleet with no shared CA required.
For the mTLS implementation patterns, see mTLS Architecture. For the broader zero-trust framing, see Machine Identity & Zero Trust.
SPIRE agents at the edge
Full SPIRE agents run on edge gateways — Linux-based devices with sufficient resources (ARM Cortex-A, 128MB+ RAM). The agent attests to the SPIRE server using a join token, TPM-based attestation, or cloud instance identity, then acts as the local identity provider for downstream devices connected to that gateway.
Constrained devices (MCU-class, no OS, <256KB RAM) cannot run a SPIRE agent. These devices use the gateway as a proxy: the gateway attests the device using SE challenge-response or TPM quotes, then requests an SVID on the device's behalf. The device receives a short-lived certificate without running any SPIFFE-aware software — the gateway handles the protocol.
Hardware attestation: TPM and Keylime
SPIRE supports TPM-based node attestation via the tpm_devid attestor. The device's TPM provides a DevID certificate (IEEE 802.1AR IDevID or LDevID) that the SPIRE server verifies against the manufacturer's CA. This ties SPIFFE identity to hardware identity — the SVID is only issued to a device that can prove it has the correct TPM.
Keylime extends this with runtime integrity verification. Beyond initial attestation, Keylime continuously monitors the device's TPM-measured boot state, detecting firmware tampering or unauthorised software changes after initial provisioning. A device that passes Keylime attestation has provable boot integrity, not just a valid certificate.
For the underlying hardware key storage considerations, see Hardware vs Software Key Storage. For factory-floor provisioning of the TPM/SE credentials that feed this attestation chain, see Factory Provisioning.
Where SPIFFE works for devices — and where it doesn't
| Scenario | SPIFFE fit | Why |
|---|---|---|
| Edge gateways → cloud | Strong | Gateway runs SPIRE agent; federation with cloud SPIRE; automatic mTLS |
| Linux devices with TPM | Strong | tpm_devid attestor; Keylime integration; full SPIRE agent |
| MCU devices via gateway | Partial | Requires gateway proxy; device itself is not SPIFFE-aware |
| Matter / protocol-specific ecosystems | Poor | Matter requires DAC in specific format; SPIFFE SVIDs don't satisfy Matter spec |
| Offline / intermittent connectivity | Poor | SVID rotation requires SPIRE agent ↔ server connectivity; short-lived SVIDs expire |
Hybrid model: SPIFFE + traditional device PKI
Most real deployments end up hybrid. Traditional device PKI (long-lived certificates in SE/TPM) handles device attestation at the hardware level — this is non-negotiable for Matter DAC and regulatory compliance. SPIFFE handles workload-to-workload communication between devices and cloud services, using the device's hardware credential as the attestation anchor for SPIRE.
The device has two identities: a long-lived device attestation certificate proving "I am a genuine device" and a short-lived SVID proving "I am authorised to access this service right now." The first is provisioned at the factory; the second is issued dynamically by SPIRE based on the first.
For organisations managing certificates across both SPIFFE-issued and traditionally-issued identities, the certificate sprawl and visibility challenge applies — a unified inventory across both identity models is essential. Workload microsegmentation patterns apply to the mTLS policies governing which SVIDs can communicate with which services.
Implementation Guide — CTO Strategy & Business Case — Factory Provisioning — Machine Identity & Zero Trust — mTLS Architecture — Hardware vs Software Keys — Matter DAC — Private CA Comparison. Contact Axelspire or Ask Axel.