Because they were built for static environments and manual control paths. Cloud sovereignty demands automated issuance, renewal, revocation, and auditability across distributed environments, which exposes certificate sprawl and inconsistent governance when older PKI processes are moved without redesign.
Why cloud sovereignty breaks the old PKI operating model
Traditional PKI assumes certificates are issued and tracked through relatively stable systems, with humans or tightly controlled administrators handling renewal and revocation. Cloud sovereignty changes the operating model: identities, workloads, regions, and trust boundaries move faster than manual PKI processes can follow. The real issue is not cryptography, it is control-plane fit.
That is why certificate management becomes a governance problem as much as a technical one. When certificate issuance, renewal, and revocation stay manual, the organisation can end up with blind spots across cloud tenants, regions, and providers. NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide is useful here because it frames certificates as a lifecycle problem rather than a one-time provisioning task.
Cloud sovereignty also raises the bar for auditability. A PKI model built for a small number of servers can tolerate slower review cycles and centralised approval paths; a sovereign cloud model usually cannot. If you cannot prove where a certificate came from, who approved it, how long it remains valid, and how it is rotated or revoked, the sovereignty claim is weak even if the underlying cryptography is strong.
Where the failure shows up in practice
The most common failure is certificate sprawl. Teams create new workloads, clusters, APIs, and service paths faster than PKI teams can inventory them, so certificates accumulate across environments with inconsistent owners and renewal dates. That makes expiry outages, duplicate trust anchors, and orphaned certificates more likely.
Another failure mode is policy drift. Cloud environments often use different issuance patterns for internal services, external endpoints, and cross-region replication. Without redesign, older PKI controls are applied inconsistently, which creates mismatched validity periods, weak revocation handling, and exceptions that are hard to reconcile during audits.
Cloud sovereignty also depends on locality and operational control. Traditional PKI often assumes a central CA and a central approval process. In sovereign deployments, the business may need region-specific trust boundaries, constrained administrative access, and clearer evidence that certificate operations do not bypass policy or residency expectations. The CA/Browser Forum is relevant because it reflects the modern baseline pressure toward shorter-lived public certificates and tighter lifecycle discipline.
What redesign actually means for PKI
Redesign usually means shifting from manual certificate administration to automated lifecycle management. Issuance should be tied to workload identity and deployment events, renewal should be automatic well before expiry, revocation should be operationally reliable, and inventory should be continuous rather than periodic. That is the only way PKI stays usable when environments are distributed and change quickly.
Key management and certificate handling also need to be treated as separate but connected disciplines. The private key must remain protected while the certificate lifecycle is automated, otherwise faster issuance only increases blast radius. NIST SP 800-57 Key Management is the right anchor for the lifecycle side of that problem, because it ties cryptoperiods, rotation, and key handling to operational control.
In practice, sovereignty-friendly PKI also needs strong machine-to-machine authentication patterns. Where service identities or APIs are involved, the certificate is part of a larger trust chain that includes issuance policy, storage, rotation, and access control. That is why modern programs increasingly align certificate governance with NIST Cybersecurity Framework 2.0 functions such as govern, identify, protect, detect, and recover, rather than treating PKI as a standalone utility.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-57 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management Recommendations | Cloud sovereignty depends on disciplined key and certificate lifecycle control. |
| Recommendation — Apply key-rotation and cryptoperiod rules that keep certificate lifecycles governable across clouds. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | PKI sovereignty depends on aligning certificate operations to the cloud operating model. |
| PR.DS-04 — Data is managed consistent with risk strategy | Certificates and keys must be handled under policy, not ad hoc operational convenience. | |
| Recommendation — Define certificate ownership and lifecycle responsibility in the cloud governance model. Enforce certificate and key handling rules that match the organisation's risk strategy. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Certificate systems require controlled administrative access and authoritative ownership. |
| Recommendation — Restrict certificate administration to approved roles and controlled access paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Old PKI models often leave certificates valid too long for cloud dynamics. |
| Recommendation — Shorten certificate lifetimes and automate renewal to reduce long-lived credential exposure. | ||
Practitioner Guidance
What to prioritise: inventory all certificate-using workloads before you migrate PKI assumptions into cloud. If you cannot answer who owns each certificate, where it is deployed, and what rotates it, the model is already out of sync with the environment.
What to verify: make sure renewal, revocation, and audit evidence are automated enough to survive scaling. A sovereign cloud design should be able to prove lifecycle state without relying on tribal knowledge, spreadsheet tracking, or a single administrator’s memory.
Common mistake: teams often modernise the CA but leave the operating model unchanged. That creates faster issuance without better governance, which usually increases sprawl rather than reducing it.
Practitioner takeaway: cloud sovereignty is not achieved by using certificates in the cloud, it is achieved by making certificate lifecycle, ownership, and evidence machine-operable at cloud speed.
Related resources from NHI Mgmt Group
- Why do traditional IAM models struggle when organizations need fine-grained control across cloud, SaaS, and legacy systems?
- How should teams secure non-human identities across cloud and SaaS?
- Why do cloud consoles complicate traditional PAM models?
- Why do traditional DLP controls struggle in cloud and AI workflows?