Teleport secures infrastructure access. Smallstep extends device trust beyond it.

For SSH to Linux hosts with SSO-issued or hardware-bound certificates, yes: Smallstep SSH covers user and host certificates, IdP-synced access control, and audit events on native OpenSSH. Where the requirement is session recording, brokered Kubernetes, database, or desktop access, or reaching hosts only a proxy can see, Teleport's architecture is the right starting point and the two run side by side. Teleport optimizes for one control plane over many protocols; Smallstep optimizes for a device identity that resources outside any proxy can verify. The buying trigger for a Teleport customer is usually the first Wi-Fi, VPN, or IdP project that needs device proof Teleport cannot supply.

Yes. Teleport Device Trust, an Enterprise feature, enrolls devices into Teleport's inventory, uses the Secure Enclave on macOS and a TPM on Windows and Linux, syncs with Jamf and Intune (Teleport docs), and enforces per role or cluster-wide on Teleport-managed resources through Teleport's authentication and authorization architecture. The difference is scope: that trust applies to the resources Teleport manages. Smallstep issues resource-specific credentials from one trusted device inventory. SSH servers, RADIUS, compatible VPN gateways, and GitHub validate supported credentials directly; an IdP can require device certificate authentication at sign-in before issuing tokens for downstream applications. That covers the resources no proxy fronts. Running both products means two enrollments today; Smallstep does not remove Teleport's.

Yes. Keep Teleport as the access plane and enroll the same laptops with Smallstep for the resources outside it: EAP-TLS Wi-Fi, certificate-based VPN, device-gated SSO, and hardware-bound GitHub access. Fronting Teleport itself with Smallstep's enterprise relay is a possible architecture rather than a documented integration; ask us before planning on it.

Teleport's standard architecture is proxy-mediated: sessions pass through its proxy, which is what makes recording and multi-protocol access possible, and what makes the proxy a dependency; Teleport also documents a direct-connect mode for self-hosted clusters and can front existing OpenSSH servers. Smallstep SSH has no session proxy: the client gets a short-lived certificate, sshd validates it against the user CA, PAM and NSS modules enforce an ACL synced from your IdP, and if the Smallstep service is unavailable, hosts keep using their last-synchronized authorization data while existing certificates remain valid; new issuance and authorization changes wait until sync resumes. One is a control point in the path; the other is a credential and a policy on the host.

On the SSO path, the user signs into the IdP once, receives a 16-hour SSH certificate, and it lives in ssh-agent, never on disk. On the device identity path, the Smallstep agent issues the SSH certificate to a key generated in the TPM or Secure Enclave and exposes it through an SSH agent socket; the private key never leaves the hardware. Assurance follows the platform: Windows and Linux keys are device-attested; on macOS, Smallstep attestation proves possession of the private key but does not independently verify that the key resides in a genuine Apple Secure Enclave.

No. A PAM module logs session start, sudo use, and session end, and those events appear in the Smallstep console. If regulators require recordings, that is a reason to keep Teleport in front of those hosts.

Hosts: Linux with OpenSSH, registered by a script that can run from existing automation. Clients: macOS, Linux, and Windows with the step CLI or the Smallstep agent. Access control syncs from Okta, Entra ID, or Google Workspace. Enforcing GitHub SSH certificate authentication through an organization-level CA requires GitHub Enterprise Cloud (setup guide); hardware-backed SSH commit signing is a separate capability. Network appliances that do not accept a user CA, and non-SSH protocols, are outside scope.

IoT fleets and lab devices that are not network-addressable are a proxy problem, and Teleport's reverse tunnel handles them well. Smallstep's enterprise relay can front an endpoint with hardware-attested mTLS, but native OpenSSH needs a network path to the host, and the relay is not a replacement for a reverse-tunnel access plane across an unroutable fleet.

Yes. Smallstep SSH Run Anywhere installs in Kubernetes and integrates with your HSM for CA keys, for regulated environments that cannot use the hosted CA.

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.