Anonymous access
In OPC UA, anonymous access means a session activated with an AnonymousIdentityToken: no user credential is presented. It is independent of channel security, so an anonymous session can still be fully encrypted and application-authenticated. Part 18 maps anonymous sessions to the well-known Anonymous role, which is where you constrain what they can do.
It is a legitimate configuration, used badly
Anonymous read access to a curated part of the address space is perfectly reasonable, and it is how public demonstration servers work. The problem is the default shape most products ship: anonymous, over a security-policy-None endpoint, with full browse and read across the whole model and often write access too. Each of those three is a separate decision and they get conflated into one checkbox labelled allow anonymous.
Separate the three questions
First, is the channel secured - anonymous over SignAndEncrypt still gives you application authentication, tamper detection and confidentiality. Second, what can the Anonymous role see - restrict it to the nodes a dashboard actually needs, not the whole model. Third, can it write or call methods - almost always no. Answer these separately and anonymous access becomes a designed capability rather than an open door.
Where it breaks attribution
Audit events record a ClientUserId, and for an anonymous session there is nothing useful to record. If any anonymous session can write a setpoint or call a method, your audit trail can tell you a value changed and not who changed it, which fails both incident response and most process-safety and regulatory expectations. This is the argument that actually persuades plant management, more than any abstract security case.
What to do instead
Keep an anonymous, read-only, narrowly scoped endpoint if a dashboard or historian genuinely needs one, and require a real identity token for anything that changes state. Use AccessRestrictions to require signing or encryption on the sensitive parts of the model, and set RolePermissions so the Anonymous role has Browse and Read and nothing else. A server whose only configuration is all-anonymous-read is a finding in any competent security review.
Example
A defensible anonymous configuration versus the common default
common default - do not ship this
endpoint None / SecurityPolicy#None
tokens Anonymous
roles Anonymous -> Browse, Read, Write, Call on the whole address space
defensible
endpoint SignAndEncrypt / Basic256Sha256 (no None endpoint at all)
tokens Anonymous, UserName
roles Anonymous -> Browse, Read on Objects/Plant1/Public only
Operator -> + Write on setpoints, Call on start/stop
Engineer -> + Write on configuration
AccessRestrictions on the setpoint folder: EncryptionRequiredDefined in: Part 4 - Services, ActivateSession; Part 18 - Role-Based Security for the Anonymous 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.