Machine identity is the set of credentials that let software, servers, containers and services prove who they are to each other: certificates, keys, tokens and service accounts. They outnumber human accounts in most systems and tend to be less governed. Public TLS certificates are about to expire much faster, which makes manual handling unworkable.
What counts as a machine identity?
The common kinds are TLS certificates on servers and clients, API keys, service account credentials, SSH keys, code-signing keys and tokens issued to workloads. Each is a secret or a key pair that a program uses without a person typing anything.
The SPIFFE project, an open standard for workload identity, describes the problem for modern infrastructure: conventional practices such as network policies that allow traffic only between particular IP addresses struggle to scale in dynamic, heterogeneous environments, so workloads need a first-class identity framework. At the heart of its specifications are short-lived cryptographic identity documents, called SVIDs, which workloads use to authenticate to each other, for example by establishing a TLS connection or by signing and verifying a JWT.
NIST's zero trust publication reaches a similar place from the access side: client identity can include the user account or service identity, and the associated attributes assigned to that account or to artifacts used to authenticate automated tasks.
Why are lifetimes shrinking?
The CA/Browser Forum's Baseline Requirements set the rules for publicly trusted TLS certificates. In their current text, the maximum validity of a subscriber certificate depends on the issue date:
- issued before 15 March 2026: 398 days
- from 15 March 2026 up to 15 March 2027: 200 days
- from 15 March 2027 up to 15 March 2029: 100 days
- on or after 15 March 2029: 47 days
The domain validation data reuse period shrinks on the same schedule, ending at 10 days from 15 March 2029. These dates come from the Baseline Requirements text as fetched on 18 October 2026, so check the current document before you plan around them.
The practical meaning is that a certificate you renew by calendar reminder once a year will, within a few years, need renewing roughly every month or two. A team with 300 certificates and a spreadsheet will miss some.
What goes wrong without management?
Expired certificates cause outages, and the expiry always lands on a weekend. Unknown certificates cause security gaps, since nobody owns what nobody inventoried. Long-lived keys that are never rotated turn one leak into permanent access. And service account credentials copied into code, images or chat messages end up in places no scanner covers.
How does short-lived identity help?
SPIFFE's approach, and similar workload identity systems, issue credentials automatically and let them expire quickly, so there is nothing to remember to rotate. A stolen credential works for hours, not years. The tradeoff is that you now depend on the issuing system being available, so it needs the same operational care as a database.
A constructed example
A company runs 40 services behind three load balancers. Certificates were bought individually, with expiry dates tracked by one engineer. When she changes teams, two certificates lapse and a partner integration breaks for six hours. The team inventories every certificate with owner and expiry, moves public certificates to automated issuance and renewal, and gives internal services short-lived identities from a workload identity system. The six-hour outage becomes impossible by design, because renewal no longer depends on a person remembering.
How to check or apply this
- Build an inventory of certificates, keys, tokens and service accounts, with an owner for each.
- Search code, configuration and images for embedded credentials, and rotate any you find.
- Move public TLS certificates to automated issuance and renewal now, before the 200-day and 100-day steps arrive.
- For internal services, use short-lived workload identities instead of static secrets where the platform allows.
- Set expiry alerts at several thresholds, and test that they reach a team and not one person.
- Define rotation intervals per key type, and rehearse emergency rotation.
- Log issuance and use, so a surprising identity shows up.
For AI agents, which act with credentials of their own, Safeguard includes agent identity alongside guardrails and policies, so agents are not running on a borrowed human login.
Quick check
What is the maximum validity of a public TLS certificate today?
Under the Baseline Requirements text as fetched on 18 October 2026, 200 days for certificates issued from 15 March 2026 until 15 March 2027, reducing to 100 days and then 47 days on the dates above.
Why prefer short-lived credentials?
A stolen short-lived credential stops working quickly, and automatic issuance removes the manual rotation that people forget.
Sources
- CA/Browser Forum, Baseline Requirements for TLS Server Certificates
- SPIFFE, Overview
- NIST SP 800-207, Zero Trust Architecture
Last reviewed: 18 October 2026.
