OPC UA 1.03 vs 1.05: Certification Ends 2026, Migration Guide

Last Updated: September 23, 2026

The OPC Foundation has now said it three quarters in a row, most recently in the September 2026 Compliance Corner: support for certifying OPC UA 1.03 products ends at the end of 2026, and vendors should be targeting a 1.05 version of the specification. For anyone weighing opc ua 1.03 vs 1.05, that turns a technical preference into a product-roadmap deadline with roughly fourteen weeks left on the clock. The gap is not cosmetic. Between the two lie the whole 1.04 generation (PubSub, a revised Part 12 for discovery and global services, alias names) and a 1.05 series that adds elliptic-curve secure channels, a rewritten JSON encoding, standalone role-based security, device onboarding and a much finer-grained profile structure that the new Compliance Test Tool (CTT) now tests against.

This guide explains exactly what changed at the wire and model level, what the certification cutoff does and does not mean, and how a vendor should sequence the migration so that a 1.05 certificate is realistic rather than aspirational.

What this covers: the verified certification timeline, the version-by-version deltas that matter to implementers, how the ECC handshake actually works, the 1.05.06 CTT and the free UACTT Lite tool, a step-by-step vendor migration plan, and the gotchas that stall real projects.

Context and Background

OPC UA is the IEC 62541-family architecture that most modern PLCs, DCS controllers, MES connectors and edge gateways use to expose typed, browsable, secured industrial data. If you need the fundamentals first — address space, services, secure channels, sessions — start with our complete technical guide to the OPC UA protocol. This post assumes that baseline and focuses on the version gap.

The specification is published as a numbered series of parts (OPC 10000-1 through OPC 10000-26 and beyond), each versioned independently. That matters, because “OPC UA 1.05” is not one document with one date. On the OPC Foundation’s online reference, Part 4 (Services) and Part 6 (Mappings) both currently sit at 1.05.07, published 2026-04-15, with their previous edition listed as 1.04 dated 2017-11-22. Part 7 (Profiles) is at 1.05.02 from 2022-11-01. Part 14 (PubSub) is at 1.05.06 from 2025-10-22. When a vendor says “we support 1.05”, the honest follow-up question is always: which parts, at which revision, against which profiles?

Certification is the other half of the story. An OPC UA product is certified by an accredited OPC Foundation test lab, which runs the Compliance Test Tool against the profiles and Conformance Units (CUs) the vendor claims, plus interoperability and robustness checks. The CTT evolves in lock-step with the specification. The 1.05 CTT arrived as a Beta in March 2026, which the Foundation described as its most extensive content expansion in several years, and by June 2026 the Foundation was telling vendors to use the released 1.05.06 CTT.

Demand for certificates is rising, not falling. The Foundation reports that end-user standards such as MDIS and O-PAS require certification, that OPC UA FX products will also require it, and, in its March and September 2026 Compliance Corners, that both its European and Chinese labs passed audits that extended their capabilities (including Ethernet-APL testing). Against that backdrop, keeping a 1.03 stack alive past 2026 means shipping into a market where buyers increasingly ask for a current certificate — and where you can no longer get a new one for that stack. The OPC Connect Compliance Corner for September 2026 is the primary source for the cutoff.

OPC UA 1.03 vs 1.05: What Actually Changed

In short: OPC UA 1.05 keeps the 1.03 client-server core but adds elliptic-curve and Diffie-Hellman secure channels, a new compact/verbose JSON encoding, PubSub, standalone role-based security (Part 18), device onboarding (Part 21), LogObject (Part 26), and finer-grained profiles. New certifications against 1.03 end with 2026.

Figure 1: The path from OPC UA 1.03 through the 1.04 editions to 1.05.07, the 1.05.06 CTT, and the end-2026 cutoff for 1.03 certification.

The figure reads top to bottom. The 1.04 editions (2017–2018 for the core parts) introduced PubSub and a revised Part 12. The Global Discovery Server itself predates 1.04: the Foundation’s .NET GDS sample implements it as specified in Part 12 Release 1.03. The 1.05 series began with 1.05.00 in 2021 and has kept revising: several parts carry 1.05.06 editions from October 2025 and 1.05.07 editions from April 2026. Brand-new parts arrived only in the 1.05 series. The testing tools followed, and the certification cutoff closes the loop.

The certification cutoff, precisely stated

The exact wording in the September 2026 Compliance Corner is that support for 1.03 certification will end at the end of 2026, and that vendors should be targeting a 1.05 version. The June and March 2026 editions say the same thing. Three consequences follow, and one does not.

First, any product you plan to certify in 2027 or later must be tested as a 1.05 implementation. Second, if you have a 1.03 product mid-certification, you are racing the lab calendar, not the spec. Lab slots before year-end are finite, and demand is up. Third, the choice of CTT version is no longer optional; the Foundation’s guidance is to use the released 1.05.06 CTT.

What does not follow: the notice says nothing about existing 1.03 certificates being revoked. It speaks only to support for certification. Do not tell customers their already-certified 1.03 product becomes uncertified on 1 January 2027 — the source does not say that. The likely implication, which the notices do not spell out, is that any product change requiring re-certification after 2026 will have to be tested as 1.05. Confirm the specifics for your certificate with the Foundation’s compliance team (compliance@opcfoundation.org).

Why 1.04 is a waypoint, not a destination

It is tempting to treat 1.04 as the cheap middle step. The certification notice does not support that reading: it says vendors should target a 1.05 version, not “anything newer than 1.03”. In practice, 1.04 functionality is a subset of what the 1.05 profiles and CTT test, so a 1.04-shaped product will be tested with 1.05 tooling anyway.

There is also a subtle stack-level trap. The OPC Foundation’s own UA-.NETStandard stack notes in its 1.04-to-1.05 migration guidance that a few features are still missing to fully comply with 1.05, while certification of 1.04 remains possible with the 1.05 release of that stack. That is a useful caution in both directions. A “1.05 SDK” does not automatically mean every 1.05 Conformance Unit you want is implemented, and the version string of your dependency is not your certification claim.

The change that most vendors underestimate: profiles and Conformance Units

The largest structural change is not a new crypto primitive. It is that, in 1.05, profiles were restructured with many new, finer-grained Conformance Units. The March 2026 Compliance Corner says this forced a major restructuring of CTT test cases. Profiles themselves are maintained in the online profile database at profiles.opcfoundation.org rather than as static text in Part 7.

The practical effect is that your 1.03 facet list does not map one-to-one onto the 1.05 facet list. A 1.03 “Standard UA Server” claim fans out into more, smaller CUs, and some behaviour that was loosely implied before is now an explicit CU with its own test script. Vendors who skip the mapping exercise discover it in the lab, which is the most expensive place to discover anything.

Version-by-Version Deltas That Matter to Implementers

This section walks through the changes by layer — security, encoding, information model, discovery and new parts — and ends with a comparison table.

Security: from RSA key transport to ephemeral key agreement

In 1.03, the secure channel handshake uses RSA for both signing and encryption. The client encrypts its nonce with the server’s public key, the server does the same in reverse, and both sides derive symmetric keys from the two nonces. That design has a well-known weakness: if a server’s long-lived private key is ever stolen, a recorded session can be decrypted after the fact, because the nonces were protected only by that key. There is no forward secrecy.

The 1.05.07 edition of Part 6 changes this in two ways. Clause 6.8 defines an Elliptic Curve Cryptography (ECC) handshake. Clause 6.9 defines Diffie-Hellman key agreement for RSA (RSA-DH), which the text says provides perfect forward secrecy for RSA-based profiles and is “generally preferred for modern systems”. Both use the same pattern: sign with the long-lived certificate, agree keys with throwaway ephemeral keys.

Figure 2: The ECC OpenSecureChannel handshake in OPC UA 1.05. Ephemeral public keys travel in ClientNonce and ServerNonce, and both sides derive identical symmetric keys with HKDF.

The mechanism, following Part 6 §6.8.1, runs like this. ECC can only sign, not encrypt, so the handshake cannot hide a nonce by encrypting it. Instead, the client generates a fresh key pair and sends the public half as the ClientNonce in a signed OpenSecureChannel request. The server verifies the signature, generates its own ephemeral pair, and returns its public half as the ServerNonce. Each side then combines its own ephemeral private key with the peer’s ephemeral public key using the Diffie-Hellman scheme from RFC 8422 to compute the same shared secret, without that secret ever crossing the wire.

The shared secret feeds HKDF, the HMAC-based key derivation function from RFC 5869. Part 6 spells out the salts: the server salt is the key length, the UTF-8 label “opcua-server”, the ServerNonce and the ClientNonce concatenated; the client salt mirrors it with “opcua-client” and the nonces reversed. An extract step produces a pseudorandom key, and an expand step produces the signing key, encrypting key and initialization vector at fixed offsets. Because the ephemeral keys are discarded after each channel negotiation, compromising the certificate’s private key later does not expose past traffic.

Several details in §6.8 carry implementation weight:

• Multiple certificates are mandatory for ECC. Each ECC security policy names one curve for the ephemeral keys and a list of curves allowed for the certificate. Applications that support ECC policies “shall support multiple Certificates”, because an RSA certificate and one or more ECC certificates must coexist.
• Smaller minimum buffers. Part 6 requires a transport buffer of at least 8,192 bytes when RSA asymmetric cryptography is used, and allows 1,024 bytes when ECC is used. That is a real gain for constrained field devices, where an 8 KB receive buffer per channel is not trivial.
• Encrypted user tokens need a new exchange. With RSA, a client encrypts its password token with the server’s certificate. With ECC, it cannot. So the server returns an EphemeralKey in the AdditionalHeader of the CreateSession and ActivateSession responses, keyed by an ECDHPolicyUri the client specifies. An invalid ECDHPolicyUri produces Bad_SecurityPolicyRejected.
• New policy flags. The 1.05.07 SecurityPolicy definition includes a LegacySequenceNumbers flag (1,024-based versus zero-based sequence-number rules), a SecureChannelEnhancements flag (channel-bound signatures in CreateSession and ActivateSession, and chained key derivation when a channel is renewed), and a CertificateThumbprintAlgorithm that defaults to SHA-1 when unspecified.

On the policy list itself, the security policy URIs implemented in the OPC Foundation’s .NET reference stack include None, Basic128Rsa15, Basic256, Aes128_Sha256_RsaOaep, Basic256Sha256, Aes256_Sha256_RsaPss, ECC_nistP256, ECC_nistP384, ECC_brainpoolP256r1, ECC_brainpoolP384r1, ECC_curve25519, ECC_curve448 and Https. Newer builds of that stack also document AES-GCM and ChaCha20-Poly1305 ECC variants and RSA_DH policies. Basic128Rsa15 and Basic256 rely on SHA-1 and are deprecated in the current profiles; the reference stack documents both as “deprecated but still supported for backward compatibility”, to be enabled only for legacy systems, and rejects SHA-1-signed certificates by default. A 1.03 product that still offers only those two policies plus None is precisely the product the cutoff targets.

Encoding: JSON grew up

A 1.03 product speaks OPC UA Binary, and XML where needed. JSON became important with PubSub and HTTPS mappings, and the 1.05 text replaced the earlier JSON forms. Part 6 now defines a CompactEncoding and a VerboseEncoding and states that they replace the ReversibleEncoding and NonReversibleEncoding, which are kept in Annex H as deprecated.

The differences are concrete. In CompactEncoding, a NULL field inside a JSON object is omitted; in VerboseEncoding, it is written as the JSON literal null. The EncodingMask for structures with optional fields, and the SwitchField for unions, appear only in the compact form. VerboseEncoding is defined only for JSON, and exists for consumers that lack schema information. For HTTPS, a body with media type application/json uses the JSON Compact encoding.

NodeIds changed shape too. In the 1.05 JSON encoding a NodeId is a JSON string using the text format from §5.1.12. NodeIds in namespace 0 use the bare identifier form, such as i=2258. All other NodeIds use the namespace-URI form, such as nsu=http://example.com/UA/Line1/;s=Press04.Temperature. Under the deprecated encodings a NodeId was a JSON object with IdType, Id and Namespace fields, and a decoder that supports both detects which is which by checking whether it received a string or an object.

That one change is enough to break a naive cloud consumer. A pipeline that parses {"Id": 42, "Namespace": 3} will fail on a string, and vice versa. Annex H states the expectation that publishers support all four encodings and subscribers decode Reversible, Compact and Verbose — which tells you the Foundation expects a long coexistence period.

Information model and access control

Role-based security exists as its own part in the 1.05 series. Part 18, Role-Based Security, has no 1.04 edition listed on the reference site; its current edition is 1.05.06 from October 2025. It defines the information model for roles and identity-mapping rules, and says servers should support the well-known roles defined in Part 3: Anonymous, AuthenticatedUser, Observer, Operator, Engineer, Supervisor, ConfigureAdmin, SecurityAdmin and TrustedApplication.

The mapping rules are what make it useful. An IdentityMappingRuleType selects identities by a criteriaType such as UserName, Thumbprint, X509Subject, GroupId, Application (the client’s ApplicationUri) or Role (a restriction carried in an access token). The Anonymous role is always granted to every session, AuthenticatedUser applies whenever valid user credentials are provided, and TrustedApplication applies to any client with a trusted application instance certificate. A server may not modify or delete those three. The effect is that “who can write this setpoint” becomes a model-level question, answerable by browsing, rather than hidden in vendor-specific configuration files. The March 2026 CTT release explicitly extended coverage of User Roles and Security.

This is also where OPC UA meets plant security architecture. Role mapping, certificate trust lists and per-policy endpoints are the controls you use to implement zone and conduit rules inside a controller or gateway. Our guide to IEC 62443 zones and conduits for industrial control systems shows how to map those OPC UA controls onto a 62443 security design.

Discovery, certificate management and alias names

Part 12, Discovery and Global Services, has a 1.04 edition dated 2018-02-07 and a current 1.05.07 edition from April 2026. The current text covers the Global Discovery Server, pull and push certificate management, KeyCredential management and AuthorizationServices for issuing access tokens.

Push management is the piece most 1.03 products lack. In the push model, a certificate manager connects to the server and pushes a new trust list or a new certificate through a standard ServerConfiguration interface. That is what makes fleet-wide certificate rotation possible without touching each device. The 1.05 CTT extended coverage of Discovery and GDS workflows, including AliasNames. Part 17, Alias Names, dates from a 1.04 edition in April 2020 and now sits at 1.05.07; it lets clients resolve human-meaningful tag aliases to NodeIds through a standard query.

Entirely new parts in the 1.05 series

Several parts have no 1.04 edition at all on the reference site. Part 18 Role-Based Security (1.05.06) is one. Part 20 File Transfer (1.05.06) is another. Part 21 Device Onboarding (1.05.04, October 2024) defines the device lifecycle and a Registrar that matches new devices against Tickets, so that a device can be authenticated and issued certificates automatically. Part 23 Common ReferenceTypes (1.05.02) and Part 26 LogObject (1.05.07, April 2026) round out the list. Part 26 defines a LogObject whose GetRecords method returns structured diagnostic log records.

Be careful with two parts that are often mislabelled: Part 19 (Dictionary Reference) and Part 22 (Base Network Model) both list 1.04 editions, from March 2020 and October 2021. They were extended in 1.05, but they are not “new in 1.05”.

Comparison table: 1.03 vs 1.04 vs 1.05

Dimension	OPC UA 1.03	OPC UA 1.04	OPC UA 1.05 (current: 1.05.07 for Parts 4, 6, 12, 17, 26)
New certifications	Support ends at end of 2026	Target 1.05 instead	The version vendors should target
Core services and mappings	Client-server, Binary and XML	Parts 4 and 6 editions dated 2017-11-22	Parts 4 and 6 at 1.05.07, 2026-04-15
Secure channel key exchange	RSA key transport, no forward secrecy	RSA; newer SHA-256 RSA policies in use	ECC (§6.8) and RSA-DH (§6.9) with ephemeral keys and HKDF
Deprecated policies	Basic128Rsa15 and Basic256 common	Still widely deployed	Deprecated in current profiles
Minimum transport buffer	8,192 bytes	8,192 bytes	1,024 bytes allowed with ECC
JSON	Pre-dates the PubSub JSON mapping	Earlier Reversible / NonReversible forms	Compact and Verbose; older forms deprecated in Annex H
PubSub	Not available	Part 14 1.04 (2018-02-06)	Part 14 at 1.05.06
Role-based security	Vendor-specific	Role concepts in base parts	Standalone Part 18 with well-known roles
Device onboarding	None	None	Part 21 (Registrar, Tickets)
Diagnostics logging	Vendor-specific	Vendor-specific	Part 26 LogObject
Profiles	Coarse facets	Coarse facets	Finer-grained CUs, online profile DB
Test tooling	Legacy CTT	1.04 CTT	CTT 1.05.06 plus free UACTT Lite

Read the 1.04 column as a waypoint. The rows where 1.05 differs from 1.04 — key agreement, JSON, roles, onboarding, profiles — are exactly where the new CTT concentrates its added coverage.

The New Test Tooling: CTT 1.05.06 and UACTT Lite

The Compliance Test Tool is the gate you must pass, so its contents are the most reliable guide to what “1.05 compliant” means in practice. The March 2026 Compliance Corner put numbers on the change: over 800 file updates integrated and more than 50 feature requests completed. Extended coverage includes the Base Information Model, User Roles and Security, LogObject features, Discovery and GDS workflows including AliasNames, PubSub UADP over UDP with flexible, periodic and dynamic layouts, and Address Space enhancements such as IRDI and URI dictionary entries, non-volatile properties, interfaces and event types.

The roadmap is equally informative. Further 2026 releases were announced for UDP UADP subscriber testing, MQTT JSON publisher support, and OPC UA FX enhancements for Connection Managers and Offline Engineering. The stated goal is 95% test-case coverage of core UA features by the end of 2026. TSN testing for initial features such as priority and time synchronisation was targeted for late 2026. If your product depends on any of those areas, check the current CTT release notes before planning a lab date. If you ship FX devices, the FX spec itself is moving too — see our breakdown of OPC UA FX v1.00.04 vs v1.00.03 and the Part 81–84 changes.

By June 2026 the guidance was unambiguous: use the released 1.05.06 CTT, which has restructured, more granular Conformance Units, broader test coverage and extended FX support.

UACTT Lite: free information-model validation

The June 2026 release of UACTT Lite is the most useful new tool for companion-specification vendors. It is free, and when the Foundation announced it in March (as an “Information Model Implementation Verifier”) it said the tool would need no configuration beyond the server connection details.

Figure 3: How UACTT Lite validates a server. It reads the namespace list, loads the released NodeSet for each namespace, and compares expected against actual address space.

The flow is a structured gap analysis. The tool connects, retrieves the server’s list of namespaces, and validates each namespace against the corresponding released NodeSet. The Foundation says it has defined more than 160 information models, so this covers a lot of ground. Validation goes beyond existence checks: it verifies that expected nodes are present, references are correct, attributes match, data types are compatible, and type definitions are applied consistently across instances. It checks both mandatory and optional nodes, and it reports each element as passed, failed, or not supported by design.

Two limits matter. First, UACTT Lite checks structure, not behaviour. If you implement OPC UA for Machinery, it confirms the types and instances are right; it does not test the functional behaviour the companion specification defines. Second, it complements the full CTT and does not replace it. Services, security, core functionality, client and PubSub interfaces all remain the full CTT’s job.

The practical move is to run UACTT Lite in CI for every build that touches a NodeSet. Model drift — a renamed browse name, a missing optional property you claimed, a mis-typed instance — is cheap to fix on the day it happens and expensive to fix after a lab report. For the modelling side, our OPC UA companion specification implementation tutorial walks through building NodeSets that pass this kind of validation. Note that the China lab was also verified in 2026 for using the new tool and for general information-model verification.

A Practical Vendor Migration Plan

This is the sequence that minimises lab surprises. It assumes an existing 1.03 server or embedded device, which is the most common case.

Figure 4: A vendor migration path from a 1.03 product to a 1.05 certificate, from profile inventory through UACTT Lite, full CTT self-test and IOP to the certification lab.

Step 1: Inventory what you actually claim

List every profile and facet on your current certificate or datasheet, every endpoint and security policy you expose, every user-token type you accept, and every companion-specification namespace you load. Include the undocumented ones — the debug endpoint with SecurityPolicy None that ships enabled is exactly what a lab or a customer’s penetration tester will find.

Then map each claim onto the current 1.05 profiles in the online profile database. Expect one old facet to become several CUs. Mark each CU as “implemented”, “implemented but untested”, “not implemented” or “will not claim”. The last category is legitimate: claiming fewer CUs is often the right call for a first 1.05 certificate.

Step 2: Choose the stack deliberately

Most vendors do not write their own stack, so the stack choice sets your ceiling. Ask your SDK supplier four questions in writing. Which 1.05 revision is the stack built against? Which ECC policies, and which curves, are implemented on your target OS and crypto library? Are RSA-DH and the SecureChannelEnhancements behaviour supported? Which Part 18 and Part 12 push-management features are implemented?

Crypto library support is not a formality. ECC in OPC UA needs raw ECDH and specific curves, and platform coverage varies. The .NET reference stack, for instance, documents platform-dependent ECC support. On embedded targets, check that your TLS or crypto library supports the curves you plan to offer, and that it has constant-time implementations for them. brainpool curves in particular are absent from some lightweight libraries.

Step 3: Rebuild the security surface

This is the heaviest step, and it is where a 1.03 product changes most.

1. Endpoints. Offer at least one SHA-256 RSA policy (Basic256Sha256 or Aes256_Sha256_RsaPss) and at least one ECC policy that matches your market. NIST P-256 is the widely supported starting point; add brainpool or Edwards-curve policies only when a customer or sector requirement asks for them and your crypto library supports them.
2. Deprecated policies. Disable Basic128Rsa15 and Basic256 by default. If a legacy client needs them, make enabling them an explicit, logged configuration change, never a factory default.
3. Certificates. Support multiple application instance certificates, one per key type, because ECC requires it. Store them in separate trust-list-aware groups.
4. Buffers. If you target constrained devices, test with the 1,024-byte ECC minimum. If your stack hard-codes 8,192 bytes, you are not getting the ECC benefit.
5. User tokens. Implement the ECC user-token path: return EphemeralKeys in the CreateSession and ActivateSession AdditionalHeader, handle the ECDHPolicyUri, and reject invalid URIs with Bad_SecurityPolicyRejected. Never accept the same ephemeral key twice after a successful ActivateSession.
6. Push management. Implement the Part 12 push interface so that trust lists and certificates can be updated remotely, and test a full certificate rotation without a device restart.

A worked sizing example shows why step 4 matters. Consider a field device with 20 KB of RAM budgeted for OPC UA transport and two concurrent secure channels, each needing a receive and a send buffer. At the 8,192-byte RSA minimum that is 32,768 bytes, which does not fit. At the 1,024-byte ECC minimum it is 4,096 bytes, leaving room for message processing. This is illustrative arithmetic, not a benchmark, but it is why ECC is the only realistic security option for some sensor-class devices.

Step 4: Adopt role-based security

Map your existing user model onto Part 18 roles. The usual pattern is Observer for read-only HMI and historian clients, Operator for setpoint and command writes, Engineer for configuration, and SecurityAdmin for trust-list and user administration. Keep Anonymous minimal, since it is granted to every session. Then set RolePermissions on the nodes that matter, and expose the role configuration through the standard model so that an integrator can audit it without your proprietary tool.

Step 5: Fix your encodings

If you publish PubSub JSON or expose HTTPS JSON, implement CompactEncoding and VerboseEncoding as defined in 1.05. Keep decoding the deprecated forms if you have deployed subscribers or brokers that emit them, and add a configuration switch for which encoding a publisher emits. Test NodeId round-trips with non-zero namespaces explicitly, because the string-versus-object switch is the most common interop break.

Step 6: Validate the model, then the whole product

Run UACTT Lite against every companion namespace you expose, and fix all failures that are not intentional “not supported” cases. Then run the full 1.05.06 CTT in-house against your CU claims. Treat the self-test as a release gate: no lab submission until the in-house run is clean.

Step 7: Interoperability, then the lab

Book an interoperability workshop if your timing allows. The European IOP runs 28 September to 2 October 2026 in Erlangen, hosted by Siemens, and was near capacity in September. The next North American IOP is the week of 19 April 2027, hosted by Beckhoff near Toronto. Multi-vendor testing catches the handshake and encoding mismatches that single-vendor CTT runs can miss. Then submit to an accredited lab with your 1.05 CU claims.

Timeline reality check

With the cutoff at the end of 2026, a vendor starting this plan in late September has two realistic options. The first is to finish an in-flight 1.03 certification before year-end if the product is genuinely ready and a lab slot exists. The second — the right answer for most — is to plan a 1.05 certification in 2027 and set customer expectations now. A half-migrated product rushed into a year-end lab slot tends to fail on security and CU mapping and costs more than a planned 2027 run.

Trade-offs, Gotchas, and What Goes Wrong

Most of the pain in an OPC UA 1.03 vs 1.05 migration is not in reading the specification. It is in the seams between stacks, crypto libraries, deployed clients and certification claims.

ECC interop is still the rough edge. ECC depends on curve support in both peers’ crypto libraries, on multiple-certificate handling, and on the new user-token exchange. The most common failure is a client and server that both claim ECC_nistP256 but disagree on certificate selection, or a client that tries to encrypt a password token the RSA way over an ECC channel. Keep a SHA-256 RSA policy available alongside ECC for the migration period, and log which policy each client negotiates so you can see adoption.

RSA-DH and SecureChannelEnhancements are recent text. Both appear in the 1.05.07 Part 6. Stacks lag the specification, and profile requirements for them may evolve. Do not market forward secrecy on RSA policies until your stack supports RSA-DH and a CTT release tests it.

Removing deprecated policies breaks old clients. Somewhere on your customer’s site there is a SCADA driver or historian collector that only speaks Basic256. Turning it off by default is correct; doing it silently in a firmware update is how you generate an outage and a support escalation. Ship release notes, a clear log message, and a documented opt-in.

Certificate lifecycle becomes an operational burden. Multiple certificates per application, shorter validity periods and push management are good security, but somebody must run them. Products without a working push interface end up with expired certificates in the field and operators toggling security off to restore connectivity. That outcome is worse than 1.03.

Profile mapping mistakes are the top lab failure mode. Claiming a CU you only partly implement fails in the lab; not claiming one a buyer needs fails in procurement. Do the mapping exercise with someone who has read the profile database, not the marketing datasheet.

Part 26 is explicitly provisional. The LogObject part carries an editor’s note that it has had limited implementation, and that later implementation and interoperability testing may cause breaking changes. Implement it if you need it, but isolate it behind an adapter.

JSON coexistence is messy. Cloud consumers built against the deprecated Reversible form will misparse Compact output, especially NodeIds and unions. Coordinate encoding changes with downstream data teams, not just with OPC UA clients.

“1.05 SDK” is not “1.05 certified”. The stack version, the spec revision, the CU claims and the certificate are four separate facts. Customers and sometimes internal sales teams conflate them. Say precisely which you mean.

Practical Recommendations

For vendors, the OPC UA 1.03 vs 1.05 question is now settled by the certification program; what remains is sequencing. Treat the end-2026 cutoff as a planning date rather than a panic date. The expensive failure is not missing 2026; it is shipping a 1.05 claim you cannot pass. Start with the profile inventory, because it drives everything else, and put UACTT Lite and the full CTT into your build pipeline so that compliance is a regression test rather than an annual event.

If you are an end user or system integrator, ask for 1.05 roadmaps in writing from every OPC UA supplier on your approved list. Ask which security policies are enabled by default, whether ECC and push certificate management are supported, and when a 1.05 certificate is expected. Use UACTT Lite yourself to check that purchased products expose the companion models they claim — the Foundation explicitly positions it for end users as well as developers.

If you run an OPC UA estate, plan for a multi-year mixed period. Keep 1.03 devices behind conduits with deprecated policies disabled wherever the clients allow it, and prioritise replacing devices that can only offer Basic128Rsa15 or Basic256.

Checklist:

• [ ] Inventory profiles, facets, endpoints, policies and namespaces on every product.
• [ ] Map claims to 1.05 Conformance Units in the online profile database.
• [ ] Confirm your stack’s 1.05 revision, ECC curves, RSA-DH and push-management support in writing.
• [ ] Offer SHA-256 RSA plus at least one ECC policy; disable Basic128Rsa15 and Basic256 by default.
• [ ] Implement multiple certificates, ECC user-token handling and Part 12 push management.
• [ ] Map users onto Part 18 roles and set RolePermissions.
• [ ] Implement JSON Compact and Verbose; test NodeId round-trips.
• [ ] Run UACTT Lite in CI, then the full 1.05.06 CTT as a release gate.
• [ ] Book an IOP and a lab slot for a 1.05 certification.

Frequently Asked Questions

When does OPC UA 1.03 certification end?

The OPC Foundation’s Compliance Corner, repeated in March, June and September 2026, states that support for certification of OPC UA 1.03 products ends at the end of 2026, and that vendors should be targeting a 1.05 version of OPC UA. In practice, a new certification from 2027 onward should be planned as a 1.05 implementation tested with the released 1.05.06 Compliance Test Tool. If you have a 1.03 certification in progress, confirm lab availability now, because demand for certification is increasing and year-end slots are limited.

Do existing OPC UA 1.03 certified products lose their certification in 2027?

The Foundation’s notices do not say that. They say support for 1.03 certification ends, which concerns new certifications, not existing certificates. Do not assume revocation, and do not tell customers it will happen. The practical consequence is different: any product change that requires re-certification after 2026 will most likely need to be tested as 1.05 (an inference, not a stated rule), and buyers increasingly ask for current certificates in procurement. For an actively developed product, the migration is effectively required either way; for a frozen legacy product, check your specific certificate terms with the Foundation.

What is the main difference between OPC UA 1.03 and 1.05?

Security and structure. OPC UA 1.05 adds ECC secure channels and RSA-DH key agreement with ephemeral keys, giving forward secrecy that 1.03’s RSA key transport lacks. It replaces the earlier JSON forms with Compact and Verbose encodings, and adds PubSub (from 1.04), standalone role-based security, device onboarding and LogObject. It also restructures profiles into finer-grained Conformance Units, which the 1.05 CTT tests. The core client-server service model is familiar, so migration is evolutionary, but the security surface changes substantially.

Which OPC UA security policies are deprecated?

Basic128Rsa15 and Basic256 are deprecated in the current profiles, mainly because they rely on SHA-1, and the OPC Foundation’s .NET reference stack flags both as deprecated. Current RSA options are Basic256Sha256, Aes128_Sha256_RsaOaep and Aes256_Sha256_RsaPss. The ECC family includes ECC_nistP256, ECC_nistP384, ECC_brainpoolP256r1, ECC_brainpoolP384r1, ECC_curve25519 and ECC_curve448. A migrating product should disable the deprecated pair by default and offer at least one SHA-256 RSA policy plus one ECC policy.

What is UACTT Lite and does it replace the CTT?

UACTT Lite is a free tool released by the OPC Foundation in June 2026 that validates a server’s information models. It reads the server’s namespaces, loads the released NodeSet for each, and compares nodes, references, attributes, data types and type definitions, both mandatory and optional. It reports results as passed, failed or not supported by design. It does not replace the full CTT, which still tests services, security, core functionality, and client and PubSub interfaces. Use it early and often, especially in CI.

What is the latest OPC UA specification version?

As of September 2026, the OPC Foundation reference site lists OPC UA 1.05.07, published 2026-04-15, for Parts 4 (Services), 6 (Mappings), 12 (Discovery and Global Services), 17 (Alias Names) and 26 (LogObject). Other parts are at earlier 1.05 revisions: Part 2 Security Model and Part 14 PubSub at 1.05.06 from October 2025, and Part 7 Profiles at 1.05.02 from November 2022. The first 1.05 release, 1.05.00, came out in 2021. Always check the individual part, because revisions are per part.

Further Reading

• OPC UA protocol: the complete technical guide — the address space, services and secure-channel fundamentals this migration builds on.
• OPC UA FX v1.00.04 vs v1.00.03: Part 81–84 changes — the field-level extension the 1.05 CTT is adding coverage for.
• OPC UA companion specification implementation tutorial — building NodeSets that pass UACTT Lite validation.
• IEC 62443 zones and conduits for industrial control systems — placing OPC UA security policies and roles inside a 62443 architecture.
• OPC Connect Compliance Corner, September 2026 — the primary source for the end-2026 1.03 certification cutoff.
• OPC Connect Compliance Corner, June 2026 — UACTT Lite and the 1.05.06 CTT guidance.
• OPC UA Online Reference: Part 6 Mappings — the ECC, RSA-DH and JSON encoding text at 1.05.07.
• RFC 5869: HMAC-based Extract-and-Expand Key Derivation Function — the key derivation used by the ECC handshake.

By Riju — about