A technical blog · one issue per month from September 2026

Quantum-Safe Pipeline Notes

Post-quantum cryptography and operational-technology security for U.S. oil and gas pipelines: what the new federal rules mean in the control room, and what operators can do about it now.

Issues along the line

MP 01 September 2026 What EO 14412 means for a pipeline operator's certificate inventory 7 min read · DOI 10.5281/zenodo.23130001 MP 02 October 2026 Harvest-now-decrypt-later for SCADA telemetry 6 min read · DOI 10.5281/zenodo.23130292

MP 03 November 2026 · coming November 3 Finding the cryptography inside an OPC UA deployment

MP 04 December 2026 · coming December 3 Before the FAR post-quantum rule: what OT vendors should be ready to answer

MP 05 January 2027 · coming January 3, 2027 Hybrid key exchange over narrowband SCADA radio: modeling the cost

MP 06 February 2027 · coming February 3, 2027 Firmware-signing roots and the 2040 problem

MP 07 March 2027 · coming March 3, 2027 What a cryptographic bill of materials should tell a pipeline operator

← All issues

Issue 01 · September 2026 slot

What EO 14412 means for a pipeline operator's certificate inventory

Friday Ogochukwu Ikwuogu · ORCID 0009-0009-2222-1318 · Published 2026-10-03 · 7 min read

On June 22, 2026, the White House signed Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks. It sets the federal government's deadlines for moving to post-quantum cryptography (PQC): high value assets and high impact systems must use PQC for key establishment by December 31, 2030, and for digital signatures by December 31, 2031.

If you run cybersecurity for a natural gas or hazardous liquids pipeline, the honest first reading is that the order does not bind you directly. It is addressed to federal agencies. The order never mentions pipelines, energy, OT, or TSA. So why write about it for pipeline operators?

Because the order reaches private critical infrastructure through three side doors, and all three lead to the same place: an inventory of where your systems use public-key cryptography. For most operators the most tractable piece of that inventory, and the right place to start, is certificates.

The three side doors

1. Sector Risk Management Agencies. Section 5 directs the Sector Risk Management Agencies, working through CISA, to assist critical infrastructure owners and operators with PQC migration planning. Under National Security Memorandum 22 (April 2024), pipelines fall in the Transportation Systems sector, where DHS (through TSA) and the Department of Transportation are the SRMAs, and oil and natural gas also sit in the Energy sector, where the Department of Energy is the SRMA. "Assistance" is not a mandate, but it is how guidance becomes expectation.

2. Procurement. Within 180 days of signing (about December 19, 2026), the FAR Council must propose a rule requiring covered federal contractors to comply with NIST PQC standards by December 31, 2030. The SCADA, historian, firewall, and remote-access vendors that sell to federal customers sell to you too. Their product roadmaps will move on the federal clock, and their legacy firmware will stop being the default sooner than your asset lifecycle assumes.

3. The cryptographic bill of materials. Within 270 days (about March 19, 2027), CISA and NIST must publish guidance on the minimum elements of a cryptographic bill of materials (CBOM): a machine-readable statement of the cryptography inside a hardware or software product. Once that format exists, expect it to show up in vendor questionnaires, in assessment programs, and eventually in audit requests.

Add to this the regulation that already binds you. Operators designated as critical under TSA's Security Directive Pipeline-2021-02 series maintain a TSA-approved Cybersecurity Implementation Plan, a Cybersecurity Incident Response Plan, and an annual Cybersecurity Assessment Plan for their Critical Cyber Systems. The directives do not yet ask about quantum-vulnerable algorithms. But an operator that can describe its authentication and encryption controls algorithm by algorithm is in a far better position when they do, and TSA's proposed rule Enhancing Surface Cyber Risk Management (89 FR 88488, November 7, 2024) shows the direction of travel toward codified, auditable cyber risk management. As of mid-2026 that rule had not been finalized.

Why certificates first

A full cryptographic inventory covers protocols, libraries, key stores, hardware security modules, and firmware. That is a multi-year project. Certificates are where you can start this month, for three reasons.

They are self-describing. Every X.509 certificate states its public-key algorithm, key size, signature algorithm, issuer, and validity period. You do not need vendor cooperation to read them.
They are where both of the order's deadlines meet. A certificate's key is often used for key establishment (the 2030 date) and its signature carries trust (the 2031 date).
OT certificates live a long time. In IT, public TLS certificates now turn over in months, and the CA/Browser Forum's schedule takes their maximum lifetime down to 47 days by 2029. In OT, a self-signed certificate generated when an HMI or historian was commissioned can carry a 10- or 20-year validity, and a vendor root of trust used to sign firmware can outlast the equipment generation that shipped it. Anything valid past December 31, 2031 is, by definition, a certificate that will need to be replaced or justified.

Where the certificates are in a pipeline environment

A starting map, from the enterprise edge toward the field:

Location	Typical certificate use	Who usually controls renewal
Remote-access gateways and VPN concentrators	Device identity, IKE/TLS authentication	Operator (IT/OT security)
Active Directory Certificate Services in the OT domain	Smart-card logon, machine identity, LDAPS	Operator
Historian and HMI web servers	HTTPS for thin clients and dashboards	Operator, often self-signed by default
OPC UA servers and clients	Application instance certificates and trust lists	Integrator or operator
RTU, PLC, and flow-computer TLS (for example DNP3 or IEC 60870-5-104 secured per IEC 62351-3)	Mutual TLS between control center and field	Vendor tooling, operator-run
Cellular and satellite backhaul equipment	Management interfaces, IPsec	Carrier or vendor
Vendor firmware and software signing	Code-signing roots embedded in devices	Vendor only

The last row deserves emphasis. You cannot replace a vendor's firmware-signing root yourself, and the devices that trust it may be in service until the 2040s. Those entries are less a task than a question to put to each vendor, in writing.

How to collect without disturbing the process

Export before you scan. Engineering workstations, OPC UA trust-list folders, AD CS, and gateway admin consoles all let you export certificates without touching a field device.
Capture passively where you must. A SPAN or tap copy of control-center traffic shows server certificates in TLS 1.2 handshakes. TLS 1.3 encrypts the server certificate inside the handshake, so passive capture will miss TLS 1.3 servers entirely; those need export or host-side collection.
Keep active scanning on the IT side or inside planned maintenance windows, under your normal change control. Field devices with limited TLS stacks have been known to misbehave when probed.
Run everything through one parser. I have published a small companion tool, cert_inventory.py, that reads a folder of exported certificates and writes one CSV row per certificate: algorithm, key size, signature algorithm, validity, whether it is a CA, whether it outlives the 2031 signature date, and a first-pass priority. It never connects to a device. Columns the parser cannot know (asset, zone, whether it is part of a Critical Cyber System, who renews it, whether the device can change algorithms) are left for you to fill in.

A triage that fits the order's two deadlines

Priority A: trust anchors and anything valid past 2031. Root and issuing CAs, firmware-signing roots, and long-lived self-signed device certificates. These have the longest replacement lead time and the most dependents. Ask vendors for their PQC signature roadmap now.
Priority B: quantum-vulnerable leaf certificates that renew on a cycle. RSA and elliptic-curve certificates that expire well before 2031. Replace them on their normal renewal schedule once your platform supports ML-DSA (FIPS 204) or hybrid certificates, and record which devices cannot.
Cross-cutting: key establishment that protects long-lived data. Where a certificate's key negotiates sessions carrying information that must stay confidential for years, the risk is not in 2030 but today, because traffic recorded now can be decrypted later. That is the subject of the next issue.

What I would do in the next 90 days

Name an owner for cryptographic inventory, the way the order requires each federal agency to name a PQC migration lead.
Export certificates from the five or six systems in the table above that you control directly, and run them through one parser.
Add an "algorithm" and "can change algorithm?" column to whatever asset inventory already supports your TSA Cybersecurity Implementation Plan.
Send every OT vendor the same three questions: Which public-key algorithms does the product use, and where? Can they be changed by firmware update? When will you ship ML-KEM and ML-DSA support?
Watch for the CISA/NIST CBOM guidance (due around March 19, 2027) and align your inventory fields to it when it lands.

None of this requires a quantum computer to exist. It requires knowing what you have, which is what every cybersecurity program already claims to do.

Views are my own and do not represent any employer or client. This post uses only public sources and contains no non-public operator information. It is not legal advice.

Sources

The White House, Securing the Nation Against Advanced Cryptographic Attacks (EO 14412), June 22, 2026.
Skadden, New Executive Orders and Government Strategy Advance US Quantum Innovation and Mandate Post-Quantum Cryptography Transition, June 2026.
TSA, Security Directives and Emergency Amendments (SD Pipeline-2021-02 series).
Federal Register, Pipeline Corporate Security Reviews and TSA Security Directive Pipeline-2021-02 Series, information collection notice, January 2, 2026.
Federal Register, Enhancing Surface Cyber Risk Management (proposed rule), November 7, 2024.
NIST, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), August 2024.

DOI: https://doi.org/10.5281/zenodo.23130001 (archived on Zenodo)

Text licensed CC BY 4.0. Cite as: Friday Ogochukwu Ikwuogu, “What EO 14412 means for a pipeline operator's certificate inventory,” Quantum-Safe Pipeline Notes, issue 1, https://doi.org/10.5281/zenodo.23130001.

← All issues

Issue 02 · October 2026 slot

Harvest-now-decrypt-later for SCADA telemetry

Friday Ogochukwu Ikwuogu · ORCID 0009-0009-2222-1318 · Published 2026-10-03 · 6 min read

Executive Order 14412 opens by naming the threat that makes post-quantum migration urgent before any quantum computer exists: adversaries recording encrypted U.S. data today so they can decrypt it once a cryptographically relevant quantum computer is available. Security people call it harvest-now-decrypt-later, or HNDL.

HNDL is usually discussed in terms of diplomatic cables, health records, and trade secrets. This post asks a narrower question: does it matter for the telemetry that moves between a pipeline control center and its field sites? My answer is yes, but not where most people look first, and not before a more basic problem.

First, the uncomfortable baseline

HNDL assumes the traffic is encrypted. A great deal of SCADA telemetry is not. Modbus and DNP3 were designed for closed serial networks, and many links still carry them in cleartext, sometimes inside a VPN tunnel across the WAN, sometimes not even that. For cleartext links the threat model is simpler and worse: harvest now, read now. No quantum computer required.

So the first-order fix is still the old one: encrypt and authenticate the links that are not. The quantum question changes how you should do that, because every link you encrypt this year with classical key exchange becomes a link an adversary can record and set aside.

Where the vulnerable math sits in a telemetry path

Quantum attacks threaten the public-key parts of a protocol, the parts that agree on keys and prove identity. The symmetric parts that actually encrypt the bulk data (AES) and authenticate messages (HMAC) are only modestly weakened, and NIST continues to treat AES with 128-bit and larger keys as acceptable. In a typical pipeline telemetry path, the public-key exposure sits in:

WAN VPNs (IPsec with IKEv2), where Diffie-Hellman or elliptic-curve Diffie-Hellman sets up the tunnel keys.
TLS wrapping DNP3 or IEC 60870-5-104 under IEC 62351-3, and TLS to cloud historians and MQTT brokers.
OPC UA secure channels, whose standard security policies use RSA or elliptic curves for key agreement and signatures.
Cellular and satellite backhaul, where the carrier or vendor IPsec configuration decides the algorithms.
DNP3 Secure Authentication, whose session keys are symmetric (HMAC) but whose optional asymmetric update-key change method in IEEE 1815-2012 relies on classical public-key cryptography.

An adversary who records the handshake and the session today can, with a sufficiently capable quantum computer later, recover the session key from the handshake and read everything that followed.

The shelf-life test

The useful tool here is Michele Mosca's inequality. Let x be how long the data must stay confidential, y how long your migration will take, and z how long until a cryptographically relevant quantum computer exists. If x + y is greater than z, data you send today is already at risk.

Nobody knows z. The federal deadlines in EO 14412 (2030 for key establishment, 2031 for signatures) and NIST's proposed transition schedule in NIST IR 8547 (released as an initial public draft in November 2024: RSA and elliptic-curve algorithms at the 112-bit security level deprecated after 2030, and all of them disallowed after 2035) tell you where the government has placed its bet. For an operator, y is the number you control, and for field equipment it is measured in years.

Applying x to telemetry is where judgment comes in. Here is how I classify it:

What crosses the link	How long it stays sensitive (x)	HNDL concern
Individual pressure, flow, and temperature readings	Minutes to hours	Low on its own
Aggregated operating history (normal envelopes, setpoints, seasonal patterns, compressor run profiles)	Years	Moderate: reveals how the system behaves and where its margins are
Network and asset detail visible in traffic (device addresses, models, firmware versions, polling schedules)	Years, until the equipment is replaced	High: a map for a future intrusion
Credentials, keys, and engineering files sent over the link (logins, configuration downloads, ladder logic)	As long as they remain valid	Highest: a recorded password that is never rotated is a future login
Commercial data (nominations, custody-transfer measurement)	Months to years	Moderate

The pattern is that the single reading is rarely the prize. The prize is the accumulated picture, and anything in the stream that stays valid for years.

Integrity is a different clock

HNDL is a confidentiality problem. The more dangerous failure for a pipeline is integrity: a forged command or forged firmware. Forging a signature requires the quantum capability at the moment of attack, so it is not a "harvest now" risk. But it has its own long tail: a firmware-signing key or root certificate deployed today may still be trusted by field devices when that capability arrives. That is why the previous issue put long-lived trust anchors at the top of the certificate inventory.

OT bandwidth makes this an engineering problem, not a checkbox

Post-quantum key exchange is not free on narrow links. Using the sizes in FIPS 203:

An ML-KEM-768 exchange (encapsulation key plus ciphertext) moves 2,272 bytes; a classical X25519 exchange moves 64 bytes, about 36 times less.
On a 9,600 bps serial radio, that ML-KEM payload alone takes about 1.89 seconds to transmit, against roughly 0.05 seconds for X25519, before protocol overhead or retries. At 19,200 bps it is about 0.95 seconds.
Signatures are larger still. An ML-DSA-65 public key plus one signature (FIPS 204) is 5,261 bytes, about 4.38 seconds at 9,600 bps.

On a fiber or LTE link these are rounding errors. On a licensed radio polling dozens of remote sites, they change poll cycles. The practical implications: do key establishment rarely and rekey symmetric sessions in between; terminate post-quantum tunnels at the most capable hop instead of at every RTU; and test on the actual link before committing to a design.

What to do now, in order

Close the cleartext gap. Inventory links that carry SCADA protocols without encryption or authentication. That is today's exposure, quantum or not.
Prefer hybrid key exchange when you encrypt. Hybrid schemes combine a classical algorithm with ML-KEM, so a link is at least as strong as the stronger of the two. The TLS 1.3 hybrid group X25519MLKEM768 ships in OpenSSL 3.5 and is on by default in major browsers, and IKEv2 has standards for adding post-quantum protection (RFC 8784 for mixing in pre-shared keys; RFC 9370 for multiple key exchanges). Support in OT gateways and field devices varies, so check each product.
Use AES-256 for long-lived links. It is cheap insurance and matches NSA's CNSA 2.0 suite.
Shrink what is worth harvesting. Keep engineering downloads and credential exchange off long-haul links where possible, rotate credentials that cross them, and avoid static secrets that never change.
Rank links by shelf life, not by bandwidth. The link carrying configuration files and remote-access sessions deserves post-quantum protection before the link carrying a single tank level.
Put the question to vendors and carriers. Which key-exchange algorithms do your VPN, cellular, and satellite products negotiate, and when will hybrid ML-KEM be supported?

Telemetry is not the crown jewel of a pipeline. But the traffic around it, the maps, credentials, and accumulated operating history, is exactly what someone patient would want to keep. The time to decide which links matter is before the recording becomes readable.

Views are my own and do not represent any employer or client. This post uses only public sources and contains no non-public operator information. Byte counts and transmission times are computed in code/compute_stats.py from the published FIPS parameter sets and exclude protocol overhead.

Sources

The White House, Securing the Nation Against Advanced Cryptographic Attacks (EO 14412), June 22, 2026, Section 1.
NIST, FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, August 2024.
NIST, FIPS 204, Module-Lattice-Based Digital Signature Standard, August 2024.
NIST, IR 8547 (initial public draft), Transition to Post-Quantum Cryptography Standards, November 2024.
IETF, RFC 8784, Mixing Preshared Keys in IKEv2 for Post-quantum Security, 2020; RFC 9370, Multiple Key Exchanges in IKEv2, 2023.
NSA, Commercial National Security Algorithm Suite 2.0 (CNSA 2.0).
M. Mosca, "Cybersecurity in an era with quantum computers: will we be ready?", IEEE Security & Privacy, 2018.

DOI: https://doi.org/10.5281/zenodo.23130292 (archived on Zenodo)

Text licensed CC BY 4.0. Cite as: Friday Ogochukwu Ikwuogu, “Harvest-now-decrypt-later for SCADA telemetry,” Quantum-Safe Pipeline Notes, issue 2, https://doi.org/10.5281/zenodo.23130292.