Use ACME for web servers, load balancers and cloud-native workloads that need TLS certificates renewed automatically, use SCEP mainly for managed phones, laptops and network gear that already support it through MDM, and use EST for newer devices and IoT where you want stronger, TLS-protected enrollment and easy re-enrollment. Many organizations run all three and manage them from one certificate lifecycle management platform.
This guide explains how each protocol works, where it fits, its main security trade-offs, and how to run a mix of all three without losing control.
Why certificate automation protocols matter
Manual certificate requests do not scale. Under CA/Browser Forum Ballot SC-081, the maximum lifetime of public TLS certificates falls to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Our guide to 47-day TLS certificates covers the timeline in detail.
An enrollment protocol lets a device or server request, receive and renew its certificate without a person in the loop. The right protocol depends on the device and what it supports, not on fashion.
ACME in brief
Standard: RFC 8555 (March 2019). ACME was created for Let’s Encrypt and is now supported by many public and private CAs.
How it works: the client proves it controls a domain name by completing a challenge, then receives the certificate. RFC 8555 defines the HTTP-01 and DNS-01 challenges, and RFC 8737 adds TLS-ALPN-01. Renewal repeats the same flow automatically.
Enterprise features: External Account Binding, defined in RFC 8555, links ACME clients to a known account at the CA. ACME Renewal Information (ARI), published as RFC 9773 in June 2025, lets the CA suggest when clients should renew, for example before a mass revocation.
Common clients: Certbot, acme.sh, cert-manager in Kubernetes, and web servers with built-in ACME support.
SCEP in brief
Standard: SCEP grew out of an enrollment protocol sponsored by Cisco and was in wide use for many years before it was published as RFC 8894 in September 2020 (Informational).
How it works: the device creates a key pair and sends a certificate request protected with a shared “challenge password”.
Where it shines: SCEP is built into many MDM tools, operating systems and network devices, so it is often the only option for managed phones, laptops, routers and VPN gateways.
Watch-outs: a static or shared challenge password is a weak point. Use one-time or dynamic challenges, and limit what each challenge can request.
EST in brief
Standard: RFC 7030 (October 2013).
How it works: enrollment runs over HTTPS. The client authenticates with an existing certificate, or with a username and password inside the TLS session. Operations include fetching CA certificates, enrolling, re-enrolling with the current certificate, and optional server-side key generation.
Where it shines: IoT and embedded devices, 802.1X network access, and zero-touch onboarding. BRSKI (RFC 8995) builds on EST for secure device bootstrapping, and EST-coaps (RFC 9148) carries EST over CoAP for very constrained devices.
Watch-outs: there are fewer off-the-shelf clients than for ACME or SCEP, so check device support early.
Side-by-side comparison
| Factor | ACME | SCEP | EST |
|---|---|---|---|
| Standard | RFC 8555 (2019) | RFC 8894 (2020, Informational) | RFC 7030 (2013) |
| Transport | HTTPS | HTTP, with the request protected inside CMS messages | HTTPS |
| How the client proves who it is | Challenges that prove control of the name, plus optional account binding | Shared challenge password | Existing certificate, or a password inside TLS |
| Renewal | Automatic, same flow as issuance | Supported, but often done as a fresh enrollment | Re-enrollment using the current certificate |
| Typical systems | Web servers, load balancers, Kubernetes | MDM-managed phones and laptops, network gear | IoT, embedded devices, 802.1X |
| Main strength | Fully automatic, wide client support | Built into many devices | TLS-protected, certificate-based renewal |
| Main weakness | Designed around proving control of names | Shared secrets | Fewer ready-made clients |
Other options exist too. CMP (Certificate Management Protocol), first published as RFC 4210 and now specified in RFC 9810 (July 2025), is used in telecom and industrial settings. Windows computers and users in an Active Directory domain can use autoenrollment, and custom applications can call a CA’s own REST API.
Decision guide: which protocol for which system?
| System | Usually the best fit |
|---|---|
| Public web servers, load balancers, Kubernetes ingress | ACME |
| Phones and laptops managed through MDM | SCEP |
| Routers, switches and VPN gateways with built-in support | SCEP, or EST where the device supports it |
| IoT devices, embedded systems and new device designs | EST |
| 802.1X network access | EST |
| Windows domain computers and users | Active Directory autoenrollment |
| Custom applications and pipelines | The CA’s REST API |
Security tips for any protocol
- Limit which names and certificate profiles each client or account may request.
- Protect and rotate SCEP challenges and EST passwords, and prefer certificate-based re-enrollment where you can.
- Monitor issuance for unusual volumes or unexpected names, and keep audit logs.
- Put policy in one place so every protocol follows the same rules.
How to roll out automation
- Find every certificate first. You cannot automate what you cannot see, so start with an inventory across CAs, cloud services and devices.
- Group systems by what they support. Sort servers, devices and applications by the protocols they can use today, using the decision guide above.
- Define certificate profiles and policy. Decide key types, lifetimes and allowed names for each group before you switch anything on.
- Pilot with one group. Start with systems where a failed renewal is easy to spot and fix, then widen the rollout.
- Monitor renewals, not just expiry. Alert on failed or late renewals, so problems show up while there is still time to act.
Managing all three from one place
Most organizations end up with a mix of protocols and CAs. A certificate lifecycle management platform gives you one inventory, one policy and one set of alerts across all of them.
According to its product page, Certinium CLM certificate automation supports SCEP for mobile devices, network equipment and managed endpoints, EST for enterprise enrollment and renewal, ACME for zero-touch issuance, and REST APIs for custom workflows. It is CA-agnostic and works with Microsoft ADCS, EJBCA, DictaLabs CA and other enterprise, public, private and cloud CAs. The page also describes Kubernetes and cert-manager integration, subject to connector availability and implementation scope.
DictaLabs CA itself is designed to automate enrollment, renewal, revocation and status operations through industry-standard protocols and modular APIs, including device and network enrollment automation.
Next step
Before you automate, find out which renewals are still manual. DictaLabs offers a free PKI risk assessment that looks at certificate visibility gaps, expiry risks and automation opportunities, with a report in 48 hours. You can also talk to a PKI expert about your automation plan.
