Independent analysis by NHI Mgmt GroupSource article: OLOID, “Mandatory Access Control (MAC): How It Works, Examples, and Limitations” (October 15, 2026)

TL;DR: Mandatory access control only works when the system can reliably tie a session to one verified person, and OLOID’s analysis shows that shared logins and unlocked workstations collapse that assumption by letting the wrong worker inherit labels and clearances. MAC is strongest when paired with per-session authentication, because the policy engine cannot compensate for a false identity at login.


At a glance

What this is: NHI Mgmt Group's analysis, drawing on OLOID's blog post: Mandatory access control depends on verified identity at every session, and shared workstations can undermine even strict label-based policy enforcement.

Why it matters: This matters because access control programmes often assume policy strength is enough, but frontline environments fail when session ownership is unclear and audit trails no longer map to the right person.

By the numbers:

  • Only 1 in 10 companies had labeled their files in Varonis's 2025 State of Data Security Report.

Context

Mandatory access control is a policy-driven authorization model that depends on the system knowing exactly who is using the session. In frontline environments, that premise often breaks first at the shared workstation, where one login is used by several people across a shift.

The governance problem is not whether the label scheme exists, but whether identity and session context remain trustworthy long enough for the policy to apply correctly. That is why MAC programs in healthcare, manufacturing, retail, and logistics often fail at the edge of the workflow, not in the policy design itself.

Authorisation models are useful here because MAC rarely stands alone in practice; it usually sits beside RBAC and ABAC, and its weaknesses become easier to see when the access model is viewed as a layered control stack.


Key questions

Q: How should teams secure mandatory access control on shared workstations?

A: Secure mandatory access control on shared workstations by binding each user to a named account, enforcing strong authentication, and resetting the session at logout or timeout. A shared-device session should not inherit the next person’s clearance or cached authorisations, so use automatic lock, per-user profiles, and central policy enforcement on labelled data and applications.

Q: Why do shared logins weaken label-based access control?

A: Shared logins weaken label-based access control because the system can no longer tie a clearance or need-to-know decision to one accountable person. When several people use the same account, audit trails, revocation, and separation of duties break down, and the label on the resource no longer maps reliably to the identity making the access request.

Q: What is the difference between an access control matrix and role-based access control?

A: An access control matrix assigns permissions directly by subject and object, so every access decision is explicit. Role-based access control groups users into roles and assigns permissions to those roles instead. ACM is more precise and easier to inspect at a granular level, while RBAC is usually easier to scale when many users share similar access needs.

Q: How do access logs lose value in shared-device environments?

A: Access logs lose value in shared-device environments when multiple people act under the same account, so the log shows a workstation and username rather than the real individual. That removes reliable accountability, makes access reviews harder, and weakens investigations unless each user has a unique identity and the device records session start, end, and authentication events.


Technical breakdown

How MAC evaluates access against labels and clearances

Mandatory access control evaluates every request by comparing the subject's clearance and category against the resource's label under centrally defined rules. The user cannot change the policy, and the resource owner cannot weaken it on demand. That makes MAC well suited to classified or need-to-know environments, but it also means the model assumes the identity presented at login is the right one for the entire session. When that assumption is wrong, the policy still behaves correctly, but it protects the wrong person with the wrong access context. See the Classic Security Models Guide.

Practical implication: Treat identity verification as part of MAC enforcement, not a separate login concern.

Why shared workstations create authorization gaps

A shared workstation turns one account into a proxy for several people, which breaks MAC's assumption that a single clearance maps to a single worker. If a session is left open, the next person inherits the active identity context and can reach data that should have been available only to the previous user. The control failure is not in the label decision itself. It is in the session boundary, where the system can no longer distinguish one human from another. See the IAM and IGA Basics.

Practical implication: Require distinct session handoff on every shared terminal so authorization stays tied to the current worker.

How labels, clearances and audit trails depend on session integrity

MAC depends on three moving parts staying aligned: the label on the resource, the clearance on the account, and the session that binds the account to a person. If the session is reused, audit logs still record a valid account, but they no longer establish who actually opened the file or approved the transaction. That weakens incident review, compliance evidence and accountability. In operational settings, the result is a policy that appears strict on paper while becoming ambiguous in practice. See the Access Control Policy Template.

Practical implication: Preserve session integrity so logs can support both access decisions and later investigations.


Threat narrative

Attacker objective: The objective is to use a borrowed or unattended session to reach data or actions that should have remained restricted to a different person.

  1. Entry occurs when a shared workstation remains signed in and the next worker inherits the active account session without reauthentication.
  2. Credential or session abuse follows because the system treats the inherited session as the original verified user, even though the human has changed.
  3. Impact appears as unauthorized access to records or transactions that were restricted to the prior worker's clearance, while logs still point to the same account.
  • Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
  • Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

MAC is only as strong as the identity session that feeds it. OLOID's analysis shows that the policy engine can enforce labels correctly and still fail operationally when multiple workers share one authenticated account. The control assumes the subject at login remains stable for the duration of the session, which is often false on plant floors and back-office terminals. Practitioners should treat session ownership as part of authorization design, not as an afterthought.

Shared logins expose a governance gap that RBAC and ABAC do not solve on their own. Role and attribute models can refine who should see what, but they still depend on a trustworthy session identity. When a workstation stays open across users, the access model may be formally correct while the governance outcome is wrong. Access control policy needs to state how shared-device sessions are authenticated, locked and handed off.

Verified identity at the point of use is the real MAC control point. The label on the file matters, but the decision is made against the identity presented by the active session, not against the person in the room. That is why frontline environments need controls that bind each session to one verified worker before MAC can deliver the intended separation.

Auditability breaks when the login is treated as the person. MAC can produce a neat access log while still obscuring who actually used the terminal. That creates a false sense of compliance because the evidence records account activity, not human accountability. Programmes that rely on shared credentials are therefore measuring policy enforcement against the wrong unit of identity.

What this signals

Identity binding becomes the deciding control in frontline MAC programmes. Once multiple workers can reuse one session, the policy engine still enforces labels, but it can no longer prove that the right human is behind the request. That means session handoff, lock discipline and per-user authentication matter as much as classification design.

Frontline governance fails when access review is aimed at accounts instead of sessions. A programme can certify permissions and still miss the real defect if it does not ask whether each device session maps to one person at a time. The next maturity step is to govern session transitions as part of authorization, not as a separate usability issue.


For practitioners

  • Enforce per-session authentication on shared terminals Require every shift handoff to end the current session and start a fresh one so the next worker does not inherit clearance from the previous user.
  • Separate account identity from workstation access Stop using shared credentials for frontline devices and bind each sign-in to a named worker so labels and clearances apply to the correct person.
  • Test MAC against unlocked-session scenarios Validate denied-access cases when a workstation is left open, a user changes mid-shift, or a terminal is shared across roles.
  • Review label governance for operational accuracy Check whether high-risk files, records and transactions are actually labeled, because MAC cannot enforce need-to-know when classification is incomplete.

Key takeaways

  • Mandatory access control depends on identity fidelity at the moment of access, not just on well-written policy.
  • Shared workstations create the main failure mode because one login can outlive the person who started it.
  • The control gap closes when organisations bind every session to a verified worker and remove shared logins from frontline devices.

Related NHI Mgmt Group resources: Authorisation Models Guide · IAM and IGA Basics · Access Control Policy Template


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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-10 — Human Use of NHIShared logins and shared terminals let one human use another person's active session.
Recommendation — Eliminate shared-device session reuse and bind each access event to one verified worker.
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementShared-login environments depend on strong authenticator and session lifecycle control.
Recommendation — Manage authenticators so reauthentication occurs at every handoff and session reuse is prevented.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsMAC is an authorization model whose outcome depends on correct permissions and identity context.
Recommendation — Align entitlements to the correct user context and verify access decisions against live session identity.
CIS Controls v8CIS-5 — Account ManagementShared workstations expose account sprawl and ambiguous account usage across shifts.
Recommendation — Track account use so every workstation login maps to one accountable identity.

Key terms

  • Mandatory Access Control: Mandatory Access Control is an access model in which a central authority defines and enforces who can access specific resources. End users cannot override the policy. It is used when consistency, separation of duties, and tighter governance matter more than local flexibility, especially in sensitive or regulated environments.
  • Security label: A security label is metadata attached to information or objects that records its classification, sensitivity, or handling requirements. Systems use it to enforce access and sharing rules. If labels are missing or wrong, data can be exposed, over-restricted, or routed to the wrong controls, so administrators must validate inheritance and policy mapping.
  • Clearance Levels: Clearance levels are formal grades that define how sensitive information a person may access. They are used in mandatory access control to compare a user’s authorisation with the classification of data or systems, so access decisions depend on policy labels rather than the user’s role alone.
  • Shared Workstation: A shared workstation is a computer used by more than one person, often in shifts or in common work areas. In identity security, it creates higher risk because sessions, cached credentials, and local access can cross users, so controls such as strong authentication, session isolation, and automatic logout are needed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org