Modern PKI at cloud scale is now an identity governance issue

At a glance

What this is: This case study shows how cloud-scale PKI modernization changes digital trust from a back-end security task into an identity governance problem.

Why it matters: It matters because IAM, NHI, and platform teams now have to govern certificates, service authentication, and auditability as part of the same trust lifecycle.

By the numbers:

• Zscaler's platform supports more than 50 million users and hundreds of billions of transactions each day.

👉 Read DigiCert's case study on how Zscaler scaled cloud trust with DigiCert ONE

Context

Modern PKI is the system that issues, validates, and renews certificates that establish trust between services, users, and devices. In cloud-first environments, that function is no longer a background utility. It becomes part of identity governance because the pace of certificate issuance, rotation, and revocation now determines whether the trust layer can keep up with the environment it protects.

The governance gap is not whether PKI exists, but whether it can scale with short-lived credentials, automation, and distributed service-to-service traffic. When certificate operations stay manual or fragmented, policy consistency and auditability begin to erode. That creates a direct connection to NHI governance, workload identity, and zero trust programmes that depend on machine-held trust material.

Key questions

Q: How should security teams govern PKI when cloud workloads scale rapidly?

A: They should treat PKI as identity governance infrastructure, not just cryptography. That means automating issuance, renewal, and revocation, separating root trust from routine operations, and assigning clear ownership for certificate policy and audit evidence. Once workloads scale quickly, manual administration becomes a trust risk as much as an efficiency problem.

Q: Why do short-lived certificates still need strong governance?

A: Short-lived certificates reduce exposure windows, but they also increase dependence on reliable lifecycle automation and policy enforcement. Without that governance, certificate churn can create outages, inconsistent trust decisions, and hidden exceptions. The issue is not certificate duration alone. It is whether the lifecycle can operate consistently at machine speed.

Q: What breaks when mTLS is expanded without lifecycle automation?

A: mTLS becomes brittle when issuance and renewal are handled manually or inconsistently. Services may fail closed, renewals may be delayed, and teams may create risky exceptions to keep traffic flowing. In that state, the trust layer depends on human intervention rather than continuous control, which undermines the value of the protocol.

Q: How do identity teams align certificate governance with zero trust?

A: They should connect certificate hierarchy, lifecycle controls, and audit ownership to the same zero trust programme that governs workload and service identity. A unified model makes trust decisions repeatable across product lines and reduces drift between environments. If certificates are managed outside that programme, assurance becomes inconsistent.

Technical breakdown

Why cloud-scale PKI breaks under legacy operating models

PKI relies on certificate authorities, key protection, issuance policy, and revocation handling to establish cryptographic trust. In older environments, the volume of certificates was manageable enough for manual workflows and local administration. Cloud-native systems change that equation because microservices, APIs, and workloads constantly appear, disappear, and reissue trust material. Legacy or homegrown PKI often fails not because cryptography is weak, but because the operating model assumes slow-moving infrastructure. Once trust becomes continuous and distributed, certificate lifecycle management becomes the core control plane.

Practical implication: map certificate volume, renewal frequency, and manual touchpoints before the trust fabric outgrows current governance.

How mTLS depends on automated certificate lifecycle control

Mutual TLS authenticates both sides of a connection using certificates rather than passwords or static tokens. That makes it well suited to service-to-service traffic, but only if issuance, renewal, and rotation are automated and policy-driven. If certificates are renewed manually, the authentication layer becomes brittle and operationally expensive. Short-lived certificates reduce exposure windows, yet they also increase dependency on stable automation, reliable APIs, and strong root key isolation. In practice, mTLS is less a protocol choice than a lifecycle discipline.

Practical implication: use automated issuance and rotation as a prerequisite for mTLS, not as an afterthought.

What unified PKI architecture changes for zero trust

Zero trust requires continuous verification, and PKI provides the cryptographic identity signals that make that possible across services and workloads. A unified architecture separates root and intermediate certificate authorities, keeps root keys highly isolated, and uses online intermediates for scalable issuance. That design reduces operational burden while preserving assurance boundaries. The important shift is governance: instead of treating certificates as infrastructure artefacts, teams have to manage them as identity assets with lifecycle, policy, and audit requirements attached.

Practical implication: align certificate governance with zero trust architecture so identity assurance stays consistent across every product or service line.

NHI Mgmt Group analysis

Cloud-scale PKI is now an identity governance control, not a backend utility. The article shows that once a platform supports tens of millions of users and massive transaction volumes, certificate operations become part of trust governance. Manual issuance and fragmented authority structures cannot sustain that scale without weakening policy consistency and auditability. The implication is that PKI ownership increasingly belongs in identity programmes, not only in infrastructure teams.

Short-lived certificates only work when the lifecycle is fully automated. The piece highlights API-driven issuance, renewal, and rotation as the operating model that makes distributed trust sustainable. That is the real lesson for NHI and workload identity teams: cryptographic trust fails if the lifecycle still depends on human timing. Practitioners should treat certificate automation as a control boundary, not a convenience feature.

Unified root and intermediate CA design is a governance pattern for zero trust maturity. Separating root key isolation from scalable intermediate issuance creates the assurance structure cloud environments need. This is not just a PKI architecture choice, it is a trust segmentation model that supports policy, resilience, and audit requirements together. Teams should view certificate hierarchy design as part of zero trust governance, not as an isolated security engineering detail.

Reusable trust infrastructure changes how organisations should think about product sprawl. When one PKI foundation can support multiple product lines, the governance win is consistency across identity, encryption, and assurance controls. That reduces duplicated trust logic and lowers the chance of policy drift across environments. The practical conclusion is that certificate governance should be standardised at platform level wherever multiple services share the same trust boundary.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
• For teams modernising trust at scale, our Ultimate Guide to NHIs , Why NHI Security Matters Now explains why lifecycle governance has become a core control concern.

What this signals

Cloud-scale PKI and workload identity are converging into the same governance problem: how to keep machine trust continuous without creating manual choke points. Certificate lifecycle debt: when issuance, renewal, and revocation are not automated, the trust layer eventually becomes slower than the environment it is meant to secure. That is why certificate governance now needs the same operational discipline as access governance.

With 27 days needed on average to remediate a leaked secret, per The State of Secrets in AppSec, the broader lesson is that trust operations cannot rely on slow response cycles. The same expectation should shape PKI and workload identity programmes, especially where service authentication depends on short-lived credentials and consistent policy enforcement.

Identity teams should expect more pressure to unify certificate governance, workload identity, and zero trust controls under a single operating model. Use NIST Cybersecurity Framework 2.0 to anchor ownership across identify, protect, detect, and recover functions, then keep certificate lifecycle evidence tied to the programme that owns machine trust.

For practitioners

• Inventory certificate lifecycle bottlenecks Map where certificate issuance, renewal, and revocation still require manual intervention, then quantify the backlog risk for each service tier.
• Separate root trust from operational issuance Keep root keys tightly isolated while using online intermediates for routine certificate issuance so scale does not weaken assurance boundaries.
• Treat mTLS as an automation dependency Do not expand mutual TLS into new service domains until renewal and rotation are API-driven and failure handling is tested under load.
• Align PKI governance with zero trust policy Document who owns certificate policy, audit evidence, and exception handling so PKI control sits inside the zero trust programme rather than beside it.

Key takeaways

• Cloud-scale PKI becomes an identity governance issue when certificate lifecycle operations must keep pace with distributed services.
• Automation, root isolation, and auditable certificate policy are the controls that keep mTLS and zero trust trustworthy at scale.
• Identity teams should govern certificates as reusable trust assets, not as isolated infrastructure artefacts.

Key terms

• Public key infrastructure: Public key infrastructure is the trust system that issues, manages, and validates digital certificates for users, devices, services, and workloads. In practice, it governs how cryptographic identity is established and how trust is renewed or revoked as environments change.
• Mutual TLS: Mutual TLS is a protocol where both sides of a connection prove their identity using certificates. It is commonly used for service-to-service trust because it removes passwords from the path, but it only works reliably when certificate lifecycle operations are automated and consistent.
• Certificate lifecycle management: Certificate lifecycle management is the process of issuing, renewing, rotating, revoking, and auditing certificates across an environment. It matters because trust breaks down quickly when those actions are manual, inconsistent, or disconnected from the systems that depend on them.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: How Zscaler Scaled Cloud Trust with DigiCert ONE. Read the original.