Share this post
OT security teams can usually say who holds credentials to their systems. Fewer can say with confidence whether 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 policy defines what should happen: credentials scoped to the task, sessions time-limited, and access revoked when the work is complete. The architecture has no mechanism to enforce it.
That gap exists not because of negligence, but because the access control model most OT environments run on was designed 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: assign the right role, and the permissions follow. It scales, it's auditable, and for IT environments, it remains the right foundation.
In OT environments, RBAC encounters a structural constraint that is unrelated to how well it's implemented: roles are defined around identities, not actions. A maintenance vendor assigned a "field technician" role may have the correct permissions to service one device, but those permissions typically extend to every device in the same system class, remain active indefinitely, and leave no record of what was actually touched during a specific visit.
The attack surface of any vendor access event can be understood through four variables: who can connect, what they can access, how long they have access, and whether there's a traceable record of what happened. RBAC reliably addresses the first variable. It offers limited control over the remaining three.
That's not a design flaw. It's a scope boundary. RBAC was built to manage identity-to-permission mapping at scale. It was not built to enforce the time, scope, and traceability constraints that OT environments now require.
What action-based access control looks like in practice
Action-based access control reframes the question. Instead of asking "what role does this person have?", the architecture asks: what specific action are they here to perform, on which device, and within what time window?
A vendor updating firmware on a single conveyor controller gains access to that device and not to the surrounding subnet. Their permissions cover only the required operation, not administrative rights across the system class. The access window expires when the task is complete or the 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 doesn't replace RBAC; it builds on 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, a concern specific to AI tooling and the rapid adoption of agentic systems, not to OT environments. However, the structural observation it made is a useful frame for thinking about any domain 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 Role Based Access Control (RBAC) permissions at instantiation." The result is a system that relies on correct behavior rather than on architecture that makes incorrect behavior difficult.
OT operators will recognize the pattern, even when the domain is different. Vendor access governance under RBAC faces the same structural condition: the guardrails are real, but they live in policy documents and provisioning workflows, not in the infrastructure that executes the access. A vendor can remain connected beyond the task window, reach adjacent systems, and leave an audit trail that's either absent or lives on the host they were accessing.
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 around these properties, giving operations teams the infrastructure to enforce access governance rather than relying on policy compliance alone.
Policy documents don't enforce themselves
The vendor access problem is solvable. It's largely a result of deploying identity-based controls in environments that require action-based enforcement. RBAC defines who can connect. The question that increasingly matters to auditors, regulators, and the operations team managing hundreds of field devices is what that access permits and when it stops. The answer has to come from the architecture, not the policy.
.png)
