Post-Quantum Cryptography for Companies
Post-quantum cryptography is not only an algorithm change.
For companies, it is a visibility, ownership, and migration-planning problem.
Cryptography is hidden inside websites, VPNs, certificates, cloud services, software updates, identity systems, supplier platforms, hardware, firmware, and long-term data storage.
The first useful business question is: where do we depend on cryptography that may need to change, who controls it, and how difficult will the change be?
The Page in One Picture
Identify your position
Are you an urgent adopter, regular adopter, or cryptography expert?
Diagnose exposure
Find cryptography, systems, data, vendors, certificates, protocols, and owners.
Assess risk
Look at data lifetime, business impact, quantum-vulnerable cryptography, and migration effort.
Plan actions
Set priorities, involve teams, update policies, and align vendor roadmaps.
Execute carefully
Test changes, avoid new vulnerabilities, and improve crypto-agility for future changes.
persona → diagnosis → risk → plan → careful execution
Why Companies Should Care
Cryptography is part of normal business infrastructure
Most companies use cryptography every day without seeing it directly.
It protects websites, VPNs, customer portals, digital signatures, software updates, cloud platforms, identity systems, payment systems, backups, archives, supplier connections, network appliances, and embedded devices.
This means PQC is not only a security-team topic. It can affect IT operations, risk management, procurement, compliance, legal archives, software development, vendor management, product security, and critical infrastructure.
The problem is hidden dependency
A company may know its servers, applications, and suppliers.
But it may not know which cryptographic algorithms are used, which certificates depend on RSA or ECC, which products contain hardcoded cryptography, which vendors control the crypto layer, which systems are difficult to update, or which data must remain confidential for many years.
That lack of visibility is the first business problem. Without visibility, migration planning becomes guesswork.
First Decision — What Type of Organisation Are You?
Not every organisation has the same urgency.
A useful first step is to decide which broad PQC persona fits the organisation.
Urgent Adopter
Handles long-lived sensitive data, critical systems, or long-lived infrastructure.
Start diagnosis and planning early.
Regular Adopter
Uses cryptography, but does not have the same long-term or critical exposure.
Start no-regret work and monitor guidance.
Cryptography Expert
Provides cryptographic products, infrastructure, standards, or expertise to others.
Prepare for customer questions and product migration.
Many companies may fit more than one category.
A supplier can inherit urgency from the organisations it serves. That is why supply-chain position matters.
Urgency Signals
You may need earlier action if you have:
Starting early does not mean replacing everything immediately.
It means understanding exposure before time pressure appears.
What Is Actually Changing?
The threat model is changing
Today’s public-key cryptography is designed to resist attacks from classical computers.
Future large-scale quantum computers may be able to attack some of the mathematical problems used by today’s public-key systems.
The main concern is public-key cryptography, especially areas such as RSA, Diffie-Hellman, ECDH, ECDSA, elliptic-curve cryptography, and some certificate and signature use cases.
This does not mean every type of encryption fails in the same way. It means the public-key layer needs serious attention.
Standards are no longer only theoretical
Post-quantum cryptography has moved from research into standardisation and implementation planning.
For companies, the question is no longer only: will post-quantum cryptography become real?
The better question is: where will we need it, who controls those systems, and how long will migration take?
Main Visual Block — Company PQC Readiness Filter
This is a practical decision filter. The factors combine to create business priority; it is not a strict mathematical formula.
What must stay confidential for years or decades?
Where do we use RSA, DH, ECDH, ECDSA, certificates, signatures, TLS, VPNs, or PKI?
Who owns the system, product, certificate, vendor, or risk?
Can this be patched, configured, replaced, or only changed by the vendor?
What should be reviewed, tested, replaced, or tracked first?
data lifetime + crypto exposure + ownership + migration effort = business priority
The Real Business Risk
Long-lived confidential data
Some data loses value quickly. Some data remains sensitive for years.
Examples include legal records, health records, identity data, financial records, industrial designs, employee records, government-related data, M&A documents, long-term contracts, and critical infrastructure information.
If data must remain confidential for a long time, it may need earlier attention. This is where Harvest Now, Decrypt Later becomes a business risk.
Long-lived systems and products
Some systems are still in use decades after they are designed.
Examples include industrial control systems, cars, satellites, payment terminals, smart meters, medical devices, telecom equipment, energy infrastructure, sensor networks, and firmware-based products.
These systems may be difficult to update later. If a product is being designed today and will still be deployed in ten or twenty years, PQC readiness belongs in the design discussion now.
Vendor-controlled cryptography
Many companies do not control all the cryptography they rely on.
It may be inside SaaS platforms, cloud services, identity providers, managed security products, network equipment, payment providers, industrial vendors, software libraries, hardware modules, and supplier portals.
This makes vendor evidence important. A vague statement such as “we are quantum-safe” is not enough.
A better vendor answer explains where cryptography is used, which algorithms are used, what the migration roadmap is, what is configurable, what is hardcoded, what is already supported, what is still planned, and what evidence is available.
No-Regret Moves
Some work is useful even if the quantum timeline changes.
These are no-regret moves because they improve cryptographic management in general.
- Assess supply-chain dependencies.
- Start cryptographic asset management.
- Create or improve a cryptographic inventory.
- Review cryptographic policies.
- Add quantum risk to existing risk management.
- Estimate migration cost and effort.
- Track regulatory and standards developments.
- Prepare a back-up plan for unexpected changes.
- Collaborate with peers and sector groups.
These actions help with PQC.
They also help with ordinary cryptographic incidents, such as key compromise, certificate expiry, weak algorithms, and vendor security issues.
Simple Priority Matrix
A company does not need to fix everything at once.
It needs to know what deserves attention first.
Serious Readiness vs Weak Readiness
Serious Readiness
Cryptographic assets are being discovered.
Findings are connected to systems, owners, vendors, and business context.
Long-lived data is identified.
High-risk systems are prioritised.
Vendors are asked specific, evidence-based questions.
Cryptographic policies are reviewed.
Quantum risk is integrated into existing risk management.
New systems are designed with crypto-agility in mind.
Migration is planned in phases.
Weak Readiness
Only public websites are checked.
Only certificates are scanned.
There is no view of long-lived data.
All findings are treated the same.
Vendors are asked vague questions.
Policy is not updated.
PQC is treated as a separate side project.
Legacy and embedded systems are ignored.
The plan depends on waiting for perfect tooling.
The difference is not the size of the document.
The difference is whether the company can make decisions.
Practical Example
The Company
A medium-sized company has public websites, employee VPN, customer portal, cloud identity provider, code-signing process, network appliances, SaaS platforms, long-term document archive, supplier portals, and industrial or operational systems.
The security team starts with visible TLS certificates. That is useful, but incomplete.
What the company needs next
- Which certificates are business-critical?
- Which systems use RSA or elliptic-curve cryptography?
- Which signatures protect software updates or documents?
- Which vendors control key exchange, certificates, or crypto libraries?
- Which data must stay confidential for more than 10 years?
- Which systems cannot be upgraded quickly?
- Which new purchases should include PQC-related requirements?
- Which supplier relationships create inherited risk?
This is the point where PQC becomes a management topic.
Not because management needs to choose algorithms.
Because management needs to support visibility, ownership, budget, vendor pressure, and realistic planning.
Recommended First Steps
This is the practical path from awareness to readiness.
Determine your PQC persona
Ask whether the organisation is closer to urgent adopter, regular adopter, or cryptography expert. Also check whether supplier or customer relationships change the answer.
Start crypto discovery
Look for cryptography in TLS, VPNs, PKI, certificates, signatures, identity systems, software updates, cloud services, vendor products, and long-term data stores.
Build a first cryptographic inventory
Do not wait for the perfect CBOM. Start with a practical inventory that connects system, cryptographic use, algorithm or protocol, owner, vendor, business importance, data lifetime, migration effort, and evidence source.
Run a quantum risk assessment
Assess quantum weakness of the cryptography, business impact if the cryptography fails, and time and effort needed to migrate. The output needs to be useful enough to prioritise action.
Ask better vendor questions
Ask for cryptographic inventory information, PQC roadmap, supported algorithms, hybrid or transition options, configurability, hardcoded cryptography, testing plans, evidence, and scope limitations.
Plan migration and improve crypto-agility
Focus first on long-lived data, critical systems, internet-facing services, hard-to-upgrade systems, vendor-controlled platforms, and new procurements. Design new systems so that cryptography can be changed more easily later.
Management Questions
Weak Questions
- Are we quantum-safe?
- Can we just buy a tool?
- Can IT handle this later?
- Can vendors tell us when it matters?
Weak questions lead to vague answers.
Good questions create visibility and accountability.
Better Questions
- Do we know which PQC persona fits us?
- Do we have a cryptographic inventory?
- Which systems use quantum-vulnerable public-key cryptography?
- Which data has long confidentiality requirements?
- Which vendors control cryptography for critical services?
- Do we have evidence, or only assumptions?
- Which systems are hard to upgrade?
- Which new procurements should include PQC readiness questions?
- What no-regret moves can we start this quarter?
Role-Based Next Actions
These are short pointers.
Each role has its own dedicated guide.
Management
- Set the priority.
- Ask for visibility.
- Support ownership.
- Approve a realistic roadmap.
- Avoid last-minute migration pressure.
IT and Security
- Find cryptographic assets.
- Review certificates, protocols, libraries, and systems.
- Create a cryptographic inventory.
- Test upgrade paths.
- Plan crypto-agility.
Compliance and Procurement
- Ask vendors for evidence.
- Update supplier questionnaires.
- Track roadmap commitments.
- Review contracts and assurance documents.
- Connect PQC readiness to regulatory and risk requirements.
Product and Engineering
- Avoid hardcoded cryptography.
- Design for algorithm change.
- Track dependencies.
- Review software update and signing mechanisms.
- Plan for long product lifetimes.
Common Misunderstandings
“PQC is only a problem for banks and governments.”
No.
Banks, governments, and critical infrastructure may face earlier pressure, but ordinary companies also depend on public-key cryptography.
The practical question is not: are we important enough to care?
The better question is: which data, systems, products, vendors, and dependencies would be difficult to change later?
“We can wait until quantum computers are ready.”
That may be too late for some systems.
Migration can take years because cryptography is embedded in products, protocols, certificates, libraries, hardware, firmware, contracts, and vendor roadmaps.
Waiting also creates procurement risk. Systems bought today may still be in use when PQC requirements become more concrete.
“A tool will find everything.”
Tools help, but they do not replace ownership and context.
A scan may show a certificate or protocol.
It may not show business importance, data lifetime, vendor responsibility, upgrade difficulty, contract constraints, or operational impact.
A readiness assessment needs both technical evidence and business context.
Decision Box
When Should a Company Start?
A company should start now if it has any of these:
Starting does not mean replacing everything immediately.
Starting means creating visibility and avoiding avoidable surprises.
What to Remember
One-Sentence Summary
For companies, post-quantum cryptography is a visibility, ownership, and migration-planning problem before it is an algorithm deployment problem.
Three Key Points
- The first serious step is to find where cryptography is used.
- The highest priorities are long-lived data, critical systems, vendor-controlled cryptography, supply-chain dependencies, and hard-to-upgrade assets.
- A company does not need panic. It needs visibility, evidence, ownership, and a phased plan.