Finding the Assets Before You Find the Cryptography

NIST’s initial public draft of IR 8547, Transition to Post-Quantum Cryptography Standards, published in November 2024, proposes dates. RSA-2048 and 256-bit elliptic-curve cryptography would be deprecated after 2030 and disallowed after 2035. Those dates sit in a draft and are not yet policy. For national security systems, NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), issued as a cybersecurity advisory in September 2022, sets its own milestones toward exclusive use of quantum-resistant algorithms by 2035. A programmable logic controller (PLC) commissioned this year on a twenty-year service life will still be in the field when either timeline runs out. For the engineer handed the migration plan, the algorithm choices are the settled part: ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures, published by NIST on August 13, 2024 as FIPS 203, FIPS 204 and FIPS 205. The open question is which devices are in scope, and on most industrial sites nobody can answer that from the records they have.

The order of operations

Migration methodologies list discovery first and then treat it as a cryptography exercise. It isn’t only one. A cryptographic bill of materials, or CBOM, is a structured record of the algorithms, key sizes, certificates and libraries in use, and of the systems that hold them. It describes properties, and properties belong to things. If a substation gateway is missing from your configuration management database (CMDB), the record of what the organization owns and runs, then the RSA key inside that gateway is missing too. No tool reports it. Scanners report what they find, not what they failed to reach.

Cryptographic discovery therefore reaches exactly as far as asset discovery already reached, and the shortfall stays quiet. It’s the failure we spend the most time on with engineers who arrive in our migration training with work already underway: a clean-looking CBOM covering the server estate, produced inside an organization whose field devices have not been enumerated since the last plant upgrade. The document looks like progress. What it actually measures is the coverage of the tool that produced it.

This is not a new idea in security. CIS Critical Security Control 1 is inventory and control of enterprise assets, ahead of everything else in the list, and IEC 62443 expects an asset inventory before zones and conduits – the segmented groupings of equipment and the controlled paths between them – can be defined at all. Post-quantum work simply makes the dependency expensive to ignore, because the remediation is hardware for some fraction of the estate and you cannot size that fraction from a partial list.

What the cryptographic inventory needs from the asset record

An IP address and a hostname won’t carry you into a replacement decision. To attach cryptographic properties to a device and then decide what happens to it, the asset record has to hold at least six fields.

• Identity that survives re-addressing. Serial number, MAC address, or vendor asset tag. Addresses move and leases expire, so an inventory keyed on IP will double-count some devices and lose others.
• Make, model and firmware revision. This is the field that maps onto a vendor’s answer about secure boot and signature support. Without the revision, the vendor’s answer applies to a device you may not have.
• Function and criticality. Safety-instrumented, protection, control, monitoring, or business. This decides sequence, and sequence is most of the plan.
• Data lifetime. How long does information passing through this device need to stay confidential? Grid topology, metering data and process recipes can all outlive the 2035 date.
• Ownership by named team. Every unresolved cryptographic question ends with somebody having to call a vendor, and unowned devices generate questions nobody answers.
• Planned replacement date. A device already scheduled for replacement in 2029 needs a procurement requirement rather than a migration project.

That last field changes the economics more than any other. A large share of quantum-vulnerable OT – operational technology, the control and monitoring equipment that runs a physical process – will age out on its own schedule if the procurement specification is fixed now. The devices that will not age out in time are the ones that need engineering attention, and you can only separate the two groups if the record carries a date.

Where cryptography actually lives

Engineers new to this work tend to picture cryptography as TLS on the wire. In an industrial estate it sits in four places, and they fail in different ways.

In transit. TLS, IPsec, SSH, and the secure variants of industrial protocols. The most visible layer and generally the most tractable, because the algorithm is negotiated and negotiation can often be changed in configuration.

At rest. Historians, engineering workstations, backup archives. This matters where the data has a long confidentiality life, which is the harvest-now-decrypt-later concern: traffic or storage captured today, retained by an adversary, and read once a capable machine exists.

In identity. Device certificates and machine identities, including the private key that proves a remote terminal unit (RTU) is the unit it claims to be. Certificate lifecycle work and post-quantum work land on the same team and often on the same weekend.

In the root of trust. Secure boot and firmware signature verification. This is the layer that decides whether a device can migrate at all. If a controller validates firmware signatures against an RSA-2048 public key held in read-only memory, the algorithm cannot be changed by shipping new firmware, because the component that would have to change is the component that checks the update. Those devices belong in a capital plan, not a patch cycle. NSA sequences software and firmware signing ahead of most other transitions in CNSA 2.0 for the same reason. And you cannot tell the replaceable devices from the upgradeable ones without the model and firmware revision sitting in the asset record.

Why OT breaks the standard IT playbook

Active scanning carries operational risk. A port sweep that is harmless against a web server can push a controller into a fault state, because the device was built to handle a narrow set of expected traffic and nothing else. Most operators forbid unrestricted scanning in production for that reason, which removes the fastest discovery method from the table.

Many devices have no IP address. Serial links, fieldbus segments and sub-devices behind a gateway are invisible to anything that enumerates hosts. The gateway appears as one asset. Behind it there may be forty.

Nothing accepts an agent. You will not install endpoint software on a protection relay or a smart camera, so the deepest and most reliable IT discovery technique simply doesn’t apply.

Segmentation hides the estate from the scanner. Good network design puts the control system out of reach of the corporate network, and that includes the corporate discovery tooling. Some systems are polled occasionally. Some are genuinely isolated.

Lifecycles outrun documentation. Equipment installed twenty or thirty years ago has usually outlived three owners, two integrators and the drawings. The people who know what’s in the cabinet may have retired.

Shadow OT arrives through facilities. Building management systems, metering, environmental sensors and access control get installed by teams who don’t consider themselves IT and don’t file anything. They are on a network regardless.

What each method can and cannot tell you

No single technique reaches the whole estate, and the second column below is the one that usually gets overlooked when tooling is chosen.

Method	What it gives you about assets	What it gives you about cryptography
Active network scanning	Responding hosts, open ports, service and OS fingerprints	TLS versions, cipher suites, certificate subjects and expiry on responding ports
Endpoint agents	Deep detail on managed servers and workstations, continuously updated	Installed crypto libraries and versions, keystores, OS-level crypto policy
Passive traffic monitoring	Devices that talk, their protocols, their peers, safe on OT segments	Protocols and versions observed on the wire, certificate exchanges, plaintext links
Infrastructure and record queries	DHCP leases, switch address tables, directory objects, cloud inventories, SCADA project files	Certificate authority issuance records, which is often the only clean view of your public key infrastructure (PKI)
Vendor documentation and attestation	Model-level capability, lifecycle status, support horizon	Secure boot chain, signature algorithms, device identity, field-upgradability
Physical walkdown	Everything the network cannot see, including offline equipment	Model and firmware revision, which is what makes the vendor’s answer usable

Read down the right-hand column and the shape of the work becomes clearer. Network methods tell you about cryptography in transit. Only the vendor and the nameplate tell you about the root of trust, which is the expensive part. A discovery program built entirely on passive monitoring will produce a rich picture of protocols and a blank space where the firmware signing answers should be.

A working sequence

Scope by consequence, not by network

Start from the zones where a compromise has a physical or long-lived consequence, and where equipment will still be in service after 2035. That’s usually protection, safety and metering, plus anything handling data with a long confidentiality requirement. Enumerating every smart light fitting first feels like progress and delays the decisions that need lead time.

Harvest the records you already own

Before buying anything, pull what the organization has: DHCP leases, switch address tables, directory objects, vulnerability scan history, cloud inventories, maintenance management records, purchase orders. In OT, the highest-value source is usually the engineering workstation. The SCADA project file and the HMI tag database name every device the control system expects to communicate with, along with addresses and often models. It’s the closest thing an OT estate has to a manifest, and it typically sits on a machine no security tool has ever touched.

Listen before you probe

Deploy passive monitoring on the OT segments and let it run through at least one full operational cycle, including a maintenance window and a shift pattern that exercises equipment used rarely. Devices that speak only during a monthly batch will not appear in a week.

Probe under supervision

Where active interrogation is genuinely needed, do it narrowly, during a planned window, with the vendor’s written position on what the device tolerates and with the operations team in the room. Many controllers will answer a single well-formed protocol query safely while failing under a generic port scan. The difference is the tool’s protocol awareness, not its aggression setting.

Walk the remainder

Some assets will only be found by opening the cabinet. Send people with a structured form rather than a clipboard and a good memory: location, panel, make, model, firmware revision, network connection, upstream device, photograph of the nameplate. Walkdowns routinely correct a meaningful share of existing records, and the corrections tend to cluster in the oldest and most consequential equipment.

Reconcile, then attach the cryptography

Merge everything into one record per physical thing, keyed on an identifier that doesn’t change. This step is where most of the effort actually goes, because the same device arrives from four sources under four names. Only once the reconciliation holds should you start attaching cryptographic attributes, whether in a spreadsheet or in a structured format – CycloneDX added cryptographic bill of materials support in version 1.6, and it’s a reasonable target once the underlying inventory is stable.

Keeping it current

An inventory built as a project is stale within a quarter. Two mechanisms keep it alive without a permanent census. The first is a gate: no device reaches a production network without a record, enforced through change management and procurement rather than goodwill. The second is drift detection: an alert when something appears on a segment that isn’t in the inventory, and a review when something known hasn’t been seen for a defined period. Both are modest engineering tasks. Neither survives without a named owner, which is why ownership is a field in the record rather than a line in a policy document.

Turning unknowns into procurement questions

Discovery will leave you with devices whose cryptographic behaviour nobody can determine from the outside. That list is not a failure state, it’s a purchasing input. Five questions, sent to the vendor per product line rather than per device, resolve most of it.

• Which signature algorithms does the secure boot chain accept, and where is the root public key stored?
• Can signature verification be updated in the field, and through what mechanism?
• What cryptography does the device use for its own identity, and what is the certificate lifetime?
• Which cryptographic libraries are embedded, at which versions, and will you publish a software bill of materials (SBOM), meaning a machine-readable list of the components inside the product?
• What is your published timeline for post-quantum support on this line, and for how long will the current model be supported?

A vendor answering “we don’t know” is giving you a data point, and it belongs in the record next to the device. Put the same five questions into the specification for anything you buy from now on, and the replacement-date field in your inventory starts doing the migration work for you.

What good enough looks like

Complete coverage of a large mixed estate is not a realistic first-year goal, and treating it as one tends to produce a stalled program rather than a thorough one. Coverage by consequence is the better target: near-total visibility in the zones where the cryptography has to change first under whichever timeline binds you, whether the proposed NIST dates, CNSA 2.0 for national security systems, or a sector regulator’s schedule, honest partial coverage elsewhere, and an explicit register of what remains unknown. The unknown register is a deliverable in its own right. It’s what an auditor, a regulator or an incoming engineer needs in order to judge how far to trust the CBOM sitting next to it.

Building the skills

Asset discovery for post-quantum migration sits across two disciplines that rarely share a team. It needs the OT engineer’s judgment about what can safely be probed, and the security engineer’s understanding of where cryptographic dependencies hide. Most organizations have both people and no shared method between them.

Quantum Academy’s post-quantum migration training covers cryptographic inventory as an engineering workflow, including the discovery sequence, the record structure and the vendor interrogation above. The current program catalog is at quantumacademy.com/. For the wider migration methodology this discovery work feeds into, see pqcframework.org, and for deeper technical background on algorithms and threat timelines, PostQuantum.com.