IAM workflows with device identity

Traditional IAM platforms like Okta, Entra, Google Workspace, and LDAP are built to manage users. They largely assume the device is trustworthy and rely on shared secrets or long-lived credentials for workloads, which leaves a major gap in modern environments.

Smallstep extends IAM to devices and workloads, forming a true multi-entity identity model. User identity is validated by the IdP, device identity is proven through hardware attestation using TPM, Secure Enclave, or Verified Access, workload identity is verified via cloud instance identity or orchestrator metadata, and network and application access is enforced through mTLS, SSH, or EAP-TLS. Devices and workloads become first-class actors with cryptographically proven identity, not just attributes attached to a user policy.

Even the strongest user authentication—passkeys, passwordless flows, MFA—can still be bypassed once a device is compromised. Attackers don’t break identity; they steal or replay it.

Smallstep closes this gap by requiring unforgeable, hardware-backed proof of device authenticity alongside user identity. A valid login must present both the correct user and a trusted, attested device with a hardware-bound private key. This blocks token and session replay, browser injection, OAuth phishing, MDM or EDR spoofing, and access from stolen VPN or Wi-Fi profiles, eliminating credential reuse and unmanaged device access.

Smallstep binds identity across multiple layers instead of treating them in isolation. User identity is validated through the IdP, device identity is proven via ACME Device Attestation, and workload identity is established using cloud-native tokens like AWS IID, GCP IIT, Azure MSI, or vTPM attestation.

These identities are combined into a single security context that is enforced consistently across Wi-Fi, VPN, SSH, internal APIs, ZTNA tunnels, and SaaS applications via the IdP. No single identity type—user, device, or workload—is ever trusted on its own.

Traditional IAM operates on an “authenticate once, trust forever” assumption that collapses in dynamic, automated environments. Static trust creates long windows of exposure.

Smallstep replaces that model with continuous authentication through short-lived credentials measured in minutes or hours, periodic device re-attestation, hardware-bound private keys, renewal gated on posture and inventory, and immediate revocation on compromise. Every certificate issuance becomes a checkpoint to re-evaluate trust in real time.

Smallstep integrates directly with existing IdPs to add cryptographic device trust to SSO without changing how users log in. The user initiates authentication, the device presents a hardware-backed mTLS certificate, the IdP validates device trust through Smallstep, and access is granted only when the user–device pair meets policy.

Beyond the core flow, Smallstep supports SCIM-based user and group sync, conditional access rules driven by device identity, and application-level device trust enforcement. The familiar SSO experience is preserved, but the trust behind it is materially stronger and cryptographically enforced.

Yes—Smallstep extends IAM policy into SaaS by injecting hardware-attested device identity directly into IdP login flows. SaaS access is no longer based on user credentials alone.

This blocks stolen token reuse, session hijacking, access from unmanaged devices, and personal laptops reaching sensitive or administrative SaaS consoles. Any application federated through the IdP—Google Workspace, Salesforce, GitHub, the AWS Console, and others—can require access from trusted, attested devices only.

Modern workloads are issued short-lived mTLS certificates derived from strong, native identity signals rather than shared secrets. Smallstep generates these certificates using cloud instance identity tokens, Kubernetes service account tokens, vTPM-based attestation, and ACME-based issuance.

Each certificate encodes the service identity along with environment context such as production, staging, or development, relevant roles or labels, and optional network constraints. This allows workloads to authenticate to one another across clusters, clouds, and on-prem environments without shared secrets or mesh-specific infrastructure.

Smallstep policies can evaluate identity and trust signals across every relevant dimension. They can reference user identity, hardware-backed device identity, workload or service identity, posture signals from MDM or EDR, certificate metadata, ACME attestation results, and environmental or network constraints.

Those policies are enforced consistently across Wi-Fi and VPN access, SSH, microservices, ZTNA tunnels, SaaS applications, and databases or internal APIs. IAM stops being a static allowlist and becomes a cryptographic authorization engine that evaluates real trust at the moment of access.

Smallstep is built to operate at global scale without sacrificing latency or consistency. Its architecture includes distributed attestation endpoints, HSM-backed CA signing, stateless ACME flows, CDN-backed mTLS endpoints in the SaaS offering, multi-region Run Anywhere clusters, and aggressive certificate-chain caching.

As a result, organizations routinely support tens of thousands to hundreds of thousands of devices, large fleets of workloads, and multi-cluster Kubernetes environments. Authentication remains fast, reliable, and globally consistent even under high-volume identity load.

Smallstep is designed to integrate with existing endpoint and fleet systems rather than replace them. MDM provides inventory and posture signals that Smallstep uses to gate certificate issuance, EDR compliance can be enforced as a renewal requirement, NAC can be replaced or augmented with EAP-TLS based device identity, and VPN access is hardened using IKEv2 and mTLS instead of passwords or pre-shared keys.

What Smallstep adds is the missing layer none of these tools provide on their own: cryptographic, hardware-anchored device identity that can’t be spoofed or bypassed.

Revocation in a Zero Trust model must be automatic and event-driven, not a manual cleanup exercise. Trust should disappear the moment underlying conditions change.

With Smallstep, revocation can occur when a device is removed from inventory, marked non-compliant by MDM or EDR, has its TPM or Secure Enclave reset, when a user is suspended or offboarded, or when a workload is terminated or replaced. Because certificates are short-lived, compromised devices lose access within minutes without log hunting or password resets. For environments that require active revocation, Step CA Pro supports OCSP and CRLs, while renewal gating ensures devices cannot re-establish trust without re-attesting.

Revocation in a Zero Trust model must be automatic and event-driven, not a manual cleanup exercise. Trust should disappear the moment underlying conditions change.

With Smallstep, revocation can occur when a device is removed from inventory, marked non-compliant by MDM or EDR, has its TPM or Secure Enclave reset, when a user is suspended or offboarded, or when a workload is terminated or replaced. Because certificates are short-lived, compromised devices lose access within minutes without log hunting or password resets. For environments that require active revocation, Step CA Pro supports OCSP and CRLs, while renewal gating ensures devices cannot re-establish trust without re-attesting.