BadSecurityPolicyRejected

BadPolicy mismatch

What you actually see

A client that connects fine to one server refuses to connect to another, and the failure happens immediately at channel open with no certificate dialog at all.

Why it happens

• The client requests a policy the server never offersA client pinned to Basic256Sha256 against a server offering only Aes256_Sha256_RsaPss and None has nothing to negotiate. The endpoint list is the authority; a policy hard-coded in client configuration is just a request.
• The server was hardened and deprecated policies were removedTurning off Basic128Rsa15 and Basic256 is standard hardening. Older clients and PLC-embedded clients that only implement the SHA-1 era policies then stop connecting, usually the morning after a security change window.
• The stack build does not implement the policySpec support and stack support are different statements. open62541 1.5 lists None, Basic128Rsa15, Basic256, Basic256Sha256 and Aes256Sha256RsaPss and no ECC policies at all, so an ECC policy negotiated on paper cannot be honoured by that build.
• The client connected to a discovery endpoint rather than the session endpointDiscovery endpoints commonly offer only None. A client that takes the discovery endpoint's URL and then demands a secure policy on it is asking for something that endpoint does not provide.
• Certificate key type incompatible with the requested policyAn RSA certificate cannot be used with an ECC policy and the reverse. Some servers report the mismatch as a rejected policy rather than as a certificate policy failure, which sends people looking in the wrong place.

How to fix it

In diagnostic order: work down, do not skip ahead.

1. List what the server actually offersCall GetEndpoints with security None against opc.tcp://host:4840 and print SecurityPolicyUri and SecurityMode for every endpoint. UaExpert shows the same list in its endpoint selection dialog when you add the server.
2. Pick a policy from that list, not from your configuration templateSet the client to a SecurityPolicyUri the server advertises, and remember the mode and the policy are independent: the same policy typically appears once with Sign and once with SignAndEncrypt.
3. Check the server side if the policy should be thereOn a server you control, confirm the policy is enabled in the endpoint configuration and that the server has a certificate whose key type matches. A policy enabled with no usable certificate is silently not offered.
4. Upgrade the weaker side rather than weakening the stronger oneIf an old client only speaks Basic128Rsa15, the correct answer is a client or firmware upgrade. Re-enabling deprecated SHA-1 era policies on the server to accommodate one device lowers the bar for every other connection to that server.
5. Avoid best-effort policy selectorsA selector that picks the best available can silently choose None when discovery returns no secure endpoint descriptors, and the documented guidance is that it is better to fail connecting. Pin the policy and mode explicitly in production configuration.

Where it shows up, by tool and stack

What it looks like in the log

OpenSecureChannel failed: BadSecurityPolicyRejected for http://opcfoundation.org/UA/SecurityPolicy#Basic256
Requested security policy is not supported by this endpoint
The security policy does not meet the requirements set by the server

Confirm the fix

Call GetEndpoints and confirm the policy you configured appears verbatim in the returned list, then connect on that exact policy and mode combination and complete a Read.

Stop it happening again

Standardise one modern policy across the estate, inventory which devices can actually speak it before hardening, and configure clients by selecting from GetEndpoints instead of hard-coding a policy URI.

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.