How ScepNet works, before you sign up.

What it is

ScepNet operates a private certificate authority for your organization and issues X.509 certificates to your devices. Those certificates are what your devices present to get onto the network — over 802.1X on Wi-Fi and wired ethernet, in place of a shared password.

Each organization gets its own root and intermediate CA, generated at signup. They are not shared with any other customer. A certificate issued to someone else does not chain to your root, so your network has no reason to accept it. That isolation comes from the shape of the hierarchy, not from a rule we apply.

This is a private CA. Browsers do not trust it, and it cannot issue certificates for public websites. It is for devices you control, on networks you control.

How enrollment works

SCEP — Simple Certificate Enrollment Protocol — is how a device asks a CA for a certificate. Every serious MDM speaks it, which is the reason we use it.

1. Your MDM sends a device a profile containing a SCEP URL and a challenge password.
2. The device generates a private key on the device. That key never travels, and we never see it.
3. It sends a signing request to the URL, proving it is allowed to ask by including the challenge.
4. We sign a certificate and return it. The device installs it and starts using it.

The whole exchange is encrypted to the CA, so the device's request is not readable in transit even by us until we decrypt it.

Renewal

Certificates are valid for a year by default; you can set anything from 6 months to 3 years. Renewal is driven by your MDM, not by us — we have no channel to your devices and never initiate anything. Intune, Jamf and the other managed platforms re-enroll automatically as a certificate ages. A configuration profile installed by hand, with no MDM behind it, does not.

Renew before expiry and the device does not need the challenge again. Once a certificate has actually expired that shortcut is gone, and the device needs the profile pushed again — so it is worth letting your MDM handle it.

What you need

• An MDM, or a way to deliver a configuration profile. Jamf Pro, Intune, Mosyle, Kandji, Workspace ONE, or a profile you install yourself.
• A RADIUS server that does EAP-TLS — Windows NPS, FreeRADIUS, Cisco ISE, Aruba ClearPass.
• Wi-Fi or switches that support 802.1X. Effectively all business equipment does.

You do not need to run a certificate authority, install NDES, or open any port to the internet. Nothing of yours becomes reachable from outside.

MDM and platforms

The endpoint is standard SCEP with a static challenge. One URL serves your entire fleet — there is no per-device URL and no per-device setup.

• Apple (macOS, iOS, iPadOS) — via Jamf Pro, Mosyle, Kandji, Workspace ONE, or a plain .mobileconfig. Add a SCEP payload, set the challenge type to Static, key size 2048.
• Windows — through Intune's SCEP profiles, or any NDES-style proxy pointed at our URL.
• Android — through the SCEP support in your EMM.
• Network appliances — anything that speaks SCEP with a static challenge.

The part that breaks deployments

Not enrollment — enrollment usually works first time. What fails is authentication, when the names inside the certificate do not match what your RADIUS server expects:

• Device certificates need the fully-qualified hostname in a DNS SAN. For Active Directory it must match the computer object's dNSHostName.
• User certificates need the UPN as an otherName principal-name entry (1.3.6.1.4.1.311.20.2.3). A UPN in the subject CN alone is not enough for AD.

RADIUS and 802.1X

Your RADIUS server needs to trust your CA and to be able to check revocation. Both the trust anchor and the revocation list are downloadable from your dashboard at fixed URLs.

The RADIUS server also needs a server certificate of its own — the other half of an EAP-TLS handshake. You can issue one from your dashboard, from the same CA, so devices that already trust your root trust the server too.

Device certificates are issued with clientAuth only, and server certificates with serverAuth. Keeping those apart means a device certificate cannot be used to impersonate your RADIUS server.

Revocation

Revoking a certificate adds it to a certificate revocation list published at a fixed address. The list is regenerated the moment you revoke something, and again automatically before it expires, so the URL always serves a current list.

Every certificate we issue carries that address inside it, so a validator knows where to look without being told.

An expired CRL fails authentication outright. Validators do not treat "cannot fetch the list" as "nothing is revoked" — they reject the chain. Our lists are valid for 7 days and refreshed well before that; fetch daily and you have ample margin. If you would rather not depend on us being reachable, mirror the list to an address you control and we will stamp your address into the certificates instead.

Bringing your own root

If you already have a corporate CA, you do not have to introduce a second trust anchor. Download a signing request from your dashboard, sign it with your own offline root, and paste the result back. We then issue beneath your root.

Your root key never leaves your premises and never touches this service. Your devices already trust it, so nothing needs redistributing. You can also constrain what our intermediate is permitted to issue for, so it cannot mint a certificate for a name outside your domains even if it wanted to.

You can start on a CA we generate and move to your own later. Devices already enrolled keep working through that change, because the intermediate keeps its key.

Limits and honest caveats

• Not publicly trusted. These certificates secure your network, not your website. No browser will accept them.
• Static challenge passwords. The challenge is shared across your fleet, which is how SCEP works nearly everywhere. Anything holding one can enroll, so scope the profile to the devices that need it and rotate if one leaks. Rotating is one click.
• Renewal is your MDM's job. We never contact a device. If nothing re-enrolls it, a certificate expires and that device stops authenticating.
• No service-level agreement. We monitor continuously and back up nightly, but we do not sell an uptime guarantee. Certificates already issued keep working regardless — an outage stops new enrollments, not your Wi-Fi.
• Deleting your account destroys your CA key. After that nothing issued under it can be revoked or re-issued, and no revocation list can be published. Remove the trust anchor from your devices first.