iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Emerging industrial protocols can put operational technology (OT) at risk when they add communication paths or functions that a site has not secured, monitored, or accounted for in its safety and reliability plans. The risk is not that a protocol is new by itself: it depends on the protocol’s security features, how those features are enabled, and how the system is deployed.
Why industrial protocol changes matter to OT
OT comprises programmable systems and devices that interact with the physical environment, or manage devices that do. In a plant, building, utility, or other industrial setting, communications can carry measurements, status, and commands that affect physical processes. A change to how those systems communicate can therefore affect more than data confidentiality: it can also affect process integrity, availability, reliability, and safety.
IEC’s IEC PAS 62443-1-6:2025 describes how the Industrial Internet of Things (IIoT) can introduce new communication channels and a new organization of functions. Those changes can create additional paths between devices, applications, operators, service providers, and business systems. Each path brings security decisions about which systems may communicate, what they may do, and how to detect or contain misuse.
How a protocol can contribute to risk
A protocol defines how systems exchange information, but a protocol name alone does not reveal the security of a particular installation. A 2026 joint paper from FieldComm Group, ODVA, OPC Foundation, and PROFIBUS & PROFINET International notes that many deployments lack built-in authentication, authorization, integrity, or confidentiality mechanisms. It also describes enhanced security profiles in some Ethernet-based protocols, while emphasizing that the practical risk depends on the implementation and operating environment.
#1 Best Overall
- Industrial Cybersecurity: Efficiently monitor the cybersecurity posture of your ICS environment, 2nd Edition
- ABIS BOOK
- Packt Publishing
- Authentication: Can the receiving system verify which device or application sent a message?
- Authorization: Can the installation limit what an authenticated device or application is allowed to do?
- Integrity: Can a recipient detect whether information was altered in transit?
- Confidentiality: Can the exchange be protected from unauthorized reading where that matters?
If protections are absent or disabled, a deployment may rely more heavily on network isolation, tightly controlled access, monitoring, and other compensating controls. That does not establish that every deployment using the protocol is vulnerable, or that an emerging protocol has a known flaw. It means the site must evaluate the protections and exposure of its actual implementation.
How to assess a protocol in its actual deployment
Assess the whole communication path, not just a protocol’s advertised capabilities. A security profile that exists in a specification will not protect a site if the deployed devices do not support it, it is not enabled, or connections bypass the intended architecture.
- Inventory the systems and flows. Record the devices, applications, protocol versions or profiles where known, communication endpoints, purpose of each connection, and the process or service it supports. Include connections to IT networks, remote access, vendors, and maintenance systems.
- Assess the operational risk. Determine what could happen if a message were read, changed, forged, delayed, or blocked. Consider the consequences for the process, recovery needs, and safety, as well as the likelihood of exposure in the site’s network and operating conditions.
- Verify the implementation’s security features. Check documentation and configuration for supported and enabled authentication, authorization, integrity, and confidentiality protections. Identify exceptions, legacy endpoints, and connections that use different settings.
- Check interoperability and operational constraints. Confirm that proposed controls work with the connected devices and applications, and assess any effect on performance, reliability, maintenance, and safety. A security change that disrupts a critical process can create its own operational risk.
- Document the result and required controls. Record what is protected, what remains exposed, who owns each action, and how exceptions will be reviewed. Use the assessment to decide whether to retain, restrict, redesign, or migrate a connection.
How to reduce exposure in an OT network
Network design can reduce the consequences of missing protocol protections, but it should not be treated as a substitute for assessing the protocol and implementation. The UK National Cyber Security Centre (NCSC) advises restricting industrial control protocols such as Modbus, OPC DA, and EtherNet/IP to isolated OT network segments. For exchanges between OT and IT, it recommends using a demilitarized zone (DMZ) and secure, standardized protocols such as OPC UA over TLS, MQTT over TLS, or HTTPS.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11- Keep industrial control traffic within intended OT segments. Limit routes and access to the systems that need to communicate; do not expose control protocols to broader networks by default.
- Broker OT/IT exchanges through a DMZ. Define which data must cross the boundary and use controlled, monitored pathways rather than direct, unrestricted connections.
- Use secure protocol options where they fit the deployment. Verify that the selected option is supported, configured, and compatible with the actual endpoints and operational needs.
- Make insecure protocols exceptions, not assumptions. Where a legacy or constrained system cannot use a secure variant, document compensating controls and the reason for the exception.
- Plan migration deliberately. The NCSC states: “Where your organisation has insecure industrial protocols in use, you should establish a roadmap for migration to secure industrial protocol variants.” A roadmap should account for equipment compatibility, testing, outage windows, and safety review rather than treating replacement as a simple network change.
Why protocol-level protection is only one layer
Security features in a protocol do not automatically secure every application, device, account, or site that uses it. IEC 62541-2:2026 describes the OPC UA security model as focused on protecting data exchanged between applications, while noting that developers must consider other application security concerns and that deployment choices depend on implementation and site security.
For a site evaluating any protocol, this is a useful boundary: transport or message protections address only the risks they are designed to address. Application permissions, device hardening, remote access, monitoring, backups, incident response, and physical-process safeguards remain part of the wider security design.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to manage protocol security over the system lifecycle
Protocol security is not a one-time procurement check. ISA describes the ISA/IEC 62443 approach as risk-based and lifecycle-oriented, with responsibilities shared across asset owners, product suppliers, integrators, and service providers. In practice, those parties need clear ownership for security requirements, configuration, testing, change approval, support, and exception handling.
Rank #4
IEC PAS 62443-1-6:2025 applies the IEC 62443 series to IIoT and was published on December 19, 2025. IEC notes that the PAS document is automatically withdrawn after four years. NIST’s SP 800-82 Rev. 4, dated September 21, 2026, is an initial public draft—not a final edition—with comments due November 30, 2026. These publications provide context for evaluating OT and IIoT security; neither establishes that a particular unnamed protocol family is unsafe or universally safe.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
