Access reviews should verify who actually uses each account, whether sharing is occurring, and whether the privilege still matches the role. In shared-device environments, a simple entitlement review is not enough. Teams need evidence of identity uniqueness, session discipline, and exceptions that are still in use.
Why This Matters for Security Teams
Access reviews for shared-device teams fail when they are treated like ordinary entitlement recertification. On a shared workstation, tablet, or front-line terminal, the real question is not only whether an account exists, but whether the right person is using it, whether the account is still needed, and whether sharing has become an unofficial control. That makes identity uniqueness, session discipline, and exception tracking part of the review, not side issues.
This is especially important because weak visibility is already a broad problem in identity governance. NHI Mgmt Group notes in the Ultimate Guide to NHIs that only 5.7% of organisations have full visibility into their service accounts, which is a useful warning sign for any shared-access environment where accounts, devices, and sessions blur together. The control problem is similar to what the OWASP Non-Human Identity Top 10 highlights for non-human identities: access can persist far beyond the point where it remains justified.
Security teams need to review not just permissions, but operational reality: who actually logs in, how exceptions are approved, and whether shared access is still the safest workable model. In practice, many security teams discover account sprawl and informal sharing only after an audit finding, incident, or payroll, retail, or healthcare access complaint has already exposed the weakness.
How It Works in Practice
Start by separating three questions that are often merged into one review: who is assigned the account, who actually uses it, and whether that usage is still legitimate for the device or team. For shared-device environments, the review should combine identity evidence, manager attestation, and technical usage data. Current guidance suggests that a paper recertification alone is not enough because shared access can be formally authorised while still being operationally unsafe.
A practical review workflow usually includes:
- Identifying every shared account, kiosk account, and generic login tied to the device pool.
- Verifying the current business owner for each account and whether the account is still required.
- Checking whether use is tied to named staff, shifts, or roles, rather than an open-ended team entitlement.
- Reviewing session logs, badge or device logs, and exception approvals to confirm actual usage patterns.
- Flagging accounts that are shared without compensating controls such as reauthentication, MFA, or session timeout discipline.
Where possible, align the review with lifecycle controls from the NHI Lifecycle Management Guide, because shared-device accounts often linger after staffing changes, shift redesigns, or app refreshes. NIST also reinforces the need for identity evidence and access governance through its NIST SP 800-53 control families, especially around account management, access enforcement, and auditability.
In mature environments, the output of the review is not just approval or denial. It should be a decision record that states whether the account remains shared by necessity, whether the exception is temporary, and what compensating control is required. These controls tend to break down in high-turnover environments where multiple shifts, contractor access, and emergency use cases make accurate usage evidence hard to collect.
Common Variations and Edge Cases
Tighter review discipline often increases operational overhead, requiring organisations to balance security assurance against frontline speed and continuity. That tradeoff is real in hospitals, warehouses, plants, and retail stores where shared-device access exists because individual logins are impractical. In those settings, best practice is evolving rather than universal, and the review model should match the risk of the work, not the convenience of the workflow.
One common edge case is a team that claims shared access but actually has one primary user and several occasional backups. That pattern should usually be broken into named access with documented backup exceptions, because shared accounts make accountability weak and removal decisions ambiguous. Another edge case is break-glass or emergency access on a shared device. Those accounts should be reviewed separately, with tighter logging and shorter approval windows than standard team access.
For organisations already struggling with broader identity hygiene, the 52 NHI Breaches Analysis is a reminder that weak ownership and stale access are recurring patterns across identity types, not isolated mistakes. The same logic applies here: if a shared account cannot be tied to a current business need, a current owner, and a current control set, it should not survive the review by default.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Access reviews must confirm identity and current authorisation for shared accounts. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Shared access often hides account ownership and weak accountability. |
| NIST SP 800-63 | Identity proofing and session assurance matter when multiple people use the same device. |
Revalidate who can access each shared account and remove access that lacks current business justification.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
