SCEP (Simple Certificate Enrollment Protocol): Complete Guide

SCEP explained: enrollment, servers, and protocol comparison
Key Points
  • SCEP streamlines the certificate issuance process by using an API to facilitate secure communication between clients (your managed devices) and your Public Key Infrastructure.
  • You can use SCEP with different operating systems based on slight variations, such as Intune CA partnering with Microsoft Intune, Jamf Profy on Apple devices, etc.
  • Our JoinNow Suite can help you deploy SCEP Gateway API URL with almost all MDM by creating private intermediate CA and CSR, customized templates, and a policy engine.

Distributing certificates to managed devices is a monumental task with a lot of moving parts that need to be accounted for. PKI integration, establishing a gateway, configuration policies, certificate enrollment, and device authentication are just a few steps in the process.

Luckily, Simple Certificate Enrollment Protocol (SCEP) provides a solution to streamline the certificate enrollment process on managed devices. With it, an administrator can automatically enroll every managed device for client certificates without requiring any end-user interaction. Here, we’ll walk you through the basics of how SCEP works with examples from our experts.

What is SCEP?

Simple Certificate Enrollment Protocol, or SCEP, is a protocol that allows devices to easily enroll for a certificate by using a URL and a shared secret to communicate with a PKI. Mobile device management (MDM) software commonly uses the certificate enrollment protocol, SCEP, for devices by pushing a payload containing the SCEP URL and shared secret to managed devices. This can save an administrator a lot of time and effort compared to the alternative of manually enrolling their managed devices for certificates.

SCEP was first developed in the early 2000s as a lightweight protocol to automate certificate enrollment. It gained widespread adoption in enterprise environments, even though it was still in draft form until the Internet Engineering Task Force (IEFT) published SCEP as an informational RFC (RCF 8894) in 2020, formalizing the protocol’s specifications.

What Is a SCEP Certificate?

A SCEP certificate is the digital ID that the protocol provides to devices. SCEP was designed to manage certain enterprise X.509 certificates, which act as a digital ID when a client device must prove its identity to a network or server. The certificate validates trust for individual devices and enables it to securely communicate with Wi-Fi networks, VPNs, email servers, and other internal applications.

SCEP certificates serve different purposes depending on what an organization needs:

  • Device authentication: Laptops, phones, and other devices use SCEP to connect securely to company Wi-Fi, VPNs, and internal apps.
  • User authentication: Certificates can be linked to specific employee devices, allowing them to securely access resources such as email or other applications for the workplace.
  • Server or application authentication: SCEP certificates secure internal communications between servers or between apps and clients.
  • EAP-TLS: SCEP uses X.509 certificates for passwordless Wi-Fi authentication, enabling mutual authentication so devices and the network can verify each other.

SCEP certificates act as keys that allow devices and users to securely prove their identity without needing a password. They are a multifunctional security measure that organizations can use for a variety of applications, as we’ll explore next.

Why Do Organizations Use SCEP?

SCEP offers a variety of benefits, especially to teams managing a large number of devices. Here’s why SCEP remains a popular option for IT professionals:

Automation

SCEP automates the certificate enrollment process, eliminating the need to manually install certificates on each device. This saves time and reduces the risk of configuration errors. It also makes it easy to revoke access when an employee leaves the company or a device is lost.

Security and Trust

SCEP certificates are trusted digital identities that ensure only authorized devices and users can access confidential resources. It is much more difficult to breach than a simple password, which enhances team security.

Scalability

For organizations with hundreds or thousands of devices, SCEP makes large-scale certificate management practical. Devices can automatically enroll without requiring individual attention from IT administrators.

Support for Legacy and Diverse Devices

SCEP works with older or mixed-device environments that may not support newer certificate enrollment protocols, allowing organizations to maintain their security without forcing hardware or software upgrades.

How Does the SCEP Protocol Work?

At a high level, SCEP ensures that devices automatically receive trusted certificates without manual intervention. The protocol works in 6 steps:

  1. Device identifies itself to the gateway: The managed device connects to the SCEP gateway using the pre-configured SCEP URL.
  2. Certificate request preparation: The device generates a Certificate Signing Request (CSR) which includes the information it needs to create a unique certificate.
  3. Authorization check: The SCEP Gateway verifies the device’s authorization, typically using the shared secret or challenge password.
  4. Certificate issuance: Once the device is authorized, the gateway forwards the CSR to the CA signs the certificate based on the policy enforced by the SCEP server or gateway.
  5. Deployment of the certificate: The signed certificate is sent back to the device, enabling it to authenticate securely.
  6. Automatic management: Future certificate renewals or re-enrollments follow the same automated process, ensuring the devices remain trusted over time.

Components of a SCEP Gateway

To better understand the process, let’s dive deeper into the core components of the SCEP gateway.

SCEP Gateway API URL

Simple Certificate Enrollment Protocol instructs devices how to communicate with the PKI, through the use of a Gateway API URL. Customers using SecureW2 can easily generate a SCEP Gateway API URL with our software. Then, they can put this URL in their MDM so it can send a payload to devices that should enroll for client certificates.

Certificate Authority (CA) and Certificate Template

A Certificate Authority (CA) is the entity responsible for certificate management for a Public Key Infrastructure (PKI) by playing an instrumental role in validating the identity of a user, device, or website before issuing digital certificates.

The most crucial step for SCEP to function optimally is validating the certificate authority that has issued the certificate. This ensures that the CA issuing certificates is trusted and that the entire certificate chain is secure.

SCEP requests the CA certificate to validate important information, such as:

  • Name of the certificate authority
  • Public key of the CA
  • Digital signature of the CA as a confirmation that the certificate has not been tampered with
  • The certificate serial number
  • The validity period of the certificate to confirm it is valid and not expired

This information helps validate the integrity and authenticity of the certificate.

A certificate template is another important piece of the 802.1X ecosystem, as it contains the rules and policies that are applied when a CA issues a certificate to a client. A certificate template will also include important information, such as:

  • The cryptographic algorithms used
  • The validity period of the certificate
  • The user role defined as per company policies to determine what level of access is to be granted to the client

The strength of your network, therefore, largely depends on the design of the certificate template.

With SecureW2, creating a certificate template is simple and gives you the flexibility to customize it to meet your organization’s policies. SecureW2 certificate template management also gives you the flexibility to design templates based on the requirements and attributes defined by the MDM your company uses, as our solution integrates with all major MDM vendors.

SCEP Shared Secret

A shared secret is a case-sensitive password entrusted between the SCEP server and the certificate authority. This shared secret verifies the CA with the right server for signing certificates. With the SecureW2 JoinNow Dynamic PKI, the device presents the shared secret to our managed PKI, and then the certificate enrollment takes place on the device.

SCEP Certificate Request

Once the SCEP gateway is set up and the server and CA exchange the shared secret, you can create and distribute a configuration profile that will allow managed devices to auto-enroll for certificates. The device will send a certificate enrollment back through the SCEP gateway to the CA. Once authenticated, a signed certificate will be deployed onto the device.

SCEP Signing Certificate

Most MDMs require you to upload a SCEP signing certificate, signed by the CA issuing certificates, that includes the entire certificate chain (signing certificate, Intermediate CA, Root CA). SecureW2 makes it easy to create a signing certificate within our platform. Just select the CA that issues the certificates, and a PKCS12 file will be generated for you to upload to your MDM.

SCEP Device Enrollment Process

SCEP is the protocol that automates the issuance of a certificate to the client device by facilitating communication between the client machine or device and the SCEP Gateway provided by a PKI.

The SCEP device enrollment process is based on the HTTP for the request and response function and supports RSA cryptography. This protocol often includes a challenge password embedded in the CSR, which the SCEP server validates before forwarding the request to the CA.

MDM systems such as Intune, Jamf, and Workspace use SCEP to automate the process of PKI certificate enrollment for both managed devices and unmanaged BYOD.

The process of device enrollment with SCEP can be broadly divided into the following steps:

  1. Request the Certificate Authority (CA) for its root certificate to validate the authenticity of the CA that is issuing the certificate to the client.
  2. Send the Certificate Signing Request (CSR) to the CA to request a certificate for the client device.
  3. Perform server certificate validation to ensure the authenticity of the server.

 

Variations of SCEP

SCEP has multiple variations, each of which is designed to work with different operating systems. Though they vary slightly in terms of the process they follow, each one is designed with the core concept of automating and simplifying the process of device certificate enrollment for passwordless authentication. Here are a few examples:

Intune CA Partner is used with Microsoft Intune, an MDM and Mobile Application Management (MAM) provider. Intune CA is used for issuing certificates to devices managed by Intune, such as Apple, Windows systems, and Android devices. Click here for detailed configuration steps.

Jamf Proxy is used in conjunction with Jamf, an MDM provider that manages only Apple devices. With this SCEP variation, Jamf acts as a SCEP proxy and works differently from the traditional SCEP setups of sharing the SCEP URL and Key directly with the device, which then directly contacts the SCEP server. There are a few additional steps followed to validate the authenticity of the client by looking up client information on the identity provider. To learn more about deploying client certificates using Jamf Proxy, click here.

Microsoft Network Device Enrollment Service (NDES) is a Microsoft implementation of the certificate enrollment protocol SCEP that issues certificates to devices without other Active Directory (AD) domain credentials from a dedicated certification authority (CA). NDES is used to issue certificates to network devices such as routers and switches.

ACME: Automated Certificate Management Environment (ACME), though not a variation of SCEP, ACME is included here because it functions in a similar manner to automate the entire certificate management cycle that includes certificate revocation, issuance, validation, and renewal. It is, therefore, often compared with SCEP.

Certificate Re-Enrollment Process with SCEP

For seamless certificate lifecycle management, re-enrollment before the certificate validity expires is a necessity. When a certificate is due to expire, or the expiry date is approaching, there are two likely scenarios that occur. If the client certificate expiration date is earlier than the CA certificate validity date, the re-enrollment will happen through a renewal of the client certificate. However, if the CA certificate is due to expire before the expiration of the client certificate, the protocol then followed is rollover.

In case of renewal, when the certificate expiration date is approaching, before the expiry date (the date can be defined in settings), the client generates a CSR and will follow the enrollment process using the current certificate to authenticate to the Certificate Authority. Once a new certificate is issued, the current certificate is deleted and replaced with the new certificate.

Rollover occurs when the CA certificate is due to expire. The CA generates a “Shadow CA” certificate that becomes valid once the current certificate expires. The SCEP client requests the CA to create the “Shadow CA” certificate as it is required to generate a “Shadow ID” certificate for clients.

There are, however, a few MDMs, such as Meraki, Addigy, and Mosyle do not support auto-renewal.

Now that we have outlined how the SCEP device enrollment process works, as well as a few important concepts such as SCEP variation and re-enrollment with SCEP, let us look at how to configure SCEP.

How to Configure SCEP at a High Level

Below is a quick overview of configuring SCEP for MDM networks running on certificates using the SecureW2 JoinNow Platform, a cloud-based solution for managed devices.

Configuring your PKI and Building the SCEP Gateway

The SecureW2 Management Portal has the necessary components to deploy a SCEP Gateway with any major MDM. In less than 30 minutes, you can create the following:

  • A custom, private Intermediate CA
  • A Signing CA, signed by the Intermediate CA
  • A SCEP Gateway API URL and shared secret
  • Custom certificate templates and enrollment policies

Configuring SCEP in Your MDM

Now that we have all the components, it’s time to piece everything together to create the SCEP Gateway. Typically MDMs have a dedicated SCEP configuration section. Jamf is one of our favorite Technology Partners, and they have excellent SCEP support and are widely used across the industry. Below is an example image of where you can configure SCEP settings in Jamf. To learn more about how our SCEP Gateway integrates with Jamf, click here.

The following are a high level overview of the steps required to integrate a SCEP Gateway with an MDM to configure devices to auto-enroll themselves for certificates:

  1. Add the SCEP Gateway API URL
  2. Add the SCEP Shared Secret
  3. Upload the SCEP Signing Certificate
  4. Configure the SCEP Payload that is sent to devices
  5. Specify which devices receive the Payload
  6. Optional: Configure Payloads for certificate application settings like Wi-Fi, VPN, Application Access, etc.

To learn more about how our SCEP Gateway integrates with MDMs, check out our Managed Device Solutions Page.

However, Jamf is different from other MDMs, so you will want to look into how your MDM supports SCEP. Below, we will explain how all MDMs support SCEP and outline some unique ways each MDM supports it.

Configuring SCEP with Different MDM/EMMs

802.1x Certificate Via SCEP for Jamf Managed Devices



Jamf is unique in how it implements SCEP. It works as a SCEP Proxy and a SCEP payload. A SCEP Proxy means all the requests from Jamf, and a SCEP Payload means all the requests come directly from the device. SCEP Proxies are ideal because the SCEP request between the device and the SCEP Gateway ensures that a hacker can’t steal the SCEP URL and shared secret to issue themselves certificates. Jamf also supports certificate auto re-enrollment, which is nice when validity periods expire.

Besides that, the Jamf implementation is very standard. Click here to read how to configure Jamf with SecureW2.

SCEP Certificate Deployment with Intune



Intune is unique in that it supports both a traditional SCEP implementation and a more advanced implementation called “Intune Third-Party CA SCEP.” Generic SCEP is also supported.

With the third-party CA configuration, there is an additional step after the SCEP URL and secret are presented. Intune checks device information in Azure AD (Microsoft Entra ID) to verify that the device belongs to the organization and is active before the certificate is issued. This step helps address the security vulnerability of hackers intercepting the SCEP URL and secret and using it to get a certificate issued. It also allows certificates to be automatically revoked when a device is disabled or deleted.

If you’d like to read our documentation about how SecureW2 supports the Intune Third-Party CA SCEP configuration, click here.

SCEP Certificate Enrollment with Addigy


With Addigy, a custom mobile config is used for SCEP enrollment. This is less than ideal because it requires you to build all the settings you need rather than using the native settings available in the MDM. Automatic re-enrollment is not supported.

If you want detailed process steps, please click here.

SCEP Certificate Enrollment with Kandji

With Kandji, you can configure SCEP using its UI or a custom mobile config. When you use the UI, there are advanced options, like certificate auto-renewal, which means you don’t need to push the SCEP Profile again when the certificate validity is about to expire.

For detailed steps, click here.

SCEP with Workspace One for SCEP Certificate Deployment

Workspace One MDM supports a Proxy, which improves security by relaying the SCEP requests to your PKI rather than having the request come directly from the device. It also supports Certificate Auto-renewal, which is convenient for admins.

Click here to read our documentation on how SecureW2 supports SCEP with Workspace.

How Does SCEP Work with Windows?

SCEP works a bit differently in Windows environments compared to other MDM ecosystems.

SCEP vs WSTEP

Developed by Microsoft, the WS-Trust X.509v3 Token Enrollment Extensions Protocol (WSTEP) has the same basic premise as SCEP; creating a secure connection between MDM and devices for sending data. While SCEP works for most MDMs, it does not work for Microsoft GPO. This is where WSTEP comes into play, as it’s the standard for auto-enrolling Active Directory Managed Devices with certificates. SecureW2 offers an easy-to-configure WSTEP Gateway API that many organizations use today for their AD domain-joined devices.

Integrating SCEP and Microsoft Intune

While Microsoft GPO may not natively support SCEP, Microsoft Intune can be configured to distribute certificates with SCEP. Through the gateway, devices can receive configuration profiles so they can request to enroll themselves for certificates.

Configuring Intune to work with SCEP is quite similar to how most MDMs use our SCEP Gateway API. Click here to see our integration guide for enrolling SCEP certificates on Intune.

SCEP Certificate Device Wi-Fi Authentication

For many organizations with MDMs, making sure each device is authenticated takes a lot of time and resources. SCEP automates the certificate enrollment process, so authenticating is streamlined. EAP-TLS is the standard authentication method for devices enrolled for SCEP certificates, because it’s the industry standard for certificate-based Wi-Fi authentication.

EAP-TLS Authentication Benefits

EAP-TLS is considered one of the best methods of authentication because it eliminates the need for credentials and doesn’t require any end user interaction. During EAP-TLS authentication, the device validates the RADIUS server’s certificate before presenting its own certificate, ensuring mutual authentication.

SCEP vs EST

Enrollment over Secure Transport (EST) is considered an evolution of SCEP because EST requires TLS client-side device authentication. SCEP uses the Shared Secret protocol and CSR to start enrolling certificates. Both EST and SCEP are great methods for automated certificate enrollment on managed devices, but the difference lies in whether TLS is used for authentication.

One thing to note, EST has seen a lot of market penetration with IoT devices. SecureW2 works with IoT manufacturers that don’t support EST or SCEP natively so that their software and devices can easily enable them in the software stack or custom deliver protocol options. Devices can then come either pre-loaded with certificates for customers, or customers can use SecureW2 managed PKI to generate their own and enroll all their devices (IoT, BYOD, or Managed) for certificates.

SCEP vs ACME

SCEP and Automated Certificate Management Environment (ACME) have some fundamental differences, despite both being used for certificate management. Designed by the Internet Security Research Group (ISRG) for its SSL certificate service, Let’s Encrypt, ACME is a relatively new protocol. ACME automates the entire certificate lifecycle management from issuance to renewal and revocation, eliminating the need to issue or renew certificates manually. With ACME, you don’t have to keep track of the renewal because once set up, and it will automatically initiate the renewal when the certificate validity is due to expire, thus saving a lot of work and resources that are otherwise involved with manual management of the certificate lifecycle.

ACME handles certificate issuance and certificate lifecycle management by setting up an HTTPS server using JSON messages. It requires an ACME client and an ACME server. You can use a certificate authority of your choice, provided it supports ACME. ACME can be deployed to automate domain ownership verification, CSR generation, issuance, and installation of certificates. ACME can also be used to enable Apple Managed Device Attestation (MDA), which is one of the main ways that SecureW2’s JoinNow Connector leverages the ACME protocol.

Apple designed Apple MDA to provide a higher degree of assurance about the devices at the time of authentication for certificate enrollment for better device trust. It allows devices to communicate with their Apple servers and get attested as genuine devices by prompting the device to use Secure Enclave, which stores unique identifiers such as serial numbers that are instrumental in validating the authenticity of the device. The diagram below shows the process flow of how ACME is used with JoinNow Connector and an MDM to distribute payload for certificate enrollment in conjunction with Managed Device Attestation.

To know more about how the process works, check out our blog on Apple Managed Device Attestation.

SCEP vs CMP and CMC

Certificate Management Protocol (CMP) and Certificate Management over CMS (CMC) are both similar to SCEP structurally, but handle different aspects of digital certificates. SCEP and EST mainly cover the enrollment and issuance of certificates, while CMP and CMC mainly cover certificate management, including revocation, status, and request.

The SecureW2 JoinNow Platform employs the SCEP gateway to distribute certificates, and the Management Portal allows you to manage issued certificates accordingly. Organizations can manage the whole certificate process easily from anywhere.

How to Configure SCEP with SecureW2

SecureW2 allows you to easily configure SCEP for automating certificate enrollment and renewal. Below is a brief overview of the process steps:

  1. Configure the SCEP Gateway API in SecureW2. Use the Getting Started Wizard to generate a shared secret key and an access token.
  2. Create a new SCEP URL using the shared secret and the token. This SCEP URL will be pushed to your devices to enable auto-enrollment for certificates.
  3. Create Enrollment Policies as per your organization’s policies.
  4. Configure the Certificate Template for SCEP Gateway and insert the SCEP URL created in step two above. This is needed because it contains all the relevant information for MDMs to configure themselves to place CSR with SecureW2.

Using SCEP with the JoinNow Platform helps you automate certificate management with greater accuracy and ease, improving network security by ensuring every device on your network is equipped with a certificate.

Configuring SCEP can be complex and time-consuming, requiring significant expertise. With SecureW2 PKI solutions, SCEP implementation is simplified by giving you the power to manage all your certificates from anywhere using a single Management Portal.

SecureW2 works with IoT manufacturers that don’t natively support EST or SCEP to ensure their software and devices can be easily enabled in the software stack or custom-deliver protocol options.

Simplifying SCEP With SecureW2

Secure configuration of managed devices for WPA2-Enterprise is non-negotiable, but it doesn’t have to be difficult. Our powerful Gateway APIs allow you to use SCEP to enroll certificates to an unlimited number of managed devices in the same amount of time it takes to manually configure a single device. It’s the simplest and most secure way to provision certificates to all your devices.

Certificates will need to be distributed to every managed device for certificate-based authentication to work, but it can be done quickly and easily with our SCEP Gateway API. Configuring a SCEP gateway may seem like a difficult task but SecureW2 PKI services allow for easy implementation. The SCEP Gateway API allows managed devices to silently and easily enroll for certificates on their own. Plus, our easy-to-use Management Portal allows you to manage the entire certificate lifecycle entirely, additionally giving you full visibility into the success of the certificate enrollment for fast and remote troubleshooting.

The SecureW2 JoinNow Platform offers organizations a turnkey Managed PKI Solution that allows you to have greater visibility, control, and automation over the certificates issued within your network. We designed it to work directly with your cloud identities, such as Azure, Okta, Jamf, or Intune, to ensure that PKI management is in line with your IAM policies. If you’d like to learn more, check out our pricing and schedule a demo today.

What is the Difference Between SCEP and CSR?

SCEP and CSR are two distinct but related components of a public key infrastructure (PKI) ecosystem.

  • SCEP: A certificate enrollment protocol that securely transports and processes PKCS#10 Certificate Signing Requests (CSRs) between devices and a Certificate Authority.
  • CSR: A CSR is a structured cryptographic request object, while SCEP is the protocol used to securely transmit that request to a CA and retrieve the resulting certificate..

A CSR is a document, while SCEP serves as the delivery mechanism.

What is a SCEP Server?

A SCEP server is a network-accessible service that acts as an intermediary between endpoint devices and a Certificate Authority, facilitating the automated issuance and renewal of digital certificates at scale. 

When a device needs a certificate, say a laptop enrolling in a corporate network or a router requiring a TLS identity, it connects to the SCEP server and submits its certificate request using the SCEP protocol.. The server validates the enrollment request according to configured policy (for example, verifying a challenge password or device identity through an MDM), forwards the CSR to the backend CA for signing, and returns the issued certificate to the device 

Choosing a reliable and well-configured SCEP server is a foundational decision in any PKI deployment. SCEP servers directly impact certificate availability, network security posture, and the organization’s ability to respond to certificate expiration events before they cause outages.

Disadvantages of SCEP: SCEP vs. Dynamic SCEP vs. ACME

Despite its widespread adoption, traditional SCEP carries several notable disadvantages that have prompted the industry to develop more modern alternatives better suited to today’s complex security environments. Many traditional SCEP deployments rely on static shared secrets (challenge passwords) for enrollment authorization, which can introduce risk if the secret is reused or improperly protected.. This also makes SCEP poorly suited for zero-trust architectures where static secrets are a liability. 

Dynamic SCEP is an implementation approach that addresses this weakness by generating one-time-use challenge passwords that are tied to specific enrollment requests, which significantly reduces the attack surface associated with credential reuse. Dynamic SCEP also improves enrollment security in large-scale deployments. 

ACME (Automated Certificate Management Environment) protocol takes an even more modern approach by using cryptographic domain validation challenges instead of shared secrets. This makes ACME scalable, cloud-native, and ideal for web-facing infrastructure. 

SCEP remains deeply embedded in legacy enterprise and network device ecosystems due to broad vendor support, but organizations evaluating new PKI deployments should assess protocol choice based on device ecosystem compatibility, identity validation requirements, transport security expectations, and long-term automation strategy.