ACME, EST, and SCEP are the three dominant protocols for automating certificate enrollment and renewal. ACME (Automatic Certificate Management Environment) handles public TLS certificates with zero manual intervention, EST (Enrollment over Secure Transport) targets enterprise PKI with strong mutual authentication, and SCEP (Simple Certificate Enrollment Protocol) is a legacy standard still widely deployed in network device management. Choosing between them depends on your environment: public web infrastructure favors ACME, internal enterprise networks often rely on EST, and legacy hardware or Cisco-heavy environments lean on SCEP. Each protocol solves the same core problem – eliminating manual certificate workflows – but through architecturally distinct mechanisms.
What Is the Difference Between ACME, EST, and SCEP?
ACME, EST, and SCEP differ in their trust models, transport security, and intended deployment contexts. ACME uses domain validation challenges over HTTPS to prove domain ownership before a public CA issues a certificate. EST uses TLS with optional client certificates to enroll against an enterprise CA, making it well-suited for internal PKI environments. SCEP, originally designed by Cisco, relies on a shared secret or pre-existing CA certificate for client authentication, operating over HTTP without requiring mutual TLS.
The table below captures the core architectural differences:
| Attribute | ACME | EST | SCEP |
|---|---|---|---|
| Transport | HTTPS (TLS) | HTTPS (mutual TLS) | HTTP (optionally HTTPS) |
| Authentication | Domain challenge (HTTP-01, DNS-01, TLS-ALPN-01) | Client cert or username/password | Pre-shared secret or existing cert |
| Primary use case | Public TLS certificates (web servers) | Enterprise internal PKI | Network devices, MDM, legacy systems |
| CA type | Public CA (Let’s Encrypt, ZeroSSL, etc.) | Private/enterprise CA | Private CA or Cisco-compatible CA |
| RFC standard | RFC 8555 (2019) | RFC 7030 (2013) | Draft standard (no finalized RFC) |
| Renewal automation | Native, built-in | Supported via re-enrollment | Supported with client polling |
| Mutual TLS required | No | Yes (recommended) | No |
SCEP notably lacks a finalized RFC – it has operated for years on draft specifications and vendor implementations, which creates interoperability inconsistencies across platforms.
How Does ACME Work and When Should You Use It?
ACME automates certificate issuance by having a client prove control over a domain through one of three challenge types: placing a file at a specific URL (HTTP-01), creating a DNS TXT record (DNS-01), or using a special TLS extension (TLS-ALPN-01). Once the CA verifies the challenge, it issues the certificate. The entire process – from order creation to certificate delivery – typically completes in under 60 seconds.
ACME, defined in RFC 8555, has become the backbone of free and automated public certificate issuance. Let’s Encrypt, the world’s largest free CA, serves billions of certificates exclusively through ACME. According to Let’s Encrypt’s 2024 annual statistics, the CA actively manages over 330 million certificates – all issued without human intervention.
Use ACME when:
- You manage public-facing web servers that need TLS certificates from a trusted public CA.
- You want zero-touch renewal (certbot, acme.sh, or Caddy handle this natively).
- Your environment supports outbound HTTPS and DNS control for challenge validation.
How Does EST Work and When Should You Use It?
EST (Enrollment over Secure Transport), standardized in RFC 7030, provides a modern replacement for SCEP in enterprise environments. It runs over HTTPS and supports mutual TLS, meaning both the client and server authenticate each other – a significant security improvement over SCEP’s shared-secret model.
EST endpoints expose a small set of REST-like operations: clients can retrieve CA certificates, submit a PKCS#10 CSR, and re-enroll existing certificates. The CA sits behind the EST server, meaning network devices and endpoints never communicate with the CA directly.
Understanding the role of a certificate authority is important when deploying EST – the CA’s trust anchor must be pre-provisioned on the enrolling device before EST can establish the mutual TLS session that authenticates the request.
Use EST when:
- You operate an enterprise PKI with an internal CA (Microsoft ADCS, EJBCA, etc.).
- Your devices support modern HTTPS and TLS client certificates.
- You need to replace aging SCEP infrastructure with something that enforces mutual authentication.
- Compliance requirements demand encrypted, authenticated certificate enrollment.
How Does SCEP Work and When Is It Still Relevant?
SCEP is a certificate enrollment protocol created by Cisco and VeriSign in the late 1990s. It relies on a pre-shared challenge password or an existing CA certificate to authenticate enrollment requests. Clients send a PKCS#10 CSR encrypted with the CA’s public key, and the CA responds with the signed certificate wrapped in a PKCS#7 envelope – all transported over HTTP.
Understanding public key vs private key mechanics is foundational here, because SCEP enrollment depends on encrypting the CSR with the CA’s public key so only the CA can decrypt and process it.
Despite being decades old, SCEP remains widely deployed for specific reasons:
- Network gear (routers, switches, firewalls) from Cisco, Juniper, and Palo Alto ship with native SCEP clients.
- Mobile Device Management platforms like Microsoft Intune and Jamf use SCEP for certificate-based Wi-Fi and VPN authentication.
- Legacy systems that cannot upgrade to support mutual TLS still require it.
The key limitation: SCEP offers no transport-layer security by default and relies on shared secrets that can be intercepted or reused. For any new deployment where SCEP is not mandated by hardware, EST is the sounder choice.
Which Protocol Should You Choose?
The right protocol depends on three variables: whether your certificates are for public or internal use, the age and capabilities of your devices, and whether you have an internal CA.
| Scenario | Recommended Protocol |
|---|---|
| Public web server TLS certificates | ACME |
| Internal enterprise PKI, modern devices | EST |
| Cisco network gear, MDM platforms, legacy clients | SCEP |
| Mixed environment (public + internal) | ACME for public, EST for internal |
| Air-gapped or offline environments | EST or SCEP (with internal CA) |
A common mistake is deploying ACME for internal infrastructure. ACME validation requires public domain ownership proof, so it physically cannot issue certificates for addresses like server.internal.corp. Organizations that attempt this route typically end up using workarounds like DNS-01 with split-horizon DNS, which adds complexity without solving the underlying need for a proper internal CA.
After enrollment, verifying certificates were issued correctly is straightforward using OpenSSL commands for certificate inspection, regardless of which protocol was used to obtain them.
Can You Use Multiple Protocols Together?
Yes, and many mature organizations do exactly this. A typical hybrid deployment uses ACME for all internet-facing servers – handling web properties, APIs, and public endpoints – while running EST against an internal Microsoft ADCS or EJBCA instance for workstations, VPN clients, and internal services. SCEP often stays in place purely to serve network devices that cannot be upgraded.
The architecture of your CA hierarchy also influences this decision. Organizations running a two-tier PKI with root CA and intermediate CA separation can expose only the intermediate CA through EST and SCEP endpoints, keeping the root offline and isolated from enrollment traffic.
Making the Right Choice for Your Environment
ACME, EST, and SCEP each occupy a distinct role in the certificate automation landscape, and none of them is universally superior. As of 2025, ACME handles the vast majority of public TLS certificate automation at scale, EST is gaining adoption in enterprise and government PKI deployments as organizations retire SCEP, and SCEP persists because the device ecosystem it serves moves slowly.
Start with your use case: if you manage public websites, deploy an ACME client today. If you run an internal PKI, evaluate EST against your CA vendor’s current support. If you have network gear locked to SCEP, plan a migration path to EST as those devices refresh. The goal is not to pick one protocol forever – it’s to use the right tool for each layer of your infrastructure and build toward phasing out unauthenticated enrollment wherever you can.
Frequently Asked Questions About ACME vs EST vs SCEP
Is ACME only for Let’s Encrypt certificates?
No. ACME is an open protocol (RFC 8555) supported by multiple public and private CAs including ZeroSSL, Buypass, SSL.com, and enterprise CA vendors like Sectigo and DigiCert. Any CA that implements the ACME server specification can issue certificates through it.
Can SCEP be used for web server TLS certificates?
Technically yes, but it’s rarely done. SCEP is designed for device enrollment against a private CA, and the resulting certificates would not be trusted by browsers. For public TLS, ACME against a publicly trusted CA is the correct choice.
Does EST replace SCEP entirely?
Not yet in practice. EST is architecturally superior and is the right choice for new deployments. However, enormous amounts of existing hardware ship only with SCEP clients, so SCEP will remain relevant until that equipment reaches end-of-life. The IETF has also published RFC 8951, which modernizes SCEP with improved security, though adoption is still early.
What client software supports ACME?
Certbot (by EFF), acme.sh, Caddy, Traefik, and win-acme are the most widely deployed ACME clients. Most modern web servers and cloud platforms – including Nginx, Apache, AWS Certificate Manager, and Cloudflare – offer ACME-based automation natively or through integrations.
Is EST supported on Windows Active Directory Certificate Services?
Yes, as of Windows Server 2012 R2, ADCS supports EST enrollment via the Web Enrollment Proxy service. Microsoft also ships the Network Device Enrollment Service (NDES) for SCEP support, giving administrators both protocols from a single CA infrastructure.
What is the security risk of continuing to use SCEP?
The primary risks are the absence of mandatory transport encryption and the reliance on shared challenge passwords. If the challenge password is intercepted or guessed, an unauthorized device can obtain a valid certificate. Where possible, migrating to EST eliminates both risks through enforced mutual TLS and stronger client authentication.
Priya Mervana
Verified Web Security Experts
Priya Mervana is working at SSLInsights.com as a web security expert with over 10 years of experience writing about encryption, SSL certificates, and online privacy. She aims to make complex security topics easily understandable for everyday internet users.
