When you connect an OPC UA client to a server, one of the choices you make is the security policy - a name like Basic256Sha256 or None. That name is not decoration; it is shorthand for a specific bundle of cryptographic algorithms the two ends will use to sign, encrypt, and exchange keys. This guide explains what a security policy actually specifies, why Basic256Sha256 and Aes256Sha256RsaPss are the current recommendations while older policies like Basic128Rsa15 are deprecated, what the None policy really means, and how a client and server settle on a common policy when they connect.
Security Policy Basic256Sha256 in one line: An OPC UA security policy is a named set of cryptographic algorithms - covering message signing, encryption, and key exchange - that a client and server agree to use for a secure channel. Basic256Sha256, for example, specifies SHA-256 for signing, AES-256 for encryption, and RSA for key exchange. It is a current, recommended policy, whereas older policies such as Basic128Rsa15 are deprecated for using weaker algorithms, and the None policy means no cryptographic protection at all.
A security policy in OPC UA is best understood as a cipher suite: a single name that stands for a coordinated collection of algorithm choices. Rather than making an operator pick a hash function, a symmetric cipher, a signature scheme, and a key-exchange method independently - and risk choosing an incompatible or insecure combination - OPC UA groups sensible, tested combinations under one identifier. Selecting Basic256Sha256 selects the whole bundle at once, and both ends of the connection then know exactly which algorithms to use for every cryptographic operation on that channel.
The name itself is a rough guide to the contents. In Basic256Sha256, the Sha256 part indicates SHA-256 as the hashing algorithm used when signing messages, and the 256 relates to a 256-bit symmetric key size for AES encryption of message content. RSA is used for the asymmetric operations - the initial key exchange and certificate-based authentication that establish the secure channel before the faster symmetric encryption takes over for ongoing traffic. A newer policy, Aes256Sha256RsaPss, uses the RSA-PSS signature padding scheme, which is a more modern and robust construction than the padding used in older policies.
It is important to separate what the policy decides from what it does not. The security policy chooses the algorithms - the how of the cryptography. It does not by itself decide whether those algorithms are applied for integrity only or for integrity plus confidentiality; that is a separate setting called the message security mode. A channel can use a strong policy like Basic256Sha256 while still only signing messages rather than encrypting them, because policy and mode are orthogonal choices that combine to define the channel's protection.
Cryptography ages. Algorithms that were considered strong when OPC UA was first specified have since been weakened by advances in computing and cryptanalysis, and the set of recommended policies has moved on accordingly. Basic256Sha256 became the baseline recommended policy because it pairs AES-256 encryption with SHA-256 signing, both of which remain well-regarded. Aes256Sha256RsaPss goes a step further with modern RSA-PSS signatures and is the direction newer deployments are encouraged toward. These are the policies a security-conscious deployment should expect to use today.
Older policies have been deprecated precisely because their building blocks no longer meet current expectations. Basic128Rsa15, for instance, uses a smaller 128-bit key and an older RSA padding scheme and relies on SHA-1-era constructions, and Basic256 without the Sha256 suffix similarly leans on the older SHA-1 hash. SHA-1 in particular is no longer considered collision-resistant enough for security-critical signing, which is a large part of why any policy resting on it has fallen out of favor. Deprecated does not always mean immediately unusable - some servers still offer these policies for backward compatibility - but new connections should avoid them.
The practical guidance follows from this: prefer the current policies, treat the deprecated ones as legacy support only, and be suspicious of any deployment that still relies on SHA-1-based policies for anything sensitive. Because a server can advertise several policies at once, an operator sometimes has to look carefully to confirm the client is actually negotiating a strong one rather than silently falling back to a weaker option the server also happens to support. Choosing the policy deliberately, rather than accepting whatever connects, is part of securing an OPC UA link properly.
The None policy is exactly what it sounds like: no cryptographic protection. Messages are neither signed nor encrypted, so there is no integrity checking, no confidentiality, and no certificate-based assurance of who is on the other end. It exists because there are situations - early bench testing, a fully isolated and trusted network segment, or a discovery step before a secure channel is set up - where the overhead and certificate management of a secure policy are not warranted. But because None offers no protection whatsoever, it should never be used for real traffic on any network that is not completely trusted, and treating it as acceptable in production is a common and serious mistake.
Negotiation of the policy happens at connect time and is driven by what the server offers. An OPC UA server exposes one or more endpoints, and each endpoint advertises a supported security policy together with a message security mode. When a client wants to connect, it typically discovers the server's endpoints, sees the list of policy-and-mode combinations on offer, and selects one it supports and is configured to require. The secure channel is then established using that chosen policy. If the client insists on a strong policy the server does not offer, or the server requires one the client cannot do, the connection cannot be established - there has to be a common, mutually acceptable policy for the link to form.
For a cloud SCADA platform acting as an OPC UA client against field or plant servers, this negotiation is where security posture is set in practice. A platform such as Merobix connecting to an OPC UA server would be configured to require a current policy like Basic256Sha256 and to refuse None on any link carrying real data, so the choice is enforced rather than left to whatever the server defaults to. Getting this right at connect time - insisting on a strong, non-deprecated policy and rejecting the unprotected None option outside of controlled testing - is one of the foundational steps in making an OPC UA integration genuinely secure rather than merely encrypted-looking.
It specifies a bundle of cryptographic algorithms for a secure channel: SHA-256 for message signing, AES with a 256-bit key for encryption, and RSA for the asymmetric key exchange and certificate handling that establish the channel. Selecting it chooses the whole set at once. It is a current, recommended policy, in contrast to older policies that rely on weaker algorithms.
Because its building blocks no longer meet modern security expectations. It uses a smaller 128-bit key, an older RSA padding scheme, and SHA-1-era constructions, and SHA-1 is no longer considered collision-resistant enough for security-critical signing. Newer deployments are steered toward Basic256Sha256 or Aes256Sha256RsaPss, and deprecated policies should be treated as legacy backward-compatibility support only.
Only on a fully isolated, trusted network or for early bench testing and discovery, never for real traffic on an untrusted network. The None policy applies no signing and no encryption, so it provides no integrity, no confidentiality, and no assurance of who is on the other end. Using it in production is a common and serious mistake; production links should require a current secure policy instead.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.