CBOM for Healthcare: Protecting Patient Data with Cryptographic Inventory and PQC

Healthcare’s Unique Cryptographic Challenge

Healthcare organizations face a cryptographic challenge unlike any other industry. Protected Health Information (PHI) has an effectively indefinite confidentiality requirement — a patient’s medical records, genomic data, and health history remain sensitive for their entire lifetime and potentially beyond. This makes healthcare one of the most HNDL-exposed sectors in the economy.

The convergence of factors makes healthcare cryptographic management exceptionally complex:

• Indefinite data sensitivity: Unlike financial data with defined retention periods, PHI is sensitive for a patient’s entire lifetime
• Regulatory obligation: HIPAA requires encryption as an addressable safeguard, but increasingly treats it as an expected standard
• Medical device diversity: Connected devices from dozens of manufacturers with varying cryptographic capabilities and update cycles
• Interoperability mandates: HL7 FHIR, DICOM, and health information exchange requirements mean data flows across organizational boundaries
• Legacy systems: Clinical systems with 15-20 year lifecycles running outdated cryptographic implementations
• Life-critical systems: Some medical devices cannot tolerate the performance overhead of cryptographic upgrades without clinical validation

A CBOM is the essential tool for gaining visibility into this complexity and planning a defensible path to quantum-safe healthcare.

HIPAA and Cryptographic Requirements

HIPAA Security Rule: Encryption Provisions

HIPAA’s Security Rule addresses encryption through:

Provision	Requirement	Type	Interpretation
§164.312(a)(2)(iv)	Encryption and decryption (at rest)	Addressable	Must implement or document why not
§164.312(e)(2)(ii)	Encryption (in transit)	Addressable	Must implement or document why not
§164.306(a)(1)	Ensure confidentiality of ePHI	Required	Encryption is primary mechanism
§164.306(a)(2)	Protect against anticipated threats	Required	Quantum threat is now anticipated

Critical nuance: “Addressable” in HIPAA does not mean optional. It means organizations must either implement the safeguard or document why an equivalent alternative provides adequate protection. In 2026, with encryption freely available, regulators view encryption as the expected standard.

HHS Breach Safe Harbor

HIPAA’s breach notification safe harbor provides that encrypted PHI, if breached, is not considered a reportable breach — provided the encryption meets NIST standards:

• PHI encrypted with NIST-approved algorithms at appropriate key lengths is exempt from breach notification
• If PHI is encrypted with deprecated algorithms (e.g., DES, RC4), the safe harbor may not apply
• Quantum risk question: Will regulators eventually consider RSA-encrypted PHI as inadequately protected once PQC standards exist?

This creates a direct line from cryptographic algorithm choice to breach reporting obligations — making CBOM essential for understanding which PHI is protected by safe-harbor-qualifying encryption.

2024-2025 HHS Cybersecurity Requirements

HHS has proposed enhanced cybersecurity requirements for HIPAA-covered entities including:

• Mandatory encryption for ePHI at rest and in transit (no longer addressable)
• Technology asset inventory including cryptographic capabilities
• Vulnerability scanning covering cryptographic configurations
• Multi-factor authentication with specific cryptographic backing

These proposed rules align with CBOM capabilities, making early adoption a strategic advantage for compliance.

HNDL Risk for Healthcare Data

Why Healthcare Has Maximum HNDL Exposure

Factor	Healthcare Impact	Risk Assessment
Data lifetime	Patient lifetime + estate	50-80+ years
Sensitivity	Immutable personal data (genomic, mental health, HIV)	Cannot be “changed” if exposed
Retention requirements	State laws: 7-30 years; practical: indefinite	Far exceeds CRQC timeline
Network exposure	HIE exchanges, telehealth, cloud EHR, claims processing	High internet exposure
Adversary interest	Nation-state intelligence, identity theft, blackmail	High value target
Remediation	Cannot change genomic data, cannot change diagnosis history	Irreversible harm

Specific Healthcare HNDL Scenarios

Genomic Data

Genomic sequences are permanently sensitive — they cannot be changed if exposed, they reveal information about biological relatives, and they become more informative (not less) as genomic science advances. Genomic data encrypted with RSA key exchange today that is captured by an adversary represents permanent, irreversible privacy loss when CRQCs arrive.

Mental Health and Substance Abuse Records

42 CFR Part 2 provides additional protections for substance abuse treatment records. These records carry lifetime stigma risk and career implications. HNDL exposure could enable targeted blackmail or discrimination decades in the future.

Pediatric Records

Children’s health records generated today will still be sensitive in 60-70+ years. A child born today whose health data is transmitted over quantum-vulnerable encryption faces potential lifetime privacy exposure.

Clinical Trial Data

Clinical trial data for investigational drugs represents billions in pharmaceutical IP. HNDL capture of clinical trial data in transit could expose drug efficacy data, adverse events, and proprietary formulations years before competitors could independently develop them.

Medical Device Cryptography

The Medical Device Challenge

Connected medical devices present unique cryptographic management challenges:

• Long lifecycles: Medical devices often operate for 10-20 years — outlasting the cryptographic algorithms they shipped with
• FDA regulation: Changes to device software may require 510(k) clearance or PMA supplement, slowing updates
• Clinical safety: Cryptographic updates must not affect device performance in ways that could harm patients
• Diverse manufacturers: A single hospital may have devices from 100+ manufacturers with varying crypto implementations
• Network connectivity: IoT medical devices often communicate over TLS with hospital networks and cloud platforms

Current Medical Device Cryptographic Landscape

Device Category	Typical Crypto	Update Path	HNDL Risk
Patient monitors	TLS 1.2/1.3, RSA-2048	Firmware update (vendor-dependent)	Moderate
Infusion pumps	TLS 1.2, sometimes TLS 1.0	Firmware update (slow)	Moderate
Imaging (MRI, CT, X-ray)	DICOM TLS, RSA/ECDH	Major software revision	High (images are lifetime PHI)
Lab instruments	Varies (some unencrypted)	Manufacturer-dependent	Variable
Implantable devices	BLE with limited crypto	Cannot update in many cases	Low (local communication)
Surgical robots	Proprietary protocols	Vendor-managed	Moderate
Telehealth platforms	TLS 1.3, modern crypto	SaaS (vendor-updated)	Lower (current implementations)

FDA Guidance on Medical Device Cybersecurity

FDA’s 2023 cybersecurity guidance for medical devices requires:

• Cybersecurity design considerations including cryptographic implementation
• Software Bill of Materials (SBOM) for device software components
• Post-market cybersecurity management plans

CBOM extends SBOM for medical devices by specifically inventorying the cryptographic algorithms, protocols, and key management within device software — enabling healthcare organizations to assess quantum readiness of their device fleet.

HL7 FHIR and Health Information Exchange

Cryptographic Requirements for Interoperability

The 21st Century Cures Act and ONC interoperability rules require healthcare organizations to exchange data via standardized APIs (HL7 FHIR). This creates specific cryptographic requirements:

Patient App ←── FHIR API ──→ EHR System ←── HIE ──→ Other Provider
     │                            │                        │
     │    TLS 1.2+ required       │    TLS 1.2+ required   │
     │    OAuth 2.0 tokens        │    SAML/OAuth           │
     │    SMART on FHIR auth      │    Certificate auth     │
     │                            │                        │
     └── All use RSA/ECDH ────────┴── Quantum vulnerable ──┘

FHIR Security Implementation

FHIR Security Mechanism	Current Crypto	Quantum Vulnerability	PQC Path
TLS transport	RSA/ECDH key exchange	Key exchange vulnerable	Hybrid ML-KEM
OAuth 2.0 tokens	RSA-signed JWTs	Signature forgery (less HNDL relevant)	ML-DSA signed JWTs
SMART on FHIR	RSA key pairs	Token creation vulnerability	ML-DSA/ML-KEM
Document signatures	RSA/ECDSA	Signature validity	ML-DSA
Audit logs	HMAC-SHA256	Not vulnerable	N/A

Health Information Exchange (HIE) Network Security

HIE networks (Commonwell, Carequality, eHealth Exchange) rely on:

• Mutual TLS (mTLS) authentication between participants
• PKI certificate chains for organizational identity
• Encrypted document exchange (XDS.b, FHIR documents)

All of these mechanisms currently use RSA or ECDH — making the entire HIE network quantum-vulnerable. Migration must be coordinated across all participating organizations simultaneously.

Implementing CBOM in Healthcare

Discovery Scope for Health Systems

Clinical Systems:
  ├── Electronic Health Records (Epic, Cerner/Oracle Health, MEDITECH)
  ├── Laboratory Information Systems (LIS)
  ├── Radiology/PACS (DICOM encryption, image transfer)
  ├── Pharmacy systems (medication data, controlled substance)
  ├── Telehealth platforms (video encryption, data exchange)
  └── Patient portals (MyChart, patient-facing APIs)

Medical Devices:
  ├── Bedside monitors (patient data transmission)
  ├── Infusion pumps (medication delivery data)
  ├── Imaging equipment (MRI, CT, X-ray, ultrasound)
  ├── Lab analyzers (results transmission)
  ├── Surgical systems (robotic surgery, navigation)
  └── Wearables/Remote patient monitoring

Administrative Systems:
  ├── Claims processing (837/835 transactions, clearinghouse connections)
  ├── Revenue cycle management (payment data)
  ├── HR/payroll (employee PII)
  ├── Supply chain (vendor integrations)
  └── Research (clinical trial data, IRB submissions)

Infrastructure:
  ├── Network encryption (VPN, WAN, cloud connectivity)
  ├── Identity management (Active Directory, certificate services)
  ├── Email encryption (S/MIME, TLS for email)
  ├── Backup encryption (offsite, cloud-based)
  └── Cloud platforms (AWS, Azure, GCP healthcare services)

QCecuring CBOM for Healthcare Organizations

QCecuring CBOM addresses healthcare-specific requirements:

PHI Data Flow Mapping

QCecuring CBOM maps cryptographic protection to PHI data flows, identifying:

• Which patient data transmissions use quantum-vulnerable key exchange
• Where PHI at rest is encrypted with keys transported via RSA
• Which medical device connections lack adequate encryption entirely
• Where interoperability connections (FHIR APIs, HIE) use vulnerable algorithms

Medical Device Cryptographic Inventory

QCecuring CBOM discovers and inventories cryptographic implementations across the medical device fleet:

• Protocol scanning identifies TLS versions and cipher suites used by connected devices
• Binary analysis reveals embedded cryptographic libraries and their versions
• Network traffic analysis captures actual negotiated algorithms per device
• Generates device-level risk scores combining algorithm weakness, PHI exposure, and device lifecycle

HIPAA Compliance Evidence

QCecuring CBOM generates compliance artifacts:

• Encryption implementation evidence for Security Rule addressable requirements
• Breach safe harbor qualification reports (which PHI meets NIST encryption standards)
• Risk assessment input for the Security Rule’s required risk analysis
• Audit-ready documentation for OCR investigations

Vendor Risk Assessment

Healthcare organizations rely on hundreds of technology vendors. QCecuring CBOM:

• Identifies which vendors’ products use quantum-vulnerable cryptography
• Quantifies per-vendor HNDL risk exposure
• Generates vendor assessment reports for BAA (Business Associate Agreement) reviews
• Tracks vendor PQC migration progress over time

Implementation Roadmap for Health Systems

Phase 1: Critical PHI Systems (Months 1-4)

Focus on systems with the highest PHI exposure and longest data retention:

1. Deploy CBOM discovery on EHR platform connections
2. Inventory encryption for genomic data systems
3. Assess telehealth platform cryptographic posture
4. Scan patient portal and FHIR API security configurations
5. Generate initial HIPAA compliance report

Phase 2: Medical Device Fleet (Months 4-8)

Focus on connected devices transmitting PHI:

1. Network scan for medical device TLS/protocol versions
2. Identify devices with outdated or weak cryptographic implementations
3. Map device-to-EHR communication encryption
4. Prioritize devices by PHI sensitivity × algorithm weakness
5. Engage manufacturers for firmware update timelines

Phase 3: Interoperability and Exchange (Months 8-12)

Focus on data flowing outside organizational boundaries:

1. Inventory HIE connection cryptographic parameters
2. Assess claims processing and clearinghouse connections
3. Evaluate payer/provider data exchange encryption
4. Map research data sharing (clinical trials, registries)
5. Coordinate PQC planning with HIE network participants

Phase 4: Enterprise Coverage (Months 12-18)

Complete organizational cryptographic visibility:

1. Inventory all remaining administrative system encryption
2. Assess backup and disaster recovery cryptographic protection
3. Evaluate cloud platform encryption configurations
4. Complete vendor risk assessment for all BAA-covered vendors
5. Establish continuous monitoring and drift detection

PQC Migration Strategy for Healthcare

Priority-Based Migration

Priority	System/Data Type	Rationale	Timeline
Critical	Genomic data systems	Permanent sensitivity, cannot remediate exposure	Immediate hybrid TLS
Critical	Mental health/substance abuse records	Lifetime sensitivity, legal protections	Immediate hybrid TLS
High	EHR data exchange (FHIR APIs)	Large volume PHI, internet exposure	6-12 months
High	Telehealth platforms	Real-time PHI, internet exposure	6-12 months
Medium	Medical device communications	PHI in transit, but often local network	12-24 months
Medium	Claims/billing data	Sensitive but shorter retention	12-24 months
Lower	Administrative systems	Supporting systems, less sensitive data	18-36 months

Healthcare-Specific Migration Challenges

Challenge 1: Medical Device Firmware Updates

• Many devices cannot be updated without manufacturer support
• FDA clearance may be required for significant software changes
• Clinical validation must confirm device safety after crypto updates
• Mitigation: Network segmentation + encrypted overlay networks for legacy devices

Challenge 2: EHR Vendor Dependency

• Epic, Oracle Health, and MEDITECH control cryptographic implementations in their platforms
• Health systems must wait for vendor PQC support in many cases
• Mitigation: Demand PQC roadmaps from EHR vendors; deploy hybrid TLS at network edge

Challenge 3: HIE Coordination

• Health information exchange requires all participants to support the same algorithms
• Migration must be coordinated across hundreds of participating organizations
• Mitigation: Hybrid approach allows gradual adoption; lead by enabling hybrid on your connections

Challenge 4: Clinical Workflow Impact

• Any cryptographic change that affects latency could impact clinical workflows
• Real-time monitoring and alerting systems must not be delayed
• Mitigation: Benchmark PQC performance in clinical context before production deployment

Regulatory Compliance Mapping

CBOM to Regulatory Requirement Matrix

Regulatory Requirement	How CBOM Satisfies It
HIPAA §164.312(a)(2)(iv) - Encryption at rest	Inventories all encryption implementations protecting ePHI storage
HIPAA §164.312(e)(2)(ii) - Encryption in transit	Maps all ePHI transmission encryption protocols and algorithms
HIPAA §164.308(a)(1)(ii)(A) - Risk analysis	Provides cryptographic risk data as input to required risk analysis
HIPAA Breach Safe Harbor	Identifies which ePHI qualifies for safe harbor encryption standards
42 CFR Part 2 - Substance abuse records	Verifies encryption meets heightened confidentiality requirements
FDA Device Cybersecurity - Post-market management	Tracks medical device cryptographic posture over lifecycle
ONC Interoperability - FHIR security	Verifies API security implementations meet required standards
State breach notification laws	Identifies which data meets state-specific encryption safe harbor criteria

Key Takeaways

• Healthcare PHI has effectively indefinite confidentiality requirements — making it among the highest HNDL-risk data categories in any industry
• Genomic data is permanently sensitive and irreversible — once exposed by quantum decryption, there is no remediation possible
• HIPAA’s breach safe harbor depends on NIST-approved encryption — CBOM verifies which PHI qualifies for safe harbor protection
• Medical devices present unique challenges — long lifecycles, FDA regulation, and manufacturer dependency slow cryptographic updates
• HL7 FHIR and HIE networks are quantum-vulnerable — interoperability mandates create data flows protected only by RSA/ECDH
• QCecuring CBOM discovers cryptography across EHR systems, medical devices, and exchange networks — providing complete visibility into healthcare cryptographic posture
• HHS is tightening encryption requirements — proposed rules make encryption mandatory rather than addressable
• PQC migration must be coordinated with EHR vendors and HIE participants — healthcare cannot migrate independently
• Start with genomic and mental health data — these carry the highest permanent sensitivity and longest exposure windows
• Medical device segmentation provides interim protection — network-level encryption can protect devices that cannot be firmware-updated for PQC