Key points
- Treats device health as an access factor alongside identity
- Sourced from MDM (Jamf, Intune, Kandji) or EDR (CrowdStrike, SentinelOne)
- Often combined with passkeys for phishing-resistant + device-bound auth
- Core building block of Zero Trust and ZTNA
- Distinct from device-bound credentials like passkeys — covers the *device*, not just the key
What it is
Device trust answers, is this device allowed to access this resource, and is it in a healthy state right now? It complements user identity with a check on the endpoint itself.
How it works
The IdP or ZTNA broker pulls posture signals from MDM and EDR — disk encryption on, OS patched, EDR running, no jailbreak, in the corporate MDM tenant. A policy then evaluates: Finance app requires fully compliant managed device; marketing site is fine from any device with a passkey.
When buyers care
- BYOD vs corporate-device policy enforcement
- Replacing VPN with ZTNA
- Reducing impact of stolen credentials by requiring a known device
- Meeting CMMC, FedRAMP, and SOC 2 device-management requirements
Common misconceptions
- Passkeys alone are not device trust. Passkeys bind a credential to a device; device trust evaluates whether that device should be trusted right now.
- Device trust does not require MDM on every device. Unmanaged devices can be evaluated with lighter signals and get reduced access.
FAQ
Where does device trust fit alongside identity?
It sits in the access decision: identity + device + context → allow / challenge / deny. IdPs increasingly integrate device-trust signals natively.
Vendors to look at?
Okta Device Trust / Fastpass, Microsoft Intune + Conditional Access, Jamf + Beyond Identity, and dedicated ZTNA vendors all offer this.