How to make secure vendor remote access OT quantum-safe

Secure vendor remote access for OT means an equipment supplier or contractor reaches a specific industrial asset, such as a PLC, HMI or engineering workstation, through a controlled, encrypted and logged path, without getting general access to the plant network. Making that path quantum-safe means protecting its key exchange against decryption by future quantum computers.

Most plants depend on outside engineers. Turbine OEMs, robot integrators and SCADA support contractors all need to log in from time to time. The problem is not that they need access. It is that the access often outlives the job, reaches more than it should, and runs over encryption that nobody has reviewed for long-term confidentiality. This article covers the architecture, the controls on scope and time, the relevant IEC 62443-3-3, NIS2 and NERC CIP-005 requirements, and where post-quantum cryptography fits in.

How do you give OT equipment vendors secure remote access without exposing the plant network?

Send every vendor session through one centrally managed, brokered path that ends in an OT DMZ, never through a direct inbound connection to a controller. The vendor connects to an intermediate system, and only that system can reach the target asset.

This is the core of the CISA Secure Remote Access guidance. CISA urges all critical infrastructure organizations to route all necessary remote access through a secure gateway, firewall, VPN, or other centrally managed access solution, rather than connecting directly to a PLC, human-machine interface (HMI), or remote terminal unit (RTU). The agency adds that organizations should require unique usernames, strong passwords, and phishing-resistant MFA for all remote access.

Third-party dependency is a measurable source of incidents, not just a theoretical one:

The reference path, step by step

1. Outbound-only connectivity. Neither the vendor’s laptop nor the plant should accept inbound connections from the internet. Both sides connect outward to a rendezvous point in the DMZ.
2. Encrypted conduit to the DMZ. The tunnel ends in the DMZ, not on the control network.
3. Intermediate system (jump host). CISA and the US Coast Guard advise you to make bastion hosts the single access points for conducting all administrative tasks, system management, and configuration changes.
4. Per-asset firewall rules from the intermediate system to the target, limited to the required protocol and port.
5. Session logging and recording, sent to a log store outside the vendor’s control.

Should vendor remote access sessions use post-quantum encryption?

Yes, wherever the session carries data that must stay confidential for years, such as PLC logic, safety configurations, network diagrams or credentials. The usual way to do this today is a hybrid key exchange that adds ML-KEM (FIPS 203) to a classical algorithm.

The reason is “harvest now, decrypt later”. Someone who records encrypted traffic today could decrypt it once a large enough quantum computer exists, because classical key exchanges such as elliptic-curve Diffie-Hellman are exposed to quantum attacks. Vendor sessions are an obvious target for this. They cross the public internet, and they often carry exactly the engineering data that says how a process works and where its safety margins are. That data stays useful for the whole life of the installation, often 15 to 30 years.

A hybrid design combines the classical and post-quantum results into one session key, so the session stays protected as long as either part holds. In OT, look at three things besides the algorithm:

• Latency budget. CISA’s Cybersecurity Performance Goals advise to use encryption for external connections and where latency issues would not result in an impact to operations. Remote engineering sessions usually tolerate a little extra delay. Real-time control loops do not.
• Fail-closed behaviour. If the encrypted path drops, it must not fall back to plaintext.
• Crypto agility. You need to be able to swap the post-quantum algorithm later without replacing hardware at every site.

As one example of how this can be built, Quantum Network’s QPN offers a secure remote access mode. A software client for current Windows and macOS sets up a hybrid key exchange (classical plus ML-KEM, both renewed every two minutes) to a gateway in front of the site. The client needs no incoming firewall ports, and the connection never falls back to unencrypted traffic.

CISA has put the underlying need plainly. “There is a critical need for OT environments to use secure communication that protects against threats like actor-in-the-middle attacks and unauthorized updates,” said CISA Executive Assistant Director for Cybersecurity Nick Andersen.

How do you limit an external engineer’s remote access to specific OT assets?

Scope access per asset, per protocol and per job, and enforce that scope in at least two separate layers. A vendor account should never mean “access to the plant”.

CISA advises organizations to document and configure remote access solutions to apply principles of least privilege for the specific asset and user role or scope of work. In practice that means three layers, each enforced on its own:

• Network layer. Firewall rules from the intermediate system allow only the target IP addresses and the engineering protocol needed for the job. For example, the vendor of a packaging line gets its two PLCs on the relevant port, not the whole cell subnet.
• Intermediate system layer. Rights on the jump host are tied to named assets. CISA and USCG recommend controls that restrict access to authorized personnel only using RBAC principles, ensuring that personnel can only access information and perform tasks pertinent to their roles and duties.
• Asset layer. Where the controller supports it, use read-only modes, change-control keys or set-point limits, so a remote session cannot do more than the task needs.

Keep in mind what transport encryption does and does not do. A Layer 3 encryption gateway, such as the QPN gateway, protects the data in transit and works alongside the existing firewalls. It does not protect the devices behind it, and it does not decide which PLC an engineer may reach. That decision belongs in the firewall rules and the intermediate system, so treat encryption and authorisation as separate controls.

Finally, log everything on the intermediate system. CISA recommends logging all activities on bastion hosts, including authentication attempts, command executions, configuration changes, and file transfers. Review the logs against the work order. A session that touched assets outside its ticket is a finding in itself.

Which IEC 62443 requirements apply to remote access by third parties?

The main ones are the system requirements in IEC 62443-3-3 for access over untrusted networks, remote session control, authentication, use control and communication confidentiality. They are supported by IEC 62443-2-4 for service providers and IEC 62443-3-2 for zones and conduits.

IEC 62443-2-4 works from the other side. It sets security program requirements for the integrators and maintenance providers themselves, including how they handle remote access, so you can write it into supplier contracts.

NIS2 Directive Article 21

For EU essential and important entities, NIS2 Directive Article 21(2) requires measures that include supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers, along with policies on cryptography and on multi-factor authentication. The list runs from point (a) to point (j), so it covers at least ten categories of measures. Implementing Regulation (EU) 2024/2690 adds detail: entities must apply a cryptography policy to protect the confidentiality, authenticity and integrity of data in line with the relevant entities’ asset classification and the results of the risk assessment.

NERC CIP-005

For North American bulk electric system entities, NERC CIP-005 Requirement R2 requires Interactive Remote Access to go through an Intermediate System, with encryption that ends at that Intermediate System and multi-factor authentication. CIP-005-7 also requires methods to find active vendor remote access sessions and to disable them. In practice this calls for a working “kill switch” for vendor sessions, not just a written procedure.

How do you revoke or time-limit remote access credentials for contractors?

Make expiry the default. Grant access just in time against a work order, let it expire automatically when the window closes, and keep a tested way to end active sessions immediately.

The NIST NCCoE described the principle early on: authentication decisions should have contextual scope (e.g. task, session, time period), for example by ensuring that a user has an appropriate work order for the given time and location as part of the authentication process. A workable process looks like this:

1. Request tied to a ticket. The vendor asks for access to named assets for a set window. A plant operator approves it.
2. Account enabled for the window only. Outside the window, the account is disabled, not just unused.
3. Strong, unique credentials. CISA’s CPG 2.0 says that in OT, MFA is enabled on all accounts and systems that can be accessed remotely, including vendors/maintenance accounts.
4. Live session visibility. Operators can see who is connected and end the session.
5. Automatic clean-up. CISA’s primary OT mitigations say plainly: disable dormant accounts.

Where an OT device cannot support MFA or modern authentication, at least raise the password baseline:

Contracts matter as much as technology. Under the NIS2 implementing regulation, contracts with suppliers should specify cybersecurity requirements for the suppliers or service providers. For remote access, that means named engineers, notice when staff leave the vendor, no shared accounts, and agreement that the asset owner may end sessions at any time.

None of this happens in one project. As CISA Acting Director Madhu Gottumukkala put it, “Adopting secure communications in OT environments is a long-term effort with complexities, costs and risks.” A practical order is: first, close direct inbound paths and unmanaged vendor modems. Next, bring every vendor into one brokered conduit with MFA and per-asset rules. Then add expiry and a session kill switch. Finally, upgrade the encryption on that conduit to a hybrid post-quantum key exchange, so the engineering data that crosses it stays confidential for as long as the plant runs.