SCADA Protocol Security: Securing Modbus, DNP3, OPC UA, and IEC 60870-5-104

SCADA protocols carry the commands, measurements, alarms, and state changes that keep industrial processes operating. Their security therefore depends on more than whether traffic can cross a firewall. Defenders must understand which systems are allowed to communicate, which operations are expected, whether messages are authenticated and encrypted, and what physical consequences could follow from misuse.

Modbus, DNP3, OPC UA, and IEC 60870-5-104 have different security capabilities. Some were designed when trusted, isolated networks were the norm. Others include modern security features but remain vulnerable when certificates, identities, or security modes are configured incorrectly.

Effective SCADA protocol security combines protocol-aware architecture, restrictive communication policy, secure configuration, monitoring, and safe validation. The objective is not simply to identify insecure protocols. It is to determine whether an attacker could reach a critical device, issue a consequential operation, and bypass or evade the controls intended to stop that path.

Why SCADA protocols require specialized security

Traditional IT controls often focus on protecting data confidentiality and user accounts. SCADA security must also protect process integrity, equipment availability, deterministic communications, and human safety.

Several characteristics make industrial protocols difficult to secure:

• Legacy trust assumptions: Many protocols were designed without native authentication or encryption.
• Long asset lifecycles: Controllers, protection devices, gateways, and field equipment may remain operational for decades.
• Operational sensitivity: Aggressive scanning or malformed requests can overload or destabilize older devices.
• Protocol translation: Gateways can connect security domains while obscuring the original source or changing available protections.
• Permissive communication: Broad network rules may allow more devices, functions, or directions than the process requires.
• Limited context: A syntactically valid command may still be unauthorized or dangerous for the current process state.

This means a protocol cannot be judged by its port number alone. Teams need to understand endpoints, message direction, function or service, expected frequency, security mode, and operational purpose.

For a broader treatment of architecture and control-system risk, see the [ICS and SCADA security guide](https://frenos.io/resources/scada/ics-scada).

SCADA protocol security comparison

Security capabilities also depend on device model, firmware, implementation quality, and interoperability requirements. A standard may define a protection that deployed equipment does not support or that operators have not enabled.

How to secure Modbus

Classic Modbus TCP provides no native mechanism for authenticating a client, verifying that a command came from an approved operator, or protecting message confidentiality. If a host can reach a Modbus device, the protocol itself may not prevent that host from reading data or attempting write operations.

Priority controls include:

1. Restrict communication pairs. Permit Modbus only between explicitly approved clients, servers, gateways, and engineering systems.
2. Constrain allowed functions. Where industrial firewalls support deep packet inspection, allow only the function codes required by the process. Read-only relationships should not permit register or coil writes.
3. Block unnecessary broadcast and diagnostic behavior. Confirm whether devices need these operations before allowing them.
4. Separate control functions by zone. Do not treat every device using TCP port 502 as part of one trusted network.
5. Use Modbus Security where supported. Modbus Security uses TLS and X.509 certificates to provide stronger authentication and message protection. Adoption must account for device support, certificate operations, latency, and failover requirements.
6. Monitor for behavioral deviations. Alert on new communication pairs, unexpected function codes, repeated exceptions, unusual write volume, and changes outside approved operational patterns.

Encrypting Modbus does not replace restrictive authorization. TLS can protect a connection while still allowing an overprivileged or compromised endpoint to issue harmful requests.

How to secure DNP3

DNP3 is widely used for telemetry and supervisory control. Its operational features include event reporting, time synchronization, unsolicited responses, and control operations. Defenders must distinguish normal protocol behavior from actions that could alter process state.

Recommended safeguards include:

• Allow traffic only between expected masters, outstations, and approved intermediaries.
• Baseline object groups, variations, control functions, and traffic direction.
• Monitor for unexpected operate commands, configuration changes, time changes, cold or warm restarts, and abnormal unsolicited-response behavior.
• Apply DNP3 Secure Authentication when supported, especially for critical operations.
• Protect cryptographic keys and define procedures for enrollment, rotation, recovery, and device replacement.
• Use additional channel protection when confidentiality is required, because Secure Authentication is focused on authenticating messages and users rather than encrypting every exchange.

Teams should verify the exact Secure Authentication version and feature set implemented by each product. Stating that a device “supports secure DNP3” is not enough to prove that critical commands are authenticated in the deployed configuration.

How to secure OPC UA

OPC UA has a substantially richer security model than many earlier industrial protocols. It supports application authentication, user authentication, message signing, encryption, and granular authorization. Most OPC UA weaknesses arise when these capabilities are disabled, inconsistently deployed, or poorly governed.

A secure baseline should include:

1. Disable insecure security policies and message modes. Avoid configurations that permit unsigned or unencrypted sessions unless a documented operational exception requires them.
2. Manage application certificates. Validate trust lists, certificate chains, expiration, revocation, and replacement procedures.
3. Separate application and user identity. A trusted application certificate should not automatically grant every user broad access.
4. Enforce least privilege. Restrict browsing, reading, writing, method calls, subscriptions, and administrative functions by role and operational need.
5. Limit exposed endpoints. Publish only the OPC UA endpoints and profiles required for approved workflows.
6. Monitor session and service activity. Look for failed certificate validation, rejected sessions, endpoint discovery anomalies, unexpected method calls, new clients, and high-risk writes.

Certificate validation must also be tested during renewal and failure scenarios. A system may appear secure until an expired certificate causes operators to weaken verification or disable encryption to restore service.

How to secure IEC 60870-5-104

IEC 60870-5-104, often shortened to IEC 104, transports telecontrol messages over TCP/IP. The base protocol does not provide strong cryptographic authentication or confidentiality. Security therefore depends heavily on architecture, enforcement points, and the protections defined by the IEC 62351 family.

Key controls include:

• Restrict IEC 104 communication to approved controlling and controlled stations.
• Enforce expected traffic direction and operational roles.
• Monitor type identifications, causes of transmission, common addresses, information object addresses, sequence behavior, and control operations.
• Detect unexpected commands, spontaneous-data anomalies, test commands, time synchronization changes, and repeated connection resets.
• Evaluate IEC 62351 protections supported by each endpoint, gateway, and management process.
• Apply TLS-based protection where it is technically supported and operationally validated.
• Test certificate expiration, trust failure, redundancy, and recovery behavior before enforcing changes in production.

Encryption alone cannot determine whether a command is operationally appropriate. Protocol-aware allowlisting and process context remain necessary even when traffic is protected in transit.

A protocol-aware SCADA security framework

Organizations can apply a common workflow across all four protocols.

1. Inventory communication relationships

Document the communicating assets, protocol versions, ports, client and server roles, message direction, security settings, and operational owner. Include serial-to-IP and protocol-conversion gateways because these devices may terminate one security model and begin another.

2. Map communications to process requirements

For every relationship, identify which reads, writes, commands, methods, or object types are necessary. A required network connection does not imply that every protocol capability should be available.

3. Define zones and conduits

Place assets with similar function, criticality, and trust requirements into defensible zones. Treat each approved communication flow as a controlled conduit with an explicit business and operational purpose. The Frenos [OT network segmentation guide](https://frenos.io/resource/ot-network-segmentation-guide-ics-scada) explains how to apply this structure in ICS and SCADA environments.

4. Harden protocol configurations

Enable supported authentication, signing, and encryption. Remove obsolete security policies, default trust relationships, unused services, and excessive permissions. Document exceptions where legacy equipment cannot support the preferred control.

5. Monitor commands, not just connections

Network monitoring should identify who communicated, what operation was attempted, which asset or process point was affected, and whether that behavior matched the baseline. Port-level visibility alone cannot distinguish a routine read from a process-changing write.

6. Prioritize compensating controls

When devices cannot support modern cryptography, use restrictive firewall policy, protocol-aware inspection, application allowlisting where appropriate, passive monitoring, change control, and strong zone boundaries. Compensating controls should be tied to a specific exposure rather than treated as generic protection.

7. Validate complete attack paths safely

A vulnerability list does not prove that an adversary can reach a controller or issue a consequential protocol operation. Conversely, a device without a known software vulnerability may still be exposed through excessive trust and valid but unauthorized protocol use.

Frenos creates cyber digital twins from available OT data and uses simulated adversary techniques to evaluate attack paths without testing live production systems. This allows teams to assess questions such as:

• Can an unapproved source reach a Modbus write function?
• Can a path reach a DNP3 outstation capable of accepting critical operations?
• Could an overprivileged OPC UA identity call a sensitive method?
• Can an IEC 104 command traverse multiple control boundaries to a critical station?
• Which segmentation, authentication, or monitoring change breaks the path most effectively?

This approach complements asset visibility, vulnerability management, and monitoring. It provides empirical evidence for prioritization rather than replacing existing controls or engineering judgment. Learn more about [safe SCADA testing with digital twins](https://frenos.io/resources/scada/visibility-attack-paths).

SCADA protocol security checklist

Use this checklist when reviewing an industrial protocol deployment:

• Identify every approved client, server, master, outstation, gateway, and control station.
• Record protocol versions and supported security capabilities.
• Map required functions, services, object types, and traffic direction.
• Deny communication that lacks a documented process requirement.
• Enable signing, authentication, and encryption where supported and validated.
• Apply least privilege to protocol operations, not only network connections.
• Monitor new peers, sensitive commands, authentication failures, and configuration changes.
• Define compensating controls for legacy or unsupported equipment.
• Test certificate and key lifecycle procedures.
• Validate whether attack paths can reach critical protocol functions without touching production.
• Reassess after architecture, firewall, firmware, or process changes.

Prove which protocol exposures create real risk

SCADA protocol security should produce more than a list of open ports and unsupported features. Leaders and engineers need evidence showing which communication paths can reach critical assets, which controls stop them, and which remediation will reduce operational risk most effectively.

Request a Frenos demo to see attack paths in your OT environment and assess defenses without production impact.