Post-Quantum Cryptography and OT Security: Preparing for 20-Year Asset Lifecycles

In Brief (TL;DR)

OT environments can stay in operation for 20 years or more, potentially outliving the cryptography they rely on. As organizations prepare for post-quantum cryptography, they need to understand which OT assets, identities and systems could be difficult to update - and start planning for crypto-agility, procurement and migration now.

When I look at post-quantum cryptography through an OT lens, I think the problem becomes much more difficult.

Traditional IT environments are used to refresh cycles. Operating systems change. Applications change. Servers get replaced. Cloud platforms evolve. Network devices eventually reach end of life.

OT does not always work like that.

Industrial systems can stay in production for 10, 15, 20 years or longer. That creates a simple but difficult question:

What happens when the cryptography reaches end of life before the physical asset does?

Think about PLCs, industrial gateways, HMIs, embedded controllers, manufacturing equipment, building-management systems and other connected OT assets. Many of these platforms were designed around cryptographic assumptions that were made years ago.

Their cryptographic dependencies can include:

• RSA

• ECC

• Embedded certificates

• TLS

• Firmware signing

• Vendor PKI

• Remote-access mechanisms

• Proprietary protocols

• Hard-coded cryptographic libraries

Now imagine that equipment is expected to stay in service until 2040 or 2045. That changes the migration discussion significantly.

Replacing a web server is one thing. Replacing a critical production asset is something completely different.

Security teams also need to recognize that OT has a different operating model.

Availability matters. Safety matters. Deterministic performance matters. Maintenance windows matter. Vendor certification matters. Operational continuity matters.

You cannot simply push a new cryptographic library into a production control system because a security standard changed. That means OT needs to be part of post-quantum cryptography planning much earlier.

For IT systems, a cryptographic migration may be something that can be planned into a normal technology refresh. In OT, the same change could involve hardware replacement, vendor involvement, recertification, lengthy testing or a carefully managed maintenance window.

The question is therefore not simply whether an OT system uses vulnerable cryptography. It is whether that cryptography can actually be changed when it needs to be.

The other part of this conversation that I think gets overlooked is identity.

OT environments increasingly depend on human identities, privileged identities, device identities, certificates, vendor identities, service accounts, remote-access identities, cloud-connected workloads and machine identities.

So this is not just about encrypting traffic between industrial systems. It is also about trust.

Can I trust this device?

Can I trust this certificate?

Can I trust this vendor connection?

Can I trust this firmware?

Can I trust the identity accessing the system?

That makes PQC an identity and trust issue in OT as well as a cryptography issue.

As more OT environments become connected to enterprise IT, cloud platforms and remote services, the boundaries between IT and OT identity are also becoming harder to separate. Understanding those trust relationships will be an important part of preparing for future cryptographic change.

The equipment being purchased today may still be running when PQC becomes the normal cryptographic baseline. That means quantum readiness needs to start showing up in procurement questions.

For example:

• Can the cryptography be upgraded?

• Can the certificates be replaced?

• Is there a PQC roadmap?

• Does the device support modern certificate lifecycle management?

• Can the firmware-signing mechanism evolve?

• Is the device identity tied to a hard-coded algorithm?

• What happens if the underlying cryptographic library becomes obsolete?

• Will migration require hardware replacement?

These questions are particularly important for assets expected to remain operational for many years.

The decisions made during procurement can determine how difficult a future cryptographic migration becomes.

For long-lived OT assets, quantum readiness is not simply about choosing a new algorithm. It is about whether the technology can adapt when that algorithm eventually needs to change.

That is where crypto-agility becomes important.

Can cryptographic algorithms, certificates, libraries and trust mechanisms be updated without replacing the underlying asset or disrupting operations?

For IT systems, that may be relatively straightforward. For a production line or critical industrial control system, it can be a much bigger challenge.

Planning for crypto-agility now can help organizations avoid being locked into cryptographic choices that become difficult or impossible to change later.

Quantum readiness across OT does not need to start with replacing equipment. It starts with understanding where cryptography, identity and trust sit within the environment - and which assets could create problems further down the line.

Xalient can help organizations with:

• OT asset and cryptographic dependency discovery

• Certificate and machine identity reviews

• Remote-access architecture assessments

• Vendor and OEM quantum-readiness analysis

• IT/OT trust-boundary reviews

• Network segmentation and Zero Trust analysis

• Lifecycle and replacement-risk mapping

• PQC requirements for future OT procurement

• Crypto-agility planning for long-lived assets

The goal is not to tell an operations team to replace everything.

The goal is to identify which assets create future constraints and start planning around them now.

In OT, the most expensive PQC problem may not be a vulnerable algorithm. It may be the asset that cannot be changed.