Topic starter
06/11/2026 6:38 pm
TL;DR: Shared-device environments can run SSO, RBAC and phishing-resistant MFA and still fail to show who actually performed an action, according to OLOID. That breaks incident response, offboarding and behavioural detection because attribution has to exist at session level, not be reconstructed after the fact.
Editorial analysis by NHI Mgmt Group, based on content published by OLOID: “Accountability in IAM: The Missing Layer in Shared-Workforce Security”.
Key questions
Q: How do organisations make shared-device actions attributable to one person?
A: Organisations make shared-device actions attributable by requiring each person to authenticate individually, then starting a person-bound session starts record that ties the action to a named identity, device, time and context.
Q: Why do shared logins weaken incident response?
A: Shared logins weaken incident response because the audit trail no longer shows which human performed a specific action, so containment, escalation and forensics all start from an ambiguous account.
Q: How does shared access affect behavioural detection?
A: Shared access reduces the signal quality of behavioural detection because activity from multiple people is blended into one account profile.
Practitioner guidance
- Map shared-device workflows to attribution requirements Identify every frontline workflow where a shared credential, inherited session or shared terminal could obscure who performed the action.
- Add person-bound session start controls Require an individual authentication event at every session start so the device records which worker began the session before any sensitive action occurs.
- Engineer clean session handoffs Make one worker's session end, lock or transfer cleanly before another worker begins using the same device, so the audit trail preserves a clear change of actor.
Bottom line: Shared-device access can defeat attribution even when authentication and authorization are functioning as designed.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:42 pm
Accountability is the missing layer when identity controls stop at authentication. Shared-workforce security can have strong login controls and still fail governance because the system does not preserve a durable link between an action and the person who took it. That is not a logging defect alone; it is a design choice that assumes one credential equals one actor. Practitioners should treat attribution as part of the identity model, not as an audit afterthought.
A question worth separating out:
Q: When should teams treat accountability as an IAM control?
A: Teams should treat accountability as an IAM control whenever a business action must be tied to a specific human identity, especially on shared devices, privileged systems or regulated workflows. That usually means unique accounts, step-up authentication, session logging, approval trails and periodic access review, so responsibility can be assigned to one person rather than to a device or team.
👉 Read our full editorial: Shared-workforce security fails when accountability is assumed