Cloud-Based Certificate Management

Cloud-based certificate management is the practice of discovering, issuing, renewing, revoking, and auditing digital certificates across cloud infrastructure, containers, and hybrid environments from a centralized platform. It matters because cloud environments generate certificates at a scale and velocity that manual tracking cannot keep pace with, and a single expired certificate in a load balancer or API gateway causes a complete service outage. The recommended action is to deploy a centralized certificate lifecycle management (CLM) platform with automated ACME-based renewal before the CA/Browser Forum’s SC-081v3 schedule reduces TLS certificate validity to 47 days by March 2029.

Quick Answer: What Does Cloud-Based Certificate Management Require?

Cloud-based certificate management requires four capabilities working together: continuous discovery of all certificates across every cloud account, region, and service so no certificate is invisible to the security team; automated renewal through ACME or cloud-native APIs before certificates expire; private key protection in hardware-backed key stores rather than in application configuration or environment variables; and a centralized audit log of every issuance, renewal, and revocation event tied to an authenticated identity. Each of these is necessary independently; none is sufficient alone.

Key Takeaways

• Certificate sprawl is the primary cloud CLM risk: Cloud auto-scaling, containers, and microservices generate certificates programmatically, often without IT visibility. Most organizations discover they have three to five times more certificates than they believed once they run a full cloud discovery scan.
• Shorter validity deadlines make automation mandatory: The CA/Browser Forum SC-081v3 schedule reduces maximum TLS certificate validity to 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029. At 47-day validity, manual renewal is operationally impossible at any meaningful scale.
• Native cloud CLM and third-party CLM serve different scopes: Native services (AWS Certificate Manager, Azure App Service certs, GCP Certificate Manager) automate renewal within one cloud provider’s ecosystem. Third-party CLM platforms provide unified visibility and policy enforcement across all cloud providers, on-premises systems, and certificate types.
• Private key protection is as important as certificate renewal: An automated renewal process that stores the new private key in plaintext in an environment variable or config file creates a worse security posture than the expired certificate it replaced.
• Compliance frameworks now explicitly require certificate governance: PCI DSS v4.0.1 (mandatory March 2025), DORA (applicable January 2025), HIPAA, FedRAMP, and GDPR all require documented certificate lifecycle controls, not just encryption in transit.

What Is Cloud-Based Certificate Management?

A digital certificate is a cryptographic credential that binds a public key to an identity (a domain name, a service, a device, or a person) and is signed by a Certificate Authority (CA) to make that binding trustworthy to relying parties. TLS/SSL certificates are the most common type in cloud environments: they authenticate web servers, API endpoints, load balancers, and internal microservices to clients, and they encrypt the connection between them.

Cloud-based certificate management covers the complete lifecycle of these certificates in cloud environments: discovery (finding every certificate in every cloud account and region), issuance (requesting certificates from a public or private CA), deployment (installing certificates on the right endpoints), renewal (replacing certificates before they expire), revocation (invalidating compromised or decommissioned certificates), and audit (logging every lifecycle event for compliance evidence). Managing this lifecycle manually through spreadsheets and calendar reminders fails in cloud environments where certificates number in the thousands and their validity periods are shortening toward 47 days.

Why Cloud Environments Make Certificate Management Harder

On-premises environments typically have a bounded, relatively static inventory of servers and services, each running certificates with validity periods of one to two years. Cloud environments are fundamentally different in four ways that each compound the certificate management problem.

Scale and velocity: Auto-scaling groups, container orchestration platforms (Kubernetes), serverless functions, and microservice deployments generate and consume certificates programmatically. A single Kubernetes cluster can run hundreds of pods, each with its own service certificate, with pods being created and destroyed continuously. The certificate inventory in a cloud environment changes faster than any manual process can track.

Distributed ownership: In cloud environments, certificates are provisioned by application teams, DevOps pipelines, platform engineering teams, and sometimes individual developers, often without central IT involvement. This creates shadow certificate inventories that the security team cannot see, which means certificates expire without warning and private keys are stored insecurely in application repositories.

Multi-cloud and hybrid complexity: Most enterprises run workloads across AWS, Azure, and GCP simultaneously, alongside on-premises infrastructure. Each cloud provider has its own native certificate services with different APIs, different certificate types, and different renewal mechanisms. Managing certificate policy consistently across this landscape requires a management layer above the individual cloud providers.

Shrinking validity windows: The CA/Browser Forum Ballot SC-081v3 reduces the maximum validity of publicly trusted TLS certificates on a phased schedule: 200 days starting March 15, 2026; 100 days starting March 15, 2027; and 47 days starting March 15, 2029. At 47-day validity, every certificate in a large cloud estate must renew approximately eight times per year. This makes automated renewal not a best practice but an operational necessity.

Native Cloud CLM vs. Third-Party CLM Platform: What Each Covers

Every major cloud provider offers a native certificate management service. Understanding what each covers and where each stops is essential before choosing a CLM strategy.

AWS Certificate Manager (ACM): Issues and automatically renews public TLS certificates for AWS resources (Elastic Load Balancers, CloudFront distributions, API Gateway, Elastic Beanstalk). Private keys are managed by AWS in HSM-backed storage and are never exposed; you cannot export them. ACM also supports a Private CA add-on for issuing private certificates. ACM does not manage certificates on non-AWS infrastructure, does not provide visibility into certificates deployed to EC2 instances directly, and does not manage certificates from third-party CAs outside the ACM ecosystem.

Azure Key Vault Certificates: Stores, manages, and auto-renews certificates within Azure Key Vault, with integration to Azure services (App Service, Application Gateway, Front Door). Supports certificates from DigiCert and GlobalSign through Key Vault’s CA partner integrations, and supports importing certificates from other CAs. Azure Key Vault does not manage certificates in AWS or GCP environments, and visibility into certificates outside Key Vault requires additional tooling.

GCP Certificate Manager: Manages SSL certificates for Google Cloud load balancers and Cloud CDN, with ACME-based automated renewal for Google-managed certificates. GCP Certificate Authority Service (CAS) provides a managed private CA for issuing internal certificates. GCP Certificate Manager does not manage certificates in non-GCP environments.

The scope limitation of each native service is the same: it manages certificates within its own cloud provider’s ecosystem. An organization running workloads across all three providers has three separate certificate silos with no unified inventory, no consistent policy enforcement, and no single audit log.

Capability	Native Cloud CLM (per provider)	Third-Party CLM Platform
Certificate discovery scope	Within one cloud provider only	All cloud providers, on-premises, SaaS
Certificate types managed	TLS for that provider’s resources	TLS, code signing, S/MIME, device, SSH
CA integrations	Provider’s own CA (and limited partners)	Any public CA, any private CA, ACME
Automated renewal	Yes (within that provider)	Yes (across all providers via ACME/API)
Unified policy enforcement	No (per-provider only)	Yes (single policy across all environments)
Centralized audit log	No (per-provider logs only)	Yes (single audit trail for compliance)
Private key visibility	Managed by provider (not exportable in ACM)	Configurable; HSM-backed options available
Best for	Single-cloud, simple workloads	Multi-cloud, regulated, large-scale estates

Private Key Protection in Cloud Certificate Management

Private key compromise is a more severe security event than certificate expiry. An expired certificate causes an outage; a compromised private key can enable an attacker to impersonate your service, decrypt historical traffic, or sign malicious content. Cloud environments create several private key exposure risks that on-premises deployments typically do not face.

The most common cloud private key exposure vectors are: private keys stored in plaintext in application configuration files or environment variables that are visible in version control; private keys included in container images that are pushed to public or shared registries; private keys stored in S3 buckets, Azure Blob containers, or GCS buckets with overly permissive access policies; and private keys in CI/CD pipeline secrets that are accessible to all pipelines in a repository without scope restriction.

The correct architecture for private key protection in cloud environments depends on whether the private key needs to be accessible to the application at runtime or not.

Keys managed by the cloud CLM service (not accessible to application): For TLS certificates on load balancers, API gateways, and CDN endpoints, use the cloud provider’s native certificate management service. AWS ACM, Azure Key Vault Certificate integration, and GCP Certificate Manager store private keys in HSM-backed infrastructure and present the certificate to the service without exposing the private key to the application or to any IAM principal. This is the most secure model and should be used wherever the application does not need direct key access.

Keys accessible to the application at runtime: For mutual TLS (mTLS) between services, code signing, or certificate types where the application must perform cryptographic operations directly, store the private key in a cloud secrets manager (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager). Rotate the secret on the same schedule as the certificate renewal. Never store the key as a Kubernetes secret in plaintext YAML; use an external secrets operator to inject it from the secrets manager at pod startup.

For the highest key protection requirements (FIPS 140-2 Level 3, FedRAMP High, or classified workloads), use a dedicated Hardware Security Module (HSM) to generate and store private keys. Cloud providers offer HSM-backed key storage through AWS CloudHSM, Azure Dedicated HSM, and GCP Cloud HSM, and Encryption Consulting’s HSM as a Service provides dedicated FIPS 140-2 Level 3 HSM infrastructure that integrates with cloud certificate management workflows.

IAM Model for Cloud Certificate Management

Access control for cloud certificate management should apply least privilege at three levels, separating who can issue certificates, who can access private keys, and who can manage the CLM platform itself.

Certificate issuance permissions: Only authorized identities (application deployment pipelines, CLM service accounts, or approved DevOps roles) should be able to request certificate issuance from the CA. In AWS ACM, this means IAM policies granting acm:RequestCertificate only to specific roles. In Azure Key Vault, this means Key Vault Certificates Officer role assignment to specific service principals. Developers and application runtime roles should not have certificate issuance permissions.

Private key access permissions: Access to private keys stored in secrets managers or Key Vault should be scoped to the specific application identity that needs the key, using resource-level permissions rather than broad secrets manager read access. In AWS, use Secrets Manager resource policies to restrict secretsmanager:GetSecretValue to the specific IAM role of the application. In Azure, use Key Vault access policies or RBAC to grant Key Vault Secrets User only to the specific managed identity of the application.

CLM platform administration: The ability to configure CA integrations, set certificate policies, approve issuance for sensitive certificate types, and access the CLM audit log should require a separate, audited CLM administrator role distinct from the roles used by application pipelines. No CI/CD service account should have CLM administrative permissions. Enforce MFA for all CLM administrative access.

ACME Automation: How Automated Certificate Renewal Works in the Cloud

ACME (Automatic Certificate Management Environment) is an IETF protocol defined in RFC 8555 that automates the issuance and renewal of certificates. An ACME client proves to an ACME-compatible CA that it controls a domain (or, for IP certificates, an IP address) through one of several challenge types, then receives a signed certificate without human intervention. ACME is the protocol behind Let’s Encrypt’s free public certificate issuance and is supported by an increasing number of enterprise CAs.

In cloud environments, ACME operates through three primary challenge types:

• HTTP-01 challenge: The ACME client places a token at a well-known HTTP URL on the domain being validated. The CA fetches the URL and verifies the token. This works for internet-accessible endpoints but not for internal services or wildcard certificates.
• DNS-01 challenge: The ACME client creates a TXT record in the DNS zone for the domain being validated. The CA queries DNS to verify the record. This works for wildcard certificates and for internal services where HTTP validation is not possible. Cloud DNS providers (Route 53, Azure DNS, Cloud DNS) all support programmatic DNS record creation, making DNS-01 the preferred challenge type for cloud automation.
• TLS-ALPN-01 challenge: The ACME client responds to a TLS handshake on port 443 using a special certificate containing the validation token. This is less commonly used in cloud environments due to load balancer complexity.

A production ACME deployment for cloud certificate management runs ACME client agents (such as Certbot, acme.sh, or a CLM platform’s built-in ACME client) on a schedule that renews certificates when they reach approximately 30 days remaining validity. With the SC-081v3 schedule moving to 47-day certificates by March 2029, renewal at 30 days remaining means certificates renew every 17 days, which requires fully automated renewal with no human approval step in the critical path.

When to Use a Private CA in Cloud Environments

Not every certificate in a cloud environment needs to be issued by a public CA. Publicly trusted certificates are required for any endpoint that receives connections from browsers or operating systems that trust the public root store. Internal service-to-service communication (microservice mTLS, Kubernetes internal services, API calls between backend services), developer tooling, and IoT device identity can use certificates from a private CA, which provides several advantages over public CA certificates for these use cases.

Private CA certificates are not subject to the CA/Browser Forum validity restrictions that govern public certificates. You can issue internal certificates with validity periods matched to your deployment cycle. Private CAs give you full control over the certificate profile: you can include custom extensions, Subject Alternative Names for internal DNS names and IP addresses, and Extended Key Usage values specific to your application (such as clientAuth for mTLS). Private CA issuance is also faster and does not require domain validation against external DNS.

Cloud-native private CA options include AWS Private CA (formerly ACM Private CA), which charges $400 per CA per month for a general-purpose CA or $50 per CA per month for a short-lived certificate CA, and GCP Certificate Authority Service (CAS), which provides a managed private CA with Cloud HSM-backed CA key storage. For organizations that need a private CA that spans multiple cloud providers or integrates with on-premises PKI, Encryption Consulting’s PKI as a Service provides a managed private CA with ACME support, AD Connector for Windows environments, and integration with all major cloud platforms.

Audit Logging for Cloud Certificate Management

A complete certificate management audit trail requires two log streams: certificate lifecycle events and private key access events. Compliance frameworks including PCI DSS v4.0.1, FedRAMP (NIST SP 800-53 AU controls), and DORA all require documented evidence of certificate lifecycle governance.

Certificate lifecycle logs capture every issuance, renewal, revocation, and deployment event. On AWS, ACM certificate events appear in AWS CloudTrail under the acm: event namespace. On Azure, Key Vault certificate operations are logged in Azure Monitor diagnostic logs. On GCP, Certificate Manager and CAS operations appear in Cloud Audit Logs. These logs must be enabled explicitly for data-plane operations and routed to a tamper-resistant log destination (a write-protected S3 bucket, Azure Storage Account with immutability, or GCS bucket with Object Lock).

Private key access logs capture every instance of a secret or key being read by an application or identity. In AWS Secrets Manager, every GetSecretValue call is logged in CloudTrail. In Azure Key Vault, every secret read is logged in Key Vault diagnostic logs. In GCP Secret Manager, every access is logged in Cloud Audit Logs. Alert on: any key access from an identity not in the approved application role list; any key export or download by a human identity; any revocation of a certificate that has not been renewed; and any certificate expiry within 30 days that has no pending renewal.

Multi-Cloud Certificate Management Architecture

Organizations running certificate workloads across AWS, Azure, and GCP face the same consistency problem in CLM that applies to key management: each cloud provider’s native tools are scoped to that provider. Three architecture patterns address multi-cloud certificate management:

• Centralized CLM platform with per-cloud connectors: Deploy a third-party CLM platform that connects to all three cloud providers through their respective APIs (ACM, Azure Key Vault, GCP Certificate Manager). The CLM platform maintains a unified certificate inventory, enforces consistent certificate policies (minimum key length, allowed CAs, maximum validity, required SANs), and triggers renewal through each provider’s native APIs or through ACME. This is the recommended approach for organizations with significant multi-cloud footprints and compliance requirements.
• Private CA as a single issuance root: Deploy a private CA (cloud-native or third-party) that issues certificates to all internal services across all cloud environments. All service-to-service certificates trace back to the same private root, regardless of which cloud the service runs in. Public-facing endpoints still use public CA certificates through native cloud CLM services. This provides consistency for internal certificate issuance without requiring a full third-party CLM platform.
• ACME with a shared CA across providers: Configure ACME clients on services across all cloud providers to renew from the same ACME-compatible CA. The CA may be a public CA (for public-facing certificates) or a private ACME CA (for internal certificates). Certificate policy is enforced at the CA level and applies uniformly regardless of which cloud the ACME client runs in. This approach provides the simplest automation but requires the CA to support the certificate types and profiles needed across all environments.

Compliance Requirements for Cloud Certificate Management

Several compliance frameworks now explicitly require certificate lifecycle management controls, not just encryption in transit.

PCI DSS v4.0.1 (mandatory since March 31, 2025): Requirement 4.2.1 requires all certificates used to safeguard Primary Account Number (PAN) data in transit to be confirmed as valid, trusted, and not expired. Requirement 12.3.3 requires a documented inventory of all cryptographic cipher suites and certificates used in the Cardholder Data Environment (CDE), reviewed at least once every 12 months. This requirement makes a certificate management platform that produces an inventory report a direct compliance control, not just a best practice.

DORA (Digital Operational Resilience Act, applicable January 17, 2025): Article 9 requires EU financial entities to use strong encryption and cryptographic controls, and Article 10 requires ICT-related incident detection capabilities. Certificate expiry outages that cause service unavailability are reportable ICT incidents under DORA; certificate management controls that prevent those outages are therefore a DORA ICT risk management requirement.

HIPAA: The HIPAA Security Rule Technical Safeguard 164.312(e)(2)(ii) requires encryption in transit for electronic Protected Health Information (ePHI). In cloud environments, this means maintaining valid TLS certificates on all endpoints that transmit ePHI, with documented evidence of certificate management controls.

FedRAMP (NIST SP 800-53 Rev. 5): The IA-3 (Device Identification and Authentication) control requires cloud systems to manage device identity credentials, which includes certificates used for mutual authentication. The SC-17 (Public Key Infrastructure Certificates) control requires a certificate policy covering issuance, renewal, and revocation. FedRAMP High additionally requires FIPS 140-2 or FIPS 140-3 validated cryptographic modules for certificate operations.

Cloud Certificate Management Implementation Checklist

1. Run a full certificate discovery scan: Use your CLM platform, cloud-native discovery tools, or Encryption Consulting’s CBOM Secure to discover every certificate across all cloud accounts, regions, and on-premises systems. Expect to find significantly more certificates than your current inventory shows.
2. Classify certificates by type and ownership: For each discovered certificate, identify the issuing CA, the certificate type (public TLS, private TLS, code signing, S/MIME, device), the owning team, the deployment location, and the renewal mechanism (manual, ACME, cloud-native auto-renew).
3. Identify certificates with no automated renewal: Any certificate without an automated renewal mechanism is a future outage. Prioritize implementing ACME or cloud-native auto-renewal for these certificates, starting with the ones expiring soonest.
4. Audit private key storage: Verify that private keys for all discovered certificates are stored in approved locations (cloud HSM, secrets manager, CLM platform). Identify and remediate any keys stored in version control, container images, or application configuration files.
5. Implement certificate policy in your CLM platform: Define minimum acceptable certificate parameters: minimum RSA key length (2048-bit minimum; 4096-bit for CA certificates), allowed signature algorithms (SHA-256 or stronger), maximum validity (aligned to SC-081v3 schedule), required SANs (no wildcard certificates where more specific SANs are feasible), and approved issuing CAs.
6. Configure expiry alerting: Set alerts at 60 days, 30 days, and 14 days before expiry for any certificate without automated renewal. Route alerts to the owning team and to the security operations team.
7. Enable and route audit logs: Enable certificate lifecycle logs and private key access logs in all cloud providers. Route to a tamper-resistant destination. Configure alerts for the key security events described in the audit logging section above.
8. Review and test the renewal process quarterly: For each certificate type with automated renewal, verify that the renewal process completes successfully and that the renewed certificate is correctly deployed. Test revocation procedures for at least one certificate per quarter to verify that revocation infrastructure is functioning.

How Encryption Consulting Can Help

Encryption Consulting is an applied cryptography firm with ISO/IEC 27001:2022 and SOC 2 certifications. We help organizations design, implement, and audit cloud certificate management programs from initial discovery through ongoing compliance evidence generation.

• CertSecure Manager: Encryption Consulting’s CertSecure Manager is a centralized certificate lifecycle management platform that provides automated discovery across cloud providers and on-premises systems, ACME-based automated renewal, private key protection, certificate policy enforcement, expiry alerting, and a unified audit log. CertSecure Manager integrates with AWS, Azure, and GCP natively, supports ACME for any ACME-compatible CA, and includes an AD Connector for Windows environments using Microsoft Auto-Enrollment.
• PKI as a Service: For organizations that need a managed private CA for internal cloud certificates, Encryption Consulting’s PKI as a Service provides a fully managed private CA with ACME support, integration with all major cloud platforms, and FIPS-validated key storage. Suitable for Kubernetes service mesh certificates, mTLS between microservices, and device identity programs.
• HSM as a Service: For certificate management scenarios requiring FIPS 140-2 Level 3 private key protection, Encryption Consulting’s HSM as a Service provides dedicated HSM infrastructure that integrates with CLM platforms and cloud certificate services, keeping CA private keys and high-value end-entity private keys in hardware-backed storage.
• CBOM Secure: Encryption Consulting’s CBOM Secure runs automated discovery across AWS, Azure, GCP, and on-premises environments to produce a Cryptographic Bill of Materials (CBOM) in CycloneDX format. This provides the certificate inventory required by PCI DSS v4.0.1 Requirement 12.3.3 and FedRAMP IA-3 controls, and identifies shadow certificates and certificates with insecure configurations.
• Compliance Advisory: We map your cloud certificate management controls to the specific requirements of PCI DSS v4.0.1, DORA, HIPAA, FedRAMP, NIS2, and other applicable frameworks, identify control gaps, build the remediation roadmap, and produce the audit evidence package. See our Compliance Advisory Services.
• PQC Readiness: NIST finalized post-quantum cryptography standards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 points toward deprecating RSA and ECC for new uses around 2030. The transition to post-quantum algorithms will require re-issuing every certificate in your cloud estate. Encryption Consulting’s PQC Readiness service maps your full certificate and cryptographic posture against the post-quantum migration timeline and designs the migration sequence for cloud certificate estates.

To discuss your cloud certificate management requirements, contact Encryption Consulting.

Conclusion

Cloud-based certificate management has shifted from a nice-to-have operational process to a mandatory security and compliance control. The CA/Browser Forum SC-081v3 schedule makes automated renewal an operational necessity by 2029. PCI DSS v4.0.1 and DORA make documented certificate inventory and lifecycle governance explicit compliance requirements. And cloud-native certificate sprawl across auto-scaling groups, containers, and multi-cloud workloads makes manual management operationally impossible at any meaningful scale.

The organizations that will handle this transition without outages or compliance gaps are the ones that implement continuous certificate discovery now, deploy ACME automation before the 100-day validity deadline in March 2027, establish private key protection policies that survive the migration to shorter-lived certificates, and build the audit trail that compliance frameworks increasingly require. The ones that wait until 47-day certificates are mandatory in March 2029 will face a compressed, high-risk remediation under deadline pressure.

Frequently Asked Questions

What is cloud-based certificate management?

Cloud-based certificate management is the practice of discovering, issuing, renewing, revoking, and auditing digital certificates across cloud infrastructure, containers, and hybrid environments from a centralized platform. It replaces manual certificate tracking with automated lifecycle management that prevents certificate expiry outages, enforces private key protection, and generates compliance audit evidence across multi-cloud estates.

Why do cloud environments need dedicated certificate management?

Cloud environments generate certificates at a scale and velocity that manual management cannot track. Auto-scaling groups, containers, microservices, and API gateways each need valid certificates, and many are provisioned without central IT visibility. A single expired certificate in a cloud load balancer or API gateway causes a complete service outage. Dedicated CLM provides continuous discovery, automated renewal, and centralized visibility into expiry dates, issuing CAs, key strengths, and compliance status across all cloud accounts and regions.

What is the difference between native cloud certificate management and a third-party CLM platform?

Native cloud services (AWS Certificate Manager, Azure Key Vault Certificates, GCP Certificate Manager) automate renewal for resources within that single cloud provider’s ecosystem. They provide no visibility into certificates in other clouds, on-premises systems, or certificate types outside their scope. A third-party CLM platform provides a unified certificate inventory and consistent policy enforcement across all cloud providers, on-premises infrastructure, and certificate types including code signing, S/MIME, and device certificates.

How should private keys be protected in a cloud certificate management environment?

Private keys should be stored in hardware-backed secret stores, never in plaintext configuration files, environment variables, or version control. For load balancer and API gateway certificates, use the cloud provider’s managed certificate service where the key is never exposed. For certificates where the application needs direct key access, store the key in a cloud secrets manager with automated rotation. For FIPS 140-2 Level 3 requirements, use a dedicated HSM through cloud HSM services or a third-party HSM as a Service provider.

What is ACME and how does it enable automated certificate renewal in the cloud?

ACME (Automatic Certificate Management Environment) is an IETF protocol (RFC 8555) that automates certificate issuance and renewal by allowing a client to prove domain control to a CA and receive a certificate without human intervention. In cloud environments, ACME clients run as agents on compute instances or in containers, and renew certificates automatically before expiry. With TLS certificates moving to 47-day validity by March 2029 under the CA/Browser Forum SC-081v3 schedule, ACME automation is essential for any cloud environment with more than a handful of certificates.

Which compliance frameworks require certificate management controls in cloud environments?

PCI DSS v4.0.1 (mandatory since March 31, 2025) requires a documented certificate inventory and valid certificates for cardholder data in transit. DORA (applicable January 2025) requires ICT risk management controls covering cryptographic certificate lifecycle governance. HIPAA requires valid TLS certificates on all endpoints transmitting Protected Health Information. FedRAMP (NIST SP 800-53 Rev. 5) requires a certificate policy covering issuance, renewal, and revocation. GDPR requires appropriate technical measures for data in transit including certificate hygiene.