Role (Part 18)
In OPC UA, a Role is the Part 18 unit of authorisation: a named set of permissions that identities are mapped into, rather than permissions granted to users directly. A session is assigned its roles at activation, and per-node RolePermissions decide what those roles may do. Roles are browsable in the server's RoleSet.
The well-known roles
Part 18 defines a standard set so that products mean the same thing by the same name: Anonymous, AuthenticatedUser, Observer, Operator, Engineer, Supervisor, ConfigureAdmin and SecurityAdmin. Observer reads, Operator changes process values, Engineer changes configuration, SecurityAdmin manages certificates and trust lists. Servers may add their own roles, but mapping onto the well-known set is what makes a multi-vendor plant administrable by one policy.
Identity mapping is the mechanism
Roles are not stored on users; each Role object in the RoleSet carries identity mapping rules that say which identities belong to it - by username, by user certificate thumbprint or subject, by a group claim from an external identity provider, or by the blanket criteria anonymous and authenticated user. At ActivateSession the server evaluates the rules against the presented identity token and fixes the session's role list. Change the mapping and existing sessions do not necessarily re-evaluate, so plan for a reconnect.
The application role most people miss
Part 3 defines a well-known TrustedApplication role, which is granted on the basis of the application instance certificate rather than the user - the reference stack assigns it automatically to applications whose certificate is trusted. That gives you a genuinely useful distinction: an anonymous session from a trusted application is not the same thing as an anonymous session from an unknown one, and you can permit more to the former without inventing a user account for a gateway.
Enforcement lives on the nodes
A role by itself grants nothing. The RolePermissions attribute on a node lists role and permission pairs, UserRolePermissions shows the effective permissions for the current session, and AccessRestrictions can additionally demand signing, encryption or a session. Nodesets ship default per-node permission tables as .NodeIds.permissions.csv files, which is a useful starting point rather than something to write from scratch.
Example
Roles as they appear when you browse a server, with an identity mapping
Server
ServerCapabilities
RoleSet
Anonymous Identities: [ { criteriaType: Anonymous } ]
AuthenticatedUser Identities: [ { criteriaType: AuthenticatedUser } ]
Observer Identities: [ { criteriaType: UserName, criteria: "hmi_view" } ]
Operator Identities: [ { criteriaType: GroupId, criteria: "line3-operators" } ]
Engineer Identities: [ { criteriaType: Thumbprint, criteria: "3f9a1c..." } ]
SecurityAdmin Identities: [ { criteriaType: UserName, criteria: "pki_admin" } ]
# Part 3 also defines a well-known TrustedApplication role, granted from the
# application instance certificate rather than from the user identity.Defined in: Part 18 - Role-Based Security; Part 3 - Address Space Model for the permission attributes and the TrustedApplication role.
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.