If you came into PKI through the lens of certificates for people and websites, the last decade has quietly rewritten your job description. The interesting problems are no longer about issuing a credential to a human who logs in once a day. They are about identity for things that never log in at all: services, containers, functions, sensors, gateways and microcontrollers that come and go by the thousand.
It can be stated plainly. The dominant PKI growth today is in machine and workload identity, not human identity. Machines outnumber us by orders of magnitude, they appear and vanish in seconds, and they cannot answer a security question or tap a hardware token. The human-centric mental model does not transfer, and pretending it does is how you end up with a thousand long-lived certificates and a private key sitting in a world-readable config file.
This article is about how identity actually works for machines and devices: where the trust comes from, how a brand-new thing earns its first credential, and why the architecture splits cleanly into two tiers.
The scale shift, and why human models break
Human identity has comfortable assumptions baked in. There are relatively few users. They change slowly. They have an out-of-band channel (a phone, an email, an HR onboarding process) that you can lean on for enrolment. A certificate that lives a year is fine, because a human can be re-issued one with a bit of friction once.
None of that holds for machines. A workload may live for ninety seconds. A fleet may scale from ten nodes to ten thousand in response to load, then back down again before you have finished reading the alert. There is no human in the loop to approve anything, and there is no out-of-band channel, because the device is the channel. Worse, the population is heterogeneous: a constrained sensor with 64KB of RAM sits in the same trust domain as a beefy container orchestrator, and both need an identity that means something.
So the requirements invert. Instead of long-lived credentials renewed with human friction, you want short-lived credentials renewed with zero friction. Instead of an enrolment ceremony, you want automated attestation. Instead of "who is this person", you want "what is this workload, where is it running, and can it prove it".
Secret zero: the problem everything else hangs off
One question separates a serious machine-identity design from a fragile one. A brand-new workload or device boots for the first time with no credentials. How does it obtain its first one?
The naive answer is to bake in a shared secret: an API key, a bootstrap token, a password in an environment variable. The moment you do that, you have created secret zero: the credential that protects the issuance of all other credentials, which must therefore be present on every machine, and which you now have to protect everywhere. If it leaks, an attacker can mint legitimate identities at will. All you have done is smear the bootstrapping problem across your entire estate.
The bootstrapping problem is never truly eliminated. It is relocated to the one place that can actually be defended. Good architecture is the discipline of choosing that place deliberately rather than scattering secrets and hoping.
The way out is to stop relying on something the workload knows and start relying on something it is or where it runs. A workload can be attested by the platform that scheduled it. A device can prove possession of a key that was burned into hardware at manufacture. In both cases the "secret" is non-exfiltratable and tied to a verifiable property, so there is nothing portable for an attacker to steal and replay.
Hardware roots of trust
If identity is going to mean anything for a device, the private key behind it must be incapable of leaving the device. Software keys fail this test by definition, since anything readable can be copied. This is where hardware roots of trust earn their place.
TPM 2.0, secure elements and HSMs
A TPM 2.0 generates and stores keys such that the private half never appears in addressable memory; you operate on it by handle, never by value. A secure element gives you the same property in a cheaper, smaller package suited to embedded and IoT designs. An HSM does it at the high-assurance, high-throughput end, typically for CAs and signing services. They differ wildly in cost and form factor but share the one property that matters: the key is bound to the hardware and cannot be exfiltrated.
On the host side you generally reach these through PKCS#11, the standard interface for cryptographic tokens. Your application asks the token to sign; it never sees the key. The discipline to enforce is simple: where it is practical, a key that identifies a machine should be generated on, and never leave, a hardware root of trust. Anything short of that is a compromise you should be able to name out loud.
Attestation: proving state before you trust
Possessing a hardware-bound key proves which device you are talking to. Remote attestation goes further and lets the device prove what state it is in before you issue it anything operational. A TPM accumulates measurements of the boot chain into PCRs and can produce a signed quote over them, anchored to an attestation key whose lineage traces back to the manufacturer-provisioned endorsement key.
The architectural pattern is to gate issuance on attestation. The device does not simply ask for a certificate; it asks, and presents evidence, and the issuing service verifies that evidence (correct firmware, expected boot measurements, genuine hardware) before it will sign anything. Possessing a token is no longer enough; issuance depends on provable device integrity.
Birth certificates vs operational certificates
Once you accept that the key must be hardware-bound and that issuance should be gated on attestation, a two-tier model falls out naturally and makes a sensible default.
The first tier is the birth certificate: a long-lived identity, often called an IDevID in the 802.1AR sense, provisioned at manufacture against a key generated inside the device's hardware root of trust. It is durable, it is globally unique, and it exists for one purpose: to bootstrap. It should never be used directly to authenticate to day-to-day services.
The second tier is the operational certificate (an LDevID): short-lived, issued at runtime, used for actual workload-to-workload authentication, and rotated continuously. The device authenticates with its birth certificate, proves its integrity through attestation, and in exchange receives a fresh operational credential it can use until it expires minutes or hours later.
MANUFACTURE TIME RUNTIME
---------------- -------
+------------------+ +-----------------------+
| Hardware Root of | | Operational Identity |
| Trust (TPM / SE) | | Authority (online) |
+--------+---------+ +-----------+-----------+
| keygen in-place ^
v | (3) present birth
+------------------+ (1) provision +---------+ cert + attestation
| BIRTH CERT |--- at factory -------> | evidence; request op cert
| (IDevID) | |
| long-lived | (2) ship device | (4) verify attestation,
| key non-export |======================> | issue SHORT-LIVED
+------------------+ | OPERATIONAL CERT
v (LDevID, mins/hours)
+-------------+-----------+
| Workload uses op cert |
| for mTLS; rotates |
| before expiry; repeat |
+-------------------------+The elegance is that the long-lived secret never touches the wire for routine authentication. It is used only to obtain ephemeral credentials, so the blast radius of a leaked operational certificate is measured in minutes, and revocation at the operational tier becomes a non-event. You simply stop renewing.
Workload identity: SPIFFE, SPIRE and the service mesh
The two-tier idea has a direct analogue in cloud-native infrastructure, and a widely-used project here is SPIFFE with its reference implementation SPIRE. SPIFFE gives every workload a stable, structured identity (a SPIFFE ID) encoded as a URI SAN inside an X.509 certificate it calls an X.509-SVID.
SPIFFE ID: spiffe://prod.example.internal/ns/payments/sa/ledger-api
X.509-SVID (relevant fields):
Subject: (empty — identity lives in the SAN)
Subject Alt Name (URI): spiffe://prod.example.internal/ns/payments/sa/ledger-api
Key Usage: Digital Signature
Ext Key Usage: TLS Web Server Auth, TLS Web Client Auth
Not Before: 2026-05-20T09:00:00Z
Not After: 2026-05-20T10:00:00Z <-- one-hour lifetime
Trust Domain: prod.example.internalTwo things matter here. First, the identity lives in the URI SAN rather than being crammed into a Common Name, so it is machine-readable and namespaced by trust domain. Second, look at the validity window: one hour. These credentials are designed to be short-lived and rotated automatically, which means a stolen SVID is worthless almost immediately and there is no certificate-revocation problem to manage because nothing lives long enough to need revoking.
Node attestation and workload attestation
SPIRE solves secret zero with a two-step attestation that maps neatly onto the tiers above. Node attestation establishes that an agent is running on a legitimate node. Here SPIRE can use a TPM, a cloud instance-identity document, or a Kubernetes projected token as the evidence. Workload attestation then establishes which specific process on that node is asking, by interrogating kernel and orchestrator facts such as process UID, container labels and the service account it runs under. The workload cannot simply assert these properties for itself.
The workload ends up with an SVID without ever holding a portable secret. There was no API key to leak, because identity was derived from verifiable platform facts. That is the whole game: replace "what the workload knows" with "what the platform can prove about it".
mTLS as the consumer
The payoff is mutual TLS everywhere. In a service mesh, sidecars or libraries present their SVIDs and validate the peer's SVID against the trust domain, so every connection is authenticated both ways and authorisation policy can be written against stable SPIFFE IDs rather than brittle IP addresses or network position. Identity becomes the security boundary instead of the network. In my experience that is the only model that survives contact with autoscaling and ephemeral infrastructure.
The constrained-device reality
SPIFFE assumes a fairly rich platform. Much of the IoT world does not have one. A microcontroller with kilobytes of RAM, an intermittent low-bandwidth radio link and a ten-year battery budget cannot run a mesh agent, and it will not be re-provisioned by hand once it is in the field. This is where enrolment protocols earn their keep.
EST and SCEP
EST (RFC 7030) is a sensible target for new designs. It runs over HTTPS, authenticates the server with TLS, and supports server-side key generation for devices too weak to generate good keys themselves. Critically, its /simpleenroll and /simplereenroll endpoints map cleanly onto the birth-vs-operational model: a device authenticates the initial enrolment with its manufacturer-provisioned credential, then re-enrols to rotate.
# EST initial enrolment over the birth credential (TLS client auth)
POST /.well-known/est/simpleenroll HTTP/1.1
Host: est.example.internal
Content-Type: application/pkcs10
Content-Transfer-Encoding: base64
# (client TLS cert = IDevID birth certificate)
#
# body: a PKCS#10 CSR for the operational key
MIIBVDCB...base64-encoded-CSR...Qm9v
# Server replies with the issued operational cert:
HTTP/1.1 200 OK
Content-Type: application/pkcs7-mime; smime-type=certs-only
Content-Transfer-Encoding: base64
MIIC8w...base64-encoded-PKCS7...x9Az
# Later, rotate via /simplereenroll authenticated by the CURRENT op certSCEP is still everywhere in the field and you will inherit it, but it carries legacy baggage: it has historically been weak in its challenge-password bootstrap and its cryptographic defaults. Treat it as a protocol to interoperate with where you must, and to migrate off where you can, with EST as the target.
Fleet realities: onboarding, rotation, decommissioning
At fleet scale the protocol is the easy part; the lifecycle is where designs live or die. A few hard-won principles:
- Onboarding must be zero-touch. If provisioning a device requires a human step, you cannot do it a million times. The birth certificate exists precisely so that first contact is automated and authenticated.
- Rotation has to be autonomous and failure-tolerant. A device that bricks itself because a renewal failed over a flaky radio link is worse than one with a slightly longer-lived certificate. Renew well before expiry, retry with backoff, and never let a single failed rotation take a device offline.
- Decommissioning is a first-class operation, not an afterthought. Revocation across millions of constrained devices is genuinely hard. CRLs grow unbounded and OCSP assumes connectivity many devices do not have. Short operational lifetimes are again your friend: stop re-enrolling a device and it ages out of trust on its own, which scales where revocation lists do not.
That last point applies to everything above. Across hardware roots of trust, SPIFFE workloads and constrained IoT alike, the durable answer is the same: bind identity to something unforgeable, keep operational credentials short, and let expiry do the work that revocation cannot do at scale.
The direction of travel is clear. As confidential computing makes hardware-backed attestation routine even for ephemeral cloud workloads, the line between "device" and "workload" identity will keep blurring, and attested, hardware-rooted, short-lived identity will become the default rather than the exception. The architects who internalise that two-tier model now (birth credentials to bootstrap, ephemeral credentials to operate) will be the ones whose systems still make sense when the machine population grows another order of magnitude. The final part of this series turns to what it takes to operate all of this trust at genuine enterprise scale.
NK