Align identity signals with device management so the organisation can tie activity to a known user and a known device state. Where that link is missing, restrict access, increase verification, or deny sensitive workflows until governance signals are restored. That reduces the chance of unmanaged activity becoming accepted normal behaviour.
Why accountability breaks down when device control and user identity drift apart
Security teams run into trouble when a user can act through a device whose state is not trustworthy, or when a managed device is used without a reliable user signal. In practice, that breaks the basic assumption that access decisions can be tied to a known person operating from a known endpoint. Once that link weakens, policy enforcement, logging, and incident review all become less reliable.
At that point, the issue is not just device hygiene. It becomes an access governance problem because the organisation can no longer tell whether a request came from an approved identity, an approved device, or both. That ambiguity often leads to over-permissive exceptions, especially in remote work, shared devices, BYOD, and third-party access scenarios.
For teams that need a practical baseline on tying access to the device state as well as the user, the Remote Access Identity Guide covers the controls that matter most at the remote access boundary.
What security teams should do when the trust signal is incomplete
The right response is to treat missing alignment as a control gap, not as a minor convenience issue. If the organisation cannot confirm both who is acting and what state the device is in, it should not let that session reach high-value workflows by default. The safest pattern is to narrow access until the trust chain is restored, then restore normal access only after the user and device signals are again consistent.
That usually means three practical moves: increase verification, reduce available actions, and re-check the device posture before granting access to sensitive systems. In some environments, that can mean step-up authentication, conditional access, or temporary denial for workflows that would otherwise create durable records, financial impact, or privileged changes.
When the missing signal is the device itself, a strong device identity and attestation model is often the cleanest fix. The Device and IoT Identity Guide is useful where teams need stronger assurance that an endpoint is not just present, but recognisably managed and trustworthy.
For identity governance, the most important point is ownership. If no one is accountable for the identity-device relationship, exceptions linger and become normal. The NHI Ownership and Accountability Guide is a useful reference for the broader principle that every access path needs an owner who can answer for its lifecycle and misuse.
How to prevent unmanaged activity from becoming accepted behaviour
The long-term fix is to make the exception path more expensive than the compliant path. Teams should align endpoint management, identity policy, and access decisions so users do not learn that “temporary” workarounds are a normal route to production systems. If remote sessions without reliable device context are repeatedly allowed into sensitive flows, the exception becomes a parallel operating model.
Good practice is to reserve broad access for devices that are enrolled, visible, and policy-compliant, while treating unknown or partially managed endpoints as limited-trust. That makes accountability stronger because logs and control decisions can be interpreted against a known baseline. It also improves investigations, since the team can separate genuine user activity from activity that only appears user-driven.
Where remote work is a major driver of the problem, the Remote Access Identity Guide provides a practical lens for combining MFA, device posture, and access boundary design without treating all remote sessions as equivalent.
If the environment includes endpoints, kiosks, mobile hardware, or IoT-like devices, the Device and IoT Identity Guide helps teams think about lifecycle controls that keep device trust from degrading over time.
Risk and Threat Considerations
When user accountability diverges from device control, the main risk is that security decisions start relying on partial truth. An authorised user on an unmanaged device can create the same access ambiguity as a compromised device used under a valid login, which makes misuse harder to detect and easier to excuse as normal remote activity.
Failure mechanism: The control failure is usually a weak conditional access model, inconsistent device posture enforcement, or shared exception handling that lets low-trust sessions reach sensitive systems without a reliable ownership trail.
Impact: That creates a cleaner path for unauthorised changes, harder incident reconstruction, and slower containment because logs no longer map cleanly to a specific user and managed endpoint.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | User accountability depends on reliable organizational user authentication. |
| IA-3 — Device Identification and Authentication | The question hinges on trusting the device state behind the access request. | |
| AC-6 — Least Privilege | Unknown device trust should shrink the actions a session can perform. | |
| Recommendation — Require strong user authentication before granting access to sensitive workflows. Authenticate managed devices before allowing privileged or sensitive access. Reduce privileges for sessions that lack a trusted device-state signal. | ||
| CIS Controls v8 | CIS-5 — Account Management | Access control breaks down when managed and unmanaged activity are treated the same. |
| Recommendation — Enforce account lifecycle and exception handling so access stays attributable. | ||
Practitioner Guidance
What to prioritise: First classify which workflows truly require both user assurance and device assurance, then deny or step up only those paths rather than weakening the whole access model. That keeps the control targeted and avoids teaching users that unmanaged access is broadly tolerated.
What to verify: Confirm that your logging, access policy, and help-desk exception process can all answer the same question: who acted, from what device, and under what trust state. If those three answers do not line up, your governance signal is not strong enough for sensitive work.
Common mistake: Teams often treat device compliance as an IT inventory issue and user identity as an IAM issue. For this problem, those are one control surface, and splitting them makes accountability weaker rather than stronger.
Practitioner takeaway: Do not accept access paths that cannot be tied to both a trusted user and a trusted device state. If you must grant an exception, make it narrower, more observable, and easier to revoke than the compliant path.