SPIFFE Workload Identity for Device Fleets — Architecture, TPM Attestation, and SPIRE Edge Deployment

By Dan C., AxelSpire — Founder and Principal Consultant. Published 31 March 2026 · Updated 23 April 2026.

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. For organisations managing machine identity across both cloud workloads and physical devices, SPIFFE offers a standards-based machine identity framework that can unify both worlds under a single trust model.

The question is whether SPIFFE's architecture can extend from data centres to factory floors, edge gateways, and constrained devices. This guide — based on AxelSpire's client implementations — 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

Key definitions

The primitives below are the atomic concepts this guide uses. AxelSpire has deployed each in client device-fleet architectures; the definitions reflect operational usage, not only specification language.

What is SPIFFE?

SPIFFE (Secure Production Identity Framework for Everyone) is an open standard — maintained under the Cloud Native Computing Foundation — that defines how workloads prove their identity cryptographically, without shared secrets. AxelSpire extends SPIFFE from its original cloud-workload context to device fleets, using edge gateways as identity brokers and hardware-backed attestation at the leaf as the trust anchor.

What is a SPIFFE SVID?

A SPIFFE Verifiable Identity Document (SVID) is a short-lived cryptographic credential — typically an X.509 certificate with the SPIFFE ID encoded in the URI SAN field — that proves a workload's identity. SVIDs are rotated automatically by the SPIRE agent on a minutes-to-hours cadence. In AxelSpire's device-fleet deployments, the SVID is the runtime access credential, while a hardware-backed DevID or secure element key provides the persistent attestation anchor.

What is SPIRE?

SPIRE (SPIFFE Runtime Environment) is the CNCF-governed reference implementation of SPIFFE. It consists of a server that issues SVIDs and agents that run on each workload host, attesting workloads and delivering SVIDs to them. For device fleets, AxelSpire deploys full SPIRE agents on edge gateways (ARM Cortex-A class, Linux-based) and proxies SVID issuance to constrained downstream devices via TPM or secure element attestation.

What is a SPIFFE trust domain?

A SPIFFE trust domain is the logical identity boundary of a SPIFFE deployment — for example, spiffe://devices.example.com for a device fleet, separate from spiffe://cloud.example.com for cloud workloads. Trust domains federate by exchanging trust bundles, enabling mTLS between domains without a shared certificate authority. AxelSpire's reference architecture uses separate trust domains for device and cloud workloads, federated for inter-domain communication.

What is TPM DevID attestation?

TPM DevID attestation, specified in IEEE 802.1AR, binds a device's cryptographic identity to its Trusted Platform Module. SPIRE's tpm_devid node attestor verifies that the device possesses a DevID certificate whose private key resides in the same TPM as the device's endorsement key, using TPM 2.0 credential activation. AxelSpire uses this primitive as the hardware anchor for SVID issuance — a cloned DevID certificate cannot pass attestation on a different physical device.

SPIFFE architecture for device fleets

Cloud workloads attest via cloud-provider metadata (AWS Instance Identity Document, GCP Instance Identity Token). Devices cannot — they attest via hardware-backed credentials: TPM quotes, secure element challenge-response, or platform integrity measurements. In AxelSpire's assessment, the attestation mechanism is the only meaningful divergence between cloud-native SPIFFE and device-fleet SPIFFE; everything above the attestor layer — SVIDs, trust domains, federation, rotation — remains identical.

This distinction is structural, not incidental. SPIFFE SVIDs serve as the runtime workload credential; the underlying hardware attestation (TPM DevID, SE key) serves as the persistent device identity anchor. Both are needed; neither replaces the other. Teams attempting to use SVIDs alone — without a hardware-rooted DevID — lose the tamper-resistance property that makes device identity credible in the first place.

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. In AxelSpire's reference architecture 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 DevID and Keylime integration

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.

TPM attestor configuration

The server-side configuration for tpm_devid attestation requires the manufacturer CA bundle that issued the device's DevID certificates. The agent-side configuration points to the TPM device path and the DevID key material provisioned during manufacturing:

# SPIRE Server — server.conf
NodeAttestor "tpm_devid" {
    plugin_data {
        devid_ca_path = "/opt/spire/conf/devid-ca-bundle.pem"
    }
}

# SPIRE Agent — agent.conf
NodeAttestor "tpm_devid" {
    plugin_data {
        devid_cert_path = "/opt/spire/conf/devid-cert.pem"
        devid_priv_path = "/opt/spire/conf/devid-key.pem"
        devid_pub_path  = "/opt/spire/conf/devid-pub.pem"
    }
}

The attestation flow uses TPM 2.0 credential activation: the server issues a challenge encrypted to the device's endorsement key (EK), proving the DevID private key resides in the same TPM as the EK. This prevents key exfiltration — a DevID certificate copied to a different device will fail the credential activation challenge. For the factory-floor provisioning of these DevID credentials, see Factory Provisioning.

Runtime integrity verification with Keylime

Keylime extends TPM attestation with continuous runtime integrity verification. Beyond initial attestation, Keylime continuously monitors the device's TPM-measured boot state via Linux IMA (Integrity Measurement Architecture), 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. The Keylime SPIRE plugin replaces the standard node attestor, adding continuous integrity verification to the SVID issuance decision.

For the underlying hardware key storage considerations, see Hardware vs Software Key Storage.

Where SPIFFE works for devices — and where it doesn't

In AxelSpire's assessment, SPIFFE fit for device identity breaks down along two axes: device capability (can it run a SPIRE agent?) and connectivity pattern (can it maintain SPIRE server communication for SVID rotation?). The table below summarises how AxelSpire categorises SPIFFE suitability across five deployment scenarios encountered in client work:

Hybrid model: SPIFFE + traditional device PKI

In AxelSpire's client work, 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.

Frequently asked questions

What is a SPIFFE SVID and how does it work for machine identity?

A SPIFFE Verifiable Identity Document (SVID) is a short-lived cryptographic credential — typically an X.509 certificate — that proves a workload's identity. The SPIFFE ID (spiffe://trust-domain/path) is encoded in the certificate's URI SAN field. Unlike traditional long-lived machine certificates, SVIDs are automatically rotated on a minutes-to-hours cadence by the SPIRE agent, eliminating the operational burden of manual certificate renewal. For device fleets, AxelSpire uses the SVID as the runtime access credential, while a hardware-backed DevID or SE key provides the persistent attestation anchor.

How does SPIRE use TPM for device attestation?

SPIRE's tpm_devid node attestor verifies that a device possesses a valid DevID certificate (IEEE 802.1AR) whose private key is bound to the device's TPM. The attestation uses TPM 2.0 credential activation: the SPIRE server encrypts a challenge to the device's endorsement key, and only a device where the DevID key and endorsement key reside in the same physical TPM can solve it. AxelSpire recommends pairing tpm_devid with Keylime to extend attestation from a one-time enrolment decision to continuous boot-integrity verification via TPM-measured IMA logs, allowing SPIRE to revoke SVIDs from devices with compromised firmware.

What does a SPIFFE workload identity architecture look like for device fleets?

AxelSpire's reference architecture uses two federated SPIFFE trust domains: one for cloud workloads (spiffe://cloud.example.com) and one for the device fleet (spiffe://devices.example.com). Edge gateways run full SPIRE agents and attest downstream constrained devices via TPM or SE challenge-response. The two trust domains exchange trust bundles, enabling mTLS between any cloud service and any device without a shared CA. See the architecture diagram above for the full topology.

Can SPIFFE work with IoT and constrained edge devices?

Directly, no — MCU-class devices (<256KB RAM, no OS) cannot run a SPIRE agent. In AxelSpire's implementation pattern, the practical approach is gateway-proxied attestation: the edge gateway runs the SPIRE agent, attests the constrained device using hardware credentials, and requests an SVID on the device's behalf. The device receives a short-lived certificate without any SPIFFE-aware software. This works well for devices with reliable gateway connectivity but breaks down for offline or intermittently connected devices, where traditional long-lived device certificates remain necessary.

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.