How should security teams implement device trust before granting access to business apps and resources?

Why This Matters for Security Teams

device trust is not just a login control. It is the decision point that determines whether a business app, data set, or admin portal should ever be reachable from a given endpoint. If that decision happens only at authentication, a device can become noncompliant after access is granted and still keep its session. Current guidance from the OWASP Non-Human Identity Top 10 and NIST-aligned access control practice both point toward continuous verification rather than one-time trust.

This matters because stolen credentials are rarely the only problem. A trusted identity used from an unmanaged, jailbroken, or malware-infected endpoint can still reach SaaS apps, internal tools, and sensitive APIs if device posture is not enforced before and during access. NHIMG research on the Ultimate Guide to NHIs shows how often weak identity governance translates into real exposure, especially when controls stop at issuance instead of following the session. In practice, many security teams discover the gap only after a valid credential is replayed from a device that should never have been trusted in the first place.

How It Works in Practice

A practical device-trust program starts by defining what “known,” “healthy,” and “compliant” mean for each access tier. For managed endpoints, that usually includes device certificates, EDR presence, OS patch level, disk encryption, screen lock settings, and local risk signals. For unmanaged endpoints, best practice is evolving, but many teams use a narrower trust model with browser-based controls, conditional access, or step-up verification instead of full device enrollment.

The key design choice is to evaluate device trust before granting the session, then re-check it continuously as risk changes. That means access decisions should consider signals such as missing security updates, revoked certificates, impossible travel, tampered agent state, or a loss of MDM visibility. This approach aligns with Zero Trust thinking in NIST SP 800-53 Rev 5 Security and Privacy Controls, where access enforcement is tied to ongoing policy and not only initial authentication.

• Require device attestation or certificate-based proof for managed endpoints.
• Apply conditional access rules based on device health, location, and risk.
• Use short-lived sessions so trust is re-evaluated during the session lifecycle.
• Trigger automated remediation where a device can be repaired without blocking the user entirely.
• Cut access immediately when posture falls below policy, especially for admin and data-sensitive apps.

For identity-heavy environments, the same logic applies to service access and automation too, which is why NHIMG’s 52 NHI Breaches Analysis is useful reading alongside endpoint trust design. These controls tend to break down when legacy apps cannot consume device signals or when remote users rely on unmanaged devices that have no reliable posture telemetry.

Common Variations and Edge Cases

Tighter device trust often increases friction for contractors, BYOD users, and frontline teams, requiring organisations to balance stronger access control against user productivity and support overhead. That tradeoff is real, and there is no universal standard for this yet. Some organisations use a two-tier model: full device trust for privileged and sensitive applications, and limited, browser-mediated access for lower-risk workloads.

There are also exceptions. Shared kiosks, call-centre desktops, and air-gapped environments may need compensating controls because traditional endpoint posture checks do not fit their operating model. In those cases, session isolation, network segmentation, and stricter app-level authorization become more important than trying to force a one-size-fits-all device policy. For unmanaged endpoints, current guidance suggests using the least-trusting option that still allows the business process to operate, rather than pretending the device is fully compliant.

Security teams should also avoid equating “managed” with “trusted” without telemetry. A device can be enrolled and still be compromised, so continuous device trust should be paired with identity risk signals, session monitoring, and revocation workflows. This is especially important where privileged access, sensitive data, or third-party access is involved, because those are the environments where posture checks age the fastest.

Related resources from NHI Mgmt Group

• How should security teams implement zero trust access across network and non-network resources without creating operational drift?
• How should security teams implement adaptive identity decisions in cloud and remote access environments?
• How should security teams implement policy controls for identities, applications, and devices in a business password management programme?
• How should security teams manage SaaS access when employees use both managed and unmanaged apps?