Machine Identity, PKI and Certificate Lifecycle Guide

Certificates are machine identities: they prove which server, service, device, workload or code signer is on the other end. For years many organisations managed them in spreadsheets and calendar reminders, renewing once a year and occasionally suffering an outage when one expired. That approach is ending. The maximum lifetime of public TLS certificates fell to 200 days in March 2026 and will reach 47 days in 2029, internal workload identity systems such as SPIFFE are built around short-lived certificates, and the move to post-quantum cryptography means every certificate and key will eventually need replacing. This guide explains certificate-based machine identity, the lifecycle, the changes under way, and how to build, monitor and measure automated certificate lifecycle management. It is written for PKI owners, platform and SRE teams, NHI programme leads and security architects.

Key takeaways

• The public schedule is already biting. Under CA/Browser Forum ballot SC-081v3, public TLS certificates issued from 15 March 2026 may last at most 200 days, falling to 100 days from 15 March 2027 and 47 days from 15 March 2029, when domain validation reuse also drops to 10 days.
• Manual renewal stops being viable. A continuously used certificate will need eight or more renewals a year by 2029; ACME (RFC 8555) and its renewal information extension (RFC 9773) are the practical route.
• Most certificates are internal. Private CAs issue certificates for services, devices, workloads and agents; they need the same inventory, ownership and automation as public ones, and can go much shorter.
• Private and signing keys are the real secrets. The Microsoft Storm-0558 Key Breach 2023 showed what one stolen signing key can do; protect keys in hardware and rotate them automatically.
• Inventory now for post-quantum. NIST plans to deprecate and remove quantum-vulnerable algorithms from its standards by 2035; you cannot migrate certificates and keys you cannot find.

How certificates act as machine identity

An X.509 certificate, profiled for the internet in RFC 5280, binds a public key to an identity such as a domain name, service name or SPIFFE ID, and is signed by a certificate authority (CA) that relying parties trust. The holder proves its identity by using the matching private key, for example in a TLS handshake. Anyone can copy the certificate; only the holder of the private key can use it, which is why key protection matters more than certificate secrecy.

SPIFFE describes itself as open-source standards for identifying software systems, built around "short lived cryptographic identity documents" called SVIDs. See the Workload Identity Federation Guide, the Service Mesh Security Guide and the NHI Authentication Guide.

The certificate lifecycle

The same lifecycle applies to every machine identity. See the NHI Lifecycle Management Guide and the Cryptographic Key Management Guide.

The shrinking lifetime of public certificates

The CA/Browser Forum sets the Baseline Requirements for publicly trusted TLS certificates. Ballot SC-081v3 passed in April 2025 with 25 certificate issuers in favour, none against and five abstaining, and all four certificate consumers (Apple, Google, Microsoft and Mozilla) in favour. The schedule, now in section 6.3.2 and section 4.2.1 of the Baseline Requirements:

Reuse of other validated subject information falls from 825 to 398 days from 15 March 2026. The ballot's rationale is that a certificate is a point-in-time statement that grows less accurate as it ages, and that "Certificate status services, such as CRLs and OCSP, are technologies which do not adequately protect relying parties at the current scale of the internet". Shorter lifetimes protect users whether or not revocation works.

Some CAs are going further. Let's Encrypt announced six-day certificates, generally available from January 2026, which carry no OCSP or CRL URLs at all, and it switched off its OCSP responders in August 2025 in favour of CRLs, citing the privacy cost of OCSP. Any client software that still depends on OCSP for public certificates needs checking. The 10-day domain validation reuse limit from 2029 also means DNS and HTTP validation must be automated, not just the certificate request.

Common failure patterns

• Expiry outages: a forgotten certificate expires and takes down a service or partner integration. Shorter lifetimes make this weekly risk rather than an annual one unless renewal is automated and monitored.
• Unknown certificates: certificates issued by teams directly from public CAs or internal CAs outside central visibility, with no owner when they fail.
• Private key exposure: keys stored in code, shared file systems, container images or backups. In the ASP.NET Machine Key Attacks 2025, Microsoft found more than 3,000 publicly disclosed machine keys copied from documentation and repositories, one used to deliver the Godzilla framework.
• Signing keys left active: in the Storm-0558 case a 2016 consumer signing key that should have been retired in 2021 was still valid; manual rotation had stopped after an outage, according to the CSRB as reported by BleepingComputer.
• Code signing keys within reach of production: after the AnyDesk Breach 2024, AnyDesk revoked its code signing certificate; Akamai advised that earlier versions were signed with the revoked certificate.
• One certificate, many tenants: in the Mimecast Certificate Compromise 2021, a certificate Mimecast issued so its products could connect to customers' Microsoft 365 Exchange services was stolen and used against a small number of tenants.
• Wildcard certificates shared across many systems, so one compromised server exposes the key for all of them.
• Trust store sprawl: outdated, test or unnecessary CAs trusted by applications, containers and devices long after they were needed.

Building certificate lifecycle management

1. Discover and inventory

• Scan networks, cloud load balancers, Kubernetes secrets and service meshes for certificates; import CA issuance records and Certificate Transparency (CT) log entries for your domains. RFC 9162 describes CT as allowing anyone to "audit certification authority (CA) activity and notice the issuance of suspect certificates".
• Inventory internal CAs, trust stores, SSH CAs, code signing keys and token signing keys, including those in Active Directory Certificate Services.
• Record owner, application, location, issuer, expiry, key algorithm, key size and key storage for each certificate.

2. Assign ownership and policy

• Every certificate has an owning team; certificates without owners are investigated, not left to expire. See the NHI Ownership Guide.
• Define approved CAs, algorithms, key sizes, maximum lifetimes and key storage requirements, aligned with NIST SP 800-57 key management guidance.
• Restrict wildcard certificates and require separate certificates per service; publish CAA records naming the CAs allowed to issue for your domains.

3. Automate issuance and renewal

• Use ACME (RFC 8555) with public and internal CAs wherever supported, and native integrations for cloud load balancers, Kubernetes certificate controllers and service meshes.
• Support ACME Renewal Information (RFC 9773), which lets a CA suggest a renewal window; the RFC notes a CA can use it to ask clients to renew "prior to a mass-revocation event".
• Renew well before expiry at a randomised time, generate a new key at each renewal, and alert when automation fails rather than when the certificate expires.

4. Protect private keys

• Generate keys on the endpoint and keep them there; avoid exporting them.
• Use hardware security modules or cloud key management for CA keys, code signing keys, token signing keys and other high-value keys, with separate administration from production.
• Never store private keys in source code, images or shared storage; scan for them. See the Secrets Management Guide.

5. Go short-lived internally

Internal PKI does not have to follow public CA timelines. SPIFFE is built around short-lived identity documents delivered through a workload API, and service meshes rotate workload certificates automatically, so a stolen key has little value and revocation matters less. The Baseline Requirements now define a "Short-lived Subscriber Certificate" as one valid for seven days or less when issued from 15 March 2026; internal workloads can go shorter still.

6. Plan for revocation

Revocation checking is unreliable in many clients, which the SC-081v3 rationale itself acknowledges, and is another reason to prefer short lifetimes. For high-value identities such as client certificates for partners and administrators, test that revocation actually stops access, and keep a runbook for mass replacement if a CA or key is compromised. For Microsoft PKI specifically, see the Active Directory Certificate Services (AD CS) Security Guide.

Workload, device and AI agent certificates

Certificates are increasingly the identity behind non-human actors that are not servers at all. Kubernetes workloads, IoT fleets, CI/CD runners and AI agent runtimes all need to prove what they are to the services they call.

• Workloads: issue identity at start-up through the platform (SPIFFE, mesh or cloud workload identity) rather than baking certificates into images. See the Kubernetes NHI Security Guide.
• Devices: plan for devices that cannot renew easily; long-lived device certificates need hardware key storage and a tested replacement path. See the Device and IoT Identity Guide.
• AI agents: an agent runtime that calls tools and APIs should present a workload certificate or federated token unique to that agent, not a shared client certificate or a long-lived key in its configuration. Mutual TLS with certificate-bound tokens (RFC 8705) means a stolen access token is useless without the key. See the AI Infrastructure Workload Identity Guide.

Detection and monitoring

• Expiry and renewal failures: alert on failed automated renewals and on any certificate inside its final third of life, not only at seven days.
• Unexpected issuance: monitor CT logs for certificates issued for your domains by CAs you do not use, or for names you did not request.
• Key reuse and weak keys: flag certificates renewed with the same key, deprecated algorithms or short RSA keys.
• Private keys in the wrong place: secret scanning of repositories, images and file shares for PEM and PFX material.
• Signing key use: log every code signing and token signing operation, with an owner who reviews unexpected volume or callers.
• Trust store changes: detect new CAs added to system, container and application trust stores.

Framework mapping

This is an indicative NHI Mgmt Group alignment, not an official crosswalk. Control IDs were checked against NIST CSF 2.0, the NIST SP 800-53 Rev. 5 control list, the CIS Controls v8.1 control list and the OWASP NHI Top 10 (2025); ISO/IEC 27001:2022 Annex A numbers and names come from a published Annex A index.

Metrics that show progress

Implementation roadmap

Preparing for post-quantum cryptography

NIST published its first three post-quantum standards in August 2024: FIPS 203 (ML-KEM) for key establishment, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures, with SLH-DSA intended as a backup to ML-DSA. NIST's mathematician Dustin Moody urged administrators to "start integrating them into their systems immediately, because full integration will take time". Under the transition timeline in draft NIST IR 8547, NIST says it "will deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems transitioning much earlier". Organisations should:

• Build a cryptographic inventory, starting from the certificate and key inventory above.
• Prioritise long-lived secrets, long-lived device certificates and data that must stay confidential for many years.
• Make PKI and applications crypto-agile, able to change algorithms without redesign; shorter certificate lifetimes help, because every renewal is a chance to change algorithm.
• Track CA, browser and library support for post-quantum and hybrid certificates before committing to dates.

See the Post-Quantum Cryptography Migration Guide and the Post-Quantum Readiness Guide.

Practitioner checklist

• Inventory all public and internal certificates, CAs, trust stores and signing keys, with owners.
• Set policy for CAs, algorithms, key sizes, lifetimes and key storage, and publish CAA records.
• Automate issuance, renewal and domain validation with ACME and platform integrations before March 2027.
• Support ACME Renewal Information so CAs can bring renewals forward.
• Generate new keys on renewal and keep private keys on the endpoint or in HSM or KMS.
• Put CA, code signing and token signing keys in hardware, out of reach of production compromise.
• Use short-lived certificates for internal workload and agent identity.
• Remove dependence on OCSP where public CAs have dropped it.
• Monitor renewal failures, CT logs, key reuse and trust store changes.
• Rehearse mass certificate replacement after a CA or key compromise.
• Start a post-quantum readiness plan based on your cryptographic inventory.

Standards and references

• CA/Browser Forum: Ballot SC081v3, Introduce Schedule of Reducing Validity and Data Reuse Periods
• CA/Browser Forum: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates
• IETF: RFC 8555, Automatic Certificate Management Environment (ACME)
• IETF: RFC 9773, ACME Renewal Information (ARI) Extension
• IETF: RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• IETF: RFC 9162, Certificate Transparency Version 2.0
• NIST: Post-Quantum Cryptography project
• NIST: IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards
• NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
• SPIFFE: SPIFFE Overview
• Let's Encrypt: Ending OCSP Support in 2025
• Let's Encrypt: Announcing Six Day and IP Address Certificate Options

Related NHI Mgmt Group resources: NHI Authentication Guide · Cryptographic Key Management Guide · Secrets Management Guide · Ultimate Guide to Non-Human Identities