Certificate-based authentication

How it works

A certificate authority signs a certificate binding an identity (a user, a device, or both) to a public key. The matching private key is generated on the device and stays there, in the Secure Enclave on Apple hardware or the hardware-backed keystore on Android. During a TLS handshake the server asks the client to sign a challenge with that key. Only the holder of the key can answer, and the key is never transmitted.

Two delivery methods dominate on managed devices:

• SCEP. The MDM sends a payload pointing at a SCEP server with a one-time challenge. The device generates its own key pair and requests the certificate directly. The private key never exists anywhere else, which is why this is the preferred route. SCEP was finally published as RFC 8894 in September 2020, decades after deployment made it a de facto standard.
• PKCS#12. The MDM ships a .p12 bundle containing certificate and private key together, protected by a password. Simpler to set up, weaker by design, because the key was generated off-device and travels. Fine for a small pilot, not for a fleet.

Apple added ACME with managed device attestation in iOS 16 and macOS 13 in 2022, which lets the CA verify that the requesting device is genuine Apple hardware with the identity it claims before issuing anything. Worth planning for if your CA supports it.

The classic use cases are the ones users notice only when they break. Wi-Fi with 802.1X and EAP-TLS: the phone joins the corporate SSID with no shared key and no prompt, and a departed employee's certificate is revoked instead of the whole office PSK being rotated. VPN and ZTNA clients authenticate the same way. Then internal web apps, Exchange, and MDM enrollment itself, which uses a device identity certificate under the hood.

Why it matters for a fleet

Phishing resistance is the headline. There's nothing to type, so there's nothing to hand to a fake page. The key is bound to hardware, so malware on another machine can't replay it.

But the real story of certificate deployments is expiry, and it's where teams get hurt. Certificates have lifetimes. Renewal has to be automatic, it has to start well before the end date, and it has to work on a device that's offline the week it matters. A fleet of 800 phones with one-year certificates issued during the same rollout week means 800 renewals landing in the same week next year. Stagger lifetimes, monitor the expiry distribution, and test what actually happens to a device whose certificate lapsed: does it recover on its own, or does it need a visit?

Revocation needs a plan too. Publishing a CRL that nothing checks is a compliance exercise, not a control.

How Appaloosa handles it

Appaloosa delivers certificate payloads to enrolled iOS, iPadOS, Android, Windows and macOS devices: your CA's root and intermediates so internal services are trusted, SCEP configurations so each device enrolls its own key, or PKCS#12 bundles where that is the only option. Certificates are then referenced by the Wi-Fi, VPN and mail payloads pushed from the same console, per device group, and they leave with the work data when a device is wiped selectively. The payload types and the order they apply in are part of the profiles Appaloosa installs at enrollment.