What should organisations do when users need access from devices that cannot join standard device management?

Organisations should use a device trust approach that can evaluate devices even when they cannot enroll in standard MDM, such as BYOD, Linux, or contractor endpoints. The goal is to check posture before authentication, require remediation when policies are not met, and block access only after a reasonable grace period. That keeps control strong while preserving user productivity.

How device trust fills the gap when standard MDM is not possible

When a device cannot join standard mobile device management, the control question shifts from enrolment to verification. A device trust model lets the organisation evaluate whether the endpoint meets a minimum posture before granting access, even if it is BYOD, Linux-based, or contractor-owned. That makes the access decision depend on current state, not on whether the device can be centrally managed.

The practical value is that device trust preserves a security boundary without forcing an unrealistic management requirement. It can assess signals such as operating system state, encryption, endpoint protection, and policy compliance, then use those signals in the access decision. That is especially useful for mixed-fleet environments where a single management stack cannot cover every endpoint consistently.

For organisations that want the broader control pattern behind this approach, Zero Trust thinking is the right frame: trust is evaluated continuously, access is granted conditionally, and the endpoint is treated as one of several signals rather than as an implicit trust anchor. NIST SP 800-207 Zero Trust Architecture supports that model, and NIST Cybersecurity Framework 2.0 helps teams place it within a broader govern-protect-detect-recover programme.

What the access decision should actually depend on

The key mistake is to treat “cannot join MDM” as a reason to weaken access policy. In practice, the control should separate device enrolment from access assurance. If a device can provide trustworthy posture data, it may be allowed with restrictions. If it cannot prove anything meaningful about its health, access should be limited, stepped up, or denied depending on the sensitivity of the resource.

That means the organisation should define which posture checks are mandatory before authentication, which can be tolerated with a grace period, and which conditions require immediate remediation. A reasonable grace period is useful when the problem is fixable, but it should not become an open-ended exception that quietly turns into standing access. The policy should also distinguish between low-risk productivity apps and systems that expose secrets, customer data, or privileged administrative functions.

For teams building the control set, the relevant design principle is least privilege for access itself. CIS Controls v8 is useful here because it ties account management, access control, and logging to practical enforcement, while ISO/IEC 27001:2022 provides the governance structure for making the decision repeatable rather than ad hoc.

Why this pattern works, and where it still needs discipline

Device trust is not a softer version of security, it is a different control path. It works because it checks the endpoint before the session is established, which is more defensible than trusting access simply because a user is known or a device once passed an enrolment step. It also scales better for partners and contractors, where full corporate management may not be appropriate or possible.

The discipline comes from keeping the signal set narrow, current, and enforceable. If posture checks are too weak, the control becomes a checkbox. If the grace period is too generous, remediation stops mattering. If the organisation never revisits access when posture changes, the model loses the benefit of conditional trust and quietly becomes permanent exception handling. Ultimate Guide to NHIs is a useful companion for understanding how conditional access, visibility, and strong control expectations break down when identity-bearing assets are unmanaged, even though the endpoint problem here is broader than NHI alone.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST Zero Trust (SP 800-207), NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST Zero Trust (SP 800-207)	3 — Zero Trust Architecture Principles	Device trust is a Zero Trust access decision built on continuous verification.
Recommendation — Apply continuous verification before granting access from unmanaged devices.
NIST CSF 2.0	PR.AC — Access Control	The topic centers on conditional access and restricting access by device posture.
Recommendation — Enforce access conditions that reflect device posture and resource sensitivity.
CIS Controls v8	6 — Access Control Management	Managing access from unmanaged endpoints depends on enforced account and access controls.
Recommendation — Restrict access paths to endpoints that meet defined trust requirements.
ISO/IEC 42001:2023	7.5 — AI system risk treatment	No material AI governance relationship is present in this subject, so this framework is omitted.
NIST SP 800-63	5.1.7 — Session Management	Conditional access decisions rely on trustworthy session handling after authentication.
Recommendation — Bind session duration and reauth rules to current trust signals.

Practitioner Guidance

What to prioritise: Define the minimum posture you will accept before authentication, then apply it consistently across unmanaged and partially managed endpoints. If the resource contains sensitive data or administrative reach, require stronger checks and shorter grace periods than you would for ordinary productivity access.

What to verify: Confirm that the device trust signal is actually being evaluated at access time, not only recorded for audit. The control should be able to block, step up, or constrain access when posture falls below policy, and the exception path should have an owner and expiry date.

Common mistake: Treating contractor, BYOD, or Linux endpoints as “special cases” that bypass the same policy logic. That creates a hidden class of always-allowed access, which is exactly where conditional controls tend to fail over time.

Practitioner takeaway: The goal is not universal device management, it is dependable access assurance, so the strongest implementation is the one that preserves conditional control even when the endpoint cannot be enrolled.