You Can’t Replace It. You Must Protect It.

Some of the most important systems in the world were built for a different technological era, long before the quantum era became a consideration in cybersecurity planning. They regulate water supplies, manage industrial processes, support transportation networks and keep power flowing. Many were designed before remote connectivity became routine or cybersecurity became a boardroom concern. Yet these systems remain essential to modern life.

Today, they are expected to withstand threats their designers never anticipated while continuing to perform functions that cannot simply be interrupted. Modernization appears to offer a straightforward answer: replace outdated equipment, upgrade vulnerable software and introduce stronger security controls. But the infrastructure we depend on does not always give us that freedom.

Some of the systems we most urgently need to protect are the ones we cannot afford to replace.

When changing a system becomes a risk

In conventional IT environments, replacing outdated technology is often a matter of planning, investment and execution. Organizations routinely refresh servers, applications and network equipment, sometimes on schedules driven more by procurement cycles than by the actual condition or security requirements of the systems involved. Operational technology, however, operates under different constraints.

An industrial controller may have been installed decades ago and still perform its intended function reliably. Replacing it could mean shutting down a production line, interrupting an essential service or introducing uncertainty into a process where failure carries physical consequences. Even a software update may require extensive testing, manufacturer approval and a maintenance window that rarely arrives at a convenient moment.

This creates a dilemma that conventional cybersecurity advice does not always acknowledge. Leaving an outdated system unchanged may preserve known vulnerabilities, while changing it may introduce operational risks that are equally serious. Neither option is automatically safe, and waiting for the next modernization cycle is not necessarily a strategy.

Equipment remains in service because it works. Replacement budgets move elsewhere, suppliers disappear and engineering knowledge becomes harder to recover. Meanwhile, the environment surrounding the equipment continues to evolve. A system originally designed for isolation may now exchange information with enterprise networks, remote maintenance providers or cloud-based monitoring platforms. Its internal technology may be almost identical to what it was twenty years ago, but its exposure is not.

The architecture around the machine

When a device cannot be fundamentally redesigned, the surrounding architecture becomes especially important. A legacy controller may lack modern authentication capabilities, but access to it can still be restricted. A machine may be impossible to patch immediately, yet its communication pathways can be monitored and controlled.

Protective measures introduced at access points, network boundaries and communication pathways can reduce exposure without requiring equipment to perform functions it was never designed to support. This is one reason Zero Trust principles are increasingly relevant to operational environments.

The central idea is straightforward: access should be explicitly justified and appropriately controlled rather than granted simply because a device or user is already inside a network. Applying that principle to industrial infrastructure, however, requires engineering judgment. Some legacy systems cannot support modern identity protocols, endpoint agents or continuous security checks. Others have strict timing and availability requirements that make intrusive controls impractical.

The objective is to design a security architecture that accounts for those limitations. Network segmentation, controlled remote access, monitoring and carefully placed security gateways can help reduce the opportunities for compromise. Their effectiveness depends on the environment, the threats being addressed and the consequences of disrupting normal operations.

These measures do not remove every weakness from the underlying equipment, but they can make those weaknesses substantially harder to exploit.

Cybersecurity becomes an operational decision

A vulnerability assessment alone cannot determine which protective measures make sense. A technically outdated device may support a function that cannot tolerate even a brief interruption. Another system may have similar vulnerabilities but operate within a tightly controlled environment with limited external exposure. The appropriate response depends on more than the technical severity of the vulnerability.

Security teams need to understand what the equipment actually does, what happens when it fails and which changes can be introduced without compromising safety or availability. That knowledge rarely sits within the cybersecurity department alone. It belongs to engineers, operators, equipment manufacturers and the people responsible for keeping essential services running.

Instead of treating operational constraints as obstacles to a security plan, we should recognize them as part of the security problem itself. A control that improves protection against a cyberattack but creates an unacceptable risk of physical disruption is not necessarily an improvement. In critical infrastructure, the ability to keep operating is part of what we are trying to protect.

The quantum complication

The transition to post-quantum cryptography (PQC) brings this challenge into sharper focus. Modern IT systems may be able to adopt new cryptographic algorithms through software updates, hardware upgrades or planned infrastructure changes. Some industrial and embedded systems have no comparable path. They may depend on proprietary protocols, limited processing resources or manufacturers that no longer support the equipment. Their cryptographic mechanisms may be deeply embedded in devices expected to remain operational for many more years.

Encryption is only part of the problem. Authentication, digital signatures, firmware integrity and trusted communications can all depend on cryptographic mechanisms that may eventually require replacement. The operational lifetime of a system can therefore extend well beyond the useful security lifetime of some of the technologies protecting it.

This does not mean every legacy device must immediately become post-quantum capable. Organizations need to understand where quantum-related risks exist and determine which protections can be changed directly, which depend on suppliers and which may require architectural measures outside the device.

A modern security gateway, for example, may help protect communications across a vulnerable network segment without modifying the legacy equipment itself. But that protection has boundaries. Securing a communication channel does not automatically secure the device, its firmware or every authentication mechanism on which it depends.

A compensating control is valuable because of the specific risk it reduces, not because it makes the underlying system secure in every respect. That distinction should guide both technical decisions and the claims made about them.

Start where failure matters most

For organizations responsible for essential infrastructure, the most useful starting point may not be the oldest equipment or the longest list of vulnerabilities. I would begin with one operational function whose failure would have serious consequences.

Identify the devices, communication pathways, suppliers and access mechanisms that keep that function running. Then work through three decisions.

What cannot safely change? Identify equipment and processes that cannot be modified, patched or replaced without unacceptable disruption. Verify those constraints with the people who operate the systems.

What can be protected around it? Examine remote access, network segmentation, authentication, monitoring and communication boundaries. Look for measures that reduce meaningful exposure while preserving operational safety.

What must remain adaptable? Determine where future changes, including post-quantum protections where appropriate, could be introduced without redesigning the entire environment.

This exercise will not produce a complete modernization plan, but it should provide a clearer picture of the risks that matter, the constraints that are real and the protective measures the organization can implement.

It also creates a basis for more productive conversations with technology suppliers. Rather than asking whether a product is secure or quantum-ready, organizations can explain the operational problem they need to solve and evaluate whether the proposed solution addresses it.

Protecting what must endure

Technology moves quickly. Critical infrastructure rarely does. The systems supporting electricity, water, manufacturing and transportation are built around investments, engineering decisions and operational commitments that can last for decades. Their security cannot depend on the assumption that everything vulnerable will soon be replaced, nor should the limitations of existing equipment become an excuse for accepting avoidable risk.

We need architectures that allow protection to evolve even when the systems underneath them cannot. That requires more than new cryptography, stronger access controls or another generation of security products. It requires understanding the operational environment well enough to introduce change where it helps and exercise restraint where change itself could cause harm.

The quantum transition makes this tension more visible, but the underlying challenge is much older. We have built a world that depends on technology designed to last, and we must protect it in a world where threats change much faster than the infrastructure itself.

The measure of successful modernization is not simply what we replace. It is what we can continue to protect.

Next: Trust Is Not a Permanent Permission. As machines, applications and automated systems communicate with increasing independence, what should it actually take for one system to trust another?