How should security teams manage certificates consistently across AWS, Azure, and Google Cloud?

Why This Matters for Security Teams

Certificate management across AWS, Azure, and Google Cloud fails most often when teams treat each platform as a separate ownership domain instead of one machine-identity problem. Certificates are operational controls, but they also define trust between services, workloads, and external users. When expiry, issuer policy, or key strength drifts by cloud, the result is not just inconsistency. It is outage risk, hidden privilege paths, and audit evidence that does not reconcile cleanly across environments. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs frames this as a lifecycle problem, not a storage problem, and the distinction matters for shared responsibility across cloud teams. NIST’s Cybersecurity Framework 2.0 also reinforces that asset visibility and continuous governance are core security functions, which is exactly where certificate programs tend to fragment. SailPoint research cited by NHIMG reports that 57% of organisations lack a complete inventory of machine identities, and certificate expiry is the leading cause of outages for 45% of organisations. In practice, many security teams discover the mismatch only after a workload goes offline or a renewal window has already closed, rather than through intentional lifecycle control.

How It Works in Practice

A consistent certificate program starts with one inventory, one policy set, and three cloud-native execution paths. The inventory should record issuer, subject, SANs, environment, owner, workload dependency, renewal date, and where the certificate is deployed. Policy should define minimum key strength, approved algorithms, maximum lifetime, auto-renewal thresholds, and exception handling. The cloud-specific detail belongs in the delivery layer, not the policy layer. A practical model looks like this:

• Use a central source of truth for certificate metadata and ownership.
• Classify certificates by use case: ingress, service-to-service, workload, or client authentication.
• Apply the same validation rules before issuance in AWS, Azure, and Google Cloud.
• Trigger renewal automatically through each platform’s native mechanism, rather than through manual ticketing.
• Log renewal status, failed issuance, and revocation into a common monitoring workflow.

For governance, NIST SP 800-53 Rev. 5 supports control families that map well to key management, access enforcement, and auditability, while NHIMG’s NHI Lifecycle Management Guide is useful for aligning certificate handling with broader non-human identity lifecycle discipline. The operational goal is simple: prevent each cloud from inventing its own certificate policy. That means Azure Key Vault, AWS Certificate Manager, and Google Cloud certificate services should be treated as execution back ends, with the same policy decisions flowing into each. These controls tend to break down when teams allow application teams to create ad hoc certificates outside the central workflow because ownership and expiry tracking become inconsistent across cloud boundaries.

Common Variations and Edge Cases

Tighter certificate governance often increases operational overhead, requiring organisations to balance standardisation against application and platform constraints. Not every certificate should be handled the same way. Public TLS certificates, internal service certificates, client-auth certificates, and code-signing certificates often have different renewal cadences and approval requirements. Best practice is evolving for short-lived certificates, especially where workload identity and automated issuance are available, but there is no universal standard for this yet across all cloud-native stacks. Edge cases usually appear in hybrid and multi-account environments. Legacy applications may pin certificate chains or require manual trust store updates, which makes fast rotation risky. Cross-cloud APIs may depend on certificates issued by different internal CAs, and some compliance programs require evidence of issuer approval or geographic controls that differ by workload. In those cases, policy should still stay uniform even if the exception path does not. NHIMG’s Top 10 NHI Issues is a useful reminder that poor visibility and manual tracking are persistent failure modes, not rare exceptions. For teams handling high-value cloud workloads, the issue is less about which certificate store is used and more about whether every certificate is traceable, renewable, and revocable from one governance model. In practice, that model usually breaks down first in environments with inherited accounts, unmanaged service principals, or certificates created directly by application teams outside security’s approval path.

Related resources from NHI Mgmt Group

• How should security teams govern multi-cloud access across AWS, Azure, and GCP?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• How should security teams make NHI best practices usable across the business?