Cryptographic Debt Is Becoming An Enterprise Security Risk

For years, the quantum security conversation has had a slightly strange problem. Everyone has been waiting for the computer. We’ve talked about when a cryptographically relevant quantum computer might arrive, how powerful it would need to be and which encryption methods it could eventually break. 

Meanwhile, the practical work enterprises need to do has become much less hypothetical. The National Institute of Standards and Technology (NIST) has standardised post-quantum cryptography (PQC) algorithms, governments are publishing migration timelines and major technology providers are setting quantum-safe targets.

Yet knowing what should eventually replace RSA or elliptic curve cryptography (ECC) doesn’t tell an enterprise where either technology is being used today. That’s a much bigger problem than it sounds. Cryptography has spent decades working its way into applications, identity systems, network protocols, cloud services, databases, devices, APIs and third-party products. 

Some of it is actively managed. Some was configured years ago and hasn’t needed much attention since. Other implementations are buried inside systems maintained by someone else entirely. The result is cryptographic debt: the accumulated risk, complexity and cost created when cryptography becomes difficult to identify, manage or change.

DigiCert’s 2026 Global PKI Modernization Research Report gives us some idea of the scale of the problem. Only 22 per cent of respondents said their organisation had fully assessed its cryptographic libraries and systems for vulnerabilities related to future quantum attacks. Another 36 per cent had only partially done so.

Quantum computing didn’t create this weakness. It’s simply giving enterprises a reason to finally deal with it.

Quantum Migration Is Exposing A Problem Enterprises Already Have

Most organisations didn’t sit down one day and design their entire cryptographic environment. A development team chose a library for one application. An infrastructure team configured Transport Layer Security (TLS) somewhere else. Identity teams introduced certificates for authentication. 

Vendors built cryptography into their products, while cloud services, virtual private networks (VPNs), databases, code-signing processes and connected devices added more over time. Each decision may have been perfectly sensible on its own. Collectively, they create a cryptographic dependency that can stretch across teams, technologies and suppliers.

This is where the difference between known cryptography and embedded dependency becomes important. Known cryptography tells you that a certificate exists, which algorithm it uses or where a key is stored. Dependency tells you what happens if you change it.

An RSA certificate might be easy to identify. 

• But which application expects it? 
• Does an API depend on that application? 
• Does authentication break if the certificate changes? 
• Can the software support a different algorithm through configuration, or will somebody need to rewrite part of it? 
• Does the organisation even control the product involved?

Those questions turn a technical inventory into an enterprise risk problem. And organisations are already struggling with the basics. Entrust and the Ponemon Institute surveyed 4,000 IT, security and risk leaders for their 2026 Global State of Post-Quantum and Cryptographic Security Trends report. 

More than two-thirds, 68 per cent, described managing cryptographic assets as extremely or very difficult. Respondents pointed to problems including fragmented systems, difficulty building accurate inventories and unclear ownership.

Cryptographic debt builds when those dependencies become undocumented, hard-coded, manually managed, poorly owned or difficult to replace. 

For years, much of that debt could remain largely undisturbed because the underlying cryptographic assumptions weren’t changing. PQC migration changes the equation. Suddenly, organisations need to replace technology that was never designed with replacement in mind.

A Cryptographic Inventory Is Necessary, But It Isn't Enough

You can’t migrate cryptography you don’t know exists, which is why discovery is the natural place to start. But a useful cryptographic inventory needs to tell you considerably more than how many certificates you have. NIST defines it as a record of cryptography across systems, applications, services, devices and data flows. 

That can include algorithms, TLS, Secure Shell (SSH), VPNs, keys, certificate chains, code signing and authentication, alongside the systems and data depending on them. The last part changes what the inventory is actually for. Imagine finding 500 instances of quantum-vulnerable public-key cryptography.

Knowing they exist gives you visibility. It doesn’t tell you which one to tackle first. For that, teams need context. Each cryptographic asset should be connected to the business service using it, the data it protects, the owner responsible for it and any technical or supplier dependencies involved. 

They also need to know how long that data must remain confidential and how difficult the cryptography will be to replace. This creates decision-ready visibility. Instead of asking, “Where are we using RSA?”, leaders can start asking, “Where does RSA create the greatest combination of security exposure, business dependency and migration difficulty?”

And those are two very different questions.

Not Every Cryptographic Dependency Has The Same Risk

Once an organisation can see its cryptographic environment properly, replacing everything at once would still be the wrong response. The risk isn’t evenly distributed. Some systems protect information that will lose its sensitivity fairly quickly. Others hold intellectual property, government information, financial records or personal data that may need to remain confidential for years. 

That longer lifespan increases exposure to “harvest now, decrypt later” attacks, where encrypted information is stolen today in the hope that future quantum capabilities will make it readable later. Business criticality changes the calculation too. So does internet exposure, identity dependency, hardware age and the amount of control the organisation has over the system involved.

Then there’s the part that can easily get overlooked: migration difficulty. A highly exposed application that can accept new cryptography through a routine software update may be relatively straightforward to address. A moderately exposed industrial device with a 15-year operating life and limited hardware capacity could take considerably longer.

Third-party systems introduce another layer. Your security team may understand exactly what needs to change and still have to wait for a supplier to support it. This is why PQC prioritisation needs to combine security risk with the expected time, complexity and operational impact of the change.

The UK National Cyber Security Centre (NCSC) expects large organisations and those operating their own IT infrastructure to need two to three years just to complete discovery and assessment, define a migration strategy and build an initial plan. Its current timeline targets completion of PQC migration by 2035.

The European Union is pushing organisations towards action even sooner. Its coordinated roadmap says Member States should begin transitioning to PQC by the end of 2026, with critical infrastructure transitioning as soon as possible and no later than the end of 2030. Those timelines make prioritisation part of the migration strategy, not something to work out once deployment begins.

Treat PQC Migration As A Lifecycle, Not A Replacement Project

It would be convenient if quantum migration worked like a software upgrade. Find the old algorithm, install the new one, test that everything still runs and move on. Cryptographic environments are rarely that cooperative. A more useful approach is to treat PQC migration as a lifecycle: discover, classify, prioritise, replace, test and monitor. 

The objective isn’t only to get quantum-vulnerable cryptography out. It’s to build a repeatable way of managing cryptographic change.

Discover and classify

Discovery needs to continue beyond the first inventory exercise. Applications change. New infrastructure appears. Vendors update products. Certificates are issued and retired. Development teams introduce new libraries. 

So cryptographic discovery works best as an ongoing capability, with assets classified according to their owner, business use, data sensitivity and technical dependencies. Otherwise, the organisation begins working from an inventory that becomes less accurate with every change to the environment.

Prioritise and replace

Once assets have context, migration can be sequenced around actual risk. Some cryptography may be replaceable through configuration. Elsewhere, teams may need software upgrades, architectural changes, new hardware or supplier support.

Organisations may also need periods where traditional and post-quantum mechanisms operate together while systems and partners transition at different speeds. The right migration order will therefore look different for every enterprise. What counts is understanding the trade-off before the change reaches production.

Test and monitor

Replacing the cryptography doesn’t automatically mean the dependent system will behave as expected. PQC can introduce different key, signature and ciphertext sizes, while applications and hardware may have resource or protocol constraints. NIST specifically highlights these resource considerations in its current crypto-agility guidance.

Testing therefore needs to cover interoperability, performance, authentication and the integrations around the system, not simply whether the new algorithm works. Monitoring then closes the loop. New software, certificates, infrastructure or vendor changes can reintroduce cryptography an organisation has already decided to phase out. 

Without continuous discovery, today’s successful migration can gradually become tomorrow’s cryptographic debt.

Crypto-Agility Changes The Long-Term Goal

There are two ways an enterprise can come out of the PQC transition. One is with different algorithms. The other is with a different way of managing cryptography. The second is much more valuable.

NIST describes crypto-agility as an enterprise’s ability to move away from vulnerable cryptographic algorithms and adopt stronger alternatives without major infrastructure changes or unnecessary disruption. That requires more than PQC support. 

It means reducing hard-coded cryptographic choices, establishing ownership, automating lifecycle processes, maintaining accurate inventories and building testing into the way cryptographic change is handled. There are already reasons to do this that have nothing to do with quantum computers.

Public TLS certificate lifetimes, for example, are getting considerably shorter. Under the CA/Browser Forum’s current schedule, the maximum validity period fell from 398 days to 200 days for certificates issued from 15 March 2026. It falls again to 100 days in 2027 and 47 days in 2029.

Managing that pace through spreadsheets, manual processes and fragmented ownership gets difficult very quickly. PQC is therefore less useful as a one-off security project than as a catalyst. It gives organisations a reason to fix cryptographic architecture and management practices that were becoming harder to sustain anyway.

The Questions Security Leaders Need To Answer Now

Quantum readiness doesn’t have to begin with choosing an algorithm. For many organisations, a better starting point is finding out whether they can answer some much simpler questions:

• Can we identify where quantum-vulnerable public-key cryptography is being used?
• Do we know which business systems, workflows and data depend on it?
• Is ownership clear for those cryptographic assets?
• Can we distinguish high-risk dependencies from lower-priority ones?
• Which changes can we make ourselves, and which depend on suppliers?
• Do we know which migrations could take years rather than months?
• Can cryptography be changed without rewriting applications or replacing hardware?
• Can we test those changes safely before they reach production?
• Can we identify vulnerable cryptography if it appears again later?

An organisation that can answer those questions has something more useful than a list of algorithms. It has the beginnings of cryptographic risk management. And that gives leaders a better way to measure readiness. The question isn’t simply, “Have we deployed post-quantum cryptography?”

It’s, “Do we have enough control over our cryptographic environment to change it safely?”

Final Thoughts: Quantum Readiness Starts With Cryptographic Control

Nobody knows the exact date when a cryptographically relevant quantum computer will arrive. Enterprises don’t need that date to start making useful decisions. The work in front of them already exists. 

Years of applications, infrastructure, certificates, devices, cloud services and supplier relationships have created cryptographic dependencies that now need to be understood well enough to change. PQC migration is making those dependencies harder to ignore, but replacing vulnerable algorithms only solves part of the problem.

A stronger outcome leaves the organisation with clearer ownership, better visibility, repeatable migration processes and enough cryptographic agility to handle the next change without starting from scratch. Because PQC almost certainly won’t be the last cryptographic transition enterprises face.

Quantum computing may be what finally forces organisations to understand their cryptographic debt. The bigger opportunity is making sure they don’t spend the next decade accumulating it all over again.

As quantum security moves from standards and deadlines into real architecture and risk decisions, EM360Tech will continue following what that transition means for the teams responsible for keeping enterprise systems secure, resilient and ready to change.