Post-Quantum Readiness

How Healthcare and Financial Organizations Can Start a PQC Readiness Program

Healthcare and financial organizations face unique PQC readiness challenges with HIPAA, PCI DSS, and DORA compliance. Learn how to start crypto inventory and migration planning in regulated environments.

How Healthcare and Financial Organizations Can Start a PQC Readiness Program

Regulated industries face a unique PQC readiness challenge. They manage the most sensitive, longest-lived data. They operate under the strictest compliance frameworks. And they depend on complex ecosystems of third-party vendors, managed services, and legacy systems that were not designed with cryptographic migration in mind.

Healthcare organizations protect patient data governed by HIPAA. Financial institutions protect transactions, account data, and personally identifiable financial information governed by PCI DSS, DORA, GLBA, and emerging quantum-specific regulatory guidance. Both sectors share a common problem: they cannot migrate to post-quantum cryptography until they know where cryptography is deployed — and most cannot answer that question completely today.

This article provides a practical, phased framework for healthcare and financial organizations to start their PQC readiness program, with specific attention to compliance alignment, vendor management, and executive reporting.

Phase 1: External Cryptographic Posture Baseline (Weeks 1–4)

Start With What Regulators and Auditors Can See

The fastest way to establish a cryptographic baseline is an external posture assessment on every domain your organization owns. This surfaces:

Every publicly visible TLS certificate (algorithm, key size, issuer, expiry)
DNS records and host coverage
HTTP security headers
TLS versions and cipher suites negotiated on each endpoint

External assessment has a key advantage in regulated environments: it requires zero infrastructure changes, zero agent deployments, and zero credential sharing. You can start immediately without a change control board, without security architecture review, and without touching production systems.

Key Questions for Healthcare Organizations

Which patient portals, telehealth platforms, and provider-facing applications use TLS certificates?
Which health information exchanges (HIEs) and EHR integrations terminate TLS on your behalf?
Which business associates (BAs) and covered entities have cryptographic dependencies on your infrastructure?
Are your HIPAA Security Rule technical safeguards — access controls, audit controls, integrity controls, transmission security — mapped to your cryptographic inventory?

Key Questions for Financial Organizations

Which customer-facing services (online banking, mobile apps, payment gateways) use RSA or ECC in their TLS endpoints?
Which third-party processors, ACH gateways, and trading platforms terminate TLS connections to your environment?
Are your PCI DSS 4.0 cryptographic requirements (Requirement 3 for data at rest, Requirement 4 for data in transit) traceable to specific certificates and algorithms?
For EU-regulated entities: does your DORA operational resilience documentation include cryptographic risk?

Phase 2: Internal Crypto Inventory and Compliance Mapping (Weeks 4–8)

Expand to Internal Discovery

After establishing your external baseline, inventory cryptographic dependencies inside your perimeter:

Database encryption at rest (TDE, tablespace encryption, column-level encryption)
Application-level encryption of sensitive fields (PII, PHI, account numbers)
Internal PKI and certificate lifecycle management infrastructure
Cloud KMS keys (AWS KMS, Azure Key Vault, GCP Cloud KMS)
HSM-resident keys and their algorithm configuration
SSH host keys on critical servers
VPN and network encryption configurations

Map Findings to Compliance Frameworks

Create a compliance traceability matrix. For each cryptographic asset, document which regulatory requirement it supports:

| Cryptographic Asset | Algorithm | HIPAA | PCI DSS | DORA | NIST PQC | CNSA 2.0 (NSS only) | |---|---|---|---|---|---|---| | Patient portal TLS cert | RSA-2048 | 164.312(e)(1) | — | — | FIPS 203/204 | N/A — not an NSS | | Payment gateway TLS cert | ECC P-256 | — | Req 4.1 | Art. 7 | FIPS 203/204 | N/A — not an NSS | | DB encryption key | AES-256 | 164.312(a)(2)(iv) | Req 3.5 | Art. 7 | Acceptable | Acceptable | | Vendor API TLS | RSA-2048 | 164.314(a)(2)(i) | Req 12.8 | Art. 25 | Vendor-dependent | Vendor-dependent |

This matrix becomes the foundation for:

Audit evidence packages
Board-level risk reporting
Vendor PQC readiness questionnaires
Resource allocation for migration

Phase 3: Vendor Cryptographic Risk Assessment (Weeks 6–12)

Regulated industries are particularly exposed to vendor-managed cryptographic risk. Healthcare organizations depend on EHR platforms, clearinghouses, and health information exchanges. Financial institutions depend on core banking systems, payment processors, trading platforms, and market data feeds. Each of these vendors terminates TLS on your behalf and controls its own PQC migration timeline.

Structured Vendor PQC Questionnaire

Send every critical vendor a structured questionnaire covering:

PQC roadmap: Do you have a published timeline for migrating from RSA/ECC to NIST PQC algorithms (ML-KEM, ML-DSA, SLH-DSA)?
Hybrid support: Will you support hybrid certificates (RSA + PQC) and hybrid key exchange during the transition period?
CBOM availability: Can you provide a Cryptographic Bill of Materials (CBOM) in CycloneDX format for your platform?
Compliance alignment: How does your roadmap align with NSM-10, CNSA 2.0, DORA, and industry-specific guidance?
Testing and migration assistance: Do you offer test environments with PQC enabled? Will you assist with coordinated migration of customer integrations?
Transparency: How will you notify customers when you change cryptographic configurations?

CipherReady's Vendor PQC Questionnaire is a structured, ready-to-use question set that covers these areas.

Vendor Risk Tiers

Classify vendors by cryptographic risk:

Critical: Vendors with direct access to regulated data; vendors that terminate TLS for customer-facing services; vendors with no publicly stated PQC roadmap
High: Vendors processing PHI/PII/PCI data; vendors with TLS endpoints using RSA-2048 or ECC P-256
Medium: Vendors with published PQC roadmaps; vendors already testing ML-KEM or hybrid TLS
Low: Vendors with no access to regulated data; vendors already supporting PQC algorithms in production

Phase 4: Executive Reporting and Board Communication (Week 12+)

What the Board Needs to Know

Board members do not need to understand lattice-based cryptography. They need to understand:

Current risk level: What is our organization's cryptographic posture today? What percentage of our certificates, algorithms, and integrations are quantum-vulnerable?
Regulatory timeline: What deadlines apply to our organization (NSM-10, DORA, PCI DSS 4.0, state-level healthcare regulations)?
Resource requirements: What people, budget, and tooling do we need for the PQC migration program?
Third-party exposure: Which critical vendors pose the greatest cryptographic risk?
Progress metrics: How will we measure and report migration progress over the next 12, 24, and 36 months?

CipherReady's executive PDF report translates technical cryptographic findings directly into this leadership-ready format.

Establish a Quarterly Review Cadence

PQC readiness is not a one-time assessment. Schedule quarterly reviews that update:

Cryptographic inventory (new domains, expiring certificates, vendor changes)
Readiness scores and risk trends
Vendor PQC questionnaire responses
Regulatory guidance updates (NIST, HHS, PCI Council, EU DORA)
Migration roadmap progress

FAQ

Q: Does HIPAA specifically require PQC migration? A: HIPAA does not yet explicitly reference post-quantum cryptography. However, the HIPAA Security Rule's requirement for encryption as an addressable implementation specification means that organizations must assess whether their encryption is reasonable and appropriate. As NIST PQC standards become the recommended cryptographic baseline, maintaining RSA-only encryption may no longer satisfy this requirement.

Q: Does PCI DSS 4.0 require quantum-safe cryptography? A: PCI DSS 4.0 does not explicitly require PQC algorithms. However, Requirement 4 (protect cardholder data in transit with strong cryptography) and Requirement 3 (protect stored cardholder data) will naturally evolve as "strong cryptography" is redefined in the context of quantum threats. The PCI Security Standards Council is monitoring NIST PQC developments.

Q: What if our core banking/EHR vendor has no PQC roadmap? A: This is a common and serious concern. Start by documenting the gap — include it in your vendor risk assessment and your board-level reporting. Engage the vendor through formal channels (security assessments, contract reviews, procurement requirements). Explore architectural mitigations: can you terminate TLS at your own proxy before traffic reaches the vendor? Can you add an additional encryption layer you control?

Q: How do I justify PQC readiness budget to leadership? A: Frame it as a compliance and risk management program, not a technology project. Reference regulatory timelines (NSM-10, DORA), cyber insurance implications, and the harvest-now-decrypt-later threat to long-lived regulated data. Start with the free external assessment to demonstrate the visibility gap without requiring budget approval.

Start Your Regulated Industry PQC Readiness Program

Run a free external cryptographic posture assessment on a domain you own with CipherReady. You will receive a TLS certificate inventory, readiness score, executive summary, and the foundation for your compliance traceability matrix. No agents, no credentials, no infrastructure changes.

Start Free Readiness Scan →

Healthcare PQC Readiness Guide →

Financial Services PQC Readiness Guide →