The PQC problem is not just choosing a new algorithm
The Cybersecurity Insiders article, “Your PQC Plan Trusts the One Thing You May Not Be Checking,” points to an uncomfortable reality for security leaders: a post-quantum cryptography (PQC) program may look mature on paper while still depending on trust assumptions that have not been independently verified.
That distinction matters. Many organizations have begun cataloging cryptographic assets, tracking National Institute of Standards and Technology (NIST) standardization, and asking vendors about quantum-safe roadmaps. Those are necessary steps. But they are not enough if the organization cannot answer a more fundamental question: what entities, systems, certificates, keys, suppliers, and administrative processes are being trusted to make the migration secure?
For a Zero Trust program, this should sound familiar. Zero Trust is not a product purchase or a network segmentation exercise. Its core premise is that trust must be continuously evaluated, explicitly scoped, and never assumed merely because a user, workload, device, or supplier sits inside an approved boundary. PQC migration needs the same discipline.
Why PQC changes the meaning of “trusted”
Traditional public-key cryptography supports a vast amount of everyday digital infrastructure. TLS connections, VPNs, code signing, software updates, document signatures, machine identities, and certificate authorities all rely on asymmetric cryptographic systems. Quantum computing creates a long-term risk because sufficiently capable quantum computers could undermine widely deployed public-key algorithms such as RSA and elliptic-curve cryptography.
The immediate business issue is not necessarily that a cryptographically relevant quantum computer will appear tomorrow. The more urgent issue is the harvest-now, decrypt-later threat. An attacker can collect encrypted traffic or stolen encrypted data today and retain it until future computing capabilities make decryption practical. Information with a long confidentiality life—health records, trade secrets, legal documents, government material, customer identity data, and industrial designs—may therefore need protection before quantum attacks become operational.
Yet PQC is not simply a matter of replacing one cipher suite with another. New algorithms must be implemented correctly, deployed across mixed technology environments, and supported by protocols, certificates, hardware security modules, identity platforms, and vendors. Every one of those dependencies introduces a trust decision.
The hidden dependency: the trust chain
In practice, a migration relies on chains of trust. A company may trust a certificate authority to issue certificates correctly; a cloud provider to protect private keys; a software vendor to implement a hybrid PQC protocol safely; a managed service provider to configure gateways properly; and internal administrators to prevent unauthorized changes to certificate templates, key policies, or identity privileges.
If any link is weak, the organization can deploy a quantum-resistant algorithm while remaining vulnerable to ordinary compromise. For example, an attacker who gains control over a certificate authority, code-signing key, privileged identity, or software-update pipeline does not need a quantum computer to impersonate a service or distribute malicious code.
This is the important Zero Trust implication: PQC reduces a class of mathematical risk, but it does not automatically reduce identity, authorization, supply-chain, or operational risk. A migration plan that treats cryptography as isolated from identity and infrastructure will leave a large blind spot.
What Zero Trust teams should examine first
A useful way to prioritize is to identify the systems that establish, distribute, or validate trust—not only the applications that encrypt data.
1. Inventory cryptographic assets and their owners
Many organizations still cannot produce a reliable inventory of where RSA, elliptic-curve cryptography, certificates, keys, and cryptographic libraries are used. This is often called cryptographic discovery or a cryptographic bill of materials.
The inventory should include:
- Public-facing web and API endpoints
- Internal service-to-service TLS connections
- VPNs, remote access tools, and zero trust network access platforms
- Code-signing and firmware-signing systems
- Email encryption and digital-signature services
- Certificates embedded in devices, containers, applications, and CI/CD pipelines
- Hardware security modules, key management systems, and secrets managers
- Third-party SaaS and managed-service integrations
For each asset, record the algorithm, key length, protocol version, certificate issuer, expiration and renewal process, data sensitivity, business owner, technical owner, and vendor dependency. Without ownership, an inventory is a spreadsheet, not a migration plan.
2. Audit the people and systems that can alter trust
The most consequential question is not only “Which certificates do we use?” It is also “Who can issue, revoke, renew, export, replace, or redirect them?”
Review privileges around certificate authorities, DNS, domain registrars, cloud identity tenants, code-signing services, key management systems, and CI/CD pipelines. Apply least privilege and just-in-time elevation. Require phishing-resistant multifactor authentication for administrators. Log every high-impact change and alert on unusual certificate issuance, policy modifications, key exports, or authorization changes.
This is precisely where Zero Trust provides operational value: authorization should be granular, contextual, and continuously monitored rather than granted because a user belongs to an infrastructure team or connects from a corporate network.
3. Demand evidence from vendors, not roadmap language
Vendors will increasingly market “quantum-safe” capabilities. Security teams should distinguish a future intention from a deployable and auditable capability.
Ask suppliers which PQC algorithms and standards they support, whether they use hybrid modes during transition, how certificates and key lifecycles are handled, what performance trade-offs exist, and whether implementations have undergone independent security assessment. Also ask how quickly they can update vulnerable cryptographic components and how customers receive evidence of those updates.
A vendor questionnaire should include operational questions: Can the customer see cryptographic settings? Can algorithms be changed without downtime? Are machine identities governed through APIs? Are keys customer-controlled or vendor-controlled? What happens when a certificate must be urgently revoked?
Cryptographic agility is a Zero Trust capability
Cryptographic agility means an organization can identify, change, validate, and retire cryptographic mechanisms without rebuilding its entire environment. It is not simply having a configuration menu that lists several algorithms.
True agility requires governance, testing, automation, and rollback procedures. A company should be able to introduce hybrid cryptography where appropriate, test compatibility with partners and legacy systems, monitor failed handshakes, validate performance, and reverse a problematic deployment safely.
This maps directly to Zero Trust’s continuous-verification model. Security controls must adapt as risk changes. When an algorithm becomes weak, a certificate authority is compromised, a supplier is breached, or a device falls out of compliance, access decisions and cryptographic protections need to change quickly.
A practical 90-day action plan
Security leaders do not need to wait for every external standard and vendor product to mature. Over the next 90 days, they can take concrete steps:
- Classify long-lived sensitive data. Identify information that must remain confidential for a decade or longer and map where it is transmitted and stored.
- Create a cryptographic inventory. Start with internet-facing services, privileged access paths, code signing, and high-value machine-to-machine communications.
- Map trust authorities. Document who controls certificate issuance, key storage, DNS, identity administration, software signing, and cloud tenant configuration.
- Reduce standing privilege. Enforce least privilege, phishing-resistant MFA, privileged-session logging, and dual control for critical cryptographic actions.
- Assess supplier readiness. Obtain written PQC migration positions and technical evidence from strategic vendors, especially identity, cloud, networking, PKI, and endpoint providers.
- Run a controlled pilot. Test a PQC or hybrid implementation in a limited environment, measuring interoperability, latency, observability, certificate management, and rollback effectiveness.
The strategic takeaway
The central lesson from this news item is not that organizations should panic or immediately replace every certificate. It is that a PQC program must be treated as a trust-transformation project, not merely an algorithm upgrade.
Zero Trust leaders are well positioned to lead that work because they already focus on explicit verification, identity-centric controls, segmentation, telemetry, and policy enforcement. Those same capabilities help organizations expose the trust dependencies that can derail a quantum-safe transition.
A quantum-resistant cryptographic primitive is valuable. But if the keys are poorly governed, the certificate authority is overprivileged, the vendor implementation is opaque, or an attacker can compromise the software supply chain, the promised security outcome will not materialize. Verify the trust chain now, while there is still time to migrate deliberately rather than react under pressure.
FAQ
What is the biggest PQC risk for a Zero Trust program?
The largest risk is assuming that adopting a post-quantum algorithm automatically makes access and data exchange secure. PQC does not fix excessive privilege, compromised certificate authorities, weak machine identity governance, or insecure vendor implementations. These must be managed through explicit verification and continuous monitoring.
Not necessarily. Organizations should first assess data sensitivity, confidentiality lifetime, exposure, and system dependencies. Prioritize data vulnerable to harvest-now, decrypt-later attacks and systems that are difficult to upgrade later, while building a complete cryptographic inventory and migration roadmap.
What does cryptographic agility mean in practice?
It means being able to discover where cryptography is used, change algorithms and certificates in a controlled way, test compatibility, monitor failures, and roll back safely. It also requires clear ownership, automated certificate lifecycle management, and vendor support for standards-based upgrades.
How can a company evaluate whether a vendor is truly PQC-ready?
Ask for specific supported standards and algorithms, hybrid deployment options, key and certificate lifecycle details, independent testing information, update commitments, interoperability evidence, and administrative controls. A general claim that a product is “quantum-safe” without technical and operational documentation is not sufficient.
Source: Cybersecurity Insiders — Sun, 25 Oct 2026 11:06:26 GMT
