Device Trust: How It Works in 7 Steps & 5 Best Practices

What Is Device Trust? 

Device trust is a security approach that checks whether a device meets defined requirements before it can access applications, networks, or data. Instead of trusting a device because it is connected to a corporate network, the system evaluates signals such as device identity, operating system version, encryption status, security software, and configuration.

Device trust is commonly used with zero trust access controls. A trusted device may need to be registered with the organization, managed through endpoint management software, and compliant with security policies. If a device is unknown, compromised, or out of compliance, access can be blocked or limited even when the user has valid credentials.

This is part of a series of articles about DLP 

In this article:

• How Does Device Trust Work?
• What Factors Determine Whether a Device Is Trusted?
• Device Trust Levels
• Key Device Trust Technologies
• Device Trust Best Practices

How Does Device Trust Work? 

Step 1: Device Identification

The first step is determining which device is requesting access. Identification can use:

• Device certificates
• Hardware-backed keys
• Endpoint management records
• Cryptographic identifiers

These methods provide stronger evidence than easily changed values such as device names, IP addresses, or browser information. The system can then determine whether the device is registered, managed, or previously known to the organization. Device identity also makes it possible to associate security and compliance information with the endpoint making the request.

Step 2: User Authentication

Device trust is normally evaluated alongside user authentication. The user proves their identity using:

• A password
• A passkey
• A security key
• Biometrics
• Multifactor authentication 

The identity provider then associates the authenticated account with the device requesting access. This prevents device trust from becoming a substitute for identity verification. A trusted corporate laptop should not provide access when an unauthorized person is using it. Likewise, valid user credentials may not be sufficient when they are used from an untrusted device.

Step 3: Device Posture Assessment

A posture assessment checks the device’s current security state. Signals can include:

• Operating system version
• Patch level
• Disk encryption
• Firewall configuration
• Endpoint protection
• Screen-lock settings
• Whether the device has been rooted or jailbroken

Organizations choose posture checks based on the resources being protected and the risks they want to reduce. For example, access to sensitive data might require an encrypted disk and active endpoint detection and response software, while a lower-risk application may have fewer requirements.

Step 4: Device Compliance Verification

The collected posture information is compared with predefined security policies. A policy might require:

• An approved operating system
• Recent security patches
• Disk encryption
• Active endpoint protection
• Enrollment in the organization’s device management platform

Compliance is usually evaluated automatically. If a required control is missing or incorrectly configured, the device can be marked noncompliant. Some systems provide remediation instructions so the user can update or reconfigure the device before requesting access again.

Related content: Read our article about DLP policy.

Step 5: Risk Evaluation

Compliance alone does not show whether a device is safe at a particular moment. Device trust systems can therefore evaluate additional risk signals, such as:

• Malware detections
• Suspicious processes
• Unusual login locations
• Unexpected configuration changes
• Connections from risky networks

These signals can be combined into a risk level or used directly in access policies. For example, a compliant device with an active malware alert may be treated as high risk despite meeting its normal configuration requirements.

Step 6: Policy-Based Access Decisions

Access policies determine what happens after these signals have been evaluated: 

• Identity
• Posture
• Compliance
• Risk

The result does not have to be a simple allow-or-block decision. Policies can require additional authentication, restrict access to sensitive features, provide read-only access, or prevent downloads to unmanaged devices. Different applications and data can also have different trust requirements. An organization might permit email access from a personal device while requiring a managed and compliant endpoint for administrative systems or confidential data.

Step 7: Continuous Device Monitoring

Device trust can continue after the initial access decision. Endpoint management and security tools can report changes in device posture, including:

• Disabled security software
• Missing patches
• Malware detections
• Configuration changes that make the device noncompliant

When the device’s trust state changes, access can be reevaluated. Depending on the policy and available integrations, the system may require reauthentication, restrict access, revoke tokens, or terminate the session. This reduces the period during which a compromised or noncompliant device can continue accessing protected resources.

What Factors Determine Whether a Device Is Trusted?

Device Ownership

Device ownership indicates whether an endpoint belongs to the organization or to an individual user. Corporate-owned devices generally provide a higher level of assurance because the organization controls their configuration, software, updates, and security controls.

Personal devices can also be trusted, but organizations often apply different policies to them. They may require specific security settings or restrict actions such as downloading sensitive files. Ownership is therefore one input into the trust decision rather than proof that a device is secure.

Device Enrollment and Management Status

Enrollment confirms that a device is registered with an approved endpoint or mobile device management system. These platforms allow administrators to enforce security settings, deploy updates, install certificates, and collect information about the device’s compliance status.

A managed device provides stronger evidence that required controls are being maintained. Trust policies may reject unmanaged devices or give them limited access. They can also remove trust when a device is unenrolled or stops reporting to the management platform.

Disk Encryption

Disk encryption protects stored data if a device is lost, stolen, or accessed without authorization. Device trust policies commonly check whether technologies such as BitLocker or FileVault are enabled before allowing access to sensitive resources.

The check may also verify that encryption covers the required storage volumes and that recovery mechanisms are properly managed. A device with encryption disabled can be marked noncompliant even if its user successfully authenticates.

Firewall Configuration

A host-based firewall controls network connections to and from the device. Trust checks can verify that the firewall is enabled and that users have not disabled required protections.

More detailed policies may validate specified firewall profiles or configurations. This helps reduce exposure to unauthorized network connections, particularly when devices operate outside the organization’s protected network.

Device Certificates

Device certificates provide cryptographic proof that a device has been registered or approved by an organization. During authentication, the device proves possession of the private key associated with its certificate. This makes certificates more reliable than identifiers that can be copied or modified.

Certificates can also have expiration and revocation controls. If a device is retired, lost, or compromised, its certificate can be revoked so it can no longer satisfy certificate-based trust requirements.

Device Risk Score

A device risk score represents the likelihood that an endpoint is compromised or unsafe. Endpoint security tools can calculate risk using signals such as malware detections, suspicious processes, known vulnerabilities, security configuration changes, and other indicators of compromise.

Access policies can respond differently to different risk levels. A low-risk device may receive normal access, while a medium-risk device may require additional verification. A high-risk device can be blocked until the threat is investigated and remediated.

Device Trust Levels 

Trusted Managed Devices

Trusted managed devices are typically organization-owned endpoints enrolled in an approved endpoint management platform. They meet required security policies, such as:

• Disk encryption
• Current security updates
• Endpoint protection
• Firewall configuration

Because the organization can configure and monitor these devices, they usually receive the highest level of access. However, their trust can still be reduced or revoked if they become noncompliant or show signs of compromise.

Trusted BYOD Devices

Trusted bring-your-own-device (BYOD) endpoints are personally owned devices that satisfy defined security requirements. They may be:

• Registered with the organization
• Enrolled in device management
• Configured with a managed work profile that separates business data from personal data

Organizations often give these devices less access than fully managed corporate endpoints. Policies may permit access to email and business applications while restricting downloads, administrative functions, or access to highly sensitive data.

Partially Trusted Devices

Partially trusted devices meet some security requirements but do not provide all the signals required for full trust. For example, a device might have disk encryption and current patches but not be enrolled in the organization’s endpoint management system.

Rather than blocking the device completely, access policies can apply additional controls. These can include:

• Multifactor authentication
• Browser-only access
• Session time limits
• Blocked downloads
• Access only to applications with lower sensitivity

Unmanaged Devices

Unmanaged devices are not controlled through an organization’s approved endpoint management tools. Administrators may have little or no ability to:

• Enforce configurations
• Install security software
• Verify patching
• Remotely respond to security problems

These devices commonly receive restricted access. An organization might allow access to public or low-risk resources while preventing access to confidential data, internal administrative tools, or applications that require a managed endpoint.

Unknown Devices

Unknown devices are endpoints that the organization cannot reliably identify or associate with an existing device record. They may lack:

• A valid device certificate
• An enrollment record, registration
• Another approved device identity signal

Unknown devices generally receive the lowest level of trust because their security state cannot be established reliably. Policies may block them entirely or require registration, enrollment, additional authentication, and posture checks before granting access.

Key Device Trust Technologies 

Mobile Device Management (MDM)

Mobile device management (MDM) platforms enroll and manage devices such as smartphones, tablets, and laptops. After enrollment, administrators can configure security settings, distribute certificates, control applications, and enforce requirements for passwords, encryption, screen locks, and operating system versions.

MDM platforms continuously collect information about managed devices. This allows them to determine whether an endpoint meets defined compliance policies. A device may become noncompliant when encryption is disabled, required software is removed, or its operating system becomes outdated.

Device trust systems can use this compliance status during authentication. For example, access can be allowed only when a device is enrolled and compliant. MDM also supports actions such as remotely removing corporate data, revoking certificates, or locking devices when they are lost or retired.

Unified Endpoint Management (UEM)

Unified endpoint management (UEM) provides centralized management for a broader range of endpoints, including desktops, laptops, smartphones, and tablets. It combines many device management functions within a single administrative platform.

UEM systems can collect information about hardware, installed software, operating system versions, security settings, certificates, and patch levels. Administrators can use this data to create consistent compliance policies across different operating systems and device types.

For device trust, UEM acts as a source of device identity and posture information. Access systems can check whether a device is enrolled, properly configured, and actively reporting to the UEM platform. Devices that stop reporting or fall out of compliance can automatically receive reduced access.

Endpoint Detection and Response (EDR)

Endpoint detection and response (EDR) tools monitor endpoint activity to identify signs of compromise. They analyze processes, files, network connections, system changes, and other activity that could indicate malware or attacker behavior.

EDR is important because configuration compliance does not guarantee that a device is safe. A fully patched and encrypted device can still become compromised through stolen credentials, malicious software, or exploitation of an unknown vulnerability.

EDR findings can therefore become real-time device trust signals. When an endpoint receives a high risk score or an active threat is detected, access systems can block sensitive resources or isolate the device. Normal trust can be restored after the threat is contained and the endpoint is verified as safe.

Identity and Access Management (IAM)

Identity and access management (IAM) systems authenticate users and control which resources they can access. Device trust extends these decisions by adding information about the endpoint being used, rather than relying only on the user’s credentials.

An IAM policy can combine user identity, authentication method, device compliance, location, application sensitivity, and risk signals. For example, an administrator may be required to use multifactor authentication from a managed, encrypted, low-risk device before accessing a privileged system.

IAM platforms can also apply different controls when device trust is insufficient. Instead of blocking every request, a policy might require stronger authentication, restrict the session, or permit access only to less sensitive applications.

Zero Trust Network Access (ZTNA)

Zero trust network access (ZTNA) controls access to individual applications and services instead of placing authenticated users directly onto a trusted network. Each access request is evaluated against policies that can include both user identity and device trust.

A ZTNA platform can check whether an endpoint is managed, encrypted, patched, running required security software, and free from known threats. It can receive these signals from endpoint management, EDR, IAM, and other security systems.

This approach allows organizations to make application-specific decisions. A partially trusted device might access a low-risk web application but be blocked from a production environment. Some ZTNA systems also reevaluate posture during active sessions and terminate access if trust conditions change.

Secure Workspace and Application Isolation Technologies

Secure workspace and application isolation technologies create a controlled environment for accessing corporate applications and data. Common approaches include managed application containers, virtual desktops, remote browser isolation, and application virtualization.

These technologies are useful when an organization cannot establish sufficient trust in the underlying endpoint. Instead of allowing sensitive information to be processed or stored directly on the device, applications can run in an isolated local container or on remote infrastructure.

Security policies can restrict copying, pasting, printing, screenshots, file downloads, and data transfers between managed and unmanaged environments. This makes it possible to provide limited access from BYOD, contractor, or unmanaged devices while reducing the amount of corporate data exposed to the endpoint.

Isolation does not make an untrusted device trusted. Instead, it reduces the consequences of using a device whose complete security state cannot be verified and gives organizations another way to enforce access based on device trust level.

Related content: Read our article about data leakage.

Device Trust Best Practices 

Here are some of the ways that organizations can improve their device trust strategy.

1. Combine Device Trust with Strong User Authentication

A trusted device should not replace user authentication. Organizations should verify both the identity of the user and the device involved in each access request. Strong authentication methods include passkeys, hardware security keys, certificate-based authentication, and phishing-resistant multifactor authentication.

Combining these controls protects against several attack paths. Stolen credentials alone should not provide access from an unknown device, while possession of a trusted device should not allow an unauthorized person to sign in. Policies can require both conditions before sensitive resources become available.

Authentication requirements should reflect risk. Access to privileged accounts, production environments, or sensitive data can require stronger authentication even from a trusted endpoint. Higher-risk events can also trigger step-up authentication before access continues.

2. Continuously Evaluate Device Security Posture

Organizations should evaluate device posture after enrollment and at regular intervals afterward. Relevant checks can include operating system version, patch status, disk encryption, firewall configuration, endpoint protection, screen-lock settings, management status, and signs of rooting or jailbreaking.

Posture requirements should be specific enough to enforce automatically. For example, instead of requiring devices to be “up to date,” a policy can define supported operating system versions or a maximum period for applying critical security patches.

There should also be a clear response to failed checks. Minor issues may trigger a warning or remediation workflow, while serious problems can immediately block access. Once the required configuration is restored and verified, the device can regain its appropriate trust level.

3. Apply Least-Privilege Access Based on Device Risk

Device trust should influence how much access an endpoint receives. A fully managed and compliant corporate device may qualify for sensitive applications, while an unmanaged or partially trusted device may receive only limited access.

Restrictions can be applied at several levels. Organizations can prevent downloads, disable administrative functions, provide browser-only access, shorten session durations, or limit users to specified applications. A device with evidence of active compromise should normally be denied access until the issue is resolved.

Policies should also consider the user’s role and the sensitivity of the resource. An unmanaged device used to access a general employee portal presents a different risk from the same device attempting to access production infrastructure or customer records.

4. Separate Corporate Data from Personal Device Activity

BYOD environments require controls that protect corporate information without unnecessarily managing personal data. Managed work profiles, application containers, virtual desktops, and remote browser isolation can create boundaries between business and personal activity.

Organizations can use these boundaries to control how corporate data moves. Policies might prevent users from copying information into personal applications, saving files to unmanaged storage, printing sensitive documents, or opening corporate files with unapproved software.

This approach is particularly useful when the organization cannot establish full trust in a personal endpoint. Sensitive processing can remain inside a managed application or remote environment while the underlying device receives limited access. Removing the work profile or container can also remove corporate data without affecting personal content.

Related content: Read our article about endpoint DLP.

5. Monitor Device Risk Throughout the Session

A successful posture check at sign-in only describes the device at that point in time. Malware can execute, security software can be disabled, management enrollment can change, or a new threat can be detected while an authenticated session remains active.

Endpoint management and EDR tools should therefore continue supplying relevant risk and compliance signals. Access systems can use these updates to reevaluate whether the endpoint still satisfies the policy associated with the active session.

Responses should match the severity of the change. A minor compliance issue might require remediation within a defined period, while a malware detection could trigger immediate token revocation, application blocking, or device isolation. Continuous evaluation reduces the time between a device becoming unsafe and its access being restricted.

Extending Device Trust to Devices You Don’t Manage with Venn

Device trust breaks down at the point where an access decision succeeds but the endpoint itself can’t be verified, isolated, or cleaned up afterward. Venn’s Blue Border™ addresses that gap by installing a company-controlled secure enclave directly on any Mac or PC, managed or unmanaged. Work data, applications, networking, and AI workflows run locally inside the enclave, while everything outside it stays private to the user. Zero trust access controls decide who connects to which application; Blue Border governs what happens to the data once it lands on the device, so contractor, BYOD, and personal machines can be given access without being fully managed.

Key capabilities of Blue Border™:

• Company-controlled secure enclave: Installing Blue Border on a Mac or PC creates an isolated workspace on the device itself, so company data is protected without owning or fully managing the endpoint.
• Encrypted, isolated data at rest: Users save only to work-sanctioned file systems inside Venn Disk, which are isolated, encrypted, and remote wipeable.
• Application-level virtual firewall: Every installed, browser-based, or AI application is wrapped by a blue line that acts as a virtual firewall and enforces policy at the app level.
• Endpoint DLP enforcement: Controls on the device cover copy/paste, downloads, uploads, screenshots, printing, and AI usage, the data movement that access controls alone do not govern.
• Secured network path: Work traffic routes through Venn’s built-in VPN gateway or an organization’s existing private network.
• AI governance on any device: Policy determines which AI tools can reach company data inside the enclave, while personal AI use outside the enclave remains private.
• Revocable data, not just revoked access: Because company data lives only inside the enclave, a single remote wipe removes it entirely at offboarding.
• Complementary to existing zero trust investments: Blue Border runs alongside ZTNA, EDR, and identity platforms rather than replacing them, extending zero trust from the connection through to the data.

See how Blue Border extends zero trust to the endpoint and data layer on any device: Extend ZTNA with Endpoint Data Protection.