Post-Quantum Cryptography Is No Longer a Future Problem

For years, quantum computing appeared in cybersecurity conversations as something organizations could worry about later.

That has changed.

The question is no longer whether enterprises should prepare for post-quantum cryptography.

It is:

Where do we begin?

NIST has already finalized three primary post-quantum cryptography standards that organizations can begin implementing today:

  • FIPS 203 — ML-KEM, for key establishment
  • FIPS 204 — ML-DSA, for digital signatures
  • FIPS 205 — SLH-DSA, an additional digital-signature standard

NIST’s current position is explicit: organizations should begin applying these standards and planning migration from quantum-vulnerable cryptography now. NIST

That does not mean every organization should begin replacing every certificate tomorrow.

It means the migration process needs to begin.

And for most organizations, the first challenge is visibility.


Why Existing Cryptography Is at Risk

Much of today’s digital infrastructure depends on public-key cryptography.

That includes algorithms such as:

RSA

and

Elliptic Curve Cryptography (ECC).

These technologies support critical capabilities such as:

  • TLS
  • VPNs
  • PKI
  • digital certificates
  • digital signatures
  • secure email
  • authentication
  • software signing
  • APIs
  • machine identities

Large-scale, cryptographically relevant quantum computers could eventually undermine important mathematical assumptions protecting widely deployed public-key algorithms.

No one knows exactly when such a machine will exist.

That uncertainty should not be confused with absence of risk.

NIST notes that cryptographic transitions historically take significant time because standards need to move into products, platforms, protocols, and enterprise environments. NIST

For complex organizations, migration may require years of preparation.


The First Mistake: Starting With Algorithm Replacement

Organizations sometimes approach quantum readiness by asking:

“When should we replace RSA?”

That is not necessarily the first question.

Before replacing cryptography, an organization needs to know:

Where is RSA being used?

Where is ECC being used?

Which applications depend on those algorithms?

Which certificates use them?

Which vendors control the underlying implementation?

Which systems contain data that needs protection for many years?

Without those answers, migration planning becomes guesswork.

NIST’s National Cybersecurity Center of Excellence identifies cryptographic discovery and inventory as a starting point for PQC migration. NIST Pages


Step 1: Discover Your Cryptography

Cryptography is rarely centralized.

It exists throughout:

  • web servers
  • applications
  • APIs
  • databases
  • VPN gateways
  • network appliances
  • cloud environments
  • certificates
  • code-signing infrastructure
  • authentication systems
  • IoT devices
  • operational technology
  • third-party products

Some cryptography is easy to find.

Some may be embedded inside libraries or products that security teams do not directly manage.

This is why organizations need a cryptographic inventory.

NIST describes such an inventory as a record of cryptography used across systems, applications, services, devices, and data flows. NIST Pages


Step 2: Identify Quantum-Vulnerable Dependencies

Once cryptographic assets are identified, organizations can begin answering:

  • Which algorithms are in use?
  • Which protocols depend on them?
  • Which certificates rely on quantum-vulnerable algorithms?
  • Which applications depend on those certificates?
  • Which systems cannot easily be upgraded?
  • Which cryptography is controlled by a third-party vendor?

The objective is not merely to create a spreadsheet.

It is to understand dependency.

Replacing one certificate may affect:

  • load balancers
  • applications
  • authentication
  • APIs
  • clients
  • downstream integrations

The migration needs to account for the entire chain.


Step 3: Identify the Data That Matters Most

Not all information requires the same protection horizon.

Some information loses value quickly.

Other information may remain sensitive for:

  • five years
  • ten years
  • twenty years
  • longer

Examples might include:

  • healthcare information
  • intellectual property
  • government information
  • legal records
  • research
  • strategic corporate information

Long-lived information deserves additional attention because of the Harvest Now, Decrypt Later threat.

An attacker does not necessarily need to break the encryption today.

They may capture encrypted data now and retain it until future computing capabilities allow decryption.

NIST specifically identifies long-lived sensitive data as relevant to cryptographic inventory and migration prioritization. NIST Pages


Step 4: Identify Machine Identities

Week 4 discussed the growing importance of machine identity.

That becomes directly relevant to quantum readiness.

Certificates and cryptographic keys often serve as identities for:

  • applications
  • servers
  • workloads
  • devices
  • APIs
  • services

That means one asset may simultaneously represent:

an identity dependency

and

a cryptographic dependency.

For example, a TLS certificate may identify a service while also relying on an algorithm that eventually needs migration.

Machine identity discovery and cryptographic discovery therefore increasingly overlap.


Step 5: Talk to Vendors

Organizations will not control every cryptographic implementation.

Questions for technology providers should include:

Which products currently support NIST-standardized PQC?

What is your PQC roadmap?

Will migration require a software upgrade or hardware replacement?

Will hybrid classical/PQC modes be supported?

Which protocols are affected?

What is your expected migration timeline?

NIST recommends that organizations begin discussing PQC readiness with technology vendors and incorporate PQC support into procurement and modernization decisions. NIST

This is an important point.

Quantum readiness should become a procurement requirement, not merely a security research project.


Step 6: Build a Migration Roadmap

Once organizations understand:

what they have

what is vulnerable

what data matters

what vendors control

they can prioritize.

A practical roadmap may classify systems into tiers.

Priority 1

Long-lived sensitive data and high-value systems.

Priority 2

Critical infrastructure and identity services.

Priority 3

General enterprise workloads.

Priority 4

Systems scheduled for retirement.

This prevents organizations from trying to migrate everything simultaneously.


Crypto-Agility Should Be the Long-Term Goal

PQC migration should not become another once-in-a-generation emergency replacement.

Organizations should use the transition to build crypto-agility.

Crypto-agility means having the ability to:

  • identify cryptography
  • understand dependencies
  • replace algorithms
  • update certificates
  • modify policy
  • test compatibility
  • monitor cryptographic changes

without redesigning the entire environment every time standards evolve.

NIST’s PQC migration project explicitly includes work on crypto-agility strategies and practices. NCCoE

This is ultimately more valuable than simply replacing RSA with a new algorithm.


Quantum Readiness Is an Operational Capability

A one-time assessment establishes a baseline.

But environments continuously change.

New applications appear.

Certificates are issued.

Cloud workloads are deployed.

Vendors introduce new products.

APIs are created.

Machine identities multiply.

Quantum readiness therefore needs to move from:

Point-in-time inventory

to

continuous visibility.

That is where Velocis sees a connection between post-quantum readiness and security operations.


From SOC to Q-SOC™

A traditional SOC monitors:

  • endpoints
  • networks
  • identities
  • cloud systems
  • applications

A Q-SOC™ can extend that operational model toward:

  • machine identities
  • certificates
  • cryptographic assets
  • quantum-vulnerable algorithms
  • migration status
  • crypto-agility

The objective is not to create a separate “quantum SOC.”

It is to make cryptographic risk another security signal.


Where Should Organizations Start?

Start with five questions:

  1. Do we know where public-key cryptography exists?
  2. Do we know which algorithms our critical systems use?
  3. Have we identified long-lived sensitive data?
  4. Are we discussing PQC readiness with strategic vendors?
  5. Can we track migration continuously?

If several answers are no, that is the starting point.

Not algorithm replacement.

Visibility.


Prepare for the Cryptographic Transition

Velocis Technologies helps organizations evaluate quantum readiness across:

  • cryptographic discovery
  • certificate visibility
  • machine identities
  • long-lived data
  • crypto-agility
  • PQC migration planning

CTA

Do you know where quantum-vulnerable cryptography exists in your environment?

Request a Velocis Quantum Readiness Assessment.

→ Explore Quantum Readiness

→ Request a Q-SOC™ briefing

VT
AUTHOR

Velocis Technologies

Managed security operations and licensed investigations, based in Frisco, Texas.