Why Preparing for Post-Quantum Cryptography Requires More Than a Firmware Update

Why Preparing for Post-Quantum Cryptography Requires More Than a Firmware Update

In earlier posts, we explored what post-quantum cryptography (PQC) is and how preparing for it aligns with FDA cybersecurity expectations. Today, we’ll address a common misconception: that cryptographic updates are a simple matter of issuing a software update.

Unfortunately, in the world of medical devices, cryptographic agility is far more complex - and it is critical to plan for it in advance. 

Why Crypto Agility Is a System Design Challenge

Most medical devices weren’t built with cryptographic agility in mind. In many cases, algorithms, certificates, and key exchange mechanisms are tightly coupled with hardware, firmware, or third-party modules. As a result, retrofitting or upgrading cryptographic functionality isn’t just a matter of swapping in new code - it often demands hardware redesigns, extensive re-validation, updated key-management processes, and coordination with external suppliers, making the whole effort a deeply complex, resource-intensive - and therefore high-risk-undertaking.

Even if a new algorithm (such as a post-quantum alternative) becomes available, you can only swap it if:

• The device’s processors, memory, and secure elements can handle PQC’s compute and storage demands
• Hardware accelerators (AES engineers, secure enclaves) support the new primitives
• The firmware or OS can load modular crypto libraries at runtime
• The update mechanism is itself validated and resistant to rollback or tampering
• You know exactly which device models and firmware versions include upgradable crypto

Foundational Principles of Crypto Agility

1. Inventory your cryptographic components and deployments

To plan any update you first must know what you’re protecting and where it lives. Build two tied together inventories:

• Crypto components: algorithms (e.g., RSA, ECC, AES, etc.), key lengths & lifespans, certificate chains, hardware modules and secure elements, plus where each is used (TLS stacks, secure boot, firmware signing, etc.).
• Product deployments: every device model, firmware version, and customer install base - so you can target updates to the right devices.

Why it matters: PQC standards are final. NIST has selected an initial set of candidate algorithms, and timelines are set. 

Note: Documenting every algorithm, key and certificate chain isn’t just about FDA VI.A - it’s what lets you automate updates, prove coverage for every device model, and track your progress when PCQ deadlines arrive. Further, although FDA does not specifically call out PQC, the agency does point to currently NIST-approved algorithms (with its 2030 / 2035 PQC deadline).

2. Design for flexibility

If your crypto lives in monolithic or locked down hardware, you’ll encounter serious road blocks when PQC algorithms arrive. Instead, build:

• Modular crypto libraries that allow algorithm swaps 
• Automated certificate rotation workflows and key management services
• Secure firmware update pipelines that can deliver new crypto components in the field
• Programmable hardware or co-processors that can accept future PQC primitives

Why it matters: FDA is already expecting crypt-update plans. Their premarket guidance and Section 524B “reasonable assurance” that your security can evolve. 

3. Architect for long-term evolution

Many medical devices stay in the field for 10 - 15 years (or longer), so you must plan for changing standards and threats over their entire lifespan. This is critical for:

• Remote or implanted devices that can’t be physically recalled or opened - every patch must work flawlessly over the air
• Integrations with legacy hospital infrastructure (old PACS/DICOM gateways, HL7 interfaces) where you can’t force the hospital to update their side
• Products subject to periodic recertification (e.g., when firmware changes trigger re-testing) - agile crypto reduces scope and cost of re-validation

Why it matters: Long-lived devices mean you can’t afford manual patches. Every firmware swap triggers re-validation-without agility, you’ll face mounting costs and delays.

Agility enables long-term protection without a full product replacement or redesign.

Common Pitfalls We See

• Hardcoded certificates that expire after decades
• No plan for revoking compromised keys in the field
• Crypto libraries that require full manual recertification on every patch
• No visibility into which firmware, hardware and software layers are using which algorithms

Why This Matters Now

The urgency isn’t just technical - it’s regulatory.

• NIST’s PQC standards are finalized
• FDA’s expectations for cryptographic planning and updatability are active
• Section 524B of the FD&C Act requires “reasonable assurance” that protections are effective across the product lifecycle
  
  

Preparing for cryptographic change isn’t a future issue - being PQC-ready is a current compliance and design priority.

Coming Up Next

In our final blog of the series, we’ll introduce how Medcrypt’s Guardian platform helps medical device manufacturers stay ahead of evolving threats by managing  cryptography in a secure, structured, and future-ready way.

Up Next: How Guardian Helps Medical Device Manufacturers Prepare for the Post-Quantum Future

‍