Enforce SaaS access with device identity

Most SaaS access is governed solely by user identity through SSO, which leaves a critical blind spot: the device itself is rarely verified in a meaningful way. That gap allows attackers to steal browser cookies or SAML and OIDC tokens, replay OAuth access tokens from unmanaged machines, hijack sessions on compromised devices, use personal laptops to access corporate SaaS, or bypass conditional access with spoofed posture data.

Smallstep closes this gap by making hardware-attested device identity a required part of SaaS authentication. A login succeeds only when the user is authenticated by the IdP, the device cryptographically proves its identity to Smallstep, and policy explicitly allows that user–device pair. This prevents token theft, replay, and device impersonation from translating into SaaS access.

Smallstep inserts cryptographic device verification directly into the SSO login flow without changing how SaaS applications authenticate users. When a user accesses a SaaS app, the request is redirected to the IdP, and the browser presents a hardware-backed mTLS certificate issued by Smallstep. The IdP validates that certificate with Smallstep before issuing any token.

Only if the device is attested, compliant, and authorized does the IdP complete authentication. The result is that stolen credentials or tokens are useless on any other device—they are cryptographically bound to the original, trusted hardware.

No. Smallstep is not an IdP, and it doesn’t replace one. Your existing IdP continues to authenticate users and manage credentials, groups, and lifecycle.

Smallstep’s role is to authenticate devices and provide cryptographic proof of their identity. Policies then combine user and device identity to authorize each session. The existing IAM architecture and user workflows remain intact, but the security of authentication is materially upgraded.

Token theft is one of the most common and damaging attack vectors in modern environments. Smallstep neutralizes it by requiring a hardware-bound certificate as part of the login process.

A stolen token cannot be replayed from another device because the attacker does not possess the device’s TPM or Secure Enclave private key, and renewal always requires fresh attestation. Even if an attacker exfiltrates all browser session data, they still cannot reproduce the required mTLS handshake needed to authenticate.

Certificates are issued through ACME Device Attestation, which anchors identity directly in hardware. The device generates a non-exportable private key, the TPM or Secure Enclave signs an attestation statement, and Smallstep verifies the hardware identity before checking inventory and posture.

Only then is a short-lived client certificate issued and installed automatically in the operating system or browser. Renewal always requires repeating hardware attestation, ensuring trust is continuously re-established rather than assumed.

Any application federated through your IdP can enforce device trust once Smallstep is in the login path. This includes platforms like Google Workspace, Microsoft 365 and the Azure Portal, the AWS and GCP consoles, GitHub and GitLab, Salesforce and NetSuite, Slack, Atlassian, Notion, and internal administrative consoles.

Applications that support browser mTLS directly can enforce even stronger controls, but the majority of SaaS applications gain effective device trust enforcement automatically through the IdP integration.

Smallstep automates certificate provisioning across all major platforms so device trust works transparently for users. On macOS and iOS, certificates are stored in the system keychain, automatically used by Safari, Chrome, and Firefox, and delivered through MDM or the Smallstep agent. On Windows, certificates are installed in the Windows Certificate Store and are automatically honored by Chrome, Edge, and Office applications.

On Linux, certificates are exposed through a PKCS#11 interface so Chrome and Firefox can use them, remaining hardware-bound when a TPM is available. Across platforms, no user interaction or manual certificate selection is required—device identity is applied automatically and consistently.

Smallstep policies can enforce precise device trust requirements instead of treating all endpoints the same. Access can be limited to hardware-attested devices, managed devices present in inventory, systems that meet MDM or EDR posture requirements, or specific device groups and roles, with stricter rules applied to high-risk applications like cloud consoles or administrative portals.

This enables clear, enforceable policies such as allowing only attested devices to access admin consoles, permitting contractors to use GitHub but not CRM or finance systems, or requiring managed devices for production access. Sensitive SaaS applications remain accessible only from devices that are explicitly trusted.

Smallstep policies can enforce precise device trust requirements instead of treating all endpoints the same. Access can be limited to hardware-attested devices, managed devices present in inventory, systems that meet MDM or EDR posture requirements, or specific device groups and roles, with stricter rules applied to high-risk applications like cloud consoles or administrative portals.

This enables clear, enforceable policies such as allowing only attested devices to access admin consoles, permitting contractors to use GitHub but not CRM or finance systems, or requiring managed devices for production access. Sensitive SaaS applications remain accessible only from devices that are explicitly trusted.

Yes. Smallstep supports tiered assurance models instead of forcing a single trust level across all access. High-assurance access is reserved for corporate-owned, hardware-attested devices and is required for production systems, administrative tools, and sensitive SaaS applications.

Medium assurance can be applied to certificate-authenticated but non-attested devices such as those used by contractors or partners, while low assurance relies on standard SSO-only access for applications that do not require device trust. Policies enforce clear separation between device types and access levels without complicating user workflows.

No. Smallstep does not replace CASB or SWG—it complements them. CASB and SWG control traffic and user behavior after authentication has already occurred.

Smallstep determines whether authentication is allowed in the first place by enforcing hardware-rooted device identity, mTLS-bound logins, and continuous certificate renewal. This means CASB and SWG only operate on traffic from verified users on verified devices, making their controls more effective.

Smallstep is built for hyperscale environments where identity systems must handle high volume without introducing latency. Its architecture includes distributed, horizontally scalable ACME authorities, global mTLS endpoints, HSM-backed certificate authorities for high-throughput signing, and stateless device attestation services.

Certificate issuance is optimized for short-lived credentials, keeping operations efficient at scale. Login overhead remains minimal, with mTLS adding less than 200 milliseconds to typical SSO authentication flows.

Yes. With Step CA Pro and Run Anywhere, organizations can operate Smallstep entirely under their own control, including on-prem or sovereign CA hierarchies, local attestation services, private mTLS endpoints, customer-managed HSMs, and even fully air-gapped deployments when required.

This deployment model is common in highly regulated sectors such as finance, healthcare, defense contracting, government agencies, and critical infrastructure, where external control planes are not acceptable.