When should organisations require device trust before sign-in?

Why This Matters for Security Teams

device trust is not a cosmetic login check. It is a control point for deciding whether a sign-in request comes from an endpoint that can reasonably be trusted to hold credentials, enforce policy, and resist tampering. That matters most when the target system contains sensitive data, privileged workflows, or internet-accessible admin functions. NIST Cybersecurity Framework 2.0 frames this as part of identity and access governance, while device posture helps add context beyond the password or SSO assertion alone.

For organisations managing broader identity risk, the issue is familiar: valid credentials are often the entry point, not the asset being protected. NHIMG notes in the Ultimate Guide to NHIs that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage. That pattern shows why sign-in decisions must consider where and how access is being initiated, not just who is signing in.

In practice, many security teams only discover unsafe endpoint access after a compromised laptop has already been used to reach a sensitive application.

How It Works in Practice

Requiring device trust before sign-in usually means the identity provider or access gateway evaluates endpoint evidence before it issues access. That evidence can include managed-device enrollment, OS version, disk encryption, endpoint protection status, certificate presence, and attestation from a device management platform. The goal is not to make every device identical, but to ensure the sign-in path can distinguish between managed, known-good endpoints and unmanaged or unknown ones.

A practical deployment often combines several checks:

• Confirm the device is enrolled in an approved management system.
• Require a device certificate or hardware-backed proof of device identity.
• Check health signals such as encryption, patch level, and EDR status.
• Apply step-up controls or block access when the device is outside policy.
• Limit trust duration so posture is re-evaluated rather than assumed indefinitely.

This is consistent with zero trust thinking in the NIST Cybersecurity Framework 2.0, where access decisions should account for context and risk. It also aligns with NHIMG guidance in the Ultimate Guide to NHIs, which highlights how unmanaged or poorly governed access paths expand exposure when secrets and credentials are already widely distributed.

Device trust is most defensible before sign-in for remote work, privileged access, regulated data, and applications that can trigger downstream tool use or data export. It can also be paired with conditional access so low-risk systems remain usable while higher-risk systems demand stronger endpoint assurance. These controls tend to break down in bring-your-own-device environments where the organisation cannot reliably attest to hardware state or maintain consistent management coverage.

Common Variations and Edge Cases

Tighter device-trust checks often increase friction, so organisations need to balance access assurance against workforce flexibility and support overhead. That tradeoff is especially visible in hybrid workplaces, contractor-heavy environments, and incident response scenarios where users may need access from non-standard endpoints.

Current guidance suggests the strongest requirement is for privileged applications, finance and HR systems, code repositories, and environments that expose sensitive secrets. For lower-risk tools, best practice is evolving toward risk-based prompts rather than universal hard blocks. In many cases, a trusted browser session, device-bound certificate, or short-lived access grant is more practical than a blanket deny for every unmanaged device.

There is no universal standard for this yet, but the common pattern is clear: require stronger device trust when the blast radius of a compromised login is high. That is also why organisations with poor endpoint visibility struggle to enforce this consistently. NHIMG reports that only 5.7% of organisations have full visibility into their service accounts, a reminder that identity controls fail quickly when the underlying asset inventory is incomplete. Where posture data cannot be trusted, the sign-in policy becomes guesswork rather than enforcement.

Related resources from NHI Mgmt Group

• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?
• When should organisations prioritise Zero Standing Privilege for non-human identities?
• Why do NHIs complicate zero trust and least privilege efforts?