Get fresh insights, pro tips, and thought starters–only the best of posts for you.
Device trust is the level of confidence assigned to a device based on available identity, authentication, security, management, and compliance signals when making or reassessing an access decision. Rather than relying on a single identifier or security check, a device trust decision may evaluate available factors such as device identity, authentication credentials, security posture, management status, and policy compliance.
Device-related identity, authentication, and posture signals are important inputs in Zero Trust architectures, where access decisions may consider the user, device, requested resource, and other contextual information.
Organizations evaluate available security and management signals against predefined policies to determine whether a device satisfies access requirements. Depending on the environment and technology in use, these signals may include:
It is not permanent. It may be reassessed when access is requested, when relevant device changes are detected, or at configured intervals.
| Feature | Device trust | Device identity |
| Purpose | Helps inform access decisions based on available device-related signals | Represents and identifies a device and can support its authentication |
| Based on | Identity, posture, compliance, management status, authentication, and other security signals | Certificates, hardware identifiers, cryptographic keys, or enrollment records |
| Changes over time | Changes as available security or compliance signals change | Core identifiers often remain stable, while credentials, registration, and ownership attributes may change |
| Used for | Informing access decisions and policy enforcement | Device recognition and, when supported by appropriate credentials, authentication |
| Example | A compliant, encrypted, managed device satisfies organizational access requirements | A device is identified by its enrollment record and authenticated using a certificate |
Device identity establishes which device is requesting access, while device trust provides information that a policy engine can use alongside other contextual signals when determining whether access should be granted.
Organizations cannot assume that every authenticated or enrolled device is secure. A managed device may become non-compliant because of missing security patches, disabled encryption, prohibited configuration changes, or detected threats covered by organizational compliance policies.
Evaluating device trust helps organizations:
Device trust decisions may be reassessed as relevant device conditions change or at configured points during the access lifecycle.
Device trust decisions depend on sufficiently current endpoint information and appropriate access policies. Hexnode UEM supports device enrollment, compliance monitoring, policy enforcement, and endpoint lifecycle management, with available capabilities varying by platform, device type, configuration, and subscription edition.
When Hexnode UEM and Hexnode IdP are used together, supported device posture signals can be evaluated alongside user identity for policy-driven access decisions. Hexnode UEM provides centralized visibility across supported endpoint platforms, while Hexnode IdP uses supported identity and device posture signals in identity-aware access workflows.
Yes. Changes such as expired certificates, failed security checks, revoked credentials, or newly detected vulnerabilities can affect a device’s trust status.
No. Device trust complements user authentication, and many organizations evaluate both before granting access to sensitive resources.