Permission / RolePermissions
In OPC UA, RolePermissions is the node attribute that lists which roles may do what to that node - browse, read, write, call, read or modify history, receive events, change references. UserRolePermissions is the same list filtered to the current session's roles, so it is the attribute a client reads to discover its own effective rights.
Permission bits, not a single access flag
The permission set is granular and deliberately covers more than data access: Browse, Read, Write, ReadHistory, InsertHistory, ModifyHistory, DeleteHistory, WriteAttribute, WriteHistorizing, Call, ReceiveEvents, AddReference, RemoveReference, DeleteNode, AddNode, plus ReadRolePermissions and WriteRolePermissions for the permission table itself. Browse being separate matters: you can hide a node's existence from a role rather than merely refuse to read it.
How it relates to AccessLevel
AccessLevel and UserAccessLevel describe what the underlying variable supports and what this user may do with its value. RolePermissions is the role-based authorisation layer on any node class, not just Variables. They are checked together and the more restrictive wins, which is why a variable with AccessLevel CurrentWrite can still refuse a Write with BadUserAccessDenied. When a write is refused, read UserAccessLevel and UserRolePermissions before assuming the node is read-only.
AccessRestrictions is the third control
Alongside permissions, a node can carry AccessRestrictions demanding SigningRequired, EncryptionRequired or SessionRequired, and optionally applying those restrictions to Browse as well. That is how you let a dashboard read production counts over a signed channel while requiring encryption before anyone can see or change a recipe. The refusal for that is BadSecurityModeInsufficient, which is a correctly working policy rather than a fault.
Applying it without hand-editing thousands of nodes
RolePermissions can be set on a type and inherited by instances, and it can be set on a namespace's default so every node in that namespace starts from a sensible baseline. The published nodesets ship .NodeIds.permissions.csv files carrying default per-node permissions, which is the practical starting point. Design permissions at folder and type level; per-node exceptions should be countable on one hand or the policy will not survive the next model change.
Example
Reading effective permissions instead of guessing why a Write failed
Node ns=4;s=Line3.Press.SetpointForce
AccessLevel CurrentRead | CurrentWrite
UserAccessLevel CurrentRead <- this session cannot write
RolePermissions Observer : Browse, Read
Operator : Browse, Read, Write
Engineer : Browse, Read, Write, WriteAttribute
UserRolePermissions Observer : Browse, Read <- session holds Observer only
AccessRestrictions EncryptionRequired
# Write -> BadUserAccessDenied (role), or
# BadSecurityModeInsufficient (channel only Signed, not encrypted)Defined in: Part 3 - Address Space Model, RolePermissions and AccessRestrictions; Part 18 - Role-Based Security.
Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.