Register for part 2 of our Device Identity Webinar Series!

SecureW2 onboards the fleet. Smallstep extends hardware-attested identity across it.

SecureW2 JoinNow handles certificate‑based onboarding across managed, unmanaged, and BYOD devices. But hardware provenance is not established the same way on every platform. Smallstep adds a consistent device‑identity layer built around hardware attestation, trusted inventory, and hardware‑bound credentials.

Book a demo
background gradientbackground texture
Hardware provenance at enrollment
Non-exportable, hardware-bound keys
Authorization against a trusted device record
Attested at issuance, proven at access
Enrollment over ACME device-attest-01
Evidence from hardware to access

Onboarding coverage and device trust are different questions.

Both platforms issue certificates for 802.1X, and both describe ACME device attestation. Before comparing them, establish which problem the project is actually solving: getting every device configured, or proving what a device is before it connects.

  • "Can users configure their own devices without IT touching each one?" is an onboarding question
  • "Can this endpoint prove itself before Wi‑Fi or VPN?" is a trust question
  • Collapsing the two produces the wrong shortlist

Hardware attestation, not enrollment-secret possession

Smallstep checks inventory and attestation evidence before issuance, then completes ACME device-attest-01 with a key generated in the TPM or Secure Enclave. The evidence is checked before the certificate exists.

SCEP works the other way: a challenge, static or dynamic, authorizes the request. SecureW2’s Dynamic SCEP narrows the window for a stolen secret, but neither form proves where the private key was generated.

Attestation is a fleet property, not a feature checkbox

Both vendors document hardware attestation, so a feature matrix records “supported” for both. The narrower question: how is hardware evidence established on each platform, and does issuance resolve against one device record?

  • SecureW2 documents real hardware proof on Apple, Linux, and ChromeOS, each through a different mechanism

  • Its documented Windows path is SCEP, WSTEP, or SAML, with the key stored in the TPM where present. Storage is a client setting, not evidence the CA verifies, and in most corporate fleets Windows is the largest population

  • Smallstep runs its agent on Windows and Linux, Verified Access on ChromeOS, and Apple Managed Device Attestation, all against a single trusted inventory

Smallstep authorizes issuance. The enforcement point checks the credential.

Authorization is tied to trusted inventory, built from MDM synchronization, the API, or self-registration that is approval-gated by default. Credentials are short-lived, revocation is administrative or API-driven, and Smallstep offers hosted EAP-TLS RADIUS that trusts the Smallstep CA directly, so a separate RADIUS deployment is optional rather than required.

At access, RADIUS validates the certificate chain and revocation status, while the device proves possession of its non‑exportable key during the EAP‑TLS handshake. Enterprise RADIUS can also call your own webhook on every authentication to add a posture check. SecureW2 ships a pre-built CrowdStrike integration; Smallstep provides the hook.

When an onboarding platform is the right starting point

A mixed fleet can hold two trust problems at once. Thousands of unmanaged and BYOD devices that nobody can configure one at a time are an onboarding problem first, and JoinNow MultiOS self-service is built for exactly that. Smallstep’s self-registration is approval-gated by default, not equivalent breadth.

  • Large unmanaged, multi-OS populations: begin with onboarding and network authentication
  • Hardware proof before sensitive resources, with Windows or Linux in scope: begin with device identity
  • Run both when the fleet requires both

Keep SecureW2 for onboarding. Add a consistent hardware-attested identity layer across the fleet.

One attestation model, authorization against a single trusted device record, and an evidence trail from device hardware to the decision that permitted access. Predictable, device-based pricing.

Book a demo

FAQs Smallstep for SecureW2 Environments

For a managed fleet, yes. Where corporate Windows, macOS, Linux, and ChromeOS devices live in Jamf, Intune, Workspace ONE, or Fleet, Smallstep issues the Wi-Fi, VPN, and application certificates, runs the RADIUS, and replaces the SecureW2 subscription.

Where the requirement is broad self-service onboarding of unmanaged phones and tablets, SecureW2’s MultiOS breadth is the right starting point, and the two run side by side. SecureW2 optimizes for configuring managed and unmanaged devices with minimal IT involvement; Smallstep optimizes for establishing hardware-proven identity before a device reaches a protected resource.

SecureW2 owns getting large device populations enrolled and authenticating against the network, including BYOD, guests, and contractors. Smallstep owns proving what a device is before a certificate is issued, and tying that proof to a trusted device record that gates issuance, renewal, and revocation.

Consistency of assurance. SecureW2 establishes hardware evidence through different mechanisms on different platforms: Managed Device Attestation over ACME for managed Apple devices, TPM key attestation for Linux, Google Verified Access for ChromeOS, and SCEP, WSTEP, or SAML on the documented Windows path. Smallstep attests Windows and Linux through its agent, ChromeOS through Verified Access, and Apple devices through Managed Device Attestation, with every issuance resolving against a single trusted inventory and one policy. The question is not whether attestation exists, but whether assurance is established the same way across the whole fleet, Windows included.

Yes, on several platforms. SecureW2’s ACME FAQ describes its Managed Gateway API as leveraging ACME for managed Apple devices only, performing Managed Device Attestation against Apple’s attestation servers. Separately, SecureW2 documents TPM key attestation for Linux enrollment and a ChromeOS provisioning connector that uses Google Verified Access to confirm an enterprise-enrolled Chromebook with an intact TPM. On Windows it documents TPM key storage, through WSTEP or through SCEP set to use the TPM key storage provider where present and software otherwise. Storage is a client-side setting; the CA does not receive or verify attestation evidence for it. That is the distinction to test on a Windows demo.

SecureW2 documents Windows issuance using SCEP, WSTEP, or SAML in the non-Apple enrollment path, with keys stored in the TPM where the client is configured for it. TPM-backed is not TPM-attested. Windows has no native ACME device attestation, so the Smallstep Agent supplies the attestation evidence from the TPM; dynamic SCEP remains available where the agent cannot run. The agent requires TPM 2.0 and administrator privileges on Windows.

That the key was generated in the device's secure element and verified against trusted inventory built from TPM endorsement keys or Apple hardware identifiers. The agent creates an attestation key in the TPM, obtains an attestation certificate after the endorsement key is verified against inventory, then completes ACME device-attest-01 for a device certificate. Prerequisites apply on every platform: Supervised mode for Apple Managed Device Attestation, TPM 2.0 and administrator privileges for the agent on Windows.

A certificate proves the holder possesses the private key. It doesn't say where that key lives, whether the device is one you own and approved, or whether it is still trusted today. Closing that gap is what attestation plus an inventory-backed device record does.

SCEP can establish possession of the key associated with a certificate request. Traditional SCEP enrollment is authorized by a static challenge, and SecureW2's own writing describes SCEP without attestation as a security gap. SecureW2's Dynamic SCEP replaces the fleet-wide secret with unique, time-bounded challenges, which narrows the window for a stolen secret. Neither form establishes that the private key was generated in a TPM or Secure Enclave and cannot be exported, because the challenge authorizes the request rather than proving the hardware behind it.

Smallstep documents user self-registration through the agent, optionally with SSO. By default an administrator approves each device before it can access resources; that can be changed in team settings. This is not equivalent to SecureW2’s broader MultiOS self-service coverage across iOS, Windows, macOS, Android, ChromeOS, and Linux. Where BYOD breadth leads, start on the onboarding side.

The attested paths on this page cover desktop and managed platforms: Windows, Linux, and ChromeOS through the agent, plus Apple Managed Device Attestation for supervised devices. A large personal-device population on phones and tablets, a student body or a contractor pool, is an onboarding problem first, and it is the population SecureW2's MultiOS self-service is built for, with documented flows across iOS, Windows, macOS, Android, ChromeOS, and Linux. Sequence by population: onboarding for personal mobile devices, attestation-gated identity where managed endpoints must prove hardware before sensitive access.

SecureW2 documents CrowdStrike enforcement at issuance, monitoring every ten minutes, and webhook-triggered suspension or revocation. That integration ships pre-built.

Smallstep enforces at two points. Lifecycle: short-lived credentials, renewal gated on continued inventory membership, and administrative or API-driven revocation. Connection: Enterprise RADIUS can call your webhook on every EAP-TLS authentication, so a signal such as an EDR risk score or Intune compliance state can deny access at the connection itself rather than on a polling interval. Smallstep provides the hook; your team connects the EDR. Evaluate the enforcement interval against the resource being protected.

Smallstep offers hosted EAP-TLS RADIUS in Managed and Enterprise tiers. It trusts the Smallstep CA directly and supports major access point vendors, so a separate RADIUS deployment is optional rather than required. Setup is in the Protect Wireless Networks guide. Where a Cloud RADIUS estate is already the project center, evaluate the RADIUS and policy layer on its own terms; the two can coexist while populations are sequenced.

Smallstep documents access point configuration for Ubiquiti UniFi, Aruba, Cisco WLC, Meraki, Juniper Mist, MikroTik, and other popular hardware, and its managed RADIUS validates the full certificate chain and checks revocation on every authentication. You can also bring your own enforcement point: Smallstep-issued certificates work with a RADIUS server you operate, including FreeRADIUS, Cisco ISE, Aruba ClearPass, and NPS, once the Smallstep authority root is added to its trusted client CA bundle. That same option keeps the enforcement layer on infrastructure you run yourself; deployments that must sit fully on premises are scoped with the Smallstep team.

Application support for hardware-bound keys varies by platform and workload, so evaluate the protection level for the specific platform and use case with either vendor. The attested enrollment decision still holds independently: it determines what the CA verified before the credential existed.

Removing the device from trusted inventory halts renewal, short-lived credentials age out on their own, and administrative or API revocation closes the window sooner. Because issuance decisions are recorded against the device record, the organization can reconstruct what was issued and why for a device under investigation.

When the primary requirement is configuring a large unmanaged, multi-OS population for certificate-based network access, or when high-volume guest and contractor access is the problem in front of you. Begin with onboarding and network authentication, then add attestation-gated device identity where managed endpoints must establish hardware proof before access.

No. Certificate-based Wi-Fi is where most Smallstep deployments start, and the platform ships what that needs: a managed CA, hosted EAP-TLS RADIUS that validates the chain and checks revocation on every authentication, and MDM or agent enrollment on Windows, macOS, Linux, and ChromeOS. The question is what the Wi-Fi certificate should prove. If it only needs to prove enrollment-policy compliance, several products qualify. If it needs to prove a hardware-bound key on a device in your inventory, on Windows as well as Apple, that is the Smallstep scope, and the same credential then covers VPN, mTLS, and SSO without a second enrollment.

The Smallstep Agent runs on Windows 10 or later with TPM 2.0, macOS 13 or later on Apple Silicon, and enterprise Linux distributions with TPM 2.0. ChromeOS is covered through Google Workspace and Verified Access rather than the agent. Trusted inventory can be built from MDM synchronization, including Jamf Pro, Intune, and Workspace ONE UEM, from the API, or from user self-registration that is approval-gated by default. The core concepts guide explains how inventory and authorities fit together, and the device identity assessment shows where your fleet stands.