AWS Certificate Manager (ACM) is a managed service that provisions, deploys, and renews TLS/SSL certificates for AWS-integrated services. It has become the default starting point for TLS certificates in the AWS ecosystem, and for good reason: it is free for integrated services, fully managed, and effectively invisible once configured. But certificate management rarely stays neatly inside the AWS boundary.
As enterprises spread workloads across multiple clouds, on-premises infrastructure, and a growing mix of certificate authorities, the question stops being “Is ACM good?” and becomes “Where does ACM stop being enough?” This blog answers that question. It maps out where ACM genuinely fits, the practical limitations PKI teams run into once they move beyond AWS-native services, the economics that drive those limits, and how a vendor-neutral CLM platform fills the gaps, especially as shrinking certificate validity periods and the post-quantum transition raise the stakes.
Where ACM Fits, and Where It Doesn’t
If your entire workload lives behind an Application Load Balancer, fronted by Amazon CloudFront, and exposed through Amazon API Gateway, AWS Certificate Manager (ACM) is genuinely hard to beat. It issues public TLS certificates at no cost for those integrated services, takes care of renewal, and the operational overhead is close to zero. For pure AWS-native teams running a contained footprint, it is one of the better managed services AWS offers.
The trouble starts the moment your certificate posture extends beyond the AWS boundary. Most enterprises we work with at Encryption Consulting are not pure AWS shops. They run a mix of on-premises Microsoft AD CS, third-party CAs like DigiCert or Entrust for public-trusted certificates, HashiCorp Vault PKI for service mesh and DevOps workloads, and a long tail of workloads on F5 BIG-IP, NGINX, Apache Tomcat, and IIS that have nothing to do with AWS.
According to Flexera’s 2024 State of the Cloud Report, around 89% of enterprises have adopted multi-cloud, and Gartner projects that over 90% of organizations will be using hybrid cloud by 2027. In that world, a CLM tool that can only manage one cloud provider, in one region, is a partial answer at best.
This blog walks through the practical limitations of ACM that PKI teams actually run into during enterprise deployments, the economics behind them, and how a vendor-neutral CLM platform like Encryption Consulting’s CertSecure Manager closes the gaps that ACM leaves open.
ACM vs. AWS Private CA: A Quick Refresher
Before going further, it is worth separating two AWS services that are often conflated. AWS renamed “ACM Private CA” to “AWS Private CA” in September 2022, and the distinction matters when you read pricing pages or design enrollment flows.
AWS Certificate Manager (ACM) is the lifecycle service. It issues, deploys, and renews public TLS certificates from Amazon’s public CA, and also acts as the management layer for private certificates issued by AWS Private CA. ACM-issued public certificates used exclusively with integrated AWS services (ELB, CloudFront, API Gateway, App Runner, and similar) are free.
AWS Private CA is the managed private CA infrastructure. It runs your CA hierarchy on FIPS 140-2 hardware-protected keys, but you pay a monthly fee per CA plus per-issued-certificate charges.
The limitations below apply to both, because they ship as a single experience for most teams.
The Real-World Limitations of AWS Certificate Manager
1. The Free Public Certificate Was Never Really Yours
ACM’s headline feature is the free public TLS certificate, but the private key for a “standard” ACM public certificate cannot be exported. The certificate can only be bound to ACM-integrated AWS services. If your TLS-terminating endpoint is anything else (an EC2 instance running NGINX, an on-premises F5, an Azure App Service, a GCP load balancer, a third-party CDN, a hardware appliance), the free ACM certificate is simply not deployable there. You will end up running parallel workflows: one ACM-managed flow for AWS-integrated services, and a completely separate process for everything else. That is operational debt that compounds.
AWS partially addressed this in June 2025 with exportable public certificates, which let you download the private key and deploy the certificate anywhere. The flexibility is real, but the economics shift sharply:
- $7 per fully qualified domain name (FQDN), charged at issuance and again at every renewal.
- $79 per wildcard name (for example *.yourdomain.com), again at issuance and at every renewal.
- ACM certificates have a 13-month maximum validity, with renewal at 11 months, so renewals happen roughly once a year today.
That seems modest until you do the math at enterprise scale. With the CA/Browser Forum’s phased validity reduction (200 days from March 2026, 100 days from March 2027, 47 days from March 2029), renewals will go from annual to roughly every six weeks within three years. Multiply that against 500 or 5,000 FQDNs and the “free certificate manager” becomes a recurring per-certificate cost line that scales linearly with your certificate count.
The takeaway is not that exportable certificates are unreasonable, it is that ACM’s pricing model was designed for AWS-internal use. The moment you push it outside that boundary, the cost model fundamentally changes, and you are now paying per-certificate fees on top of whatever automation infrastructure you still need to build for deployment.
2. Automation Stops at the AWS Boundary
Within AWS, ACM is excellent. Renewals on ELB, CloudFront, API Gateway, and similar services are handled silently. The certificate rotates, the integrated service picks up the new certificate, and there is nothing for the operator to do.
Outside AWS, ACM does not deploy anything. For an exportable certificate destined for an on-premises F5, an NGINX server, a Citrix ADC, a Kubernetes ingress that is not in EKS, or any other non-AWS endpoint, ACM’s responsibility ends at the API call. You can subscribe to Amazon EventBridge for renewal notifications, but the actual provisioning, key rotation on the device, virtual server binding on the load balancer, restart of the listening service, and validation of the new certificate are entirely your problem to solve.
That means custom scripts, custom IAM policies, custom error handling, and a custom audit trail. Every team we have helped build this ends up reinventing the same control plane: a queue of certificate events, a worker that pulls the new certificate, a connector library for each target endpoint type, a retry mechanism for partial failures, and a rollback plan when the new cert breaks the application. That is exactly what a purpose-built CLM platform is supposed to do, and it is exactly what ACM does not do once you leave the AWS edge.
3. Inventory Is Fragmented by Account and Region
ACM’s inventory is scoped to a single AWS account and a single region. If you operate across 12 accounts and 4 regions, you have 48 logical certificate inventories to track, and there is no native single-pane view across them.
The CloudFront constraint makes this worse. Even if your application runs entirely in ap-south-1 or eu-west-1, CloudFront requires the certificate to be in us-east-1. So a typical multi-region deployment ends up holding the same logical certificate in two regions: one in us-east-1 for the CDN, one in the application’s actual region for the load balancer. There is no automatic synchronization, no shared inventory, and no native cross-region view. In practice, identical domains get separate certificates issued and renewed independently, with no inventory tying them together.
For security and audit teams, this fragmentation is a real problem. You cannot enforce an organization-wide policy (“no RSA-2048 certificates after 1 Jan 2027” or “all certificates must have a registered owner”) if there is no single inventory to enforce against. You cannot run a cryptographic posture assessment ahead of the post-quantum migration if you cannot see what you have. And shadow certificates, the ones a developer requested two years ago in a region nobody monitors anymore, are exactly the ones that cause Saturday-night outages.
4. AWS Private CA Pricing Compounds Quickly
AWS Private CA’s published pricing is straightforward, but the numbers add up faster than most teams expect:
- $400 per private CA per month for general-purpose mode (any validity period)
- $50 per private CA per month for short-lived certificate mode (max 7-day validity)
- Per-certificate issuance tiers from a general-purpose CA: $0.75 for the first 1,000, $0.35 for the next 9,000, and $0.001 above 10,000
- $0.06 per certificate per month for OCSP responses (only billed for certificates that actually receive OCSP queries)
For a typical two-tier hierarchy (one offline root and one online issuing CA), you are at $800 per month before issuing a single certificate. Add cross-region high availability and you can easily hit $1,600 to $2,400 monthly. For a manufacturing or IoT use case issuing 50,000 device certificates per month, the per-certificate charges are reasonable thanks to the volume tier, but the per-CA monthly fee does not scale down: every regional CA, every separate trust hierarchy, every test environment costs the same flat $400 per month.
Compare this to a self-hosted Microsoft AD CS hierarchy, where the marginal cost per certificate after the initial deployment is effectively zero, or a managed PKI offering where the cost is amortized differently. AWS Private CA is convenient but it is not the cheapest path, and the cost model rewards consolidation into a single CA rather than the separation-of-duties many security teams actually want.
5. Compliance Reporting Is a Build-It-Yourself Affair
ACM does not produce out-of-the-box, certificate-level compliance reports for PCI DSS, HIPAA, SOC 2, DORA, or any other framework. AWS provides adjacent capabilities (AWS Config rules can detect non-compliant ACM certificates, Security Hub has standard mappings that flag findings, AWS Artifact gives you the AWS service-level compliance reports), but none of these are a turnkey “show me, by department, the audit-ready state of every certificate, who owns it, what algorithm it uses, when it expires, and whether it deviated from policy at issuance.”
For a regulated enterprise, that gap shows up at audit time. The compliance team asks “produce a report of every TLS certificate in scope, with key length, SAN entries, ownership, issuing CA, expiry, and policy adherence.” With ACM alone, you build that report from a mix of describe-certificate calls, custom Lambda functions, AWS Config exports, and a spreadsheet that has been edited by hand. The mature CLM workflow is to click a button and get the report, scheduled weekly, delivered to the auditor’s inbox.
6. Vendor Lock-In Cuts Against Crypto-Agility
Two industry shifts are converging in the next few years, and both require crypto-agility:
- The CA/Browser Forum’s Ballot SC-081v3, approved in April 2025, is reducing maximum public TLS validity from 398 days today to 200 days (March 2026), 100 days (March 2027), and 47 days (March 2029). The domain validation reuse window drops to 10 days by March 2028.
- NIST’s post-quantum cryptography transition timeline calls for organizations to deprecate legacy RSA and ECC by 2030 and replace them entirely by 2035. ML-DSA and ML-KEM (FIPS 204 and 203) are the new standards. AWS has begun adding ML-DSA support to AWS KMS and AWS Private CA, but the broader operational story of swapping algorithms across an estate is bigger than one CA.
Crypto-agility is the ability to swap CAs, algorithms, key sizes, validity periods, and deployment targets without re-architecting your control plane. If your certificate management is architecturally tied to one provider, you do not have crypto-agility, you have a dependency. The moment AWS shifts a pricing model, changes a service contract, deprecates a feature, or your business case shifts and you need to move workloads to Azure or GCP, the cost of unwinding that dependency is the cost of rebuilding your CLM stack. That is a poor position to be in heading into both the 47-day mandate and the PQC migration.
The 47-Day Mandate Sharpens Every Gap
Everything above gets harder as certificate validity shrinks. Today, a typical TLS certificate renews once a year. In March 2026, that becomes roughly every six and a half months. By March 2027, every three and a half months. By March 2029, every six and a half weeks.
That is an eightfold increase in renewal frequency in under three years. Every gap in ACM’s automation, every region you have to check separately, every endpoint outside the AWS boundary that needs a manual deployment script, every compliance report you assemble by hand, all of these scale linearly with renewal frequency. A workflow that is annoying at 12-month validity becomes operationally untenable at 47 days.
This is exactly why the industry conversation has shifted so sharply toward closed-loop, vendor-neutral CLM. It is not because ACM is bad, it is because partial automation simply does not survive the volume.
How CertSecure Manager Addresses These Gaps
CertSecure Manager, Encryption Consulting’s CLM platform, was built by PKI practitioners who deal with these exact scenarios on client engagements every day. Where ACM stops at the AWS boundary, CertSecure Manager picks up:
- Multi-CA, vendor-neutral by design. CertSecure Manager connects to Microsoft AD CS, AWS Private CA, HashiCorp Vault PKI, DigiCert, Entrust, and other public and private CAs through a single console. You get one inventory, one policy plane, one renewal queue, regardless of which CA issued the certificate or which cloud the workload sits in.
- Closed-loop automation beyond AWS. Renewal agents for Apache, Tomcat, IIS, F5 BIG-IP, NGINX, and custom internal applications handle the deployment step that ACM does not. The new CertSecure Manager Orchestrator for F5, built through our partnership in the F5 Application Delivery and Security Platform Partner Program, automatically maps each certificate to the correct F5 virtual server SSL profile, eliminating the manual binding step that causes most certificate-related F5 outages.
- Standard enrollment protocols. REST API and ACME endpoints let cloud-native and DevOps workloads enroll automatically, the same way they would against Let’s Encrypt or any standard ACME endpoint. That means cert-manager in Kubernetes, certbot on a Linux host, or a custom CI/CD pipeline can all enroll through the same protocol.
- Centralized visibility across cloud and on-prem. Automated certificate discovery scans your environment, builds a unified inventory across AWS accounts and regions, Azure, GCP, on-premises, and Kubernetes clusters, and surfaces ownership, algorithm, validity, and policy compliance for every certificate in one dashboard.
- Policy enforcement and approvals. Global and departmental policies cover minimum key size, allowed algorithms, FIPS-approved restrictions, wildcard usage rules, CSR reuse rules, DNS whitelisting for domain validation, and M-of-N approval workflows for high-assurance certificate templates. These policies enforce at issuance time, not after the fact.
- Audit-ready compliance reporting. Scheduled reports delivered weekly or monthly to the compliance inbox, with the certificate-level detail that PCI DSS, HIPAA, SOC 2, and DORA audits actually ask for. No manual export, no spreadsheet stitching.
- Crypto-agility built in. Because CertSecure Manager is CA-agnostic, swapping out the underlying CA, rotating to a new key algorithm, or migrating from one provider to another is a policy change rather than a re-architecture. That matters heading into both the 47-day mandate and the PQC migration.
When ACM Is Enough, and When It Isn’t
Not every team needs a full CLM platform. Here is a practical view of where ACM alone is sufficient and where it stops being enough:
| Scenario | ACM alone | Vendor-neutral CLM |
|---|---|---|
| Single AWS account, single region, fully AWS-native workloads | Yes | No |
| Fewer than 100 certificates, all on ACM-integrated services | Yes | No |
| Multi-cloud (AWS + Azure and/or GCP) | No | Yes |
| Hybrid cloud with on-prem footprint (AD CS, F5, NGINX, Apache, IIS) | No | Yes |
| 1,000+ certificates across multiple CAs and environments | No | Yes |
| Strict compliance posture (PCI DSS, HIPAA, SOC 2, DORA, regulated industries) | No | Yes |
| Kubernetes and containerized workloads spanning clouds | No | Yes |
| Preparing for 47-day validity with any non-AWS endpoints | No | Yes |
| Approaching PQC migration with a heterogeneous CA estate | No | Yes |
The pattern is straightforward. ACM is sufficient where the certificate posture is contained, AWS-native, and small. The moment any of those three conditions breaks down, the cost of staying with ACM alone is paid in operational complexity, audit pain, and outage risk.
Conclusion
ACM is a genuinely good service inside its design envelope. The mistake is assuming that envelope matches enterprise reality. Most organizations operate across multiple clouds, multiple CAs, and a long tail of on-premises endpoints that ACM cannot reach. The 47-day TLS validity timeline and the PQC migration are about to make every gap in ACM’s automation, visibility, and policy enforcement significantly more painful than it is today.
The right approach is to use ACM where it shines (free public certificates on AWS-integrated services, low-friction renewals within the AWS boundary) and to layer a vendor-neutral CLM platform on top to handle everything ACM was never designed to do. That gives you the operational simplicity of ACM where it works, and the cross-environment automation, governance, and crypto-agility you need everywhere else.
