Register for part 2 of our Device Identity Webinar Series!

Keep your RADIUS. Upgrade your device identity.

Keep Cisco ISE, Aruba ClearPass, or the RADIUS you already run. Smallstep automates device certificate issuance and lifecycle, with inventory-based enrollment policy and hardware-backed identity where supported. Your RADIUS keeps enforcing access with the certificates Smallstep issues.

Get a demo
background gradientbackground texture
Works with ISE, ClearPass, FreeRADIUS
Issued only to approved inventory
Hardware assurance where supported
Passwordless Wi-Fi with EAP-TLS
Windows, macOS, Linux, ChromeOS
Automated certificate lifecycle

Keep your network policies. Improve certificate issuance.

Cisco ISE and Aruba ClearPass already authenticate and authorize, with guest, profiling, and MAB alongside; FreeRADIUS handles EAP-TLS and policy, with more depending on how it is deployed. All of that stays. What Smallstep adds is governance of where the certificate came from: whether the device was in the inventory you approve and whether its key was generated in hardware.

  • Your RADIUS validates the certificate it is shown. Smallstep governs which devices get one.
  • Access points are not the decision; they forward EAP-TLS to the RADIUS you configure.

Access point and RADIUS setup

Go beyond CA trust with policy that keys on the certificate

Configure your RADIUS to trust the Smallstep CA, recognize the certificate identity, and apply policy; clients must also trust your RADIUS server certificate. Smallstep can write MDM metadata into certificate fields at issuance, so ISE or ClearPass can map an OU or SAN to a VLAN. Policies that key on user identity, AD groups, or posture need review before migration.

Using Smallstep certificates with Microsoft NPS

Moving from PEAP to EAP-TLS changes how identity is proven: the client proves possession of the key behind a trusted certificate instead of a password. RADIUS then authorizes on certificate attributes, directory data, or other conditions.

  • NPS with AD strong mapping expects an embedded SID or an explicit mapping; check your Smallstep certificate profile against that requirement before rollout.
  • Where the SID is unavailable: explicit altSecurityIdentities mappings, proxy EAP-TLS to Smallstep RADIUS, or migrate the SSID.

Smallstep RADIUS, with EAP-TLS as the only method

Managed RADIUS validates the chain and checks revocation on every authentication, and does nothing else: no MAB, PEAP, accounting, or CoA. Enterprise adds static IPs by region, RadSec, reply attributes for dynamic VLAN, and a webhook that consults your authorization system. Keep the NAC for MAB and guest, and configure fallback so a device that fails EAP-TLS cannot get equivalent access through MAB.

Smallstep manages issuance. Your RADIUS controls network access.

Smallstep authorizes enrollment from your inventory and issues the certificate. At connection time your RADIUS does the checking; Smallstep is not in the path.

Your RADIUS owns authentication and authorization. Smallstep owns which devices get a credential and how its key is protected.

Example: ISE trusts the Smallstep CA and keys policy on certificate attributes; Intune-managed laptops enroll through the agent.

How device identity and key protection work

Key benefits for ISE, ClearPass, and RADIUS customers

Credentials only for approved hardware

Smallstep checks inventory and enrollment policy before issuing. Devices outside your policy cannot obtain those credentials; your RADIUS then enforces access with its configured trust and authorization rules.

Hardware attestation where it exists

Smallstep uses TPM attestation, ChromeOS Verified Access, and Apple Managed Device Attestation where supported. Key protection and attestation assurance depend on the OS, enrollment method, and credential configuration.

No NAC replacement required

Trust the CA, map the identity, keep your policies. Guest, MAB, accounting, profiling, and CoA stay where they are.

Nothing for users to carry

Enrollment, issuance, and renewal happen through the agent or MDM. Users connect with a managed certificate instead of entering a Wi-Fi password.

Smallstep RADIUS when you want it

For networks that need only EAP-TLS and the controls it supports, Managed or Enterprise RADIUS removes the self-hosted server. An option, not a prerequisite.

Lifecycle that follows inventory

Short lifetimes, automatic renewal, and issuance that stops when a device leaves inventory. Revocation at authentication where your RADIUS checks it.

Put issuance assurance behind the RADIUS you already trust.

Your NAC keeps authenticating and authorizing. Smallstep governs which devices receive a certificate and how its key is protected. Add Smallstep RADIUS where it fits, or never.

Book a demo

FAQs Smallstep for ISE, ClearPass, and RADIUS

No. Smallstep-issued certificates work with EAP-TLS-capable RADIUS servers including ClearPass, ISE, FreeRADIUS, and Mist Access Assurance. Configure the server to trust the issuing CA, recognize the certificate identity, and apply your authorization policy; clients also need to trust your RADIUS server certificate. If you have no RADIUS, Managed RADIUS is included with Wi-Fi.

Upload the Smallstep root and intermediate as trusted CAs, define how the certificate identity is recognized, and write or adapt authorization rules. Smallstep can place MDM metadata in certificate fields (OU, SAN, custom extension) so policy and VLAN assignment can key on them. No agent or extension runs on the NAC. MAC-auth and guest services can stay as they are; certificate-based services may need trust and policy updates to recognize Smallstep-issued certificates.

Certificate-based policies may need limited changes. Policies that depend on user identity, AD groups, posture, or profiling need review, because a certificate identifies a device, a user, or both depending on its profile and not every attribute has a certificate equivalent. Map them before migration, not after.

Microsoft's strong-mapping enforcement expects either an embedded SID extension or an explicit altSecurityIdentities mapping on the AD object (issuer and serial, or public key). Check the Smallstep certificate profile you intend to use against that requirement; where the SID extension is unavailable, the working paths are explicit mappings maintained as certificates rotate, proxying EAP-TLS from NPS to Smallstep RADIUS via a connection request policy and remote RADIUS server group, or moving the affected SSID to Smallstep RADIUS. NPS as a proxy is a different authorization model from NPS authenticating against AD; validate your certificate profile against your mapping requirements first.

Three controls, and you should plan all three. Certificate revocation, which Smallstep RADIUS checks at every authentication and your own RADIUS checks if configured. Inventory status, which stops issuance and renewal when a device is removed. And an external authorization decision at connection time, through Enterprise RADIUS webhooks or your NAC. Disabling a user's AD account does not by itself invalidate a device certificate.

MAC Authentication Bypass, PEAP or any password method, RADIUS accounting, and Change of Authorization. It validates the full chain and checks revocation on every EAP-TLS authentication and nothing else. Devices and functions that need those stay on your NAC.

Dedicated infrastructure with static IPs in the cloud regions you choose, so NAS IPs no longer need registering; RadSec with a dedicated hostname; reply attributes including dynamic VLAN, sourced from a certificate field or the device inventory; and an authorization webhook that lets Enterprise RADIUS consult your existing posture or authorization system during authentication. A non-200 or a response past ten seconds denies the request. It is an external check at authentication, not continuous posture, profiling, accounting, or CoA.

Yes. Route EAP-TLS to Smallstep RADIUS with a dedicated SSID, a wired network configuration, or a RADIUS proxy policy on the NAC; everything else keeps hitting the NAC. Configure fallback so a managed device that fails certificate authentication cannot gain equivalent access through MAB; they are not equivalent identity evidence.

When the NAC's required functions are covered or retired, not when every device has a certificate. If guest access, MAB, accounting, CoA, profiling, or session-level enforcement is still required, retain the NAC for those functions.

Remove the device from inventory, by removing it from the MDM or in Smallstep, and issuance and renewal stop; the certificate runs to its short expiry unless active revocation is configured and the RADIUS checks it. Disabling a user in your IdP can prevent user-initiated enrollment where that identity is required; it does not affect existing devices. Separately remove device authorization, disable the enrollment profile, and revoke outstanding certificates when immediate invalidation is required. None of this ends an already-established session; that is your NAC's CoA or session timeout.

Same model. Switches register the RADIUS as a AAA server and enable port authentication. Non-certificate ports need a deliberate, restricted policy, such as a guest or unauthenticated VLAN with limited reach, not a default destination. Enterprise RADIUS assigns VLANs dynamically by reply attribute.

Existing NAC or RADIUS: EAP-TLS after trust, identity, and policy setup; MAB, guest, PEAP, accounting, CoA, and directory mapping as the product supports them; revocation checking if configured. Smallstep RADIUS: EAP-TLS with revocation checked every time, dynamic VLAN and external authorization on the Enterprise tier, no self-hosted server to operate, and none of MAB, guest, PEAP, accounting, or CoA.

Smallstep can extend device identity beyond Wi-Fi to supported 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 SSO flows. Wi-Fi is the usual first project.

Cloud PKI issues certificates to Intune-enrolled devices over SCEP as a separately licensed Intune add-on. It does not reach Linux or anything outside Intune, and SCEP enrollment carries no hardware attestation. Smallstep issues to the whole fleet from one inventory with attestation where the platform supports it, and Entra CBA trusts whichever CA you upload. See the Microsoft AD CS page for the fuller comparison.

Yes. The same device identity issues EAP-TLS Wi-Fi certificates, certificate-based VPN credentials, and mTLS client certificates for internal services, and Entra ID users can get SSH certificates for TPM or Secure Enclave keys through the Smallstep Agent. One inventory, one CA, many enforcement points.