Your AWS Certificates Just Got Shorter: What the 198-Day Validity Change Actually Means
- Stephen Jones
- February 20, 2026
Table of Contents
On 18 February 2026, AWS quietly updated ACM to reduce the default validity of public certificates from 395 days to 198 days. If you’re running anything on AWS that terminates TLS — CloudFront distributions, Application Load Balancers, API Gateway endpoints, Elastic Beanstalk — this affects you.
The good news: if you’re using ACM’s managed certificates, AWS handles renewal automatically and nothing breaks today.
The uncomfortable news: this is the first step in a timeline that ends at 47-day certificates by 2029, and the organisations that aren’t preparing for automation now are going to have a very bad time.
What Actually Changed
Three things happened in the ACM update:
Validity period halved. New and renewed public certificates now max out at 198 days, down from 395. Existing 395-day certificates continue working until they renew or expire — at which point they’ll receive the shorter lifetime.
Renewal windows adjusted. ACM now begins automatic renewal attempts 60 days before expiry (previously 45 days for some certificate types). This wider window accounts for the shorter validity — you now get proportionally more lead time to catch failed renewals.
Exportable certificate pricing dropped. Exportable public certificates went from $15 to $7 per FQDN, and from $149 to $79 per wildcard. This is AWS nudging you toward using more certificates with shorter lifetimes rather than fewer certificates that last longer.
If you’re using ACM-managed certificates attached to AWS services, the renewal is automatic. Your ARN stays the same. The certificate rotates behind the scenes. For most AWS customers, this is genuinely a non-event.
But that’s not the story.
Why This Is Happening
AWS didn’t wake up one morning and decide shorter certificates would be fun. This is compliance with Ballot SC-081v3, passed by the CA/Browser Forum in April 2025, which mandates a phased reduction in TLS certificate lifetimes:
| Date | Maximum Validity | Domain Validation Reuse | Effective Renewal Cadence |
|---|---|---|---|
| Before March 2026 | 398 days | 398 days | Annual |
| March 15, 2026 | 200 days | 200 days | Every 6 months |
| March 15, 2027 | 100 days | 100 days | Every 3 months |
| March 15, 2029 | 47 days | 10 days | Every 6 weeks |
Read that last row again. By 2029, your TLS certificates will need to be renewed every six weeks, and domain validation data can only be reused for 10 days. That 10-day DCV reuse period means domain ownership verification happens with nearly every certificate request.
The ballot was backed by Google, Apple, and Mozilla — the companies that control the browser trust stores. When they agree on something, the industry follows. It’s not a suggestion.
AWS chose to move early, implementing the change on 18 February rather than waiting for the 15 March deadline. That’s typical AWS: get ahead of the compliance date, give customers a buffer.
The Security Rationale
You might be wondering why anyone would want certificates that expire faster. The logic has three layers.
Shorter exposure windows. If a private key is compromised, the certificate built on it has a limited remaining lifetime. A 47-day certificate can only be abused for, at most, 47 days. A 398-day certificate gives an attacker up to 13 months. Certificate revocation (via CRL or OCSP) exists in theory, but in practice it’s unreliable — browsers often soft-fail on revocation checks, meaning a revoked certificate continues working for many users.
Fresher domain validation. Every time a certificate renews, domain ownership is re-validated. This catches domain transfers, hijacks, and abandoned domains faster. A certificate issued against a domain you no longer own is a security problem that shorter lifetimes solve mechanically.
Forced automation. This is the one that matters most operationally. Manual certificate management doesn’t scale to 47-day renewal cycles. By making manual processes progressively more painful, the CA/Browser Forum is forcing the entire industry toward automated certificate lifecycle management. And automated systems are more consistent, more auditable, and less prone to the human errors that cause outages.
The Outage Problem Is Real
If you think expired certificate outages are edge cases, the data says otherwise. Keyfactor’s 2024 PKI report found that organisations experienced an average of three certificate-related outages in a 24-month period, with each taking approximately 5.3 hours to identify and remediate.
The hit list of organisations taken down by expired certificates reads like a Fortune 500 roll call:
- Bank of England — two CHAPS payment system outages in 2024 from expired certificates, one halting settlement transactions for over 90 minutes
- Alaska Airlines — September 2024 IT outage causing a ground stop in Seattle
- Tailscale — March 2024, 90 minutes of downtime from an expired marketing site certificate
- Microsoft, Spotify, Google Voice — all hit by the same class of incident in recent years
The counterintuitive thing is that shorter certificate lifetimes actually reduce the risk of these outages. When you’re renewing annually, it’s easy to forget. When you’re renewing every six weeks, you can’t afford to do it manually — so you automate it, and automated systems don’t forget.
What This Means for Your AWS Architecture
Let’s break this down by how you’re managing certificates.
ACM-Managed Certificates (Most Common)
If your certificates are issued and managed by ACM and attached to AWS services (CloudFront, ALB, NLB, API Gateway, Elastic Beanstalk), you’re in the best position:
- ACM handles renewal automatically
- Renewal starts 60 days before expiry
- DNS-validated certificates renew seamlessly if CNAME records are still in place
- Email-validated certificates require human interaction for each renewal — this is the one that will bite you
Action required: If you have any email-validated ACM certificates, migrate them to DNS validation now. When certificates renew every six months instead of annually, the person who needs to click that approval email will forget or be on holiday. DNS validation is set-and-forget.
Exportable ACM Certificates
If you’re exporting certificates from ACM to use on EC2 instances, containers, or on-premises infrastructure, the shorter validity means more frequent export-and-deploy cycles. The price drop (from $15 to $7 per FQDN) softens the cost impact of more frequent renewals, but you need an automated pipeline to handle the rotation.
Imported Certificates
If you’re importing third-party certificates into ACM, those certificates will also be subject to the shorter validity periods imposed by their issuing CA. ACM doesn’t manage renewal for imported certificates — you’re responsible for replacing them before they expire.
Action required: Set up AWS Config rule acm-certificate-expiration-check with a 45-day threshold. Pair it with SNS notifications or EventBridge rules to alert your team.
Self-Managed Certificates (EC2, ECS, EKS)
This is where the pain concentrates. If you’re terminating TLS directly on your instances or containers using certificates from Let’s Encrypt, DigiCert, or any other CA, you need automated renewal baked into your deployment pipeline. The ACME protocol (RFC 8555) is the industry standard for this, with certbot and acme.sh being the most common clients.
For Kubernetes environments, cert-manager integrates directly with the ACME protocol and can handle certificate issuance, renewal, and distribution across your cluster.
What You Should Do Now
The March 2026 milestone is weeks away. Here’s a practical checklist:
Audit your certificate estate. Run
aws acm list-certificatesacross all accounts and regions. Know what you have, where it’s used, and how it’s validated. If you’re multi-account, use AWS Organizations with a delegated administrator for ACM.Migrate email-validated certificates to DNS validation. This is the single highest-impact change. DNS validation renews automatically. Email validation requires human intervention every renewal cycle.
Check your ACM Config rules. Enable
acm-certificate-expiration-checkwith appropriate thresholds. When validity drops to 100 days in 2027, a 45-day warning gives you less than two months of buffer.Automate self-managed certificate rotation. If you’re running certificates outside ACM (on EC2, in containers, on-premises), implement ACME-based automation now. Don’t wait for the 100-day deadline in 2027.
Test renewal pipelines. Force a certificate renewal in a staging environment. Verify that your application handles the rotation gracefully — no hardcoded certificate paths, no pinned certificates, no cached TLS sessions that break on rotation.
Review IaC templates. If your Terraform, CloudFormation, or CDK templates reference certificate validity assumptions (like rotation schedules or monitoring thresholds), update them.
The Bigger Picture
There’s a thread running through this change that goes beyond certificate lifetimes. The CA/Browser Forum explicitly cited post-quantum cryptography readiness as a motivation for shorter validity periods.
The logic: when quantum computers eventually threaten current RSA and ECDSA algorithms, the industry needs the ability to rotate the entire certificate ecosystem to post-quantum algorithms quickly. If certificates last 398 days, that migration takes over a year. If they last 47 days, the entire web rotates to new algorithms within six weeks.
Shorter lifetimes build the automation infrastructure that makes rapid algorithm migration possible. The 47-day target isn’t just about reducing compromise windows — it’s pre-positioning the entire PKI ecosystem for the post-quantum transition.
Whether you think that transition is five years away or fifteen, the automation you build today to handle 198-day certificates is the same automation you’ll need when the cryptographic rug pull happens.
The Bottom Line
For most AWS customers using ACM-managed certificates, today’s change is painless. AWS is doing the right thing by getting ahead of the March 15 deadline and lowering exportable certificate pricing to reduce friction.
But if you zoom out, this is the industry telling you that the era of annual certificate renewals is ending. The organisations that treat this as a compliance checkbox will be caught flat-footed when 100-day certificates arrive in twelve months. The ones that use it as a catalyst to build proper automation will be ready for whatever comes next.
The certificates are getting shorter. The question is whether your processes are getting smarter.
References:
