The recent decision by the Certification Authority Browser Forum to shorten the maximum lifetime of publicly trusted TLS certificates is reshaping how organizations approach certificate management. Starting in March 2027, the allowable validity will fall to just 100 days, and two years later it will shrink further to a mere 47 days. For a mid‑size enterprise that maintains a fleet of a thousand certificates, this translates into roughly thirty renewal actions every single day. Manual processes, ticket‑based workflows, or ad‑hoc scripts simply cannot keep pace with that frequency without introducing errors, delays, or security gaps. The operational burden is not just about the sheer number of renewals; it also encompasses the need to validate domain ownership repeatedly, update configuration files, and ensure that every service reloads the new certificate without downtime. As a result, security and platform teams are under pressure to replace fragile, human‑driven procedures with robust, automated pipelines that can handle rapid turnover while preserving visibility and compliance. The shift toward shorter lifetimes is driven by a desire to limit the window of exposure should a private key be compromised, but it also forces enterprises to reconsider the tooling and processes they rely on for trust management.
In response to this growing challenge, AWS Certificate Manager has introduced native support for the Automated Certificate Management Environment (ACME) protocol, a move that brings the convenience of managed issuance to any infrastructure that can run an ACME client. Rather than forcing customers to maintain separate accounts with third‑party certificate authorities, the new feature lets them point their existing, familiar tools—such as Certbot, cert‑manager, acme.sh, or win‑acme—directly at an ACME endpoint hosted inside ACM. Certificates obtained through this endpoint are automatically enrolled in the ACM inventory, appearing alongside those created via the RequestCertificate or ImportCertificate APIs, which gives administrators a single pane of glass for viewing, renewing, and auditing all TLS assets. The integration works whether the workloads reside in Amazon Web Services, on‑premises data centers, edge locations, or hybrid clouds, thereby eliminating the need to juggle multiple CA contracts or custom automation scripts. By aligning with an open, widely adopted standard, AWS aims to reduce the friction that has historically prevented organizations from achieving true certificate lifecycle automation at scale.
At its core, the ACME protocol is a simple yet powerful exchange that automates the two fundamental steps of obtaining a TLS certificate: proving control over a domain and retrieving the signed certificate from a certificate authority. The protocol begins when an ACME client sends a request to a well‑known directory URL, prompting the server to present a series of challenges—typically DNS‑based, HTTP‑based, or TLS‑ALPN—that the client must satisfy to demonstrate ownership. Once the challenge is completed, the server issues a certificate that is valid for the agreed‑upon period and returns it to the client, which can then install it on the appropriate service. Because the entire flow is standardized, any client that implements the ACME specification can interoperate with any compliant server, which is why tools like Certbot have become ubiquitous in the Linux ecosystem and why Kubernetes operators such as cert‑manager rely on it for ingress TLS. The beauty of ACME lies in its ability to repeat this process automatically, enabling cron jobs or controllers to renew certificates well before they expire without any human intervention.
AWS’s implementation allows organizations to keep using the ACME clients they already know and trust, avoiding the cost and risk associated with retraining teams or rewriting deployment pipelines. After an administrator provisions an ACME endpoint within ACM, the client is configured with the endpoint’s directory URL and a set of external account binding (EAB) credentials that authenticate the client to the service. From that point onward, the client behaves exactly as it would when talking to a public CA such as Let’s Encrypt, except that the backend is Amazon Trust Services and the resulting certificates are stored in ACM. This approach works equally well for virtual machines running on EC2, containerized workloads in EKS or ECS, bare‑metal servers in a corporate data center, or even Internet of Things devices that need to establish mutual TLS connections. Because the integration relies on standard ACME messages, there is no need to modify application code or to install proprietary agents; the only change required is to point the client at the new endpoint and supply the EAB material.
The architecture of the new feature separates responsibilities into a control plane and a data plane, which together provide both flexibility and governance. In the control plane, a PKI administrator uses the ACM API or the AWS Management Console to create an ACME endpoint resource. Each endpoint is defined by a unique ACME directory URL, a set of IAM‑based access policies, and a list of domains that the endpoint is authorized to serve. During endpoint creation, the administrator also generates external account binding credentials that will be distributed to trusted clients. Importantly, the administrator can pre‑approve specific domain patterns—exact matches, subdomains, or wildcards—so that the endpoint will only ever issue certificates for names that have been explicitly vetted. This pre‑approval step shifts the burden of domain validation from every individual certificate request to a one‑time operation performed by someone with the appropriate ACM permissions, dramatically reducing the operational overhead for developers and operators who simply need to request a certificate.
In the data plane, the actual certificate flow begins when an ACME client presents its EAB credentials to the endpoint’s directory URL. The EAB consists of a Key Identifier and a MAC Key that are derived from an IAM role associated with the endpoint; possessing these credentials proves that the client is authorized to request certificates for the domains pre‑approved on that endpoint. Once the client is authenticated, it proceeds with the standard ACME challenge‑response exchange; however, because the domain ownership validation has already been completed at the control plane level, the client can skip the DNS or HTTP challenge steps and move directly to certificate issuance. The endpoint then forwards the request to Amazon Trust Services, which signs the certificate and returns it to the client. The newly minted certificate is automatically registered in ACM, where it inherits the same lifecycle management capabilities as any other ACM‑issued certificate. Because each EAB is tightly bound to a specific endpoint, a set of credentials that works for a development environment cannot be misused to obtain certificates from a production endpoint, thereby enforcing strong security boundaries between teams or workloads.
To further harden the issuance process, AWS Certificate Manager lets administrators fine‑tune what kinds of domain names an endpoint is allowed to certify through the DomainScope attribute. When a domain is validated, the administrator can choose to enable ExactDomain, Subdomains, Wildcards, or any combination thereof. For example, if the domain internal.example.com is validated and only the Wildcard flag is switched on, an ACME client may request a certificate for *.internal.example.com but will be denied if it asks for internal.example.com itself or for a deeper leaf such as api.internal.example.com. Conversely, enabling ExactDomain alone would allow only the precise name that was validated, blocking any subdomain or wildcard requests. This granular control prevents accidental or malicious over‑issuance and helps organizations enforce naming conventions, internal‑only policies, or segmentation strategies. Because the check occurs at the endpoint level before the request ever reaches the signing authority, it adds negligible latency while providing a strong policy enforcement point that can be audited through IAM logs and CloudTrail events.
Every certificate that flows through an ACME endpoint is automatically recorded in the AWS Certificate Manager inventory, giving administrators a unified view that spans certificates obtained via ACME, those requested through the ACM API, and any third‑party certificates that have been imported. This central repository enables simple discovery, bulk tagging, and consistent application of expiration policies. Moreover, ACM integrates with Amazon EventBridge to emit events when a certificate approaches its expiry date, allowing teams to trigger Lambda functions, SNS notifications, or custom remediation workflows. All administrative actions—including endpoint creation, EAB generation, and domain validation—are captured in AWS CloudTrail, providing an immutable audit trail that supports compliance reporting and forensic analysis. The combination of automated issuance, centralized visibility, and built‑in alerting means that organizations can move from a reactive, ticket‑driven model to a proactive, observability‑focused approach to trust management.
Getting started with ACME in ACM is deliberately straightforward, allowing teams to move from zero to automated issuance in a matter of minutes. The first step is to create an ACME endpoint: in the AWS Management Console, navigate to the ACM service, select the ‘ACME endpoints’ tab, and choose ‘Create endpoint’. Provide a friendly name, specify the regions where the endpoint should be available, and define the IAM role that will govern access. Next, validate the domains you intend to serve by adding DNS CNAME records; if the domain is hosted in Amazon Route 53, you can supply the hosted zone ID and let ACM create the record automatically, otherwise you will need to add the supplied CNAME manually with your DNS provider. Once the validation status shows ‘Success’, generate an external account binding—this yields a Key ID and a MAC Key that you will distribute to your ACME clients. Finally, point your preferred client at the endpoint’s directory URL and configure it to use the EAB credentials; for Certbot this means adding –server
Operational best practices are essential to reap the full benefits of ACME while minimizing risk. First, consider isolating endpoints by environment or business unit rather than deploying a single, company‑wide endpoint; this limits the blast radius of a compromised EAB credential and makes it easier to apply distinct domain scopes and IAM policies per team. Second, treat EAB credentials with the same rigor as AWS access keys: store them in a secrets manager, rotate them periodically, and never hard‑code them into container images or source repositories. Third, leverage IAM policies to enforce least‑privilege access—grant the ability to create endpoints or generate EABs only to a small group of PKI administrators, while developers receive only the permissions needed to request certificates via their assigned endpoint. Fourth, monitor ACME usage through CloudTrail metrics and set up alerts for anomalous patterns such as a sudden spike in certificate requests from a single client or requests for domains outside the approved scope. Finally, document the endpoint lifecycle in your internal runbooks and align the renewal cadence with your change‑management processes to avoid surprise outages.
The move toward shorter certificate lifetimes is not an isolated regulatory quirk; it reflects a broader industry shift toward zero‑trust principles and just‑in‑time access. As software supply chains become more automated and ephemeral workloads proliferate—think serverless functions, container spikes, and edge functions—long‑lived certificates become a liability rather than an asset. Enterprises that continue to rely on manual renewal or semi‑automated scripts will find themselves increasingly out of step with DevOps practices that demand immutable, reproducible infrastructure. Market analysts note that the demand for certificate automation platforms has grown at a compound annual rate exceeding 20 % over the past three years, driven by the need to reduce mean time to recovery (MTTR) from certificate‑related incidents and to satisfy auditors who require evidence of timely key rotation. By offering ACME support natively within a managed service, AWS addresses this market gap while preserving the governance, billing integration, and compliance features that enterprises expect from a cloud‑native PKI solution.
To capitalize on the new capability, begin with a pilot project that covers a non‑critical set of services—perhaps a development environment or a internal tooling suite—so that you can validate the end‑to‑end flow without affecting production traffic. Use the pilot to refine your EAB distribution strategy, verify that your monitoring and alerting are functioning correctly, and gather feedback from the teams that will be responsible for day‑to‑day certificate management. Once the pilot proves successful, expand the rollout to staging and then to production, applying the endpoint‑per‑environment isolation model to maintain clear security boundaries. Keep an eye on the AWS pricing page for any updates regarding ACME usage charges, and remember that the feature will eventually be available in AWS GovCloud (US), the China Regions, and the AWS European Sovereign Cloud, giving you flexibility for workloads with specific residency requirements. Finally, treat certificate automation as a living practice: regularly review your DomainScope settings, rotate EAB credentials, and incorporate ACME health checks into your CI/CD pipelines to ensure that your trust infrastructure remains resilient, compliant, and ready for the next wave of cryptographic evolution.