Published on

The Napkin Architecture Series - Device Onboarding with SCEP and NAC

Authors

The Why

Ever wondered how a fresh, out-of-the-box iPad securely authenticates to your corporate Intranet without a user ever typing in a Wi-Fi password?

In the old days, we handed out shared network passwords or let devices talk directly to our Certificate Authorities (CAs). Both are security nightmares. If you blindly trust a device just because it asks for a certificate, you aren't doing Zero Trust. We need a way to validate the device's compliance before we mint its identity.

Here's the trick: we put a Network Access Control (NAC) system right in the middle as a smart proxy. Let’s break down the napkin sketch above.

The Who

  • MDM Server: The control plane. It manages the endpoints and holds the device inventory.
  • iPad: The end-entity trying to get on the network.
  • NAC: The bouncer. It intercepts requests and verifies compliance.
  • Intermediate CA (SCEP) & Luna HSM: The trust plane. The CA processes the request, while the HSM physically protects the signing keys.

The Flow

Follow the arrows in the diagram above to see how we safely mint and deliver a certificate:

Step 1 (Fetch): The MDM server pushes a configuration profile to the iPad. This includes the RootCA.crt, a dynamic challenge password, and a SCEP URL (crucially, this URL points to the NAC, not the CA).

Step 2 & 3 (Prep): The iPad installs the Root CA, then securely generates its own Certificate Signing Request (CSR) and private key right on the device.

Step 4 (Delivery): The iPad packages the CSR and the challenge password, encrypts it using the NAC's public key, and sends it over.

Step 5 (Validation & Posture Check): Here is the magic. The NAC acts as a proxy, but it doesn't blindly trust the password. It decrypts the package and makes an API call back to the MDM server. The MDM checks its database (relying on its local device agent to report things like jailbreak status or OS version). If the MDM says the device is "Non-Compliant," the NAC drops the request instantly.

Step 6 (Re-wrap & Proxy): Once the NAC confirms the device is legitimate, it takes the CSR, re-wraps it (encrypting it via the CA's public key), and forwards the SCEP request to the Intermediate CA.

Step 7 (Delegate): The CA receives the request and delegates the heavy cryptographic lifting (decrypting the package and signing the cert) to the Thales Luna HSM via PKCS #11.

Steps 8 & 9 (Return Trip): The HSM spits out the freshly minted End-Entity Certificate. The CA hands it back to the NAC, which finally delivers it to the waiting iPad.

Step 10 (Access): The iPad now uses this highly trusted certificate to silently authenticate to the corporate Wi-Fi using 802.1x EAP-TLS.

Why I Like This Pattern

The CA is isolated: The PKI never talks directly to untrusted public endpoints. The NAC shields it.

Compliance-driven issuance: Certificates are only minted if the device passes the NAC's strict posture checks in Step 5.

Keys never travel: The iPad's private key never leaves its secure enclave, and the CA's signing key never leaves the physical HSM. It's cryptographically airtight.