Most quantum security discussions in operational technology focus on the systems. PLCs, RTUs, SCADA masters. The scanner works at a lower layer: the communication protocols themselves. Industrial protocols like Modbus and DNP3 were designed decades before quantum computing was a practical concern. Many carry no native cryptographic protection. For those that do use encryption, it is typically applied at the session or network layer using legacy RSA or ECDSA. exactly the algorithms a cryptographically relevant quantum computer would break. The scanner maps which protocols your OT environment uses and returns a protocol-by-protocol quantum exposure profile. Scan your OT protocol exposure
What the OT Protocol Quantum Vulnerability Scanner Does
The tool works from a knowledge base, not from active network probing. You select the industrial protocols your OT environment uses from a taxonomy covering Modbus TCP and RTU, DNP3, IEC 61850, IEC 60870-5, PROFINET, EtherNet/IP, OPC-UA, BACnet, and others. For each protocol, the tool returns:
- Whether the protocol has native cryptographic support
- What algorithm classes are used, if any
- Which layer encryption is typically applied at (transport, network, or application)
- What the quantum exposure level is at each layer
The output is a protocol-by-protocol quantum exposure map with an aggregate site-level exposure rating.
This distinction is load-bearing for the OT audience. This is a knowledge-base assessment: you select your protocols, and the tool returns their known vulnerability profiles. It does not connect to, scan, probe, or interact with any network infrastructure. Active scanning in OT environments can cause device failures and service interruptions. The knowledge-base approach is operationally appropriate precisely because of that risk.
Quantum Vulnerability Profiles by Protocol
The editorial value of the scanner is specificity. There is limited published guidance that maps quantum vulnerability to individual OT protocol layers rather than to systems as a whole. The profiles below reflect the scanner's knowledge base.
Modbus TCP and RTU
Modbus has no native cryptographic support. There is no authentication mechanism and no encryption in the protocol itself. Any protection that exists is entirely dependent on the encapsulating network layer. the VPN, the firewall zone, or the gateway encryption appliance sitting in front of the Modbus traffic. Quantum risk for Modbus environments sits at the network and VPN layer. Migration happens at the gateway, not within the protocol.
DNP3
DNP3 has an optional security mechanism: Secure Authentication version 5 (SAv5), defined in IEEE 1815. SAv5 uses HMAC-SHA-256 for its challenge-response authentication, which is symmetric and does not carry direct quantum vulnerability in the same class as RSA or ECDSA. The quantum-vulnerable component in DNP3 is in a separate layer: the key update procedures in SAv5 use asymmetric cryptography (RSA in common implementations) for key transport, and that component is quantum-vulnerable.
The more significant operational reality is that SAv5 deployment is low. Most DNP3 installations operate without any authentication mechanism at all. Quantum risk in DNP3 environments typically presents at the network or transport layer rather than within the protocol's own security features.
IEC 61850
IEC 61850 requires careful treatment because different message types use different security mechanisms. GOOSE and Sampled Values messages are multicast and use IEC 62351-6 for integrity protection. not TLS. Client-server MMS communications use TLS per IEC 62351-3, with RSA and ECDSA common in current implementations. Both the IEC 62351-3 TLS layer and the IEC 62351-6 GOOSE authentication layer are quantum-vulnerable in current deployments.
IEC TC57 WG15 is working on PQC updates to IEC 62351. No published amendment addressing PQC migration has been released as of April 2026. Current IEC 61850 implementations remain quantum-vulnerable at both the TLS and authentication layers. OT vendors have generally acknowledged PQC migration as a future requirement; very few have shipped anything.
This matters for the NIS2 context: OT operators in energy, transport, water, and digital infrastructure are essential entities under NIS2 Article 3 and subject to Article 21 security obligations. An OT protocol running unprotected or with quantum-vulnerable cryptography is a demonstrable gap in a proportionate cryptographic risk management assessment.
IEC 60870-5
Similar profile to DNP3. Minimal native cryptographic support. Where security is present, it is applied via TLS at the transport layer using classical algorithms. Quantum risk is at the transport layer.
OPC-UA
OPC-UA has a mature security model with TLS support and defined security profiles. The OPC Foundation has acknowledged PQC migration as a requirement. The migration path exists but depends on vendor support. check your OPC-UA vendor's PQC roadmap before assuming the capability is available.
Gateway-dependent versus protocol-layer dependent
The scanner's practical output distinguishes two remediation types. For Modbus and unprotected DNP3 installations, migration happens at the gateway. the VPN or encryption appliance is the migration target, not the protocol. For IEC 61850 with TLS and OPC-UA with secure profiles, migration requires vendor coordination to update algorithm suites. These are fundamentally different implementation paths, with different lead times and different team ownership.
Our tools are designed as directional tools only. Advice and standards are changing rapidly and although we update tools as new information is periodically released they are not designed as a replacement for expert advice. If your organisation results show high-priority exposure the next step is to contact our team or speak to a qualified expert member.
How to Use the OT Protocol Quantum Vulnerability Scanner
Step 1. Open the scanner. No registration required.
Step 2. Select all OT protocols in use in your environment. The tool presents the full protocol taxonomy. Tick everything that applies. Modbus and DNP3 are the most common starting points; IEC 61850 and OPC-UA are common in substation and process automation environments.
Step 3. For protocols with optional security profiles, indicate whether the secure profile is enabled. For DNP3 SAv5: is it deployed in your environment, or are you running unauthenticated DNP3? For OPC-UA: is the secure mode enabled, or is the deployment using the no-security profile? The honest answer produces the more useful output.
Step 4. Review the protocol-by-protocol exposure map. Each protocol returns an exposure level and a remediation type: gateway-layer migration, protocol security profile upgrade, or replacement required.
Step 5. Identify the highest-exposure protocols. These are your first migration priorities. The exposure rating accounts for both quantum vulnerability and operational prevalence. a highly deployed unprotected protocol scores higher than a rarely used one.
Step 6. Review the recommended remediation type for each protocol. Gateway-dependent protocols migrate differently from protocol-layer dependent ones. The scanner distinguishes these explicitly.
For large OT environments with multiple protocol types across different sites, run the scanner per site or per process segment. An energy substation and a water treatment plant in the same organisation may have completely different protocol profiles and different migration paths.
How to Interpret Your OT Protocol Scan Results
The output is a layered exposure map. The remediation pathway depends on where the vulnerability lives.
Gateway-dependent exposure (Modbus, unprotected DNP3, IEC 60870-5 without TLS): migration is through the gateway or VPN layer. Replace or update the encryption appliance with a quantum-safe alternative. This is typically the most tractable migration. gateway hardware is in the ground segment and can be replaced without OT device changes.
Protocol-level exposure (IEC 61850 with TLS, OPC-UA with secure profile): migration requires vendor coordination. The algorithm suites in TLS and in the protocol security profiles need updating. Check vendor PQC roadmaps. If your vendor has not published a PQC migration roadmap, ask for one now. that conversation has its own lead time.
Unprotected protocols in scope: these require a network architecture decision. The options are adding gateway-level quantum-safe encryption or planning for protocol replacement. For long-lived OT environments, gateway encryption is usually the practical path.
Use the OT Cryptographic Asset Prioritisation Matrix to sequence remediation based on the scan results. the scanner tells you what is exposed; the prioritisation matrix helps sequence which to address first when you cannot do everything simultaneously.
Discuss your results with a QSECDEF expert member. A directional assessment is the starting point, not the programme. If your results show high-priority exposure, the next step is a discussion about a structured migration programme with defined milestones. Request a consultation with our team or find a qualified expert member.
