Register for part 2 of our Device Identity Webinar Series!

1Password checks registered devices. Smallstep attests the hardware.

1Password Device Trust, formerly Kolide, verifies a registered device key and its health at sign-in. Smallstep verifies hardware attestation against your inventory on supported paths, then issues credentials for Wi-Fi, VPN, SSH, and application access; what each integration verifies at access is its own.

Get a demo
background gradientbackground texture

Trusted by

Hardware provenance at enrollment on supported paths
Non-exportable keys where the platform supports them
Certificates for Wi-Fi, VPN, SSH, and services
Authorization against a trusted device record
Attested device record your IdP and network can rely on
Keeps 1Password where its checks earn their place

A registered device with posture checks, or attested hardware with a certificate?

1Password Device Trust, formerly Kolide, registers a device key, verifies possession at sign-in, runs osquery health checks, and tells the user how to fix what fails. Smallstep asks a narrower question on supported paths: is this the hardware in your approved inventory, proven by TPM or Secure Enclave attestation, then issues a certificate bound to it.

  • "Is the disk encrypted and the OS patched?" is a posture question
  • "Is this key in the TPM we enrolled and matched to inventory?" is an attestation question
  • Both questions need an answer on the same fleet

Trust on first use versus proof before issuance

1Password registers a device with a long-term key the agent generates and, by default, trusts the first device a user registers through successful SSO; later devices need administrator approval or a sign-in from a trusted device, and eligibility rules can tighten this. Whether the key is hardware-protected is not documented. On supported high-assurance paths, Smallstep verifies TPM or Secure Enclave attestation against an approved inventory record before issuing the attested device credential; a provisional certificate or bootstrap token can precede it, and downstream credentials vary in key protection by OS, client, and use.

Enforcement through integrations versus credentials every service verifies

1Password Device Trust enforces at SSO as a possession-factor authenticator for Okta or Entra ID and a SAML provider for Google Workspace apps, at non-SSO web apps through its browser extension with 1Password Business, and through integrations such as Tailscale and Twingate that consume its device status. Smallstep verifies attestation at enrollment, then issues credentials that RADIUS, VPN, ZTNA, SSH hosts, services, and the identity provider each verify in their own way; key protection varies by OS, client, and use. Integrations consuming a status, or credentials each verifier checks.

Neither layer replaces the other

Smallstep has no health checks of its own and does not tell users how to fix a disk encryption setting. 1Password Device Trust has no certificate authority and does not document hardware attestation for its device key. On a fleet that runs both, each protects its own access paths: posture at SSO and web apps, attested credentials at Wi-Fi, VPN, SSH, and services. There is no shipped integration between the two and no single policy that requires both signals; ask about posture-driven issuance before designing around it.

When a posture platform is the right starting point

If the problem is unmanaged or BYO laptops reaching SaaS, contractors who cannot be enrolled in MDM, or users who need to fix their own machines without a ticket, start with posture at sign-in. If the problem is certificate Wi-Fi, VPN, SSH, mTLS, or an identity provider that must know which hardware is connecting, start with device identity. Okta Device Trust vs device identity

  • Health checks and self-remediation across SaaS: begin with posture
  • Hardware-bound credentials for network, infrastructure, and SSO: begin with device identity
  • Run both when the fleet needs both

What Smallstep adds to a 1Password Device Trust fleet

Hardware provenance, not first-use trust

On supported enrollment paths the device proves through TPM or Secure Enclave attestation that it is the hardware in your approved inventory before the attested credential is issued.

Keys that stay in the silicon

Device keys generated in the secure element where the platform supports it, with per-platform protection documented rather than left unstated.

Beyond the browser

Credentials for Wi-Fi over EAP-TLS, VPN and ZTNA, SSH, and mutual TLS to services, verified by each service itself, where a browser-enforced check does not reach.

Inventory as the source of truth

Issuance authorized against a trusted device record synced from your MDM or registered by API, so removing a device from inventory stops issuance and renewal.

A device factor your IdP can call

An external device factor in Okta, verified over mutual TLS against the inventory, and certificate-based authentication in Entra ID with issuance-time device assurance.

Runs alongside your posture tool

Smallstep adds attested hardware identity and certificates; 1Password Device Trust keeps health checks and self-remediation at sign-in. Different access paths, one fleet.

Keep 1Password where registered devices and health checks earn their place. Add hardware-attested enrollment and certificate-based access.

Hardware-attested enrollment against your inventory, non-exportable keys where the platform supports them, and one device identity behind the Wi-Fi, VPN, SSH, service, and SSO credentials each resource verifies on its own.

Book a demo

FAQs Smallstep for 1Password Device Trust environments

No. 1Password Device Trust verifies a registered device key, checks device health, and lets users fix failures before signing in to SSO and web apps, and integrations such as Tailscale and Twingate can consume its device status. Smallstep attests the hardware on supported paths and issues certificates that Wi-Fi, VPN, SSH, services, and the identity provider verify. An organization can run both; where they meet, each adds a different condition.

1Password acquired Kolide in 2024 and sells the product as 1Password Device Trust, in Core and Connect tiers. Core enforces device checks on web apps through the 1Password browser extension; Connect adds the identity provider integration, acting as a possession-factor authenticator for Okta or Entra ID and as a SAML provider for Google Workspace managed apps. The agent runs on macOS, Windows, and Linux, with a mobile app for iOS and Android, and uses osquery for its checks.

Cryptographically. At registration the agent generates a long-term key pair and the service stores the public half against the user's identity synced from the IdP. At sign-in the service issues a short-lived signed challenge, the agent signs a sealed response with that key, and the service looks up the device and evaluates posture. 1Password describes this as a NIST single-factor cryptographic device verifier and says the key material never leaves the device; its public documentation does not establish TPM or Secure Enclave attestation for that key. By default the first device a user registers through successful SSO is trusted; later devices need administrator approval or a sign-in from a trusted device, and registration eligibility rules can restrict who may register.

Hardware provenance, on supported high-assurance enrollment paths. The device's key is generated in the TPM or Secure Enclave and the device proves through attestation that it is a device already in your approved inventory before the attested device credential is issued; a provisional SCEP certificate or bootstrap token may precede that step. A posture agent proves possession of a registered key and reports what it observes about the operating system; it does not establish which physical machine it runs on. Key protection for downstream application credentials varies by OS, client, and use case and is documented per platform.

No. Smallstep has no built-in disk encryption, OS version, or screen lock checks and no self-remediation flow. Posture-driven issuance or revocation is a design question to raise with Smallstep for your posture tool; this page does not describe a shipped mechanism.

Not shipped. Prospects have asked for one. Ask for the current status before planning on it.

1Password Device Trust: SSO-protected apps through Okta, Entra ID, or Google Workspace; non-SSO web apps through the 1Password browser extension, enforced in the browser rather than at the app, with 1Password Business; and network tools that consume its device status, such as Tailscale access rules and Twingate resource policies. Smallstep: Wi-Fi over EAP-TLS verified by the RADIUS server, VPN and ZTNA over certificates, SSH through certificates, mutual TLS to internal services, and a device factor at Okta or certificate-based authentication at Entra ID. Smallstep verifies attestation at enrollment; what each service verifies at access is its own check of the credential, and key protection varies by OS, client, and use case.

Differently. 1Password Device Trust Connect acts as a possession-factor authenticator that passes when the registered device meets its checks. Smallstep integrates as an external identity provider factor: the device presents a certificate, loaded into the browser by the agent and bound to the TPM or Secure Enclave where supported, and Smallstep verifies it over mutual TLS against the inventory before answering Okta. Whether one Okta sign-in policy can require both has not been documented; the claim this page makes is that the two can serve different access paths on the same fleet.

Different mechanisms, not equivalent device factors. 1Password Device Trust integrates with Entra ID as an external authentication method and with Google Workspace through SAML for managed apps. Smallstep's Entra path is certificate-based authentication of a user certificate with issuance-time device assurance on top of Entra's controls, not a separate device factor or a live inventory check at sign-in. Its documented Google Workspace path is inventory sync and credential enrollment for ChromeOS, not app-level SAML enforcement. See Connect Google Workspace to Smallstep and the Entra ID page.

Not where the device check is required and enrollment and recovery are separately protected. With 1Password Device Trust, the registered device's key must sign the challenge, so an unregistered device fails. With Smallstep, the device must present a certificate bound to attested hardware in your inventory. The difference is in how the device came to be trusted: first-device registration through SSO and administrator approval versus attestation of the hardware itself. Neither protects apps outside its enforcement, and neither sign-in check, by itself, binds the resulting session to the device.

In 1Password, an administrator removes the device and it can no longer answer the sign-in challenge. In Smallstep, removing the device from inventory stops issuance and renewal, and revoking its certificate blocks the next authentication where the verifier checks revocation; Smallstep RADIUS checks on each authentication but has no Change of Authorization, so sessions already open continue until reauthentication or until the network ends them.

No. 1Password positions Device Trust as covering what MDM cannot reach, including unmanaged devices, and runs alongside it. Smallstep uses the MDM as an inventory source and a delivery channel for the agent and certificates, and works with Jamf, Intune, Workspace ONE, Mosyle, Iru, and Google Workspace.

The Smallstep agent is documented for Windows, macOS, and Linux, each requiring a TPM 2.0 or Secure Enclave for attested enrollment. ChromeOS enrolls through the Smallstep extension using Google Verified Access. iOS and iPadOS use ACME device attestation through a supporting MDM, and Android uses Dynamic SCEP. Key protection varies by platform and application and is published in the documentation rather than averaged into one claim.

Device inventory and certificate lifecycle records: which device, how it enrolled, whether it attested, which certificates it holds and their lifetimes, and the authority policies that set the key types. Confirm with Smallstep the exact fields and export formats available in your deployment before promising them to an auditor. Those records support the cryptographic inventory and migration plan IR 8547 asks for; they do not demonstrate post-quantum authentication, which depends on the relying parties.