OPC UA PLC Tutorial: Secure Server and Client Setup

An OPC UA PLC is a controller that runs an OPC UA server, client, or both. To commission it safely, define the PLC data contract, enable only the required role and profiles, discover the server’s endpoints, select a supported signed-and-encrypted security policy, verify both application certificates, map nodes by namespace URI and identifier, and subscribe to a read-only test value before enabling writes. Port 4840 is commonly used for opc.tcp, but it is not universal; use the endpoint URL configured by the server.

This OPC UA PLC tutorial follows the OPC Foundation’s current online specification set reviewed on August 29, 2026. Part 4, Services was version 1.05.07 when reviewed. Product menus, licences, supported profiles, resource limits, and certificate workflows differ, so the steps are expressed as protocol actions and acceptance checks rather than screenshots from one vendor.

What OPC UA is

OPC Unified Architecture is a platform-independent industrial interoperability architecture standardized as IEC 62541. It defines services, security, information modeling, discovery, client-server communication, and publish-subscribe mechanisms. Unlike OPC Classic, OPC UA does not depend on Windows DCOM.

An OPC UA application can expose more than raw values. The address space can represent objects, variables, methods, events, data types, engineering units, relationships, and vendor or industry information models.

The core objects in one connection

Object	Purpose	What to verify
Endpoint	Advertises transport, security policy, mode, and user-token options	URL, application URI, certificate, policy, mode
SecureChannel	Protects messages between the communication stacks	Signing/encryption matches the selected endpoint
Session	Associates application communication with an authenticated user	User identity, timeout, permissions
Node	An element in the server address space	Namespace, NodeId, class, attributes
DataValue	Value plus status and timestamps	Value, StatusCode, source/server time
Subscription	Server-side reporting context	Lifetime, keepalive, monitored items
MonitoredItem	Samples a node and reports changes or events	sampling, queue, discard policy, deadband

The OPC Foundation’s Part 4 Services specification defines these service sets. Part 6 Mappings defines concrete encodings and mappings, including UA Binary, XML, and JSON.

What an OPC UA PLC actually does

“OPC UA PLC,” “PLC OPC UA,” and “OPC UA for PLC” usually describe the same implementation task: move a deliberately defined controller data model across an OPC UA connection while preserving identity, type, status, time, authorization, and failure behavior. They do not describe a special wire protocol that bypasses the normal OPC UA service and security model.

A PLC can perform either application role. A server exposes an address space that clients browse, read, subscribe to, write, or call within the server’s supported profiles and permissions. A client initiates a connection to another server, such as a line controller, analyzer, edge application, or gateway. A controller may support both roles, but support is model-, firmware-, licence-, and resource-dependent.

PLC role	Connection direction	Typical use	Engineering proof required
Embedded OPC UA server	SCADA, historian, MES, or engineering client connects to PLC	Expose controller values, alarms, methods, and diagnostics	Supported server profile, endpoint, certificate trust, namespace, access rights, monitored-item capacity
OPC UA client in PLC	PLC connects to another OPC UA server	Consume analyzer values, coordinate controllers, or call a defined service	Supported client profile and instructions, server certificate trust, reconnect state machine, typed data handling
PLC as both	PLC accepts clients and initiates separate sessions	Local data service plus controller-to-controller or edge exchange	Separate trust and authorization boundaries, task load, session limits, deterministic failure response
External gateway server	Gateway reads a native PLC protocol and publishes OPC UA	Add OPC UA where the PLC lacks an embedded stack	Native-link freshness, tag mapping, gateway ownership, quality propagation, dual-sided diagnostics

The OPC Foundation and PLCopen OPC UA for programmable logic controllers companion specification defines an IEC 61131-3-oriented information model, data-type mappings, controller architecture, namespaces, and server/client facets. A product saying “OPC UA supported” does not prove that it implements that entire companion specification. Record the exact profiles, facets, companion specifications, limits, and certification claims supported by the selected product version.

OPC UA is not an automatic PLC memory window

Enabling a server does not mean every input, output, data block, tag, routine, or safety value should become remotely visible. Most controller engineering systems require an explicit exposure or symbolic-access decision. Build a published interface that has an owner and lifecycle. Separate telemetry, diagnostics, configuration, commands, and methods. Keep safety functions and internal implementation details outside that interface unless an approved design explicitly requires them.

Server support and client support are different claims

A PLC with an OPC UA server can answer client service requests; that does not prove it can initiate client sessions. A PLC with client function blocks can initiate supported requests; that does not prove its engineering station exposes an embedded server. Verify both the role and the required services. The OPC UA profiles specification explains how profiles and conformance units group supported functionality.

Client-server versus PubSub

Client-server

A client discovers endpoints, establishes a SecureChannel and Session, then browses, reads, writes, calls methods, or creates subscriptions. This is the common model for a SCADA server or historian consuming PLC data.

Publish-subscribe

Publishers send datasets that subscribers consume through a configured transport and message mapping. PubSub does not inherently mean “MQTT broker”; OPC UA defines multiple mappings and profiles. Check the exact transport, encoding, security, discovery, and metadata mechanism used by the products.

Use client-server when you need interactive browse/read/write services and a session-bound security context. Consider PubSub when the system requirement calls for one-to-many distribution or decoupled data exchange and all endpoints support the required profile.

Build a safe OPC UA lab

Use an isolated test network or local virtual machines. Do not begin with a production PLC or internet-exposed endpoint.

Lab components

• one OPC UA server or PLC simulator with a documented server;
• one independent OPC UA client;
• two separate application certificates;
• one read-only user and, if writes are required, one narrowly scoped test user;
• at least three test nodes: Boolean, integer or floating-point, and a communication/heartbeat value;
• packet capture only where policy permits it;
• a written rollback method.

You can practise the PLC sequence and tags first in PLC Simulation Software, then repeat the communication tests with an OPC UA-capable vendor simulator or server. The browser simulator is not presented as an OPC UA server; it is the logic-practice stage.

Step 1: Define the data contract

Before opening a client, define what the SCADA system needs.

Field	Example
Logical name	Tank01.LevelPV
Data type	Float
Engineering unit	%
Expected range	Project-defined
Direction	PLC to SCADA
Write allowed	No
Update requirement	Based on process dynamics
Bad-quality action	Gray display and suppress control
Source timestamp required	Yes
Owner	PLC application

Avoid using a display label as the only interface definition. Record the server namespace URI and NodeId after browsing. Namespace indexes can change between server configurations; namespace URIs provide the stable context needed to resolve nodes correctly.

Step 2: Discover endpoints

Enter the server’s configured discovery URL in the client. Compare the returned EndpointDescription records:

• endpoint URL;
• server application URI;
• server application certificate;
• message security mode;
• security policy URI;
• transport profile;
• user identity token policies.

The OPC UA specification permits multiple security configurations at the same physical URL. Treat them as distinct endpoints. Do not select the first row merely because it connects.

Pass condition

The selected endpoint matches the approved host, application URI, certificate identity, transport, security mode, security policy, and user-token type.

Step 3: Validate certificates

OPC UA clients and servers commonly use X.509 application-instance certificates. Validation must be mutual:

1. Inspect the server certificate presented to the client.
2. Confirm subject/application identity, application URI, host names or addresses, issuer, validity, key usage, and fingerprint according to site policy.
3. Move or approve the server certificate into the client’s trusted store only after verification.
4. Inspect and approve the client certificate on the server in the same way.
5. Confirm rejected, trusted, issuer, and revocation stores have restricted file permissions.

The OPC Foundation security model states that applications reject untrusted peers when security is enabled. Automatically trusting every rejected certificate defeats this boundary.

Pass condition

An approved client connects; an untrusted client is rejected. Replacing the expected certificate with another certificate causes a visible failure rather than silent trust.

Step 4: Select security policy and mode

For a normal protected deployment, prefer an endpoint that supports SignAndEncrypt and an organization-approved current security policy. The OPC Foundation’s practical security recommendations say SecurityMode None provides no protection and recommend at least Basic256Sha256 where technically possible. Your organization may require a stronger current profile.

Do not enable deprecated policies merely to make an old client connect. Record the interoperability gap and plan an upgrade or compensating design review.

Pass condition

The client confirms the negotiated mode and policy. A connection attempt using a prohibited policy or None is refused by configuration.

Step 5: Authenticate the user

Application certificates identify applications. User authentication identifies the person or service operating through the application. Configure:

• a read-only service identity for data acquisition;
• a separate identity for approved writes;
• no shared administrator account for routine clients;
• password, certificate, or other supported token handling according to policy;
• server-side authorization per node and operation.

Anonymous access should be limited to explicitly non-critical resources, if enabled at all. A user that can read a value should not automatically be allowed to write it, call methods, alter alarms, or browse sensitive diagnostics.

Pass condition

The read-only user can browse and read approved nodes but receives a bad authorization result on writes. The write user can change only the designated lab node.

Step 6: Browse and resolve nodes

Browse from the server’s Objects folder and inspect:

• browse name and display name;
• node class;
• NodeId;
• data type and value rank;
• access level and user access level;
• engineering-unit metadata where supplied;
• source/server timestamps and status;
• references to parent objects and types.

Do not hard-code a namespace index from a screenshot. Persist the namespace URI and identifier in the integration configuration, or use the product’s documented resolution mechanism.

Common NodeId forms

ns=2;s=Tank01.LevelPV
ns=3;i=1042
ns=4;g=01234567-89ab-cdef-0123-456789abcdef

These examples show string, numeric, and GUID identifiers. They do not imply that one form is superior.

Step 7: Read a DataValue correctly

An OPC UA read is not just a scalar. Capture:

• value;
• StatusCode;
• source timestamp;
• server timestamp, if provided.

Never display a stale or bad-quality value as trustworthy just because the numeric field still contains the last good sample. Define client behavior for Bad, Uncertain, missing timestamps, clock drift, and restored communication.

Pass condition

Removing the server connection changes quality visibly. The client does not present the last value as live, and recovery restores quality without an uncontrolled command.

Step 8: Create a subscription

Subscriptions reduce repeated polling and let the server report changes or events. Configure based on process requirements:

• publishing interval;
• subscription lifetime and keepalive;
• monitored-item sampling interval;
• queue size and discard policy;
• data-change trigger;
• absolute or percent deadband where supported;
• priority, if the implementation uses it.

There is no universal “best” interval. A tank level, machine interlock, vibration waveform, and energy total have different dynamics and consequences. Measure server load, network traffic, data loss, and operator need.

Pass condition

The client receives ordered changes under normal operation, detects a lost connection, identifies queue overflow or sequence gaps where exposed, and resynchronizes after reconnect.

Step 9: Add a controlled write

Use one non-safety lab value, such as a simulated setpoint, with a documented range. Before writing:

1. Confirm the user and node are approved for write.
2. Validate the engineering range and data type in both client and server.
3. Require appropriate operator confirmation.
4. Log requester, time, node, previous value, requested value, result, and quality.
5. Define what happens if the value changes concurrently.
6. Read back the result; do not assume a successful service response proves the process accepted it.

PLC logic must still validate commands. OPC UA authorization is not a replacement for permissives, interlocks, mode ownership, bounds, and safety functions.

A reproducible connection test

ID	Test	Expected result
UA-01	Connect with trusted application certificate and read-only user	SecureChannel and Session succeed
UA-02	Connect with an untrusted application certificate	Connection rejected and logged
UA-03	Request prohibited security mode	Endpoint unavailable or connection refused
UA-04	Browse approved namespace	Expected nodes and types resolve
UA-05	Read three data types	Correct value, status, and timestamps returned
UA-06	Write with read-only user	Authorization failure
UA-07	Write out-of-range value with write user	Client or PLC rejects according to requirement
UA-08	Stop server for longer than keepalive behavior	Bad quality and communication alarm
UA-09	Restart server	Controlled reconnect; no unsafe write replay
UA-10	Expire or revoke a lab certificate	Connection rejected according to trust policy
UA-11	Change namespace index while preserving URI	Client resolves nodes by approved mechanism
UA-12	Flood monitored values in test environment	Queue and loss behavior recorded

For every run record client/server product, version, endpoint, security mode/policy, certificate fingerprints, user-token type, namespace table, timestamps, and raw result. Redact private keys, passwords, and sensitive network details.

PLC integration workflow

The exact menu differs, but the engineering sequence is stable:

1. Enable the OPC UA server feature on a supported controller or gateway.
2. Define the exposed address-space items.
3. Separate read-only telemetry from writable commands.
4. Create or install the application certificate.
5. Configure trusted clients and issuer/revocation stores.
6. Enable only approved endpoint policies and user tokens.
7. Apply least-privilege node access.
8. Commission in an isolated network.
9. Run the negative tests above.
10. Archive the configuration, trust lists, certificate-expiry plan, and acceptance evidence.

Consult the exact controller manual. Some PLCs expose optimized data blocks, structures, alarms, methods, or companion specifications differently. Support may also depend on firmware, runtime licence, CPU resources, and vendor options.

Decide the PLC role before configuring tags

Write the connection sentence in active form: “Historian A is the OPC UA client; Packaging PLC B is the OPC UA server; the historian subscribes to the approved production namespace.” For a controller client, write: “Packaging PLC B is the OPC UA client; Analyzer C is the server; the PLC reads quality and measurement nodes and never writes.” This removes the common ambiguity where both engineering teams wait for the other application to connect.

The role decision also defines certificate exchange. Each OPC UA application instance has an identity. For a PLC server, the consuming client must validate the PLC application certificate and the PLC must validate the client application certificate when the protected endpoint requires it. For a PLC client, the same mutual application-trust requirement applies even though the controller initiates the transport connection.

PLC capability and capacity gate

Do not size an OPC UA PLC connection from tag count alone. A deployment consumes sessions, subscriptions, monitored items, sampling work, queues, publishing bandwidth, certificate storage, and controller CPU time. Structured values, events, methods, history, and diagnostics may rely on profiles that a basic embedded server does not implement.

Capability question	Evidence to collect	Reject or redesign when
Does this exact CPU and firmware support server, client, or both?	Current vendor manual, orderable licence, enabled feature in project	Evidence covers another CPU family, old firmware, or only a gateway
Which transport, security policies, modes, and user tokens are supported?	Endpoint discovery capture and product security documentation	Required signed-and-encrypted endpoint or approved token is unavailable
Which services and profiles are implemented?	Product profile/certification record and functional test	Required subscriptions, methods, events, data types, or discovery are absent
How many sessions, subscriptions, and monitored items are allowed?	Documented limits plus representative load test	Required peak plus recovery margin exceeds a limit
What sampling and publishing rates are sustainable?	PLC task/load trace, server diagnostics, client sequence evidence	Controller scan, communication task, queue, or network becomes unstable
Which PLC data types map without loss?	Typed test dataset and the PLC companion-spec mapping where supported	Sign, width, array bounds, time, string, structure, or quality semantics change
How are certificates renewed and revocation handled?	Trust-store procedure, owner, expiry alert, recovery test	Renewal requires unsafe trust-all behavior or lacks operational ownership
What changes after a project download or firmware update?	Regression test on a representative image	namespace, NodeIds, rights, certificates, or enabled features change silently

Use namespace URIs, not remembered indexes

An OPC UA NodeId contains a namespace index in common text notation, but that index is an entry in the server’s runtime namespace table. It can change when information models are installed or reordered. Store or resolve the namespace URI with the identifier through the product’s supported mechanism. A hard-coded ns=3 copied from a commissioning screenshot is not a stable cross-version interface contract.

Browse paths are useful for discovery but can also change when the information model is reorganized. Record both the semantic path people use and the stable resolution data the client uses. After a controller download, server replacement, or firmware change, rebrowse and compare the namespace array, node classes, data types, access rights, and expected model version before restoring writes.

Preserve value, quality, and time together

Treat the DataValue as the integration unit. The numeric or Boolean value alone is insufficient. A client must decide how it handles Good, Uncertain, and Bad status, source and server timestamps, absent timestamps, clock error, and the last value retained during a communication failure. A PLC client should not copy a stale last-good analyzer result into control logic without an age and quality gate.

For writes, distinguish successful OPC UA service processing from process acceptance. The PLC application still owns mode, permissive, range, sequence, source arbitration, timeout, and safe-state behavior. A successful write response does not prove a motor started or a setpoint was accepted by downstream logic.

Commissioning acceptance matrix for an OPC UA PLC

The most valuable tests deliberately violate one boundary at a time. Run them on an isolated or representative environment, preserve actual results and timestamps, and restore the initial state after each test.

Boundary	Positive test	Negative or recovery test	Evidence to retain
Endpoint identity	Connect to approved host and application URI	Present wrong host, URI, or unexpected certificate	Discovered endpoint list and certificate fingerprints
Application trust	Trusted client and PLC connect	Unknown or replaced application certificate is rejected	Client/server trust and rejection logs
User authorization	Read-only identity reads approved nodes	Same identity attempts write, method, or restricted browse	Operation-level StatusCode and audit event
Data contract	Read each approved scalar, array, structure, and unit	Change type or remove a test node in a versioned lab model	Namespace URI, identifier, type, rank, range, value, status, timestamps
Subscription	Receive changes at the required process rate	Break network, overflow a test queue, restart either application	Publishing/sampling settings, sequence gap, bad quality, reconnect trace
Write path	Approved user writes an in-range non-safety lab value	Out-of-range, wrong mode, stale request, and repeated request	Request, previous value, result, readback, PLC acceptance state
Resource capacity	Run representative peak sessions and monitored items	Add load to the documented or measured boundary	PLC cycle/load, communication diagnostics, queue and network metrics
Lifecycle	Renew a lab certificate before expiry	Expire or revoke a lab certificate and recover deliberately	Owner, procedure, expiry alert, trust update, rollback time
Project change	Download the approved project and reconnect	Change namespace ordering or access configuration in a test version	Before/after model diff and regression result

Acceptance result: pass, conditional pass, or fail

A pass means the expected positive behavior and the relevant rejection or recovery behavior were both observed. A conditional pass identifies a documented constraint with an owner and approved compensating control; it is not a hidden failure. A fail blocks production use of that path until the design, product selection, configuration, or test evidence changes.

Do not turn an interoperability failure into a security exception by enabling anonymous access, trusting every certificate, exposing an insecure endpoint, or restoring a deprecated security policy. If the two products lack a compatible approved profile, choose a supported gateway or upgrade path and test both sides of the new boundary.

Information modeling that survives maintenance

Flat tags are easy to start and hard to govern. Prefer an object model that separates asset identity, live values, commands, configuration, alarms, and diagnostics.

Objects
└── Area01
    └── Tank01
        ├── Measurements
        │   ├── LevelPV
        │   └── TemperaturePV
        ├── Commands
        │   └── FillSetpoint
        ├── Status
        │   ├── Mode
        │   └── CommHealthy
        └── Alarms
            ├── LevelHigh
            └── InstrumentFault

Use stable identifiers and documented semantic versioning. When a node is retired, define migration behavior rather than silently reusing the same identifier for a different meaning.

Security hardening checklist

• Keep OPC UA servers and clients off the public internet.
• Permit only required flows through firewalls and zones.
• Disable unused endpoints, transports, discovery services, and user tokens.
• Prohibit obsolete security policies.
• Use SignAndEncrypt where confidentiality and integrity are required.
• Verify certificates out of band before trust.
• Protect private keys and certificate stores.
• Manage expiry, renewal, revocation, backup, and owner.
• Apply least privilege to users and nodes.
• Log session, authentication, certificate, write, and configuration events.
• Synchronize time through the approved OT architecture.
• Test updates in a representative environment before deployment.
• Maintain recovery procedures for certificate and trust-store failure.

OPC UA provides security mechanisms; it does not design the entire OT security architecture. Use the NIST OT security guide for broader network, asset, access, monitoring, and lifecycle controls.

Troubleshooting by layer

Endpoint not found

Check DNS/IP resolution, route, firewall, configured port, server service, endpoint binding, and whether the returned endpoint URL is reachable from the client network.

BadCertificate...

Inspect trust state, application URI, host names, validity period, issuer chain, key usage, revocation status, clock, and file permissions. Do not solve it by “trust all.”

BadUserAccessDenied

Confirm user-token type, credentials, server role mapping, node user access level, operation, and whether the session identity differs from the application identity.

BadNodeIdUnknown

Rebrowse the server, compare namespace URIs, and check whether the server model or configuration changed. A changed namespace index is a common integration defect.

Values update slowly

Measure sampling, publishing, queues, deadbands, server load, network loss, client processing, and the source PLC update. Do not reduce every interval before identifying the bottleneck.

Reconnect causes stale or duplicate behavior

Inspect sequence handling, monitored-item recreation, republish support, server restart behavior, write queues, and client retry policy. Commands should be idempotent or explicitly protected against replay.

OPC UA versus OPC DA

Question	OPC UA	OPC DA
Platform model	Cross-platform architecture	Windows/DCOM-based Classic OPC
Built-in application security	Certificates, policies, modes, user tokens	Relies heavily on DCOM/Windows configuration
Information model	Typed nodes and references	Primarily data items
Firewall deployment	Configurable endpoint/transport design	DCOM can be operationally complex
New projects	Usually preferred when supported	Often maintained for legacy integration

For migration decisions, see OPC UA vs OPC DA.

Frequently asked questions

What is OPC UA on a PLC?

OPC UA on a PLC is an embedded or connected OPC UA application that lets a deliberately published controller information model be accessed through supported OPC UA services and security. The PLC may be a server, a client, or both. Confirm the exact CPU, firmware, licence, profiles, companion models, security options, and resource limits; the phrase “supports OPC UA” is not a complete interface specification.

Is a PLC normally the OPC UA server or client?

A PLC is commonly the server when SCADA, a historian, MES, or an engineering tool consumes controller data. It is a client when it initiates a session to another controller, analyzer, gateway, or server. Either is valid. Write down which application initiates the connection, which application owns the data, and which operations are permitted before configuration begins.

Does OPC UA always use port 4840?

No. It is a common default for opc.tcp, but servers may use another port or mapping. Use the endpoint configured and returned by the server.

Is OPC UA secure by default?

OPC UA defines strong security mechanisms, but a deployment can still enable insecure endpoints, trust certificates carelessly, use weak user controls, expose the service, or mishandle keys. Security depends on configuration and operations.

Should an OPC UA PLC use polling or subscriptions?

Use subscriptions for server-reported changes when supported and appropriate. Use reads for initial state, validation, or specific on-demand operations. Test load and failure behavior instead of choosing by slogan.

How do I map PLC tags to OPC UA nodes safely?

Publish an explicit interface, then record each node’s namespace URI, identifier, data type, value rank, engineering metadata, access level, status behavior, and owner. Do not depend on display labels or a remembered namespace index. Regression-test the mapping after project downloads, firmware changes, server replacement, or information-model changes.

Why does the OPC UA client report BadNodeIdUnknown after a PLC change?

The configured node may have been removed, renamed, retyped, assigned a different identifier, or resolved through a changed namespace index. Reconnect, read the current namespace array, rebrowse from the intended object, and compare it with the approved data contract. Do not fix the symptom by guessing another index.

Can an OPC UA client write directly to PLC outputs?

Even where a node is writable, remote writes should target a governed application command or setpoint rather than bypassing control ownership. The PLC logic must validate user role, mode, permissives, range, request freshness, sequence, and safe response. OPC UA authorization and a successful write response do not replace interlocks, safety functions, or process feedback.

How many OPC UA tags can a PLC handle?

There is no universal limit. The practical boundary depends on the exact controller and firmware, sessions, subscriptions, monitored items, sampling and publishing intervals, queue sizes, data types, events, network conditions, and controller task load. Start with documented limits, then run a representative peak-load and reconnect test with margin.

Can OPC UA replace PLC safety logic?

No. OPC UA communication and access control do not replace safety-rated logic, hardware, validation, or lifecycle requirements.

Sources, review scope, and limitations

• OPC UA Part 1: Overview and Concepts
• OPC UA Part 2: Security Model
• OPC UA Part 3: Address Space Model
• OPC UA Part 4: Services
• OPC UA Part 5: Information Model
• OPC UA Part 6: Mappings
• OPC UA Part 7: Profiles
• OPC UA Part 8: Data Access
• OPC UA Part 12: Discovery and Global Services
• OPC UA Part 14: PubSub
• OPC UA Part 18: Role-Based Security
• OPC UA for Programmable Logic Controllers based on IEC 61131-3
• OPC Foundation practical security recommendations
• NIST SP 800-82 Revision 3: Guide to Operational Technology Security
• Siemens S7-1500 Communication Function Manual

The OPC Foundation sources define the architecture and services; the PLC companion specification defines a shared IEC 61131-3 information-model boundary. They do not prove that a specific controller implements every service, profile, data type, or companion facet. The exact server and client manuals, product profile, certification record, firmware release notes, licence terms, and measured acceptance evidence govern a real installation. Product menus and limits in this guide are intentionally vendor-neutral and were not used as a substitute for model-specific documentation.