Status code · Security
BadSecurityModeRejected
BadMode mismatch
BadSecurityModeRejected means the server will not accept the MessageSecurityMode you asked for on that endpoint, most often because you requested None on a server that requires Sign or SignAndEncrypt, or asked for a mode that endpoint does not publish. Read the endpoint list and use a mode it actually offers.
Defined behaviour: The security mode does not meet the requirements set by the server - the requested MessageSecurityMode is not available on the selected endpoint. (our description of the condition this code reports)
What you actually see
A quick unsecured test connection is refused outright, or a client configured for Sign fails against a server that only publishes SignAndEncrypt.
Why it happens
- The client asked for None on a secured serverHardened servers disable the None endpoint entirely, since shipping SecurityMode None to production is the first thing a hardening checklist removes. Test clients configured for a quick look then fail at channel open before any certificate is involved.
- The endpoint offers only SignAndEncryptMode and policy are orthogonal and both appear in every EndpointDescription. A server may publish one policy solely with SignAndEncrypt, so a client set to Sign with the same policy has no matching endpoint even though the policy name is right.
- The client built its own EndpointDescriptionConstructing the endpoint in code rather than selecting one from GetEndpoints lets you request a mode and policy combination the server never published. The server rejects the combination, not the individual values.
- Discovery returned an endpoint set from a different listenerServers with several listeners or a proxy in front can return endpoints that do not correspond to the port you dialled. The mode you selected exists on one listener and not on the one actually answering.
- A best-available selector fell back to NoneSelectors that pick the best mode can end up at None when discovery returns no secure endpoint descriptors, and the server then rejects the unsecured request. The documented advice is that failing to connect is better than silently dropping to None.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Enumerate the endpoints before configuring anythingGetEndpoints with security None against opc.tcp://host:4840 returns every published combination. Print SecurityMode and SecurityPolicyUri together, because it is the pair that has to match, not either one alone.
- Select an endpoint object rather than assembling oneUse the stack's endpoint selection helper against the returned list so the mode, policy, server certificate and endpoint URL all come from the same description. This eliminates a whole class of self-inflicted mismatches.
- If you need an unsecured endpoint, decide whether the server should have oneEnabling a None endpoint to make a test work reopens the exact hole the hardening closed. Prefer fixing the client's certificate configuration so it can use the secured endpoint, and keep None for isolated lab servers such as the public umati or Milo demo servers.
- Check the server's endpoint configuration if you own itConfirm which modes are enabled per policy. A server configured with a policy but no certificate, or with a mode disabled in one profile and enabled in another, publishes a set that does not match what the configuration screen implies.
- Pin the mode explicitly in productionConfigure SignAndEncrypt explicitly rather than a best-available selector, so a discovery hiccup produces a clean failure instead of a silent downgrade to an unsecured session.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UaExpert | The Add Server tree shows each endpoint as policy plus mode, so you can see immediately whether Sign exists for the policy you want. Selecting the None entry against a hardened server is the usual way to produce this error. |
| asyncua (Python) | set_security_string carries the mode as its second field, for example Basic256Sha256,SignAndEncrypt,cert.der,key.pem. Omitting the call entirely leaves the client on None, which a hardened server rejects. |
| node-opcua | securityMode and securityPolicy are separate client options and both must correspond to a published endpoint. The library's endpoint discovery output is worth logging once during commissioning. |
| UA-.NETStandard (C#) | CoreClientUtils.SelectEndpoint takes a useSecurity flag and picks from the server's list. Passing false against a server with no None endpoint yields this rejection rather than falling back. |
| opcua-commander | Useful as a fast check of what a server publishes from a terminal, including on a machine where you cannot install a GUI client. Connect unsecured first only if the server actually offers a None endpoint. |
| Ignition | The device connection settings carry mode and policy separately. If a connection was created against an older server configuration, its stored mode may no longer exist on the endpoint after a server upgrade. |
What it looks like in the log
OpenSecureChannel failed: BadSecurityModeRejected - requested MessageSecurityMode None
No endpoint found matching security policy Basic256Sha256 with mode Sign
The security mode does not meet the requirements set by the serverConfirm the fix
Confirm the mode and policy pair you configured appears together in a single EndpointDescription from GetEndpoints, then connect and complete a Read on that endpoint.
Stop it happening again
Configure clients by selecting an endpoint from the server's own list, pin SignAndEncrypt in production, and keep unsecured endpoints only on isolated lab servers.
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.