1. Customer portals and login systems
Customer portals are often one of the most visible places where cryptography matters, even though users rarely see it.
When a client logs in, resets a password, receives a verification link, uploads documents or accesses account information, cryptography may be involved in session protection, certificate-based connections, identity tokens, secure communications and authentication workflows.
The question for leadership is not simply:
“Is the portal secure today?”
The better question is:
Which parts of this portal rely on public-key cryptography, certificates, identity providers or third-party services that will need to transition?
This matters because portals often sit at the intersection of customer trust, privacy obligations and operational continuity. If a portal handles sensitive documents, identity information, legal material, financial data or confidential client communication, it should be included in PQC readiness planning.
Potential mal-use may include account takeover, fraudulent document access, forged reset requests, customer profiling, targeted phishing or abuse of customer-specific information exposed through portal traffic or records.
2. APIs and system integrations
Modern businesses run on integrations.
Customer platforms talk to billing systems. Internal applications talk to document repositories. Mobile apps talk to cloud services. Suppliers exchange data through APIs. Reporting tools pull information from operational platforms.
These connections often depend on TLS, certificates, authentication tokens, digital signatures, key exchange or other cryptographic mechanisms.
The risk is that API security is often treated as an application or infrastructure issue, not a cryptographic dependency issue.
A useful question is:
Which APIs carry sensitive or long-life data, and which cryptographic mechanisms protect those connections?
This is especially important for organisations with bespoke systems, complex vendor integrations or customer-facing digital platforms. A PQC transition may require not only changing components, but also testing interoperability across systems that were never designed with cryptographic agility in mind.
Potential mal-use may include unauthorised data extraction, forged system-to-system requests, manipulation of business records, exposure of customer identifiers, abuse of integration credentials or compromise of downstream systems.
3. TLS certificates and secure websites
Every secure website using HTTPS depends on certificates and public-key cryptography.
That includes corporate websites, login pages, payment pages, portals, administrative dashboards, partner platforms, intranets, SaaS tools and internal applications.
Certificates help establish trusted connections. But they also create dependencies: certificate authorities, expiry processes, renewal workflows, configuration standards, web servers, cloud platforms and application frameworks.
In a PQC transition, organisations need to understand:
- which domains and services use certificates;
- who manages them;
- which systems depend on them;
- whether certificate renewal is automated or manual;
- which vendors or platforms control certificate-related updates;
- whether legacy systems can support newer cryptographic requirements.
This is not only a cybersecurity concern. Poorly managed certificate or cryptographic changes can cause outages, failed integrations and service disruption.
Potential misuse may include spoofed services, fraudulent websites, interception of sensitive exchanges, loss of customer confidence or disputes about whether users were interacting with the genuine business.
4. VPNs, remote access and secure administration
Remote access tools often rely on public-key cryptography for authentication, key exchange and secure communication.
That includes VPNs, secure administrative access, remote desktop gateways, privileged access tools, infrastructure management consoles and third-party support channels.
These systems are critical because they often protect administrative access to sensitive environments.
The board-level question is:
Which remote-access and privileged-access systems depend on cryptography that must be reviewed before the post-quantum transition?
If these systems are difficult to upgrade, controlled by vendors or connected to legacy infrastructure, they may need early attention.
Potential misuse may include administrative compromise, unauthorised system changes, data theft, ransomware staging, tampering with logs, or use of legitimate access paths to avoid detection.
5. Digital signatures and document workflows
Many organisations use digital signatures without thinking of them as cryptographic systems.
They may appear in contract signing, legal approvals, board papers, procurement workflows, financial authorisations, software releases, audit evidence, records management, identity verification and regulated documentation.
Digital signatures matter because they support authenticity and non-repudiation: evidence that something was signed by the right party and has not been altered.
If the cryptography supporting a signature becomes vulnerable, the organisation may need to consider how long that signature must remain trusted and whether records require additional validation, timestamping, renewal or preservation controls.
The practical question is:
Which signed documents, approvals or records must remain trustworthy for years?
This is particularly relevant for legal, financial, government, healthcare, insurance and professional services environments.
Potential mal-use may include forged approvals, disputed contracts, manipulated records, fraudulent instructions, challenged audit evidence or uncertainty about whether a document remains trustworthy.
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.
