IEC 62541 · Core

Part 2: Security Model

Document number	OPC 10000-2
IEC designation	IEC 62541-2
Colloquially	Part 2
Group	Core

What it defines

A threat model and a set of security objectives, then the mechanisms that meet them. The central idea is that two independent identities are checked on every connection: the application identity, proved by an X.509 application instance certificate exchanged during OpenSecureChannel, and the user identity, proved during ActivateSession by an identity token. Confidentiality and integrity come from the secure channel, described here in terms of what it must guarantee and in Part 6 in terms of bytes on the wire.

Security policies and message security modes

A security policy names a suite of algorithms - signature, encryption, key derivation, minimum key size. A message security mode says how much of that suite is applied: None, Sign, or SignAndEncrypt. They are orthogonal, and both appear separately in every EndpointDescription a server returns from GetEndpoints. The current RSA policies are Basic256Sha256, Aes128_Sha256_RsaOaep and Aes256_Sha256_RsaPss. Basic256 and Basic128Rsa15 are the SHA-1-era policies and exist for legacy interop only; modern stacks reject SHA-1-signed certificates by default. Elliptic-curve policies are specified but implementation coverage across stacks is still uneven.

Certificates as identity, not as decoration

An application instance certificate is X.509v3 and must carry the application's ApplicationUri as a URI entry in its SubjectAltName, alongside the DNS names or IP addresses of its endpoints. KeyUsage must match the key type, and RSA keys must be at least 2048 bits. Those SubjectAltName contents are checked, which is why a certificate that looks perfectly valid to a browser is rejected by an OPC UA peer. The concrete stores and folder layout that hold these certificates are Part 12 territory.

Users, roles and audit

Part 2 enumerates the user identity token types - Anonymous, UserName with password, X.509 user certificate, and IssuedToken for JWT, OAuth2 and OIDC flows - and requires that credentials be protected by the active security policy. It also establishes auditability as a security objective; the concrete audit event types live in Part 4 and the authorisation model built on top of user identity is Part 18.

What it defines

Concept	What it is
Application instance certificate	The per-installation X.509v3 identity of a client or server. Its SubjectAltName must contain the ApplicationUri and the endpoint hostnames, and mismatches are the single largest source of connection failures.
MessageSecurityMode	None, Sign or SignAndEncrypt. Sign gives integrity and authenticity; SignAndEncrypt adds confidentiality. None gives neither and should never reach production on a routable network.
Security policy	The named algorithm suite, identified by a URI in the EndpointDescription. Current choices are Basic256Sha256, Aes128_Sha256_RsaOaep and Aes256_Sha256_RsaPss.
Deprecated policies	Basic256 and Basic128Rsa15 use SHA-1 and RSA PKCS#1 v1.5. Enable them only to talk to equipment that cannot be upgraded, and document why.
User identity token types	Anonymous, UserName with password, X.509 user certificate and IssuedToken. A server advertises which it accepts per endpoint in its UserTokenPolicies.
Certificate validation requirements	Trust check, chain build, validity dates, key usage, key size, signature strength, then hostname and ApplicationUri checks against SubjectAltName. Some failures are suppressible by an application callback; most are not.
Nonces and key derivation	Client and server nonces exchanged during channel and session establishment derive the symmetric keys and bind the session to the channel. A reused or short nonce is a protocol violation, reported as BadNonceInvalid.
Auditability	Security-relevant service calls are expected to be auditable. Part 2 sets the requirement; Part 4 defines the AuditEventType hierarchy that carries it.
Trust model	Trust is per-application and mutual. A client trusting a server does not make the server trust the client, which is why one-sided certificate installation leaves you half-connected.

Do you need to read it?

Anyone who has to get a connection working through a security policy rather than around it, and anyone writing the security section of an integration document. Commissioning engineers need the SubjectAltName rules and the mode-versus-policy distinction. Security architects need this part to explain to an IT function why OPC UA is not just TLS with extra steps.

Traps that trace back to this part

• MessageSecurityMode and SecurityPolicy are independent, and clients routinely confuse them. An endpoint can offer Basic256Sha256 with mode Sign and another with SignAndEncrypt; selecting the policy does not select the mode. Read both fields from the EndpointDescription and choose both explicitly.
• UserName and password are protected by the active security policy, so a username/password login to an endpoint running MessageSecurityMode.None puts the password on the wire in the clear. Any endpoint that accepts credentials must run Sign or SignAndEncrypt.
• Avoid client-side selectors that mean pick the best available security. If discovery returns no secure endpoint - because a server is misconfigured or a firewall mangled the response - best can resolve to None and the connection silently succeeds without security. Fail closed instead.
• Self-signed application certificates are convenient and give almost no trust value. Two peers each accepting whatever the other presents is not authentication; it is auto-accept with extra files. Move to a CA-issued application certificate before production.

Last verified 7 September 2026 against OPC UA 1.05.07. The specification parts themselves are published by the OPC Foundation. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.