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. There is a longer walkthrough in what is a SCEP server.

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.

A certificate you issued from the dashboard for installing by hand is the exception: nothing on that device can ask for a renewal. Its row in your certificate list gains a Renew button in its last 90 days (the row shows the date until then), and the expiry warning email links straight to it. Renewing downloads a new certificate for the same name with a new private key — install it in place of the old one, then revoke the old one from the list once the device is on the new certificate.

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. Your account generates the .mobileconfig for you, with your CA, your endpoint and your challenge already in it — and, if you give it an SSID, the Wi-Fi payload wired to the certificate it enrolls.
• 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 802.1X guide covers the wider picture — EAP-TLS, what the certificates have to contain, and the order to roll it out in.

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.

For a production network, mirror the list to an address you control. We recommend this as the default rather than offering it as an advanced option, because it removes the last thing your day-to-day authentication depends on us for: an issued certificate already works without us, and once the CRL is yours, so does revocation checking. Tell us the mirror address and we stamp your address into the certificates instead of ours, so devices never query us at all. The setup guide generates the cron job.

The obligation moves with it. A mirror that stops updating expires, and an expired list rejects every device just as surely as an unreachable one — so monitor the mirror the way you would monitor any other piece of authentication infrastructure.

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.

The free tier, plans and refunds

Every account includes a free tier of 5 devices. It does not expire and needs no card. Enrol five devices and they keep working, keep re-enrolling, and keep appearing on your revocation list like any other; revoke one and the slot is free immediately. Only a sixth device needs a paid plan.

Plans are measured in devices — distinct certificate subjects that are currently valid — not in certificates issued. A device that re-enrolls does not consume another slot, and revoking one frees its slot immediately. Prices and tiers are on the pricing page.

An account whose paid plan ends returns to the free tier rather than to nothing.

30-day full refund on yearly plans

If ScepNet is not right for you, ask within 30 days of paying for a yearly plan and we refund the whole year — for any reason, and without pro-rating it.

Monthly plans are not covered. Nothing renews on its own, so a monthly plan ends at the end of its period unless you buy another.

Separately, and at any time: if the service does not work as described, we refund the period in question.

A refund revokes immediately. A plan that simply ends is slower — see below.

If you do not renew

A period that ends without renewal gives you a 30-day grace period. Your devices carry on authenticating and re-enrolling throughout it; only adding new devices stops. We warn you by email and on your dashboard as it runs down.

This applies to monthly plans. Certificates can be issued for up to three years, so without it a single month's payment would buy three years of service.

The full wording is in the terms of service.

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.