Notifications
Clear all
Topic starter
12/06/2026 12:50 am
TL;DR: Device access control is presented as a way to regulate hardware use, reduce unauthorised access, and support logging, encryption, and least privilege across endpoints and peripherals, according to Zluri. The wider lesson is that device controls only hold when identity, policy, and lifecycle governance are aligned end to end.
NHIMG editorial — based on content published by Zluri: Access Management Device Access Control: A Comprehensive Guide
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
Questions worth separating out
Q: How should security teams govern device access without creating unmanaged exceptions?
A: Security teams should bind device permissions to identity, role, and business purpose, then review exceptions through the same governance process used for other access rights.
Q: Why do device controls fail when identity governance is weak?
A: Device controls fail when the underlying identity is overprivileged or stale, because the device policy ends up enforcing the wrong account state.
Q: What do security teams get wrong about device access control?
A: Teams often treat device access control as a blocking mechanism instead of a governance control.
Practitioner guidance
- Map device permissions to identity lifecycle events Tie device access approvals, removals, and exceptions to joiner-mover-leaver workflows so users do not retain peripheral access after their role changes.
- Separate device blocking from data protection Enforce encryption on removable media and endpoint storage even when USB access is restricted, because physical access and data exposure are different risks.
- Reconcile NAC with IAM policy Check that network access control and device access rules use the same identity source and role logic, so one layer does not silently override the other.
What's in the full article
Zluri's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step device access control examples for USB, endpoints, and local hardware policies
- Operational examples of monitoring, event logging, and audit trails for device activity
- Implementation detail on integrating device controls with network access control and encryption
- Practical workflow examples for future-proofing device governance in day-to-day operations
👉 Read Zluri's guide to device access control and endpoint governance →
Device access control: what IAM teams are missing now?
Explore further
12/06/2026 10:19 am
Device access control is only effective when it is treated as identity governance, not as an endpoint add-on. The article describes a control layer for hardware and peripheral use, but the practical security outcome depends on whether identity, role, and lifecycle decisions are accurate upstream. When that linkage is weak, organisations end up enforcing device rules against stale or over-broad entitlements. Practitioners should treat device access as part of the access model, not a separate patch on top of it.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- Another 97% of NHIs carry excessive privileges, which broadens the attack surface and makes device-level restrictions easier to bypass through over-scoped identity paths.
A question worth separating out:
Q: How can organisations tell whether device access control is actually working?
A: Device access control is working when audit trails show consistent enforcement, exceptions are rare and approved, removable media is encrypted, and revoked users no longer retain device-level access. If logs are incomplete or reviews do not remove obsolete permissions, the control exists in policy only.
👉 Read our full editorial: Device access control exposes the limits of device-centric IAM
