The Leadership Gap in Post-Quantum Migration
Nearly half of organizations lack a designated leader for their post-quantum cryptography (PQC) migration, according to research from Axiad. While 75% of organizations maintain updated inventories of certificates, cryptographic keys, and algorithms, this hasn't led to coordinated action. Knowing where your cryptographic assets are doesn't mean you're ready to replace them.
The urgency is real. About 67% of respondents identified "harvest now, decrypt later" attacks as a priority, acknowledging that adversaries are already collecting encrypted data to decrypt once quantum computers become viable. For banks holding customer financial records, transaction histories, and authentication credentials that must remain confidential for decades, this isn't a theoretical risk.
Key Findings
Leadership vacuum creates coordination failure. When Axiad asked who owns PQC migration, 46% of organizations pointed to no one. Another 39% said responsibility was "shared across a team" with no single owner. This matters because PQC migration affects encryption, digital signatures, and authentication across systems that may take years to update. Without one person accountable for timelines, budgets, and testing schedules, your migration becomes a series of disconnected technical projects rather than a coordinated program.
Executives and practitioners see different realities. Confidence in PQC readiness increases with seniority, but drops sharply among PKI specialists who actually manage certificates and keys. This pattern held across multiple readiness measures. Either your executives are reporting readiness your teams can't verify, or your practitioners lack visibility into inventories and assessments happening elsewhere in the organization. Both scenarios delay migration.
Testing lags inventory. About half of organizations have never formally assessed whether their public-facing infrastructure supports post-quantum key exchange. You may know where your TLS certificates live, but do you know which cipher suites your payment gateways negotiate? Which authentication flows depend on RSA-2048? Where ECDSA signatures would need replacement? Inventory without testing leaves you guessing about the scope of your migration.
Competing priorities block progress. Even organizations that consider themselves prepared cited competing security priorities as the primary obstacle to PQC migration, followed by budget constraints and lack of regulatory guidance. Translation: you're waiting for NIST to finalize standards, for your board to fund the work, or for your fraud detection upgrade to finish before you start cryptographic remediation.
What This Means for Your Team
If you're a bank information security officer, you're facing a multi-year cryptographic transition with no clear regulatory deadline and limited vendor support. The absence of a single owner means your PQC work will compete with PCI DSS 4.0 implementation, fraud model updates, and whatever zero-day response lands in your queue next quarter.
Here's the operational reality: your payment HSMs, card authorization flows, and customer authentication systems all depend on cryptographic primitives that quantum computers will break. You can't replace them overnight. Migration requires testing every certificate, key exchange, and signature algorithm across production and disaster recovery environments. It requires vendor coordination for payment processors, core banking systems, and fraud detection platforms. It requires budget cycles, change control windows, and fallback plans.
Without someone responsible for sequencing this work, you'll start migration when a vendor forces your hand or a regulator sets a deadline. By then, you're reacting under pressure instead of planning methodically.
Action Items by Priority
Assign a single owner this quarter. Don't distribute PQC migration across your PKI team, your infrastructure group, and your application security lead. Pick one person to own the program, coordinate dependencies, and report progress to your CISO. This person doesn't need to implement every change, but they need authority to set priorities and allocate resources.
Map cryptographic dependencies before you test algorithms. Start with systems that handle cardholder data, authentication credentials, or wire transfer authorization. Document which protocols, key sizes, and signature schemes each system uses. This isn't the same as your certificate inventory. You need to know which TLS cipher suites your payment gateways accept, which HSM firmware versions support FIPS 140-3 modules, and where your disaster recovery procedures assume specific key exchange mechanisms.
Test one public-facing service for post-quantum readiness. Pick a non-critical API or customer portal and assess whether it can negotiate quantum-resistant key exchange. This test will surface compatibility issues with load balancers, WAFs, and client libraries that your inventory won't reveal. Document what breaks and what configuration changes you'd need at scale.
Close the executive-practitioner visibility gap. If your CISO reports high confidence in PQC readiness but your PKI team can't verify that claim, you have a communication problem that will derail migration. Schedule a working session where practitioners present their actual inventories, testing results, and blockers. Use that session to align your executive roadmap with ground truth.
Prioritize systems with long confidentiality requirements. Customer account data, loan applications, and transaction records must remain confidential for years. These systems face the highest risk from harvest-now-decrypt-later attacks and should move first in your migration sequence. Your session tokens and temporary API keys can wait.
