6. Identity systems and access control
Post-quantum transition is not only about encrypted data. It is also about trust in identity.
Identity and access systems rely on certificates, keys, tokens, signed assertions, secure key exchange, identity federation, multi-factor authentication infrastructure and third-party identity providers.
These systems control who can access sensitive data, approve transactions, administer systems or interact with customers.
That makes them central to transition planning.
Ariadne’s view is that access control deserves special attention because it connects cryptographic trust with operational trust. If an identity workflow is outdated, poorly documented or tightly coupled to legacy systems, PQC transition may expose broader architecture weaknesses.
The key question is:
Which systems decide who can access sensitive information, and how are those trust decisions protected?
Potential misuse may include impersonation of users or administrators, privilege escalation, unauthorised approvals, fraudulent access to customer records, bypassing controls or creating uncertainty about who performed an action.
7. Cloud platforms and SaaS applications
Many cryptographic dependencies are controlled by vendors, not by the organisation directly.
Cloud infrastructure, SaaS products, payment platforms, collaboration tools, document systems, CRM platforms, identity providers and managed security services may all rely on cryptography that the customer cannot directly modify.
This does not remove responsibility from the organisation. It changes the work required.
Instead of rebuilding everything, the organisation must ask better vendor questions:
- What is your PQC roadmap?
- Which services rely on RSA, ECC or related public-key cryptography?
- Which customer configurations may need to change?
- What evidence will you provide?
- What timelines are you working toward?
- Will customers need to update integrations, agents, certificates, SDKs or APIs?
Vendor dependency is not a reason to wait. It is one of the main reasons to begin early.
Potential mal-use may include exposure of hosted records, abuse of shared integrations, compromised collaboration spaces, forged vendor communications, account takeover or failure to provide assurance to customers who ask about supplier readiness.
8. Software updates and code-signing
Software updates often rely on digital signatures to prove that code, packages or firmware came from a trusted source and have not been altered.
This may apply to desktop software, mobile apps, embedded systems, internal tools, firmware, cloud agents, container images, libraries and deployment pipelines.
If an organisation develops software, operates customer platforms or manages internal applications, it should understand how code-signing and release integrity are protected.
Questions to ask include:
- Which applications or packages are signed?
- Who manages signing keys?
- Where are signing keys stored?
- How long must signatures remain trustworthy?
- Which build and deployment systems depend on public-key cryptography?
- Which third-party libraries or tools create additional dependencies?
This is an important area for technology companies and any organisation maintaining bespoke software.
Potential mal-use may include malicious software updates, compromised deployment pipelines, forged release packages, supply-chain compromise or loss of customer trust in the organisation’s software.
9. Backups, archives and long-term records
Some of the most important data is not in active systems. It is in backups, archives, document repositories and historical records.
That creates a different kind of problem.
If encrypted archives are copied today and decrypted later, the business damage may occur years after the original exposure. This is why “harvest now, decrypt later” matters for organisations holding long-life sensitive information.
The key question is:
Which archived or backed-up data would still be damaging if exposed in the future?
This may include client matters, identity records, intellectual property, financial history, health information, legal evidence, board records, commercial agreements or regulated communications.
The issue is not only how data is encrypted today. It is whether the data’s confidentiality life is longer than the expected safe life of the cryptography protecting it.
Potential malicious use may include identity fraud, commercial blackmail, strategic intelligence, legal disadvantage, reputational harm, regulatory exposure or future claims from people whose information was retained and later compromised.
10. Bespoke and legacy applications
The most difficult systems to transition are often the ones built specifically for the organisation.
Bespoke systems may contain old libraries, hard-coded cryptographic assumptions, outdated protocols, undocumented integrations, custom authentication logic or dependencies on infrastructure that no one has reviewed recently.
Legacy systems may be even harder. They may use unsupported copmonents, be fragile, business-critical or connected to workflows that cannot easily tolerate downtime.
This is where PQC becomes a software-modernisation issue.
The organisation needs to know:
- which bespoke systems use cryptography directly or indirectly;
- whether current libraries can be upgraded;
- whether integrations will continue to work;
- whether access-control logic is properly separated from application logic;
- whether the system can support future cryptographic change;
- whether redevelopment is safer than repeated patching.
For some organisations, the PQC roadmap will become part of a broader secure modernisation program.
Potential mal-use may include silent data leakage, weak authentication, fragile access control, unpatchable dependencies, inability to produce audit evidence or operational failure when cryptographic components must change.
Why every system matters
Quantum-vulnerable cryptography is not hiding because someone made a mistake.
It is hiding because cryptography is supposed to be invisible when it works.
The problem is that invisible dependencies are hard to manage during a major transition. Organisations cannot prioritise what they cannot see. They cannot budget for what they have not identified. They cannot ask vendors the right questions if they do not understand where the dependencies sit.
That is why PQC readiness should begin with inventory and prioritisation, not panic.
The first goal is to build visibility:
- Where is traditional public-key cryptography used?
- Which systems protect long-life sensitive data?
- Which dependencies are vendor-controlled?
- Which systems are business-critical?
- Which applications are bespoke, legacy or difficult to update?
- Which changes could create operational disruption?
- Which systems need a roadmap before the transition becomes urgent?
What to do first
A practical first step is a PQC readiness review.
This does not mean replacing every system immediately. It means building a clear view of exposure and priority.
A useful review should identify:
- Long-life sensitive data
Information that must remain confidential for years. - Critical systems
Portals, APIs, identity systems, document repositories, integrations and operational platforms. - Cryptographic dependencies
Use of RSA, DH, ECDH, ECDSA, certificates, TLS, digital signatures, key exchange and related mechanisms. - Vendor-controlled dependencies
Cloud, SaaS, infrastructure, security, payment and platform providers. - Bespoke and legacy systems
Applications that may require redevelopment, reinforcement or architectural change. - Transition priorities
What should be addressed first, what can wait and what requires executive decision-making.
The practical conclusion
Post-quantum risk is not limited to cryptography specialists. It is embedded in the systems that ordinary businesses use every day.
That includes customer portals, APIs, certificates, digital signatures, identity platforms, cloud services, backups, vendor systems and bespoke software.
The risk is also not limited to someone reading information. The greater risk is that exposed data and weakened trust mechanisms can be used to impersonate people, forge actions, manipulate records, attack third parties and undermine confidence in digital systems.
If that harm traces back to data, systems or dependencies your organisation was responsible for protecting, the consequences can return as legal, regulatory, contractual, commercial and reputational damage.
The organisations that prepare well will not be the ones that rush into technical change. They will be the ones that first understand their dependencies, prioritise the systems that matter and create a practical transition path.
PQC readiness starts with finding the cryptography you already rely on.
Only then can you decide what needs to change.
Ariadne Thread Solutions helps organisations assess PQC exposure, map system dependencies, develop transition roadmaps and modernise the access-control, integration and software systems required for a secure post-quantum future.
New to Post-Quantum Risk?
Start With the Plain-English Guide
Post-quantum security can sound technical: public keys, private keys, PKI, certificates, digital signatures and quantum-vulnerable cryptography.
Our short executive dictionary explains the essential terms in plain English.
