Cryptographic inventory OT network: how do you build one?

A cryptographic inventory for an OT network is a structured record of every place where public-key cryptography (RSA, elliptic-curve and Diffie-Hellman) protects connections between control sites, cloud environments and remote users, including which algorithm, key size, protocol and device is involved. It is the prerequisite for any planned migration to post-quantum encryption.

For operators of substations, water treatment plants, pipelines and factories, the inventory looks different from an IT asset scan. Many devices cannot tolerate active probing, firmware hides its cryptography, and the most sensitive traffic often travels over long-lived site-to-site links. This article explains how to build the inventory without disrupting the process, how to record it in a cryptographic bill of materials, and how to use it to decide what to migrate first.

What do CISA, NIST and OMB expect from a cryptographic inventory?

US guidance treats the inventory as step one of post-quantum migration and explicitly includes OT. The documents below define what to collect and how.

The CISA Quantum-Readiness Factsheet, published jointly by CISA, NSA and NIST in August 2023, states that organizations should create a cryptographic inventory that offers visibility into how the organization leverages cryptography in its IT and OT systems. It also assigns ownership: the inventory should be led by an organization’s Information Technology (IT) and Operational Technology (OT) procurement experts, together with supply chain vendors.

“It is imperative for all organizations, especially critical infrastructure, to begin preparing now for migration to post-quantum cryptography,” said Jen Easterly, then Director of CISA, when the factsheet was released.

OMB M-23-02, issued on November 18, 2022, sets reporting rules for US federal agencies. It does not bind private operators, but its data fields are a useful template. CISA’s page on its PQC initiative now lists OMB Memorandum M-26-15 & OMB Memorandum M-23-02 together as the basis for executing the federal migration.

Statistic: M-23-02 Section II requests nine data items per cryptographic system, and according to CISA only three of the nine may be collected with automated tools; most of the nine data items cannot be detected or collected using currently available automated tools, and therefore, are manually collected. (CISA, September 2024)

NIST SP 1800-38 is the practice guide series from the NIST NCCoE Migration to PQC project. Volume B, Quantum Readiness: Cryptographic Discovery, tests discovery tools, and the project runs a workstream focused on the use of cryptographic inventory tools to allow an organization to learn where and how cryptography is being used.

Statistic: CISA is a collaborator along with over 28 industry partners in the NIST National Cybersecurity Center of Excellence’s (NCCoE) “Migration to PQC” project. (CISA, September 2024)

Statistic: CISA’s 2022 analysis covered critical infrastructure systems across the 55 NCFs (National Critical Functions) and found quantum-related risks in each of them. (CISA Insight, August 2022)

How do you find out which RSA and ECC algorithms your OT network connections use?

Begin with the handshakes. Almost every protocol that sets up an encrypted session exchanges its algorithm choices in cleartext before encryption starts, so a sensor on a mirror port can read them.

NIST SP 1800-38A scopes this exact use case: discovering vulnerable algorithms used in network protocols, enabling traceability to specific systems using active scanning and historical traffic captures. In OT, put historical and live captures first, and treat active scanning as an exception.

What each protocol reveals on the wire

Record each finding as a flow: source asset, destination asset, protocol, algorithm, key size, certificate expiry and the data it carries. A list of algorithms without the connection context cannot support any prioritisation decision later.

Can you discover cryptography passively without disturbing OT processes?

Yes, for most network-level cryptography. Passive collection from SPAN ports or network taps reads handshake metadata without sending a single packet to a controller, which makes it the safe default for Level 0 to Level 2 networks.

Practical design points for passive discovery:

• Place sensors where tunnels terminate. Site-to-site key exchange is visible on the WAN side of the boundary device, not on the cell or zone networks behind it.
• Capture long enough to see rekeying. IKE and SSH sessions on OT links can stay up for weeks. A short capture shows only established traffic, not the handshake. Plan captures around maintenance windows or scheduled rekeys.
• Use unidirectional taps on safety-relevant segments, so the sensor cannot inject traffic even if misconfigured.
• Fill TLS 1.3 gaps on the IT side. Where certificates are encrypted, a single scheduled handshake against a DMZ server or cloud endpoint is far less risky than probing a controller.

How do you inventory cryptography on PLCs, RTUs and legacy industrial devices?

Combine three sources: passive network evidence, offline configuration and firmware data, and written vendor statements. On legacy controllers, no single method gives a complete picture.

The Quantum-Readiness Factsheet warns that discovery tools may not be able to identify embedded cryptography used internally within products, hindering discoverability or documentation. That limitation hits OT hardest. An IETF Internet-Draft on cryptographic asset discovery makes the same point: CBOM-style self-description cannot help identify legacy devices and systems.

A workable sequence for controllers and field devices:

1. Export, do not query. Pull project files and configuration backups from engineering workstations. They often reveal certificate settings, OPC UA security policies and DNP3 Secure Authentication options without touching the running device.
2. Check firmware signing. The factsheet explicitly includes systems involved in creating and validating digital signatures, which also incorporates software and firmware updates. Ask which algorithm validates firmware images, because that cannot be changed later without a new bootloader.
3. Request written answers from vendors on algorithms, key sizes, and whether a post-quantum update is planned for that hardware revision. A request worded around the CISA factsheet tends to get a more specific answer.
4. Mark unknowns explicitly. A field reading “unknown, vendor asked on date X” is more useful than a blank, because it shows up in risk review.

Many serial and fieldbus protocols carry no cryptography at all. Record them anyway. They usually depend on the encryption of the WAN link that carries them, so the risk sits in that link’s key exchange.

What is a cryptographic bill of materials (CBOM)?

A CBOM is a machine-readable list of the cryptographic assets in a product or system: algorithms, keys, certificates, protocols and libraries, and how they relate to each other. The most widely used format is the CycloneDX CBOM.

Within Ecma International, TC54 maintains CycloneDX (ECMA-424), a Bill of Materials specification supporting both Software BOM (SBOM) and Cryptography BOM (CBOM), including standardised algorithm families to enable crypto-agility and planning for the transition to PQC. Because the same format covers software components, a CBOM can link a vulnerable algorithm to the exact firmware version or library that implements it.

For OT, the CBOM serves two purposes. Internally, it turns scattered capture results and vendor letters into one dataset that can be compared over time. In procurement, asking suppliers to deliver a CycloneDX CBOM with new controllers, gateways and engineering software moves the documentation burden to the party that actually knows the embedded cryptography. Keep in mind that a product CBOM describes capability, not configuration: you still need network evidence to confirm which algorithm a deployed connection actually negotiates.

Which connections should you migrate to post-quantum encryption first?

Start with connections that cross untrusted networks and carry data with a long confidentiality life, because those are exposed to “harvest now, decrypt later” collection today. Device-internal cryptography with short-lived value can follow later.

The factsheet ties prioritisation directly to the inventory: organizations should feed the quantum-vulnerable inventory into their risk assessment process, allowing risk officials to prioritize where to ensure use of PQC as soon as it is available. It also stresses identifying quantum-vulnerable cryptography that protects critical processes, especially for Critical Infrastructure.

Timelines matter for planning budgets. Statistic: in the NIST IR 8547 initial public draft, ECDSA at 112 bits of security strength is Deprecated after 2030 Disallowed after 2035. (NIST, November 2024) NIST also states that it will deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems transitioning much earlier.

“The transition to a secured quantum computing era is a long-term intensive community effort that will require extensive collaboration between government and industry,” said Rob Joyce, then Director of NSA Cybersecurity.

Because PLCs and RTUs often run for decades, the first migrations in OT usually happen at the network boundary rather than in the device. One example is Quantum Network’s QPN, an encryption gateway placed at each end of a site link that encrypts at Layer 3 using a hybrid key agreement (a classical part combined with ML-KEM, standardised in FIPS 203), without installing software on the equipment behind it. A boundary approach like this protects data in transit only, not the devices themselves, so the controller entries in your inventory stay open until the hardware is upgraded or replaced.

How do you keep the OT cryptographic inventory usable over time?

Give every entry an owner, a review date and a link to an asset record, and refresh it from passive data after every maintenance window.

The factsheet recommends that organizations correlate cryptographic inventory with inventories available from existing programs, such as Asset Inventory and identity and access management. In OT, that means linking each cryptographic finding to the asset register used for patching and change management, so that a firmware update that changes a cipher suite automatically triggers a CBOM revision. Crypto-agility, meaning the ability to swap algorithms without redesigning the connection, should be a selection criterion for every new gateway, remote-access path and cloud connector, because the post-quantum standards themselves will keep evolving.