Legacy systems have a strange habit.
They sit quietly in the corner of the organisation, doing something important enough that nobody wants to touch them.
They run the old portal.
They hold the old records.
They connect to the old vendor.
They support the old workflow.
They generate the report everyone still needs.
They authenticate users in a way no one has reviewed for years.
They are not always broken.
That is the problem.
Because systems that still “work” can become the hardest systems to change when the security foundations underneath them need to move.
Post-quantum cryptography transition will expose this issue.
Legacy systems were not built for this transition
Many older systems were designed in a different security era.
They may rely on old libraries, old protocols, old certificates, hard-coded assumptions, unsupported frameworks, custom authentication logic or vendor components that are no longer actively maintained.
Some were built before today’s cloud patterns.
Some were built before modern identity systems.
Some were built before current expectations around logging, auditability and access control.
Some were modified so many times that no one fully trusts the documentation.
This makes them risky during transition rather than making them useless.
PQC transition is not simply a matter of replacing one cryptographic component with another. It may affect certificates, APIs, digital signatures, identity flows, remote access, vendor integrations, software updates and system-to-system communication.
A modern system may be able to absorb those changes with planning.
A legacy system may resist them.
The danger is not always obvious
Many older systems were designed in a different security era.
They may rely on old libraries, old protocols, old certificates, hard-coded assumptions, unsupported frameworks, custom authentication logic or vendor components that are no longer actively maintained.
Some were built before today’s cloud patterns.
Some were built before modern identity systems.
Some were built before current expectations around logging, auditability and access control.
Some were modified so many times that no one fully trusts the documentation.
That does not make them useless.
It makes them risky during transition.
PQC transition is not simply a matter of replacing one cryptographic component with another. It may affect certificates, APIs, digital signatures, identity flows, remote access, vendor integrations, software updates and system-to-system communication.
A modern system may be able to absorb those changes with planning.
A legacy system may resist them.
Legacy risk often hides behind familiar phrases:
“It has always worked.”
“Only one team uses it.”
“The vendor manages that.”
“We will replace it eventually.”
“Nobody knows exactly how it works, but we cannot turn it off.”
“It is not customer-facing.”
“It is too sensitive to touch.”
Each sentence may be understandable.
Together, they describe a system that may become a transition blocker.
The organisation may discover too late that an old application cannot support newer cryptographic requirements, cannot be patched safely, cannot integrate with updated vendor systems, or cannot provide evidence of who accessed, approved, changed or exported information.
That is when a technical dependency becomes a business continuity issue.
Where legacy PQC risk appears
Legacy systems may create PQC transition problems in several ways.
Old cryptographic libraries
The system may rely on libraries that are outdated, unsupported or difficult to replace without rewriting parts of the application.
Hard-coded assumptions
Older software may assume specific algorithms, key sizes, certificate formats or protocols. If those assumptions are buried in code, transition becomes harder.
Certificate pinning and brittle integrations
Some systems are tightly bound to specific certificates, endpoints or vendor configurations. A certificate or protocol change may break the workflow.
Poor access-control design
Older systems may use shared accounts, fixed roles, weak permissions, manual workarounds or custom authentication logic that no longer fits modern security expectations.
Weak audit evidence
If the system cannot clearly show who accessed, approved, signed, changed or exported something, it becomes harder to defend during an incident, audit or assurance review.
Unsupported vendors
The original vendor may be gone, unresponsive, acquired, or unwilling to provide a PQC roadmap. In that case, “waiting for the vendor” may mean waiting for nothing.
Hidden business dependence
The system may look minor on paper but support something operationally critical: reporting, reconciliation, compliance evidence, customer records, membership data, staff access, payments or approvals.
Why this matters to leadership
Legacy system risk is easy to underestimate because it looks technical.
But the consequences are not technical.
A failed transition can cause outages.
A brittle integration can stop a business process.
An unsupported system can block a vendor upgrade.
A weak access-control model can expose sensitive records.
Poor logging can make an incident impossible to explain.
An old workflow can undermine customer, insurer or board confidence.
The leadership question is not:
“Do we still have old systems?”
Most organisations do.
The better question is:
“Which old systems would create business risk if they could not adapt to the post-quantum transition?”
That is the question worth answering early.
Modernisation does not always mean replacement
This is important.
Identifying legacy risk does not mean declaring war on every older system.
Some systems can be isolated.
Some can be wrapped with stronger controls.
Some can be documented properly.
Some can be integrated through a safer API layer.
Some can have access control reinforced.
Some can be scheduled for staged replacement.
Some can remain in place with a clear risk decision and monitoring plan.
The problem is not age.
The problem is unmanaged dependency.
A legacy system becomes dangerous when the organisation does not understand what it does, what it protects, who depends on it, what cryptography it uses, which vendor controls it, and how difficult it will be to change.
The most practical first step
Before migration pressure arrives, organisations should identify systems that may need modernisation.
A useful review should ask:
- Which systems are old, bespoke, unsupported or poorly documented?
- Which systems use certificates, APIs, digital signatures, VPNs, identity providers or secure integrations?
- Which systems handle long-life sensitive data?
- Which systems control access, approvals or administrative actions?
- Which systems depend on vendors with unclear PQC roadmaps?
- Which systems would disrupt operations if changed badly?
- Which systems cannot easily provide audit evidence?
- Which systems may require redevelopment rather than configuration?
These question creates options for companies.
The Ariadne View
PQC transition will not only test cryptography. It will test the organisation’s ability to understand and change the systems it depends on.
For many businesses, the hardest work will not be in the newest cloud platform. It will be in the old portal, the inherited database, the custom workflow, the undocumented integration, the vendor product nobody can replace, and the access-control logic that has grown fragile over time.
That is where Ariadne can help.
Ariadne Thread Solutions helps organisations identify legacy and bespoke systems that may need modernisation during PQC transition. We support readiness assessment, dependency mapping, access-control review, API and integration hardening, secure software redevelopment, and implementation planning for complex cases.
The goal is not to replace everything.
The goal is to know which systems can adapt, which systems need help, and which systems should not be left until the deadline.
Identify systems that may need modernisation.
Not sure where PQC touches your access-control systems?
Start with visibility.
Ariadne’s PQC Readiness Snapshot helps leadership identify sensitive data, critical systems, vendor dependencies and cryptographic touchpoints before transition decisions become urgent.
