Intune SCEP Certificates Without a Windows Server

If you administer Microsoft Intune, or you have been handed the job of managing certificates on managed devices, the standard path runs through Active Directory Certificate Services and the Network Device Enrollment Service role. That is the setup Microsoft's own documentation walks you through, and it means standing up a Windows server, joining it to a domain, and publishing it to the internet.

There is another option. Intune supports third-party certificate authorities, and Infisical can be one of them. It handles the certificate authority, the issuance rules, and the SCEP endpoint your devices talk to, all in one place. By the end of this walkthrough you will have a certificate authority you own and a certificate issued to an Intune managed device. From there you can point it at Wi-Fi, RADIUS, VPN authentication, or anywhere else that needs it.

One note before starting: SCEP enrollment and the Microsoft Intune connection both require a paid Infisical plan. You can check the tiers on the pricing page.

There are three pieces in this setup, and each one does exactly one job.

The first is the certificate authority, which in this case is Infisical. On its own, a certificate is just a file with a name and a public key in it, and anyone can generate one. What makes it mean something is a signature from something your devices already trust. Producing that signature is what a certificate authority does, and of the three moving parts, it is the only one that does it.

The second is Intune. Intune decides which devices should get a certificate, and it does that by pushing down a certificate profile. Infisical checks with Intune before issuing anything, and Intune itself never issues a certificate.

The third is the device. The device generates a key pair, which is two matching halves. It keeps the private half secure locally and asks Infisical for a certificate covering the public half. That direction matters: the device asks for a certificate rather than Infisical handing one out. Intune decides who should ask and confirms each request is real, the device does the asking and holds the private key, and Infisical signs.

For any of this to work, there are two different certificates involved, and they do two different things.

The first is your CA certificate, which you export from Infisical. It is a public certificate, and it ends up in the trusted root store of every device. Its job is to let a device recognize the things your certificate authority has signed. Without it, your devices have no way to tell a certificate signed by your CA apart from one anybody generated.

The second is the certificate each device gets. Every device gets its own, unique to it, and that is the device's identity. One certificate says who all your devices trust. The other says who the device is. That is why you will build two separate Intune profiles later and apply both to the same device.

If the underlying trust model is new to you, we made a separate video on how certificates, certificate authorities, and PKI fit together that covers the components of a certificate in more depth.

Infisical is an open-source platform for managing secrets and certificates. The product used here is Certificate Manager, and everything in this walkthrough happens inside a Certificate Manager project. You can run it on Infisical Cloud or self-host it. For a full tour of how certificate management works in the platform, there is a dedicated video on Infisical Certificate Manager.

Inside a project, there are four layers, and it helps to know how they stack.

At the bottom is the certificate authority, the thing that signs. A CA has its own expiry date, and when a CA expires, every certificate it ever signed stops being trusted. You generally want that date much further out than the lifetime of the certificates it issues, so years rather than months.

Above the CA is the certificate policy, a rule set for what is allowed to be issued at all: which subject attributes can appear, which subject alternative names, how long a certificate can remain valid, and which algorithms and key usages are acceptable. Each of these can be allowed, denied, or required.

Above the policy is the certificate profile, where an application team says how they want their certificates to come out: how long they last, what they can be used for. The profile points at the CA for signing, and anything it asks for has to stay inside the policy's rule set.

At the top is the application, the thing in your organization that needs certificates. Your Intune managed laptops are an application. An internal API or a Kubernetes cluster would be a different one. This is the level where you choose the profile, choose how clients enroll, and review the certificates that have been issued.

In Infisical, open the Certificate Manager product and go to Certificate Authorities, then create an internal CA. Set the CA type to `root`, give it a common name, leave the key source as Infisical, and pick `RSA 4096` for the key algorithm. A 10-year validity is a reasonable default, and a path length of `-1` is fine.

Next, go to Certificate Policies and create one for Intune device certificates. Leave subject attributes and subject alternative names unrestricted for now. Restrict signature algorithms to `SHA256-RSA`, and key algorithms to `RSA 2048` and `RSA 4096`. Allow the `digitalSignature` and `keyEncipherment` key usages, allow `clientAuth` for the extended key usage, and set maximum validity to 365 days.

Then go to Certificate Profiles and create a profile pointing at the CA and the policy you just made. Set the default time to live to one year, which is the same number you will enter in Intune later, and set the same defaults for algorithm, key usages, and extended key usage.

Finally, go to Applications and create one for your managed laptops, connecting the certificate profile you just built.

At this point everything exists in Infisical, but nothing can request a certificate yet, because nothing has been given a way to do it.

When a device sends a certificate request to Infisical, Infisical has to ask Intune whether that request was actually authorized. Nobody is signed in during that exchange, so Infisical needs its own identity in Microsoft to ask the question.

That service identity is an app registration in Entra. The name is a little misleading. This is not an app you install on anyone's device. You create the registration, grant it permission to do a couple of things, then hand its credentials back to Infisical so Infisical can talk to Microsoft.

In the Microsoft Entra admin center, go to App registrations and create a new single-tenant registration. Add two application permissions: `scep_challenge_provider` under Intune, and `Application.Read.All` under Microsoft Graph. Then grant admin consent, which is the part that is easy to skip. Together these let Infisical find Intune's validation service and check certificate requests against it, and both need tenant-wide consent.

Save three values from the registration: the application ID, the directory ID, and a client secret you create. Copy the secret value while it is on screen, because it will not be shown again. Note the expiry you picked as well. When that secret expires, certificate enrollment stops, and the error will not obviously point back here.

Back in Infisical, go to Settings and create a Microsoft Intune app connection, pasting in the client secret, the application ID, and the directory ID. Infisical validates them on save, so a successful connection message confirms the permissions and consent were set up correctly.

Every device has to ask for its certificate, and SCEP, the Simple Certificate Enrollment Protocol, is how it asks. An enrollment method in Infisical is what turns a profile into an endpoint something can actually talk to.

Open your application, go to Settings, find your profile, and click Configure under enrollment methods. Add a SCEP enrollment method and set the challenge type to Microsoft Intune, then pick the connection you just created.

The challenge type is what proves a certificate request is allowed to be fulfilled. With SCEP this is often a static shared password. With the Intune connection, Intune generates a separate single-use challenge for each device, and Infisical checks in with Intune before issuing anything, so there is no shared password anywhere.

One setting matters more than the rest: Sign RA certificate with the CA has to be on. Intune requires it, and it cannot be changed after the enrollment is created.

Enabling the method gives you a SCEP endpoint URL. Hold onto it. If you self-host Infisical, this URL is what every device talks to, so it has to be reachable from wherever your devices are.

Your devices need your CA's certificate before anything else works. This is the first of the two certificates described earlier.

In Infisical, go to Certificate Authorities, open your CA, and download the CA certificate. Infisical exports it as a `.pem` file and Intune's upload field only accepts `.cer`, so rename the extension.

In Intune, go to Devices, then Configuration, and create a new policy. Pick your platform, choose the Templates profile type, and select the Trusted certificate template. This profile does one job: it installs the CA certificate into the trust store of every device you assign it to. From then on, those devices trust anything that CA signs.

The deployment setting depends on the platform. On Apple, set the deployment channel to Device channel, since this certificate identifies the machine rather than the person, which puts it in the system keychain. That cannot be changed later without creating a new profile. On Windows there is no deployment channel, only a destination store, and since this is a root CA you want the computer certificate store root. Upload the `.cer` file and assign the profile to the group of devices that should get certificates.

Create a second policy in the same place, again using Templates, this time with the SCEP certificate template. On Apple, set the deployment channel to Device channel again and leave the certificate type as Device.

Subject name format is the setting worth slowing down for. The subject name is the identity written into the certificate, and you write it in Intune as a template using double curly braces, which Intune fills in per device when it delivers the profile. `CN` is the common name and the main identifier. The simplest version is the device name, but a user can change that. If you want something they cannot change, the default `AAD Device ID` is the device's Entra ID, and it is a common choice for network authentication.

This choice matters because whatever authenticates later, RADIUS, VPN, or Wi-Fi, matches on that name. If your RADIUS server is configured to match on the Entra ID and you issued on device name, authentication fails. The certificate is still perfectly valid. It was just issued with something RADIUS is not set up to match.

There is a second reason to be deliberate here. The Infisical policy left subject and SAN unrestricted, so anything is allowed and this just works. If you tighten that policy later, the pattern you use in Intune has to be on the allow list, or Intune will approve the request and Infisical will refuse it.

Leave the subject alternative name empty, set certificate validity to one year to match the Infisical profile, choose the `digitalSignature` and `keyEncipherment` key usages, and set key size to 2048. Point the root certificate field at the trusted certificate profile you just made, and set extended key usage to client authentication, matching the Infisical profile again.

The renewal threshold is a percentage of remaining life. A threshold of 20 means the device asks for a new certificate once 80 percent of the lifetime is gone, so roughly 10 months into a one-year certificate.

Last, paste in the SCEP endpoint URL from Infisical, which again has to be reachable by all of your devices. Assign the profile to the same group and create it.

These profiles are per platform. If you have Windows devices as well as Macs, you build a second pair of profiles for Windows. The Infisical side is shared, and both just point at the same endpoint.

Sync a device or wait for its next check-in. In Intune, open the SCEP profile and view the device status report, which takes a few minutes to populate.

If it failed, Infisical's audit logs record what Intune said when it was asked, which tells you which side refused.

You can also check the device itself. On macOS, open Keychain Access and look in the system keychain for your root CA and the device certificate, which should show a one-year expiry. On Windows, the equivalent is `certlm` or `certmgr`.

Back in Infisical, the application's certificate inventory lists the same certificates with their expiration dates, validity, and issuance details, all centrally in one place.

When a certificate reaches the renewal threshold, Intune re-enrolls it through the same SCEP profile with a brand new challenge, so renewal is validated exactly the way the first request was, fully automated.

To put the whole flow in one paragraph: the trusted certificate profile installs your CA's certificate on the device. The SCEP profile gives the device a single-use challenge and the Infisical endpoint. The device generates a key pair, keeps the private key, and sends its request to Infisical with the challenge attached. Infisical checks the challenge with Intune, signs the certificate with your CA, sends it to the device, and reports it back to Intune, which is why it shows up in Intune's certificate reports about a day later. When you set up Wi-Fi, VPN, or RADIUS authentication later, you point it at the same CA.

The certificate authority you just built is not only for Intune. SCEP is one of four enrollment protocols it supports, alongside API, EST, and ACME. The same CA, with the same root your devices already trust, can issue certificates to your servers, your internal services, and your Kubernetes workloads. There are guides for NGINX, Apache, Windows Server, and Kubernetes with cert-manager.

It also survives a change of MDM. If you move off Intune to Jamf Pro or anything else, you rebuild the profiles in the new MDM and the enrollment in Infisical. The CA stays exactly as it is, certificates that are already issued stay valid, and your RADIUS configuration does not have to change.

That is a certificate authority you own, issuing certificates to your managed devices, with no Windows server anywhere in the picture. The full written version of these steps lives in the Microsoft Intune with SCEP guide, which follows the same order as the video.