I wrote about ACM Private CA back in 2019, and the recommendation then was simple: stop running your own PKI in AWS, use the managed service, and integrate it with KMS for key protection. Seven years on, that recommendation still holds — but the supporting facts have moved on, the service itself has matured, and the FIPS validation landscape has shifted from 140-2 to 140-3.
This is a refresh of the original post with what’s actually accurate in 2026.
What ACM PCA gives you
The core proposition hasn’t changed: AWS Private CA is a managed certificate authority service that lets you provision a private PKI hierarchy without running the underlying infrastructure. You get a root CA, optional subordinate CAs, certificate issuance via API or via ACM integration, and the keys never leave the underlying HSMs.
What’s changed is the breadth of integration. In 2019, the headline use case was issuing certificates for end-to-end TLS beyond the load balancer. In 2026, ACM PCA is the certificate authority backing IAM Roles Anywhere (workload identities outside AWS), AWS Verified Access, EKS pod identity scenarios, and a long tail of internal service mesh deployments. If you’re running an internal PKI in AWS in 2026, ACM PCA should be the default starting position.
Where the keys actually live
This is the question that comes up in every architecture review, so it’s worth being precise. ACM PCA stores CA private keys in AWS KMS. The KMS keys are protected by HSMs operated by AWS. You don’t have direct HSM access, but you do have key policies that govern who can use the keys for what operations, and CloudTrail logs every use.
For most workloads, this is the right level of abstraction. You get HSM-grade key protection without the operational burden of running an HSM. For workloads that genuinely require single-tenant HSMs — typically PCI PIN environments or specific regulatory requirements that explicitly mandate them — you’d pair ACM PCA with CloudHSM, but this is the exception rather than the rule.
FIPS 140-3 validation
Here’s where I want to be properly accurate, because the original post referenced FIPS 140-2 and the landscape has changed.
FIPS 140-3 is now the active validation standard. NIST stopped accepting new FIPS 140-2 submissions in September 2021, and existing 140-2 certificates are being phased out as their five-year validity expires. AWS KMS HSMs hold FIPS 140-3 validation, and the Cryptographic Module Validation Program publishes the certificates and security policies on the NIST website.
For anyone needing to evidence compliance with regulatory requirements that mandate FIPS-validated cryptographic modules, the practical implication is:
- Verify the current validation status of any AWS service you’re relying on by checking the NIST CMVP search directly, rather than trusting older blog posts (including the one you’re reading — check the source).
- For AWS service endpoints, use the FIPS endpoints (typically
<service>-fips.<region>.amazonaws.com) where available, which guarantees the cryptographic boundary you’re crossing is FIPS-validated. - Document the cryptographic module validation in your compliance evidence, not just the FIPS endpoint usage. Auditors increasingly want to see the actual certificate referenced.
The NIST CMVP search lives at csrc.nist.gov/projects/cryptographic-module-validation-program — that’s the authoritative source. Use it to find the current certificate for the modules you’re relying on, and reference the certificate number in your control documentation.
Architectural patterns worth knowing
A few patterns that have become well-established for ACM PCA deployments:
Centralised CA hierarchy in a dedicated account. Run your root CA and subordinate CAs in a dedicated PKI account, with strictly limited access. Certificate issuance happens via cross-account sharing with Resource Access Manager, so workload accounts can request certificates from approved subordinate CAs without having any direct CA management permissions. The root CA in particular should be used only to sign subordinates, then effectively kept dormant.
Short-lived certificates. ACM PCA supports certificate validity periods down to whatever you need. The default mindset of one-year or two-year certificates is a hangover from the days when issuance was operationally expensive. With API-driven issuance, certificate validity should be measured in days or weeks for workload identities, with automated renewal. This dramatically reduces the blast radius of a compromised certificate and forces you to get the rotation story right.
Integration with IAM Roles Anywhere. This is the use case that’s grown most since 2019. Workloads running outside AWS — on-premises servers, edge devices, CI/CD systems in other clouds — can authenticate to AWS using X.509 certificates issued by your private CA. The trust anchor in IAM Roles Anywhere is your CA, and the resulting AWS credentials are short-lived and scoped via IAM. This replaces a category of long-lived IAM access keys that used to be the standard pattern, and it’s a meaningful security improvement.
ACM integration for AWS-native services. For certificates consumed by ALBs, NLBs, CloudFront, API Gateway, and similar AWS services, the integration via ACM means the certificate private key never leaves the AWS boundary. ACM requests the certificate from your private CA, stores the private key in its own protected store, and binds it to the service. You don’t see or handle the private key directly, which is exactly what you want.
When not to use ACM PCA
Two scenarios where ACM PCA isn’t the right answer:
Public-facing certificates. Use ACM with public CA integration (or your existing public CA provider) for anything that needs to be trusted by external clients. ACM PCA issues certificates that only chain to your private root, which by definition isn’t trusted outside your environment.
Truly cross-cloud or hybrid scenarios where AWS isn’t the centre of gravity. If your PKI needs to issue certificates for environments that have minimal AWS footprint, the operational complexity of managing it from AWS may not be justified. In these cases, a vendor-neutral PKI platform — or your existing enterprise CA — is often the better choice. The tail wagging the dog is when an AWS-centric organisation tries to extend an on-premises Windows PKI to cover AWS workloads, instead of moving the PKI itself to ACM PCA.
Cost note
ACM PCA pricing has two main components: a monthly charge per active CA, and a per-certificate issuance charge that decreases at volume. For a multi-account organisation issuing many short-lived certificates, the per-certificate cost is the bigger line item. Worth modelling against your actual issuance volume before committing to a short-lived certificate model — though in my experience, the cost is almost always justified by the operational and security benefits.
The monthly per-CA charge does mean that proliferating subordinate CAs has a real cost. Most organisations need fewer subordinates than they think — one per major trust domain, not one per team or per environment.
Summary
The 2019 advice still stands: use ACM PCA, integrate with KMS, don’t run your own PKI in AWS. What’s changed is that the integration story is now genuinely complete — IAM Roles Anywhere, ACM, service mesh deployments, all of it — and FIPS 140-3 has replaced 140-2 as the active validation regime. If you’re still running a hand-rolled PKI to issue certificates for AWS workloads in 2026, the migration is overdue.
Always verify FIPS validation status against the current NIST CMVP record rather than blog posts, including this one.