OPC UA Tutorial: Secure PLC-to-SCADA Lab Setup

To build a secure OPC UA connection, discover the server’s endpoints, select a supported signed-and-encrypted security policy, verify both application certificates, authenticate the user, browse the address space, and subscribe to a read-only test node before enabling writes. Port 4840 is commonly used for opc.tcp, but it is not a universal requirement; use the endpoint URL configured by the server.

This tutorial follows the OPC Foundation’s current online specification set reviewed on July 25, 2026. Part 4, Services was version 1.05.07 when reviewed. Product menus 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.

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.

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

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 I 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.

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.

Primary sources

• OPC UA Part 4: Services
• OPC UA Part 6: Mappings
• OPC UA Part 2: Security Model
• OPC Foundation practical security recommendations

These sources define the protocol. The server and client vendor manuals define which profiles and features a particular product implements.