Post-quantum cryptography is often discussed as an encryption problem.
That is only true.
Encryption matters. Long-life sensitive data matters. “Harvest now, decrypt later” matters.
But post-quantum transition is not only about whether someone can read protected information in the future. It is also about whether digital systems can continue to trust identity, permissions, approvals, signatures and administrative actions.
That makes access control central to PQC transition.
For boards, CEOs, CIOs and risk leaders, the practical question is not only:
“Can our data remain confidential?”The better question is:
“Can our systems continue to prove who is allowed to do what?” PQC is about trust, not just secrecy
Modern organisations depend on invisible trust mechanisms every day.
A customer logs into a portal.
An employee accesses payroll records.
A manager approves a payment.
A supplier connects through an API.
A board paper is signed.
A software update is accepted.
An administrator changes a configuration.
A third-party identity provider confirms a user.
Each of these actions depends on more than a password or a login screen.
Behind the scenes, systems may rely on certificates, public-key cryptography, digital signatures, secure key exchange, identity tokens, signed assertions, API credentials and trusted communications between services.
Some of these mechanisms may be affected by post-quantum transition because today’s widely used public-key cryptography includes algorithms such as RSA and elliptic-curve cryptography. NIST has stated that quantum computers could threaten current public-key methods such as RSA and elliptic-curve cryptography, and in August 2024 NIST finalised its first three post-quantum cryptography standards: FIPS 203, FIPS 204 and FIPS 205.
The Australian Signals Directorate recommends that organisations cease use of traditional asymmetric cryptography, including RSA, DH, ECDH and ECDSA primitives, by the end of 2030.
That transition has consequences for access control because access control often sits directly on top of cryptographic trust.
What access control really means
Access control is not just “who has a login”
.
It is the set of rules, systems and evidence that determine:
- who can access which information;
- who can approve which action;
- who can administer which system;
- which application can connect to another application;
- which vendor can access which environment;
- which records can be changed, signed or exported;
- which actions require escalation, logging or review;
- how the organisation proves what happened later.
In a simple system, access control may mean usernames, passwords and roles.
In a modern business, it may involve identity providers, single sign-on, multi-factor authentication, certificates, tokens, privileged-access systems, API keys, service accounts, digital signatures, workflow rules, administrative dashboards and audit logs.
That means PQC transition cannot be limited to the cryptography layer. If the trust mechanisms change, the access-control architecture depending on them must be reviewed as well.
The risk is not only unauthorised reading
Many people hear “cryptography risk” and think only about confidentiality.
That is too narrow.
If cryptographic trust weakens, the risk may include:
- impersonation of a user, employee, supplier or administrator;
- forged approvals or instructions;
- abuse of APIs or service-to-service connections;
- tampering with records or workflow evidence;
- misuse of privileged access;
- fraudulent account recovery;
- disputed digital signatures;
- malicious software updates;
- uncertainty about who performed an action;
- inability to prove that a record, approval or transaction is authentic.
These are access-control problems as much as cryptography problems.
A business can suffer serious damage not only because information was read, but because someone was able to act as if they were trusted (or have authority).
That is the deeper risk.
Where access-control dependencies may hide
Access-control dependencies often sit in places leadership rarely reviews in detail.
They may appear in:
Customer and member portals
Portals control who can view personal information, upload documents, manage accounts, approve requests or interact with sensitive services.
PQC transition should consider how the portal authenticates users, protects sessions, uses certificates, connects to identity providers and records access events.
Administrative dashboards
Internal dashboards often give staff or administrators the ability to view, change, export or approve sensitive records.
If these systems are bespoke or legacy, they may have old access-control logic, weak audit trails or dependencies that are difficult to update.
APIs and integrations
APIs decide which systems can talk to each other.
Access control here may rely on certificates, tokens, signed requests, API keys, service accounts or secure key exchange. If those trust mechanisms change, integrations may need testing, redesign or hardening.
Vendor access
Many vendors require some access to systems, data, support portals or cloud environments.
Vendor access can become a weak point if the organisation does not know which supplier has access, how access is authenticated, how it is logged or how vendor systems will transition to PQC.
Digital signatures and approvals
Contracts, board papers, payroll actions, procurement approvals, software releases and regulated records may depend on digital signatures or signed workflows.
If a signature must remain trustworthy for years, it should be considered in PQC readiness planning.
Privileged access
Administrative accounts can change configurations, create users, disable controls, export data or approve critical actions.
PQC transition should include privileged-access workflows because compromised administrative trust can have consequences far beyond one system.
Software updates and code-signing
Organisations that develop software or rely on signed updates need confidence that updates came from a trusted source and were not altered.
NIST notes that digital signature standards are used to detect unauthorised modifications to data and authenticate the identity of the signatory. That is directly relevant to software updates, code-signing and trusted release processes.
Why legacy access control is a transition risk
Access-control weaknesses are often tolerated because the system “still works”.
That attitude becomes dangerous during transition.
Legacy systems may contain:
- hard-coded roles;
- shared administrator accounts;
- undocumented permissions;
- old authentication libraries;
- brittle API credentials;
- weak logging;
- manual approval workarounds;
- certificate pinning;
- dependencies on unsupported identity platforms;
- custom cryptographic assumptions;
- poor separation between business logic and security logic.
These issues may not be obvious during normal operations. But when cryptographic components, certificates, identity integrations or trusted communications need to change, legacy access-control design can become a blocker.
This is where PQC transition becomes a secure software modernisation issue.
The question becomes:
“Can this system safely adapt when the trust mechanisms underneath it need to change?”
If the answer is no, the organisation may need redevelopment, reinforcement or controlled replacement.
The connection between access control and business continuity
Access control is not only a security function. It is an operational function.
If access control fails, business stops.
- Customers cannot log in.
- Staff cannot access records.
- Payments cannot be approved.
- Vendors cannot support systems.
- Administrators cannot make changes safely.
- APIs cannot exchange data.
- Documents cannot be trusted.
- Audit evidence becomes unreliable.
That is why PQC transition should be viewed through the lens of business continuity.
The goal is not simply to replace vulnerable cryptographic algorithms. The goal is to preserve trusted operation while cryptographic foundations change.
A practical transition plan should ask:
- Which access-control systems are business-critical?
- Which systems control access to long-life sensitive data?
- Which identity providers and authentication flows are involved?
- Which workflows depend on digital signatures or signed approvals?
- Which APIs rely on certificate-based trust or signed requests?
- Which vendor-access pathways are poorly documented?
- Which administrative systems would create high impact if disrupted?
- Which bespoke or legacy applications are least able to adapt?
These questions turn PQC from an abstract cryptography problem into a practical continuity program.
Why governance must include access control
A PQC readiness program should not be owned only by a technical specialist.
It needs governance across security, IT, risk, compliance, operations, legal, procurement and business system owners.
Access control sits across all of those functions.
The security team may understand authentication and controls.
IT may understand infrastructure and identity systems.
Legal may understand retention and evidence requirements.
Compliance may understand audit expectations.
Operations may understand which workflows cannot break.
Procurement may understand which vendors control dependencies.
Business owners may understand who must access what in practice.
If these groups are not aligned, the organisation may miss critical transition dependencies.
A strong governance process should identify:
- system owners;
- data owners;
- access-control owners;
- vendor owners;
- approval authorities;
- escalation paths;
- evidence requirements;
- risk-acceptance decisions;
- change-management responsibilities.
This aligns with Ariadne’s broader assessment skeleton, where governance setup, cryptographic discovery, dependency mapping, vendor assessment, exposure classification, migration strategy and implementation planning form a staged pre-migration assessment process.
What a practical access-control review should include
A PQC-aware access-control review does not need to begin as a deep technical rebuild.
It should begin with visibility.
A practical review should examine:
1. Identity flows
How users, staff, administrators, vendors and systems prove who they are.
2. Permission models
Who can access which information, approve which actions and administer which systems.
3. Cryptographic dependencies
Where certificates, tokens, digital signatures, TLS, key exchange or signed assertions support access decisions.
4. Privileged access
How high-impact administrative actions are authenticated, approved, logged and reviewed.
5. API and service access
How systems authenticate to each other and whether service accounts, keys or certificates are properly managed.
6. Vendor access
Which suppliers have access, how it is granted, how it is monitored and whether vendor PQC roadmaps are understood.
7. Auditability
Whether the organisation can prove who accessed, approved, changed or exported information.
8. Legacy constraints
Which applications are too brittle, undocumented or outdated to support future cryptographic change safely.
The outcome should be a prioritised view of what matters most, what can wait and what requires planning before transition pressure increases.
What leadership should ask now
Boards and executives do not need to inspect certificate stores or review cryptographic libraries personally.
But they should ask management:
- Which systems control access to our most sensitive data?
- Which access-control mechanisms depend on public-key cryptography, certificates, tokens or digital signatures?
- Which identity, portal, API or administrative systems are hardest to change?
- Which vendors control access-related dependencies?
- Can we prove who accessed, approved, signed or changed critical records?
- Which access-control systems are included in our PQC readiness planning?
- Which systems would require redevelopment or reinforcement rather than simple configuration changes?
These questions are simple, but they reveal whether the organisation is treating PQC as a real system-transition issue or as a narrow encryption project.
The Ariadne view
PQC transition should not be separated from access-control modernisation.
For many organisations, the systems most affected by transition will not be abstract cryptography systems. They will be ordinary business systems: portals, APIs, approval workflows, administrative dashboards, identity integrations, vendor access paths, document systems and legacy applications.
That is where trust is enforced.
That is also where Ariadne can help.
Ariadne Thread Solutions supports organisations through:
- PQC readiness assessment;
- governance and discovery;
- cryptographic dependency mapping;
- access-control and identity workflow review;
- secure software modernisation;
- API and integration hardening;
- private AI knowledge systems for transition evidence and internal support;
- practical strategy and implementation planning.
The purpose is not to create panic or replace everything at once.
The purpose is to help leadership understand where trusted access depends on cryptography, which systems are most exposed and what practical transition path should be followed.
The practical conclusion
Post-quantum transition is not only about keeping secrets secret.
It is about preserving trust in digital action.
Who logged in?
Who approved?
Who signed?
Who connected?
Who changed the record?
Who administered the system?
Who can prove it later?
If those questions matter to the organisation, access control must be part of PQC transition from the beginning.
Ariadne Thread Solutions helps organisations assess post-quantum exposure, plan practical transition pathways and modernise the access-control, integration and software systems required for a secure digital future.
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.
