A new analysis of the medical device ecosystem, reported by The HIPAA Journal, confirms what many of us in healthcare security have been warning clients about for years: a significant portion of deployed medical devices are fundamentally incapable of supporting the transition to post-quantum cryptography (PQC). Only a small fraction of analyzed devices possess the computational headroom, firmware updatability, and cryptographic agility required to migrate away from RSA and elliptic-curve cryptography before cryptographically relevant quantum computers arrive.
This is not an abstract, far-future problem. Healthcare data has an unusually long confidentiality shelf life — a genomic record, a psychiatric history, or a pediatric chart intercepted today must remain confidential for decades. Adversaries executing harvest now, decrypt later (HNDL) operations are already capturing encrypted healthcare traffic with the expectation of decrypting it once quantum capabilities mature. For a sector where the average infusion pump or patient monitor stays in clinical service for 10–15 years, the migration clock is already inside the device replacement cycle. Defenders who wait for a quantum computer to appear before acting will have lost by definition.
Technical Analysis
Why Medical Devices Are Uniquely Exposed
The analysis highlights structural constraints that make the clinical device fleet the weakest link in any healthcare PQC migration:
- Constrained compute and memory. Implantable cardiac devices, insulin pumps, and wearable monitors run on microcontrollers with kilobytes of RAM and strict power budgets. NIST's selected PQC algorithms — ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) — have larger key sizes, larger signatures, and higher memory footprints than the ECDSA/ECDHE implementations they replace. Many deployed devices simply cannot execute them.
- No firmware update path — or a signed one that is itself quantum-vulnerable. Devices that can accept updates often validate firmware with RSA-2048 or ECDSA signatures. If the trust anchor itself is quantum-vulnerable, the update mechanism cannot be trusted to deliver a PQC migration. This is the classic crypto bootstrap problem.
- Hard-coded legacy TLS. We routinely find imaging systems (CT, MRI, PACS gateways) and older patient monitors that terminate at TLS 1.0/1.1 with RSA key exchange. These devices cannot negotiate even modern classical cipher suites, let alone hybrid PQC handshakes (e.g., X25519+ML-KEM-768).
- Long clinical lifecycles vs. short crypto timelines. CNSA 2.0 and CISA guidance push organizations to begin PQC migration now, with quantum-vulnerable algorithms targeted for deprecation in the 2030–2035 window. A device purchased in 2026 may still be in bedside service in 2038.
- Regulatory lag. While Section 524B of the FD&C Act and the FDA's premarket cybersecurity guidance now require security update capabilities and software bills of materials for new "cyber devices," the installed base — devices cleared years ago — has no such mandate.
The Threat Model: Harvest Now, Decrypt Later
No CVE applies here, and exploitation of a cryptographically relevant quantum computer remains theoretical — but the collection side of HNDL is not theoretical. Nation-state actors have demonstrated sustained interest in healthcare datasets (research, genomic, and population-health data in particular). Encrypted clinical traffic traversing hospital WANs, telehealth links, vendor remote-support tunnels, and cloud DICOM/HL7 FHIR exchanges can be passively captured today and stored indefinitely. Any data whose confidentiality requirement extends past ~2035 and is protected only by RSA/ECC key exchange should be treated as already at risk.
The practical prioritization tool is the Mosca inequality: if (data shelf-life) + (migration time) > (time to quantum threat), you are already late. For most hospital fleets, all three terms argue for immediate action on inventory and compensating controls even where device replacement is impossible.
Exploitation Status
- In-the-wild quantum cryptanalysis: None — capability does not publicly exist.
- Harvest-now-decrypt-later collection against healthcare targets: Assessed as ongoing based on longstanding nation-state interest in bulk encrypted traffic capture.
- CISA KEV: Not applicable (no discrete vulnerability).
Detection & Response
You cannot signature-detect a future quantum computer. What you can — and must — detect today is your own cryptographic posture: which devices and sessions still rely on quantum-vulnerable key exchange, and whether anything in the environment is regressing crypto hygiene (a common side effect of vendors "fixing" interoperability problems by re-enabling TLS 1.0).
Sigma Rules
---
title: Legacy TLS or SSL Protocol Re-Enabled via Schannel Registry
tid: 8c3e1a47-2f5b-4d9a-b6c0-7e1f2a3b4c5d
status: experimental
description: Detects registry changes that re-enable deprecated SSL/TLS protocol versions in Windows Schannel, a common vendor workaround that degrades cryptographic posture and increases quantum-vulnerable RSA key exchange usage on biomedical servers and PACS gateways.
references:
- https://www.hipaajournal.com/medical-devices-incapable-transition-post-quantum-cryptography/
- https://attack.mitre.org/techniques/T1562/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.defense_evasion
- attack.t1562
logsource:
category: registry_set
product: windows
detection:
selection_path:
TargetObject|contains:
- 'SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\SCHANNEL\\Protocols\\SSL 2.0'
- 'SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\SCHANNEL\\Protocols\\SSL 3.0'
- 'SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\SCHANNEL\\Protocols\\TLS 1.0'
- 'SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\SCHANNEL\\Protocols\\TLS 1.1'
selection_enabled:
TargetObject|endswith: '\\Enabled'
Details|contains: '1'
condition: selection_path and selection_enabled
falsepositives:
- Vendor-mandated compatibility changes on isolated medical device VLANs (triage against change tickets)
- GPO deployment during initial server hardening baselines
level: high
---
title: Weak RSA Key Generation or Legacy Cipher Configuration via certutil and PowerShell
id: 2b7d4e91-6a3c-4f08-9d1e-5c6a7b8d9e0f
status: experimental
description: Detects generation of short RSA keys or explicit legacy cipher configuration on Windows systems, indicating crypto-agility gaps or insecure workarounds on systems interfacing with medical devices.
references:
- https://www.hipaajournal.com/medical-devices-incapable-transition-post-quantum-cryptography/
- https://attack.mitre.org/techniques/T1609/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.execution
- attack.t1609
logsource:
category: process_creation
product: windows
detection:
selection_weak_key:
CommandLine|contains:
- 'RSA:1024'
- 'RSA:2048'
- 'KeyLength=1024'
- 'KeyLength=2048'
selection_legacy_cipher:
CommandLine|contains:
- 'Enable-TlsCipherSuite'
- 'RC4'
- 'DES_CBC'
- 'TLS_RSA_WITH'
condition: 1 of selection_*
falsepositives:
- PKI administrators issuing certificates under documented legacy requirements
- Penetration testing activity
level: medium
KQL (Microsoft Sentinel / Defender)
Hunt for legacy TLS sessions originating from or destined to medical device network segments, using TLS-inspecting firewall or load balancer telemetry ingested via CommonSecurityLog. Adjust the subnet list to your clinical VLANs.
// Legacy TLS (quantum-vulnerable RSA key exchange era) on clinical device segments
let ClinicalSubnets = dynamic(["10.40.0.0/16", "10.50.0.0/16", "192.168.20.0/24"]);
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where ApplicationProtocol has_any ("TLSv1.0", "TLSv1.1", "SSLv3", "TLS_RSA")
or DeviceCustomString1 has_any ("TLSv1.0", "TLSv1.1", "SSLv3") // adjust CEF field mapping
| extend SrcOnClinicalVlan = SourceIP startswith "10.40." or SourceIP startswith "10.50." or SourceIP startswith "192.168.20."
| extend DstOnClinicalVlan = DestinationIP startswith "10.40." or DestinationIP startswith "10.50." or DestinationIP startswith "192.168.20."
| where SrcOnClinicalVlan or DstOnClinicalVlan
| summarize SessionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
by SourceIP, DestinationIP, DestinationPort, ApplicationProtocol, DeviceCustomString1
| order by SessionCount desc
// Defender: identify medical-device-adjacent servers still negotiating weak TLS via network events
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemotePort in (443, 8443, 104, 2761, 2762, 11112) // HTTPS, HL7, DICOM TLS ports
| where DeviceName has_any ("pacs", "ris", "hl7", "biomed", "dicom")
| summarize Connections = count(), UniqueRemotes = dcount(RemoteIP) by DeviceName, RemoteIP, RemotePort
| order by Connections desc
Velociraptor VQL
Inventory the certificate stores on Windows biomedical servers and PACS gateways to enumerate RSA-keyed certificates with short key lengths — a concrete measure of PQC migration readiness and HNDL exposure.
-- Inventory machine certificates: flag RSA keys < 3072 bits (not PQC-migratable, HNDL-exposed)
SELECT * FROM foreach(
row={
SELECT Name FROM glob(globs='C:\\Windows\\System32')
},
query={
SELECT
'' AS Host,
stdout AS CertInventory
FROM execve(argv=[
'powershell', '-NoProfile', '-Command',
"Get-ChildItem Cert:\\LocalMachine\\My | Select-Object Subject, Issuer, NotAfter, @{n='KeyAlgo';e={$_.PublicKey.Oid.FriendlyName}}, @{n='KeySize';e={$_.PublicKey.Key.KeySize}}, Thumbprint | Where-Object {$_.PublicKey.Oid.FriendlyName -match 'RSA' -and $_.PublicKey.Key.KeySize -lt 3072} | ConvertTo-Csv -NoTypeInformation"
])
})
Remediation Script (Bash)
Run this from an authenticated scanner position against clinical VLANs to inventory TLS posture per device. Output feeds directly into your PQC readiness register and Section 524B vendor conversations.
#!/bin/bash
# pqc-readiness-scan.sh - Inventory TLS versions and cipher suites on medical device segments
# Usage: ./pqc-readiness-scan.sh <subnet_file> (one CIDR or IP per line)
SUBNETS="$1"
OUT="pqc_readiness_$(date +%Y%m%d).csv"
echo "host,port,tls_version,key_exchange,flag" > "$OUT"
while read -r target; do
[ -z "$target" ] && continue
echo "[*] Scanning $target"
# Enumerate SSL/TLS versions and ciphers on common clinical service ports
nmap -sV --script ssl-enum-ciphers -p 443,8443,104,2761,2762,11112 \
--open -oG - "$target" 2>/dev/null | while read -r line; do
host=$(echo "$line" | grep -oP '(?<=Host: )[0-9.]+')
port=$(echo "$line" | grep -oP '\d+(?=/open)' | head -1)
[ -z "$host" ] && continue
# Flag any negotiated protocol below TLS 1.2 or RSA key exchange
if echo "$line" | grep -qE 'TLSv1\.0|TLSv1\.1|SSLv3'; then
echo "$host,$port,legacy,RSA_or_export,QUANTUM_VULNERABLE_HNDL_EXPOSED" >> "$OUT"
elif echo "$line" | grep -qE 'TLS_RSA_WITH'; then
echo "$host,$port,tls12_static_rsa,RSA_key_exchange,QUANTUM_VULNERABLE_NO_PFS" >> "$OUT"
elif echo "$line" | grep -qE 'TLSv1\.3'; then
echo "$host,$port,tls13,ECDHE,CLASSICAL_OK_NOT_PQC" >> "$OUT"
fi
done
# Direct probe for hybrid PQC support (X25519MLKEM768) on port 443 listeners
for ip in $(nmap -sL "$target" | grep -oP '\d+\.\d+\.\d+\.\d+'); do
if timeout 5 openssl s_client -connect "$ip:443" -groups X25519MLKEM768 \
-brief </dev/null 2>/dev/null | grep -qi 'MLKEM\|ML-KEM'; then
echo "$ip,443,tls13_hybrid,X25519+ML-KEM-768,PQC_HYBRID_SUPPORTED" >> "$OUT"
fi
done
done < "$SUBNETS"
echo "[+] Results written to $OUT"
echo "[+] Rows flagged QUANTUM_VULNERABLE require compensating controls or vendor remediation"
Remediation
There is no patch for physics. Remediation here is a multi-year program, and the organizations that start in 2026 will be the ones that finish before the threat materializes.
- Build a cryptographic bill of materials (CBOM). Extend your existing medical device inventory (required under your HIPAA Security Rule risk analysis) with per-device cryptography: TLS versions supported, key exchange algorithms, firmware signing algorithms, and update mechanism trust anchors. You cannot migrate what you have not measured.
- Enforce PQC readiness in procurement now. Every RFP and purchase order for connected clinical devices should require: (a) a firmware update path with PQC or hybrid-PQC signature verification on the vendor's roadmap, (b) TLS 1.3 support with hybrid key exchange (X25519+ML-KEM-768) on all network services, (c) a published crypto-agility statement, and (d) SBOM/CBOM delivery consistent with FDA premarket cybersecurity guidance and Section 524B of the FD&C Act. A device bought today without crypto-agility is a 15-year liability.
- Prioritize by data shelf-life, not device count. Apply the Mosca inequality: DICOM archives, genomic data, research datasets, and pediatric records with 30+ year confidentiality requirements get first priority. A telemetry gateway moving ephemeral vital signs is lower risk than the PACS archive behind it.
- Deploy compensating controls for devices that cannot migrate. For the majority of the installed base that will never support PQC:
- Terminate device TLS at a PQC-capable gateway or reverse proxy on the clinical VLAN boundary, so quantum-vulnerable sessions never leave the segment.
- Wrap vendor remote-support and cloud telemetry paths in a hybrid-PQC VPN or TLS tunnel (major VPN and TLS library vendors now ship ML-KEM hybrid support — verify against current releases).
- Enforce strict network segmentation between clinical device VLANs and general IT, with egress filtering so device traffic cannot be trivially bulk-captured off the WAN.
- Kill legacy protocols at the infrastructure layer. Disable TLS 1.0/1.1 and static RSA key exchange on everything you control (load balancers, gateways, Windows Schannel via GPO). Where a device requires TLS 1.0, isolate it behind a protocol-translation gateway and document the exception — do not let the exception define your baseline.
- Engage manufacturers with a formal questionnaire. Ask every device vendor: What algorithm signs your firmware? Is your update mechanism itself quantum-vulnerable? What is your NIST FIPS 203/204/205 migration timeline? Under 524B, manufacturers of new cyber devices must describe update capabilities — hold them to it contractually.
- Plan the replacement cycle against the 2030–2035 deprecation window. Map every non-migratable device to its end-of-life date. Devices still in service past 2032 that handle long-shelf-life data need funded replacement plans on the capital budget this cycle, not the next one.
- Track the authoritative guidance. Monitor CISA's post-quantum cryptography initiative, NIST's PQC standardization page (FIPS 203/204/205 and the HQC selection for KEM diversity), the FDA's cybersecurity guidance updates, and HHS 405(d) HICP publications for healthcare-specific migration playbooks.
The quantum threat does not arrive with a CVE, a PoC, or a CISA KEV entry. It arrives as a decryption event against traffic captured years earlier — and the only defense is the inventory, procurement discipline, and compensating architecture you build starting now.
Related Resources
Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.