Why Role-Based Access Control Isn't Enough for OT Security
Key takeaways
- OT environments can identify who holds credentials, but few can confirm if those credentials were used, which devices were accessed, or whether a vendor session stayed within scope
- RBAC controls identity-to-permission mapping, but doesn't enforce time limits, device scope, or session traceability, three variables that matter most in vendor access events
- Action-based access control constrains each session to a specific device, a specific operation, and a defined time window through an architecture that enforces it
- Outbound-only connectivity, process-scoped permissions, and off-host audit logging are the infrastructure properties that make it enforceable
- The shift from role-based to action-based access is moving the guardrails from policy into architecture. That's the correction most OT vendor access programs need
OT security teams can usually say who holds credentials to their systems. Fewer can say with confidence if those credentials were used in the last 90 days, which devices were accessed, or whether a vendor session stayed within the scope of the work being done.
This is the structural gap at the center of most OT vendor access programs. The architecture has no mechanism to enforce what the policy defines should happen: credentials scoped to the task, sessions time-limited, and access revoked when the work is complete.
This gap isn’t because of negligence, but because the access control model most OT environments run on was built for a different kind of environment.
What RBAC gets right, and where it stops
Role-based access control solved a real problem. Before RBAC, managing permissions at the individual user level in enterprise environments was unscalable. RBAC simplified this by abstracting permissions into roles so the right role could be assigned and the permissions would follow. It was built to manage identity-to-permission mapping at scale, and for IT environments, it remains the right foundation.
In OT environments, RBAC faces a structural constraint that is unrelated to how well it's implemented. With roles defined around identities, not actions, a maintenance vendor assigned as a "field technician" may have the correct permissions to service a specific device but that same permission probably extends to every device in the same class, remains active indefinitely, and leaves no record of what was actually touched during a specific visit.
The attack surface of any vendor access event can be evaluated through four parameters: who can connect, what they can access, how long they have access, and whether there's a traceable record of what happened. That RBAC reliably addresses the first but offers limited control over the time, scope, and traceability constraints that OT environments have grown to require is a scope boundary, not a design flaw.
Action-based access control looks like in practice
Instead of asking, "what role does this person have?", action-based access control reframes the question so the architecture queries, “what specific action are they here to perform, on which device, and within what time window?
So, a vendor updating firmware on a single conveyor controller gains access to that device but not to the surrounding subnet. Their permissions cover only the required operation without administrative rights across the system class. The access window expires when the task is complete or the set time limit is reached. The connection originates outbound from the device, requiring no inbound ports and no persistent VPN channel. The audit trail records which device was accessed, which operations were performed, and when the session closed.
The access surface becomes: one device, one action, one bounded window, fully logged.
This model builds on RBAC, it doesn’t replace it. Identity and role still determine who can request access. Action-based controls determine what that access permits when it's used. Together, they address all four variables of the access surface.
The governance gap
In May 2026, the NSA published a cybersecurity advisory on Model Context Protocol (MCP) security, with a useful structural observation to frame thinking about domains where infrastructure scales faster than security design. The advisory noted that security guardrails in MCP implementations tend to reside in the client (i.e. in policy configurations and expected behavior), rather than being enforced by the protocol itself. It specifically observed that "MCP currently lacks support for exchanging RBAC permissions at instantiation." The result is a system that relies on correct behavior rather than on an architecture that deters incorrect behavior.
OT operators will recognize the pattern, even when the domain is different. Vendor access governance under RBAC faces the same structural constraint: the guardrails are real, but they’re stuck in policy documents and provisioning workflows, not in the infrastructure that executes access. Vendor access remains connected beyond the task window, reaches adjacent systems, and leaves an audit trail that's either absent or stored on the host they accessed.
The shift from role-based to action-based access control is, at its core, the same correction applied to OT: move the guardrails from the policy layer into the architecture. The vendor can't stay connected beyond the window because the architecture closes it. They can't reach outside the defined device scope because the architecture constrains access. The audit log can't be bypassed because it doesn't reside on the host being accessed.
The architecture that enforces it
The management architecture that supports action-based access control in OT environments shares a set of properties: device connectivity that initiates outbound and requires no inbound ports, access provisioning that is time-limited and process-scoped, and audit logging that is stored off the host being recorded. Portainer's OT management architecture is built to give operations teams the infrastructure to enforce access governance rather than rely on policy compliance alone.
Policy documents don't enforce themselves
The vendor access problem is largely a result of deploying identity-based controls in environments that require action-based enforcement. But auditors, regulators, and the operations team managing hundreds of field devices are asking not only who can connect, but what that access permits and when it ends. Policy documents don’t enforce themselves, so the answer to that question has to come from the architecture.
See what the architectural layer looks like in production
RBAC defines who can act. The next layer controls what they can do, on which device, for how long, and then closes the connection when the task is complete. Our on-demand webinar with Xiid covers how outbound-only, process-scoped connectivity works in live OT environments, and what it takes to implement it without disrupting operations. Watch now on-demand
One platform, not twelve tools.
Govern Kubernetes across your whole fleet from a single control plane. Get 3 nodes free.
Get 3 nodes freeTalk to technical sales