Status code · Security
BadSecurityModeInsufficient
BadMode mismatch
BadSecurityModeInsufficient means the connection succeeded but this particular operation demands more security than the channel has. Configuration services, trust list updates and nodes carrying an encryption AccessRestriction typically require SignAndEncrypt. Reconnect on an endpoint with SignAndEncrypt rather than trying to relax the requirement on the server.
Defined behaviour: The operation is not permitted over the current secure channel - the requested service or node requires a stronger message security mode than the channel provides. (our description of the condition this code reports)
What you actually see
Reads and browses work normally, but one specific method call or one specific node fails, and it fails identically for every user you try.
Why it happens
- A node carries an AccessRestriction requiring encryptionPart 3 AccessRestrictions let a server demand signing or encryption per node. A node marked as requiring encryption is unreachable over a Sign-only or unsecured channel regardless of the user's role, which is why changing credentials never helps.
- Certificate and trust list management servicesThe ServerConfiguration object and its TrustList, UpdateCertificate and CreateSigningRequest methods handle key material, so servers require an encrypted channel for them. Push-model certificate management over a Sign-only channel fails here.
- Credential-bearing operations over a Sign-only channelAnything that carries a secret, such as changing a password or supplying credentials to a KeyCredentialService, needs confidentiality rather than only integrity. Servers enforce this rather than letting the secret travel signed but readable.
- A role or permission model that requires encryptionPart 18 RolePermissions can be combined with AccessRestrictions so that privileged roles are only usable over an encrypted channel. The session activates fine and then the privileged operation is refused.
- The client silently connected on a weaker endpointA best-available selector, or a fallback after a certificate failure, can leave the client on None or Sign without anyone noticing. Everything ordinary keeps working, so the downgrade is only discovered when a restricted operation is attempted.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Check what mode your session is actually usingPrint the SecurityMode and SecurityPolicyUri of the endpoint the session was created on, not the one in your configuration file. In UaExpert the connected endpoint is shown in the server's properties in the Project tree.
- Reconnect on SignAndEncryptSelect an endpoint whose SecurityMode is SignAndEncrypt from GetEndpoints and reconnect. If the operation then succeeds, the diagnosis is complete and the fix is a client configuration change, not a server change.
- Confirm the server publishes an encrypted endpoint at allIf the server only offers None and Sign, an operation requiring encryption can never succeed. Enable a SignAndEncrypt endpoint on the server with a valid certificate, which also means the client must trust that certificate.
- Read the node's AccessRestrictions if a single node is at faultWhere the server exposes them, the AccessRestrictions attribute on the node tells you whether signing or encryption is required. This distinguishes a security-mode problem from a permission problem, which reports BadUserAccessDenied instead.
- Do not remove the restriction to make the call workThe restriction exists because the operation touches key material or privileged configuration. Raising the client to SignAndEncrypt is a smaller change than lowering the server's protection on a configuration interface.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UaExpert | Reconnect through Add Server and pick the SignAndEncrypt entry for the same policy rather than editing the existing connection. Certificate management panels in particular will not operate over an unencrypted channel. |
| UA-.NETStandard (C#) | The server enforces this on services touching ServerConfiguration and TrustList, and on nodes with AccessRestrictions. Select the endpoint with useSecurity true and verify the resulting session's endpoint before calling privileged methods. |
| node-opcua | Its role-based security and user management material assumes an encrypted channel for privileged operations. Set securityMode to SignAndEncrypt on the client options before attempting configuration methods. |
| asyncua (Python) | A client that never calls set_security_string runs on None, so any encryption-restricted node fails while everything else works. Set the security string explicitly before touching restricted parts of the address space. |
| OPC Publisher | Certificate push and trust list operations against a managed server require an encrypted channel. Configure the endpoint's security mode explicitly rather than relying on a best-available selector that can land on None. |
| Prosys | Where a server exposes GDS-style certificate management, the client must be on an encrypted endpoint to use it. The failure names the mode rather than the user, which is the fastest way to tell it apart from a permissions problem. |
What it looks like in the log
Call to UpdateCertificate failed: BadSecurityModeInsufficient
Node requires an encrypted secure channel; current MessageSecurityMode is Sign
The operation is not permitted over the current secure channelConfirm the fix
Reconnect on a SignAndEncrypt endpoint and repeat the exact operation that failed, confirming that no other change to users or permissions was needed.
Stop it happening again
Pin SignAndEncrypt for every production client so a silent downgrade cannot happen, and document which nodes and methods in your servers carry encryption restrictions so integrators configure clients correctly the first time.
Related status codes
Concepts on this page
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →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.