Register for part 2 of our Device Identity Webinar Series!

Certificate-based device identity for iOS and Android

Give managed iPhones, iPads, and Android devices certificate-based access to corporate Wi-Fi and supported VPNs. Smallstep controls issuance with inventory and enrollment policies; your MDM delivers the credentials. Compatible supervised Apple devices add hardware-backed attestation for stronger device identity assurance.

Get a demo
background gradientbackground texture
ACME device attestation on supervised iOS and iPadOS
Issued under inventory and enrollment policy
Android through Dynamic SCEP
Wi-Fi, VPN, and Safari on Apple devices
Works with Jamf, Intune, Workspace ONE
Renewal delivered through your MDM

Phones are in your inventory. Make them prove it.

A SCEP enrollment demonstrates possession of valid enrollment credentials, not the identity of the hardware. On supervised iOS and iPadOS, the ACME certificate payload has the device attest to Apple's attestation authority, and Smallstep matches the attested serial to your inventory before issuing. The key is generated in the Secure Enclave and cannot be exported.

Requires compatible Apple hardware, supervision, and an MDM that deploys the ACME payload with the serial available; otherwise Dynamic SCEP applies.

How ACME device attestation works

Your MDM integrates with Smallstep at two points

First, inventory: Jamf, Intune, Workspace ONE, or Mosyle syncs devices and assigned users into Smallstep, where approval and enrollment policy live. Second, the certificate payload: your MDM deploys the ACME payload where it supports one, or a Dynamic SCEP payload with a single-use challenge, alongside the Wi-Fi or VPN profile that uses the certificate. Smallstep hosts the enrollment endpoint; no SCEP connector or inbound network path is needed. Challenge exchange follows each MDM's mechanism.

What the certificate can do on an iPhone or iPad

An MDM-delivered identity serves Apple system services: 802.1X Wi-Fi, configured VPN connections, Safari client-certificate authentication, and the managed relay payload on iOS 17 and later. Ordinary third-party apps cannot read it because of keychain isolation; some managed VPN apps can, through Apple's VPN entitlement. S/MIME needs an email identity and its own certificate configuration, not the device certificate.

  • Validate each app and payload with your MDM before promising it.

Android: inventory-gated issuance through Dynamic SCEP

Android devices enroll through Dynamic SCEP with a short-lived, single-use challenge tied to each enrollment request, and Smallstep applies its inventory and enrollment policies before issuing. That reduces the risk of shared SCEP secrets but does not cryptographically prove the Android hardware; key protection depends on device and MDM configuration. Supported Wi-Fi and VPN use varies by Android Enterprise enrollment mode, MDM, and VPN client. Static SCEP is not supported.

Smallstep manages issuance. Your MDM delivers it.

Smallstep applies enrollment policy and issues the certificate. Your MDM delivers the certificate and network profile. At connection time the RADIUS server or VPN validates the certificate and applies its own access policy, including revocation checking where supported and enabled. Renewal rides on the MDM profile, so plan the certificate lifetime around your MDM's renewal behavior.

Your MDM owns supervision, profiles, and delivery. Smallstep owns which devices get a credential and the assurance behind it.

Key benefits for mobile fleets

No agent on the phone

Enrollment runs through the MDM payload Apple and Android already support. No Smallstep agent required.

Certificates for authorized devices

Certificates go to devices that satisfy the configured inventory, approval, and enrollment policies; approval can be manual or automatic for trusted inventory sources.

Device identity assurance matched to each platform

Apple attestation and Secure Enclave keys on supervised iOS and iPadOS; Dynamic SCEP under inventory policy on Android and unsupervised Apple devices, without hardware proof. The page says which applies.

Shared and student devices covered

Device-level certificates let carts of iPads and shared handsets authenticate to Wi-Fi without a user login, carrying an inventory-backed identifier such as the serial where the workflow supports it. Assign users where a user identity is needed.

Passwordless Wi-Fi and VPN

EAP-TLS Wi-Fi and IKEv2 VPN profiles reference the certificate; devices join without a password prompt or a shared network key.

Lifecycle that follows inventory

Issuance stops when a device leaves inventory; existing certificates run to expiry unless revoked on an authority with active revocation. Renewal is delivered by the MDM profile.

Bring phones and tablets under the same device identity as laptops.

One inventory, one policy, one CA. Your MDM delivers the profile; Smallstep issues under the policy you configure.

Book a demo

FAQs Smallstep for iPhone, iPad, and Android

Yes, on supervised, compatible devices (A11 Bionic or later) running iOS 16 or iPadOS 16.1 and later, through an MDM that can deploy Apple's ACME certificate payload configured for this workflow; the attested serial number must be available for inventory matching, which excludes privacy-preserving User Enrollment. The device requests an attestation from Apple's attestation authority, which proves the key was generated in that device's Secure Enclave, and Smallstep checks the attested serial number against inventory before issuing. Apple's Managed Device Attestation is available through supported management workflows, but the identifying attributes depend on enrollment type: User Enrollment omits the serial number and UDID, which makes it unsuitable for Smallstep's serial-based inventory check. Supervised devices are the documented path. Apple does not expose attestation to apps, which is why the agent-based paths used on laptops do not apply here.

Jamf Pro supports Apple's ACME certificate payload. Smallstep documents ACME device attestation with Jamf on macOS; confirm the supported iPhone and iPad workflow with our team. Dynamic SCEP is available for supported mobile MDM integrations, and an MDM supporting the payload is not by itself confirmation of this attestation and approval workflow. Intune uses ACME only for its own enrollment certificate and does not deploy third-party ACME certificate profiles, so Intune-managed iPhones and iPads use a Dynamic SCEP profile instead. For Workspace ONE, Mosyle, and other MDMs, confirm ACME payload support with us; where it is absent, Dynamic SCEP applies.

Dynamic SCEP. The MDM obtains a single-use challenge for each enrollment request, and Smallstep applies its inventory and enrollment policies, but there is no attestation: the certificate proves the requester had the profile and the challenge, not that it is specific hardware, and a profile reused on another device is not ruled out by the challenge alone. Treat it as a managed-device signal, not device identity, and keep sensitive resources behind supervised, attested devices where you can.

Through Dynamic SCEP from your MDM, such as Intune or Workspace ONE, with a short-lived, single-use challenge per enrollment request exchanged through that MDM's mechanism. Issuance follows inventory policy and reporting shows each device. Android key attestation is not used today, so this does not prove the hardware; key protection depends on the device's keystore and the MDM's configuration. Supported use differs by Android Enterprise mode: Intune, for example, supports SCEP Wi-Fi but not VPN profiles on AOSP devices. Static SCEP is not supported.

Apple system services that reference an MDM-delivered identity: Wi-Fi with EAP-TLS, configured VPN connections, Safari client-certificate authentication, and the managed relay payload on iOS 17 and later. S/MIME is supported by Apple but needs an email identity and certificate configuration of its own. Ordinary third-party apps cannot read the identity because of keychain isolation; managed VPN apps with Apple's VPN entitlement can, including hardware-bound ACME identities. Validate the specific app and MDM configuration before relying on it.

Separately from Wi-Fi and VPN. Entra supports certificate-based user authentication on iOS in supported browsers and apps, subject to its certificate-to-user mapping and client requirements; a device certificate carrying a serial number is not a user certificate and does not satisfy Conditional Access device-compliance on its own. Google's enterprise certificate condition in Context-Aware Access relies on Endpoint Verification on desktop; mobile access levels use other endpoint-management conditions. Validate the certificate identity, client, and policy for each provider, and see the Entra and Google Workspace pages.

No. Shared carts, kiosks, and student iPads can authenticate to Wi-Fi with device certificates and no user login. The certificate can identify the device with an inventory-backed identifier, with hardware identity verified when the enrollment method supports attestation; confirm the subject format for your workflow. Assign a user in inventory where a resource needs a user identity. For schools, see the education page for the BYOD and student-laptop patterns.

Following the MDM's supported behavior. For Intune-managed iOS and iPadOS devices, SCEP renewal happens inside the configured threshold and needs the device to sync while unlocked; if renewal fails and the certificate expires, Intune does not redeploy it automatically. Validate certificate and Wi-Fi profile relationships, renewal thresholds, and recovery from a failed renewal before deployment, and test one renewal cycle first.

Remove it from the MDM or from Smallstep inventory and issuance and renewal stop; the existing certificate is not invalidated by removal and runs to expiry unless revoked. Revoke it in Smallstep on an authority with active revocation where the RADIUS server or VPN checks CRL or OCSP; Smallstep RADIUS checks revocation on each authentication. MDM-originated removal reaches Smallstep on the connector's sync schedule, so remove the device in Smallstep directly when timing matters, and wipe or lock it through the MDM.

No. Smallstep hosts the ACME and SCEP endpoints, so devices reach them from any network, including off-site over cellular, and challenges are exchanged through each MDM's mechanism, a webhook for Jamf and Intune's own SCEP token exchange. Nothing needs to reach into your network.

Not today. Mobile enrollment is MDM-driven by design: Apple does not allow apps to perform device attestation, and MDM payloads already cover Wi-Fi, VPN, and Safari. Mobile app support for other use cases is under development; ask us about current status for your case.

Yes. One inventory, one set of authorities, and one policy model apply across macOS, Windows, Linux, ChromeOS, iOS, iPadOS, and Android; what differs per platform is the enrollment method and the assurance it provides. RADIUS and VPN services validate the certificates and enforce their configured access policies. Where access must depend on assurance level, use distinct issuing authorities or trustworthy certificate attributes that identify the enrollment method and its verified assurance.

The posture certificate is what Client Connector evaluates; ZPA does not use it to authenticate the application session, which continues through your identity provider and ZPA policy. If you also use Smallstep certificates for browser mTLS to an application, that is a separate credential profile with its own store and issuer. Decide which path each resource uses and configure the profile for it.

Smallstep can extend device identity beyond Zscaler to supported Wi-Fi, VPN, SSO, SSH, and internal application integrations. Each needs its own credential configuration and enforcement on the resource side; for example, Smallstep can act as an additional device identity factor in supported Okta or Entra sign-in flows.

Smallstep can extend device identity beyond Cloudflare to supported Wi-Fi, VPN, SSO, SSH, and internal application integrations. Each needs its own credential configuration and enforcement on the resource side; for example, Smallstep can act as an additional device identity factor in supported Okta or Entra sign-in flows.