PQC Readiness Shouldn’t Depend on Infrastructure Readiness
The quantum threat has moved firmly onto the security agenda. Yet understanding the threat may prove easier than doing something about it.
For many organizations, the real problem sits deep inside their existing IT estate.
Taken together, those findings expose the real PQC challenge. Organizations are most concerned about the systems that are hardest to change, while almost all acknowledge that making those environments crypto-agile will be a major undertaking. The technology carrying some of their most important data could become the very thing slowing their response to cryptographic change.
How do you change the protection around sensitive data when the systems carrying that data were never designed to change with you?
Legacy systems weren’t built for continual cryptographic change
Legacy infrastructure remains deeply embedded across major organizations. Banks still depend on decades-old applications to process critical transactions. Hospitals operate medical systems that can’t simply be upgraded without cost, disruption or regulatory implications. Government agencies, manufacturers and critical infrastructure providers face similar constraints.
These systems remain because they perform important jobs.
Replacing them can mean rewriting applications, changing network architecture, recertifying equipment, disrupting operations and committing significant budget to programs that may take years to complete.
That creates a serious problem for PQC.
A conventional cryptographic migration can require changes across applications, protocols, hardware, operating systems and network infrastructure. When those dependencies stretch across hundreds or thousands of systems, cryptographic change becomes tied to the pace of infrastructure change.
The 92% figure should therefore concern security leaders.
PQC migration may be the immediate challenge, but the underlying problem runs deeper. Organizations have built environments where changing cryptography can demand major changes to the systems around it.
That model won’t serve businesses well in an era when cryptographic standards need to change faster.
PQC readiness shouldn’t depend on infrastructure readiness
Waiting for every legacy system to be modernized creates an uncomfortable dependency.
The systems that take longest to replace can carry some of an organization’s most sensitive information. Financial transactions, patient information, intellectual property, government data and operational records don’t become less valuable because the application handling them happens to be 20 years old.
Yet a security strategy tied to modernization can leave that data waiting for protection.
This can appear to leave organizations with a choice between accelerating expensive infrastructure programs or accepting prolonged exposure while modernization continues.
There needs to be another route.
Security teams need the ability to change how sensitive data is protected without having to change every application, device and platform carrying it at the same time.
That capability is crypto-agility.
PQC is one migration. Crypto-agility prepares you for what comes after
There’s a danger in treating PQC as a destination.
Organizations could spend years completing a major migration, only to discover that the same architectural dependencies remain when cryptographic requirements change again.
Standards change. Algorithms can be deprecated. Vulnerabilities emerge. Regulatory requirements develop. New threats place new demands on existing controls.
If every cryptographic change requires application redevelopment, infrastructure replacement and another multi-year transformation program, security teams remain trapped by the same problem.
Crypto-agility changes that equation.
The objective is to give organizations the ability to adapt the protection applied to sensitive data as requirements change, without forcing corresponding changes across the entire infrastructure estate. That distinction matters.
Infrastructure modernization can continue. Organizations still need to retire technical debt, improve performance and replace unsupported systems. But cryptographic security shouldn’t have to move at the same speed.
Modernization and data protection can move at different speeds.
Separate the data protection problem from the infrastructure problem
Making those two timelines independent requires a different approach to protection.
Rather than depending on every application and infrastructure component to provide the required cryptographic capability, organizations can apply protection to sensitive data flows themselves.
That changes the scope of the problem.
A legacy application doesn’t necessarily need to understand the latest cryptographic standard. An aging device doesn’t necessarily need to be rebuilt. A critical platform doesn’t necessarily need to be taken offline simply because the organization needs to change how the data traveling between systems is protected.
Security teams gain a control point that can adapt independently of the infrastructure underneath it. Infrastructure modernization can continue according to operational priorities and budgets, while data protection changes at the pace security demands.
For organizations facing the scale of PQC migration, that separation can turn what might otherwise become a multi-year infrastructure dependency into a focused data protection challenge.
Make protection independent of infrastructure
This is where the principle becomes practical.
Certes DPRM (Data Protection & Risk Mitigation) applies protection at the data-flow level, independently of the applications and infrastructure carrying that data. Organizations can address PQC exposure across legacy and modern environments without waiting for infrastructure replacement or extensive application reengineering.
For security teams facing years of modernization work, this creates a faster route to PQC readiness. Existing systems can continue operating while the protection applied to sensitive data in transit changes around them. When cryptographic standards change again, security teams can adapt that protection without forcing another round of application redevelopment or infrastructure replacement.
Protect without disruption. Business-critical systems can remain in place. Organizations don’t have to rip and replace infrastructure simply to strengthen the protection applied to sensitive data in transit.
Move faster. Removing application and infrastructure dependencies shortens the path to stronger protection. Security teams can address exposure now rather than tying PQC readiness to multi-year modernization programs.
Protect data wherever it travels. Legacy and modern systems rarely exist in isolation. DPRM provides a consistent way to protect data in transit across physical, virtual, cloud and legacy environments, helping prevent older technology from becoming a gap in the organization’s PQC strategy.
Stay ready for what changes next. Crypto-agility gives security teams a control point for future cryptographic change. As standards change, organizations can adapt the protection applied to sensitive data without starting another application or infrastructure transformation.
The result is a different path to PQC readiness. Protect sensitive data now. Continue infrastructure modernization according to business priorities. Adapt protection as cryptographic standards change, without allowing the infrastructure carrying that data to dictate the pace of security.
Don’t make your oldest systems the deadline for your PQC strategy
The 78% of organizations concerned about legacy systems have good reason to be.
Legacy technology creates dependencies. When cryptographic change depends on those systems changing too, the oldest and hardest to modernize parts of the estate can dictate the pace of PQC readiness.
But addressing PQC exposure and replacing legacy infrastructure don’t need to happen on the same timeline.
Protect the sensitive data first. Continue modernizing infrastructure according to operational priorities, budgets and business requirements. Build crypto-agility so future cryptographic change doesn’t trigger another costly transformation program.
PQC readiness shouldn’t depend on infrastructure readiness.
Organizations that separate those two challenges can start protecting sensitive data now, continue modernization on their own timetable and remain ready to change protection again when cryptographic standards demand it.