Your cryptographic dependencies are about to become your biggest vulnerability. As quantum computing advances, the algorithms protecting your authentication systems, key management infrastructure, and encrypted data channels will fail, not in theory, but in practice. The question isn't whether to migrate to post-quantum cryptography, but whether you'll complete the transition before adversaries can harvest and decrypt your data retroactively.
IBM's CISO organization has already started evaluating supply-chain dependencies for quantum-safe cryptography adoption, focusing first on perimeter security and vendor-provided security infrastructure before tackling application-level changes. Critical infrastructure and telecom providers need to adopt post-quantum algorithms before many others, and if you're relying on their services, their timeline dictates yours.
This playbook guides your security team through the vendor assessment and migration planning process you need to start now.
Preparing for Migration
Cryptographic inventory tools. You can't migrate what you can't see. Deploy discovery tools that identify TLS configurations, certificate authorities, key management systems, and cryptographic libraries across your environment. Open-source options include Mozilla's TLS Observatory for external-facing endpoints and OpenSSL's built-in cipher suite enumeration for internal services.
Vendor relationship mapping. Document every third party that handles authentication, secrets management, encryption, or certificate issuance for your organization. Include identity providers, Hardware Security Module (HSM) vendors, certificate authorities, API gateway providers, and any SaaS platform that stores or transmits your sensitive data.
Current cryptographic standards baseline. Catalog which algorithms you're using today: RSA key sizes, elliptic curve parameters, symmetric cipher configurations. Note which systems still run TLS 1.2 versus 1.3, and which certificate chains depend on SHA-256 versus older hash functions. This baseline tells you how far you need to travel.
Executive sponsorship for a multi-year program. Quantum readiness isn't a project; it's a cryptographic modernization program that will span budget cycles. Suja Viswesan from IBM emphasized treating cryptography as an ongoing program, not a one-time upgrade. Secure budget authority and cross-functional alignment before you begin vendor assessments.
Step-by-Step Implementation
Step 1: Prioritize your vendor assessment queue. Start with vendors that provide security infrastructure, not application vendors. Your identity provider, HSM vendor, secrets management platform, and certificate authority must migrate before you can update the applications that depend on them. Critical infrastructure and telecom providers need to adopt post-quantum algorithms before many others, so if you're in financial services, your payment processors and core banking platform vendors belong at the top of your queue.
Step 2: Send the quantum readiness questionnaire. Don't ask vendors if they're "quantum-ready", that term means nothing. Ask specific questions:
- Which NIST-approved post-quantum algorithms (ML-KEM, ML-DSA, SLH-DSA) do you support today?
- What's your timeline for deprecating RSA-2048 and ECDSA P-256 in production?
- Do your products support hybrid cryptographic modes that combine classical and post-quantum algorithms during the transition?
- Have you updated your key derivation functions to accommodate larger post-quantum key sizes?
Request documentation, not assurances. If a vendor can't provide a technical roadmap with algorithm names and deprecation dates, they haven't started planning.
Step 3: Evaluate responses with business context. Viswesan noted that organizations get overwhelmed by discovery volume, you need business context to prioritize. Map each vendor response to your risk register. A certificate authority that won't support ML-DSA signatures until 2028 poses a different risk than a logging platform that still uses RSA for transport encryption. The certificate authority blocks your entire PKI modernization; the logging platform can wait.
Score vendors on a three-tier scale: migration leaders (post-quantum support in production today), migration planners (published roadmap with delivery dates), and migration laggards (no concrete plan). Your procurement and vendor management teams need this segmentation to inform contract renewals and alternative vendor evaluations.
Step 4: Align quantum readiness with protocol modernization. You must modernize protocols as well as algorithms. Many organizations still run TLS 1.2 in production, which doesn't support the cipher suite negotiation flexibility you'll need for hybrid cryptographic modes. Before you can deploy post-quantum algorithms, upgrade your TLS configurations to 1.3, migrate from older key derivation functions to NIST SP 800-108 compliant methods, and ensure your certificate management infrastructure can handle larger key sizes.
Align this work with your existing PCI DSS 4.0 cryptographic modernization efforts. Requirement 4.2.1 already mandates strong cryptography for cardholder data transmission, extend that program to include post-quantum readiness assessments.
Step 5: Integrate quantum readiness into your RBAC and least privilege reviews. Post-quantum key material requires updated access controls. Key Encryption Keys (KEKs) will grow larger, split knowledge procedures for key components need documentation updates, and your HSM access policies must account for new algorithm types. Don't treat quantum readiness as separate from your access control maturity program, align them so you're not conducting redundant reviews.
Validation: How to Verify It Works
Confirm vendor claims in staging. When a vendor claims post-quantum support, test it. Spin up a staging environment, configure hybrid TLS connections using ML-KEM for key exchange, and verify the handshake completes without fallback to classical algorithms. Check certificate chains for ML-DSA signatures. If the vendor can't provide configuration examples or their documentation references algorithms NIST didn't standardize, you've found a gap.
Run cryptographic discovery scans quarterly. Your initial inventory goes stale the moment a developer deploys new code. Schedule quarterly scans that identify new TLS endpoints, certificate issuances, and cryptographic library versions. Compare results against your approved algorithm baseline. New RSA-2048 certificates or SHA-1 signatures indicate teams that haven't received the migration guidance.
Audit vendor SLAs for cryptographic currency. Update your vendor contracts to include cryptographic modernization SLAs. Require vendors to notify you within 30 days of NIST algorithm deprecations, mandate support for NIST-approved post-quantum algorithms within 12 months of standardization, and include the right to audit their cryptographic implementations. Without contractual teeth, vendor roadmaps remain aspirational.
Maintenance and Ongoing Tasks
Treat cryptographic agility as an architecture requirement. The algorithms you migrate to today won't be the algorithms you're using in 2035. Design systems that can swap cryptographic primitives without application rewrites. Use abstraction layers, maintain algorithm negotiation flexibility in your protocols, and avoid hardcoding cipher suite selections in application code.
Establish a cryptographic governance board. Quantum readiness intersects identity management, key management, network security, and application development. Create a cross-functional governance board that meets quarterly to review vendor migration progress, approve new algorithm adoptions, and coordinate deprecation timelines. Include representatives from procurement, they need visibility into which vendors are blocking your migration.
Link quantum readiness to your broader compliance program. Don't run quantum readiness as an isolated initiative. IBM's approach of aligning quantum readiness with other organizational initiatives ensures you're not creating redundant workstreams. When you're conducting PCI DSS segmentation testing, validate that post-quantum algorithms are supported across segmentation boundaries. When you're updating MFA implementations per NIST SP 800-63B, confirm your identity provider supports post-quantum authentication protocols.
Monitor NIST cryptographic standards updates. NIST will publish additional post-quantum algorithm standards and deprecation timelines. Subscribe to NIST's cryptographic standards mailing list, assign someone on your team to review updates monthly, and maintain a decision log that documents why you selected specific algorithms. When auditors or regulators ask about your quantum readiness posture, you'll need evidence of informed decision-making.
Organizations that start vendor assessments now will complete migration before quantum computers break production cryptography. Those that wait will discover their dependencies can't migrate on their timeline.
