What breaks when certificate management stays manual in a Zero Trust programme?

Why This Matters for Security Teams

Manual certificate handling breaks the operating model behind zero trust because certificates are not just artifacts, they are proof of identity, freshness, and trust state. When issuance, renewal, and revocation depend on ticket queues or spreadsheets, the environment drifts away from the continuous verification model described in NIST SP 800-207 Zero Trust Architecture. That creates stale trust decisions, delayed offboarding, and blind spots in audit evidence.

The risk is especially acute for machine identities because they scale faster than human identity programs and often change ownership, environment, and privilege without warning. NHIMG research shows that 61% of organisations still rely on spreadsheets or manual tracking for machine identity management, and only 38% have automated certificate lifecycle management in place, according to the Critical Gaps in Machine Identity Management report. In practice, many security teams discover this only after an expired certificate disrupts production or a revoked credential remains trusted long after the underlying workload should have lost access.

How It Works in Practice

Zero Trust assumes trust is evaluated continuously and contextually, not granted once and left to age. For certificates, that means the identity layer must be able to issue, bind, rotate, and revoke credentials automatically as workloads appear, change, and disappear. Manual processes fail because they cannot keep pace with ephemeral services, CI/CD pipelines, and hybrid infrastructure where certificates may need to be renewed dozens or hundreds of times before a human can review a change request.

A practical approach is to anchor machine identity in workload identity, then treat certificates as short-lived proof of that identity rather than long-lived assets to be babysat. The Guide to SPIFFE and SPIRE is useful here because it frames identity issuance around cryptographic workloads instead of human-centric account administration. Paired with policy-based enforcement and automation, this allows certificate issuance and revocation to happen as part of the workload lifecycle, not as a separate administrative task.

• Use automated enrollment so new workloads receive certificates at creation time, not after a manual request cycle.
• Set short certificate TTLs so trust decays quickly and revocation windows shrink.
• Bind certificates to workload identity and environment context, not to a static server name alone.
• Continuously inventory certificates, owners, and dependency paths to support audit and incident response.
• Trigger automated revocation when workloads are terminated, re-platformed, or moved across trust zones.

This aligns with broader NHI lifecycle guidance in the NHI Lifecycle Management Guide and supports the identity freshness expected by Zero Trust architectures. These controls tend to break down in large legacy estates where certificates are embedded in appliances, hard-coded into applications, or governed by change processes that cannot safely automate renewal.

Common Variations and Edge Cases

Tighter certificate control often increases operational complexity at first, requiring organisations to balance stronger trust hygiene against legacy dependency risk. That tradeoff is real, and current guidance suggests there is no universal standard for how fast every certificate should rotate, because the right TTL depends on workload criticality, deployment frequency, and recovery maturity.

Some environments need special handling. Long-lived internal services may tolerate slower renewal if they are isolated and closely monitored, while internet-facing workloads generally benefit from much shorter lifetimes and automated revocation. Certificates used by third-party integrations can be harder to govern because ownership is shared and revocation may affect business continuity. In those cases, the priority is not perfect uniformity, but explicit ownership, visible expiry dates, and a tested recovery path.

Manual management also fails differently depending on the architecture. In cloud-native systems, it tends to create renewal storms and hidden outages. In heavily regulated environments, it creates incomplete evidence because the team cannot prove who approved issuance, when revocation occurred, or whether stale credentials were still valid during an incident. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Regulatory and Audit Perspectives both reinforce that lifecycle visibility matters as much as issuance speed.

Where automation is partial, the programme often looks compliant on paper but still depends on manual rescue during outages, which is where Zero Trust discipline usually collapses first.

Related resources from NHI Mgmt Group

• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?
• Why do NHIs complicate zero trust and least privilege efforts?
• What is the difference between zero trust for users and zero trust for NHIs?