How to Fix OPC UA Reads That Fail After Browse Succeeds

Back to Blog

Confirm the Session Identity You Actually Authenticated As

Browse often succeeds for anonymous or low-privilege sessions while reads of process values require an authenticated user, so the first check is which identity your session is really using. Anonymous access is a common default that a hardened server leaves able to browse the structure but not read live values. Look at the session's user token: are you connecting anonymously when the server expects a username and password?

If you are supplying credentials, confirm the server accepted them and mapped them to a role that has read permission. A server can authenticate a user and still deny the read because that user's role is scoped to browse only. This is separate from certificate trust, which if broken would stop the connection entirely - if you never got a session at all, start with OPC UA certificate trust errors instead.

Read the Node's AccessLevel and UserAccessLevel Attributes

Every variable node carries two attributes that decide readability: AccessLevel, which is what the node permits in principle, and UserAccessLevel, which is what the current session is allowed given its identity. Browse the node, then read those two attributes specifically rather than the Value. If AccessLevel does not include CurrentRead, the node is not readable by anyone and you are chasing the wrong thing.

If AccessLevel includes read but UserAccessLevel does not, the node is readable in general but not by your session - a clear authorization result. That difference is the single most useful diagnostic here: it tells you instantly whether to fix the node configuration or your user role. Understanding how the node is addressed also helps; see the OPC UA NodeId.

Check for Write-Only and Method-Only Nodes

Some nodes are legitimately not readable. A command or setpoint node may expose CurrentWrite without CurrentRead by design, so a read returns BadNotReadable no matter who you are. Confirm from the AccessLevel attribute whether read is even offered before assuming a permission bug. If it is a Method rather than a Variable, you call it, you do not read it.

Historical nodes add a wrinkle: HistoryRead is a separate permission from the current-value read. A node may let you read the live value but deny a history read, or the reverse, so match the service you are calling to the access bit that governs it. Do not conclude the whole node is broken because one flavor of read was denied.

Rule Out Server-Side Role and Namespace Restrictions

Modern OPC UA servers implement role-based permissions that can restrict reads by namespace, by node, or by user group. A common pattern grants everyone browse of the type system and public namespace while restricting the live process namespace to named operator roles. If your reads fail only inside one namespace, that is the signature of a namespace-scoped rule, not a global one.

Check the server's role configuration or ask whoever administers it which role your user maps to and what that role can read. On a remote gateway you may not administer the server directly, so document the exact NodeId, the identity you used, and the status code returned, then hand that to the server owner. The security policy in force can also gate access - review the OPC UA security policy Basic256Sha256 to confirm you are on a policy the server ties permissions to.

Verify the Fix

After adjusting the identity or role, reconnect a fresh session - permission changes usually take effect on the next session, not the current one - and read the previously failing node. A clean read with good quality confirms the authorization path. Re-read UserAccessLevel too; it should now include CurrentRead for your session, which proves the server, not luck, granted the right.

If the read now works for one node but not its neighbor, you have a per-node or per-namespace rule rather than a blanket one, and you repeat the check on the failing node's AccessLevel. Keep the successful case as your reference so the next failure is a comparison, not a fresh investigation.

Common Mistakes

The biggest mistake is treating a read failure as a connectivity problem and cycling the link, the certificate, and the endpoint while the session was healthy the whole time - browse proved that. The second is reading the Value attribute and never the AccessLevel and UserAccessLevel attributes that actually explain the denial.

Another is assuming anonymous access that browses will also read; hardened servers deliberately split those. And do not confuse BadNotReadable, which is a property of the node, with BadUserAccessDenied, which is a property of your session. The first means nobody reads this; the second means not you. They point at different fixes.

Frequently Asked Questions