As certificate lifespans shrink and infrastructure scales, manual renewal is no longer viable. Automation protocols like ACME, SCEP, EST, and CMP let machines handle enrollment, renewal, and revocation without human intervention.
For years, certificate management was a manual process. An administrator would generate a key pair, submit a Certificate Signing Request, wait for approval, download the certificate, install it on the server, and set a calendar reminder to do it all again before expiration. This approach worked when organizations managed a handful of certificates with one or two year lifespans.
That era is over. Modern infrastructure can involve thousands of certificates across cloud environments, container orchestrators, IoT fleets, and microservice architectures. At the same time, the industry is moving toward shorter certificate lifespans, with 90-day certificates already standard for public TLS and 47-day lifespans on the horizon. When you multiply thousands of certificates by renewals every few weeks, the math is clear: automation is not optional.
Fortunately, several protocols have been developed specifically to automate certificate enrollment, renewal, and revocation. Each protocol was designed for a different era and a different set of use cases. Understanding their strengths and limitations is essential for choosing the right approach for your environment.
The Automatic Certificate Management Environment (ACME) protocol is the most widely adopted automation standard for TLS certificates. Originally developed by the Internet Security Research Group (ISRG) for Let's Encrypt, ACME was standardized as RFC 8555 in 2019 and has since become the de facto protocol for automated certificate issuance.
The ACME client registers with the CA by creating an account and agreeing to the terms of service. This establishes a key pair that authenticates all subsequent requests.
The client proves control of the domain by completing one of several challenge types: HTTP-01 (placing a file on the web server), DNS-01 (creating a DNS TXT record), or TLS-ALPN-01 (responding on the TLS layer). DNS-01 is particularly useful for wildcard certificates and internal systems.
Once the challenge is verified, the client submits a CSR and the CA issues the certificate. The entire process, from request to installed certificate, can complete in seconds without any human interaction.
ACME clients are typically configured to check certificate expiration and renew automatically (often at two thirds of the certificate's lifetime). This eliminates the risk of forgetting a renewal entirely.
Let's Encrypt made ACME famous by offering free, automated DV certificates. Today, many enterprise CAs also support ACME, enabling organizations to use the same protocol for both public and internal certificates. Popular ACME clients include Certbot, acme.sh, Caddy (which has ACME built in), and cert-manager for Kubernetes.
The Simple Certificate Enrollment Protocol (SCEP) is one of the oldest certificate automation protocols, originally developed by Cisco in the late 1990s. Despite its age, SCEP remains widely deployed, particularly for enrolling network devices and IoT equipment that lack modern protocol support.
Extremely broad device support. Routers, switches, firewalls, printers, mobile device management (MDM) platforms, and many legacy systems speak SCEP natively. It uses simple HTTP GET/POST operations, making it compatible with constrained environments.
SCEP was never formally standardized as an RFC (it remains an Internet Draft). It relies on a shared secret (challenge password) for initial authentication, which poses security risks if intercepted. SCEP also lacks native support for certificate renewal; devices typically need to re-enroll from scratch.
Despite its shortcomings, SCEP is often the only option for legacy infrastructure. Organizations that need to support both modern and legacy devices frequently run SCEP alongside newer protocols.
Enrollment over Secure Transport (EST), defined in RFC 7030, was designed as the modern replacement for SCEP. It addresses many of SCEP's security weaknesses while providing a cleaner, more extensible architecture for certificate enrollment.
All EST operations run over HTTPS (TLS), meaning the enrollment channel itself is encrypted and authenticated. This eliminates the challenge password vulnerability that affects SCEP and provides a much stronger security foundation.
Unlike SCEP, EST has a dedicated re-enrollment endpoint. A device can use its existing certificate to authenticate and request a new one, enabling seamless certificate rotation without shared secrets or manual intervention.
EST supports multiple authentication methods: existing client certificates, HTTP Basic/Digest authentication, or a combination. This flexibility makes it suitable for both initial bootstrapping and ongoing renewal across diverse environments.
EST is increasingly adopted in enterprise environments, especially for device identity and internal PKI use cases. It is the recommended protocol for new deployments where SCEP compatibility is not required.
The Certificate Management Protocol (CMP), defined in RFC 4210 (with updates in RFC 9480 and RFC 9483), is the most comprehensive of the four protocols. CMP was designed to support the full certificate lifecycle, from initial request through renewal, update, revocation, and even key recovery.
CMP covers enrollment, re-keying, renewal, revocation, and cross-certification. No other protocol handles as many lifecycle operations natively.
CMP can operate over HTTP, HTTPS, or even directly over TCP. This makes it adaptable to environments where TLS termination is handled differently or where lightweight transports are needed.
CMP includes features like central key generation, proof of possession, and detailed error handling that are essential for regulated industries such as telecommunications, automotive, and industrial IoT.
CMP's comprehensiveness comes at a cost. The protocol is significantly more complex to implement and configure than ACME or EST, which limits its adoption to organizations that truly need its advanced capabilities.
CMP is particularly prevalent in the telecommunications industry (3GPP standards reference it) and in industrial environments where devices need to perform key updates and certificate renewals over constrained networks.
No single protocol is best for every scenario. The right choice depends on your devices, your CA infrastructure, and the level of lifecycle automation you need. Here is how they compare:
| ACME | SCEP | EST | CMP | |
|---|---|---|---|---|
| Standard | RFC 8555 | Internet Draft | RFC 7030 | RFC 4210 |
| Best For | Web servers, TLS | Legacy devices, MDM | Modern devices, IoT | Telecom, industrial |
| Transport | HTTPS | HTTP | HTTPS | HTTP, HTTPS, TCP |
| Renewal | Automatic | Re-enrollment | Native re-enrollment | Native renewal |
| Complexity | Low | Low | Medium | High |
| Revocation | Supported | Not supported | Not native | Native |
In practice, most organizations end up supporting multiple protocols. ACME handles web server certificates, SCEP covers legacy network equipment, EST manages modern device enrollment, and CMP serves specialized industrial use cases. The key is having a centralized inventory that tracks certificates regardless of which protocol issued them.
Multi-protocol support: Evertrust PKI natively supports ACME, SCEP, EST, and CMP, giving you a single CA platform that speaks every protocol your infrastructure needs. No separate servers or gateways required.
Unified lifecycle tracking: Evertrust CLM tracks every certificate regardless of protocol, CA, or environment. Whether a certificate was issued via ACME, enrolled through SCEP, or provisioned via CMP, it appears in the same inventory with the same monitoring and alerting.
Policy enforcement at enrollment: Automation does not mean losing control. Evertrust enforces your organization's certificate policies at the point of issuance, ensuring that automated requests still comply with key algorithm, validity, and naming requirements.
Ready for shorter lifespans: With native ACME support and continuous automation workflows, Evertrust ensures your infrastructure is prepared for the shift to 90-day and 47-day certificate lifespans without increasing operational burden.
