The hardest category in PQC migration: expensive, slow, physical, and impossible to automate. Plan for it early or pay for it late.
Software can be patched. Certificates can be reissued. Configuration can be updated by automation. Hardware cannot be patched into new cryptographic capabilities it was not designed for. If an HSM was manufactured before ML-DSA existed as a standard, it will not gain ML-DSA support through a software update — it may need to be replaced entirely.
Hardware migration is the category that distinguishes organizations that can migrate quickly from those that cannot. A cloud-native company with no on-premise HSMs and no physical smart card program can complete PQC migration in 18–24 months. A manufacturing company with 12 HSM models, 8,000 employee smart cards, and 500 IoT sensors on production lines faces a 5–7 year replacement program that cannot be accelerated without significant capital expenditure.
Hardware migration is expensive, slow, and cannot be automated. Plan for it early or pay for it late — with interest. Organizations that do not include hardware replacement in their migration budget in Year 1 routinely discover it as a surprise blocker in Year 3. At that point the compliance deadline is close and procurement lead times are unchanged. There is no shortcut.
By the end of this lesson you will be able to: (1) explain why HSMs are a hard dependency for PQC migration and what to ask HSM vendors; (2) describe the smart card replacement challenge and why it is a logistics problem as much as a technical one; (3) classify IoT and OT devices into migration categories using the four-factor framework; (4) explain compensating controls for IoT devices that cannot be migrated; and (5) estimate the hardware contribution to total migration cost.
A Hardware Security Module (HSM) is a dedicated physical device that generates, stores, and uses cryptographic keys in a tamper-resistant hardware environment. HSMs are the root of trust for every CA in an enterprise PKI. They protect CA private keys from extraction — which is why they are a compliance requirement for any serious PKI deployment.
For PQC migration, HSMs are a hard dependency at the CA layer. A CA cannot generate or use ML-DSA keys unless the HSM it relies on supports ML-DSA key operations. This is a hardware and firmware capability that must be present in the physical device — not a software configuration.
Some HSM models can gain ML-DSA support through a firmware update from the vendor. This is the lowest-cost, lowest-disruption path. However, firmware upgrades come with caveats that must be assessed before assuming this path is viable.
Key question: Does the firmware upgrade maintain the HSM's FIPS 140-3 certification for ML-DSA operations? If the answer is "pending validation," you cannot use it for a certified PKI until that validation is complete. The gap between "firmware available" and "FIPS 140-3 validated" can be 12–24 months.
Hardware replacement is the most common path for HSMs manufactured before 2022. The new HSM must be procured, validated, initialized with new key material, subjected to a formal key ceremony to generate new CA keys, and integrated into CA software before the old HSM can be decommissioned.
Parallel operation: During migration, both old and new HSMs must run simultaneously until all CAs are migrated and all certificates issued by the old CA have expired or been revoked. Do not decommission old HSMs prematurely.
The FIPS 140-3 certification question is the one most often missed in HSM vendor assessments. A vendor may truthfully say "we support ML-DSA in firmware 3.2" without disclosing that firmware 3.2 is not yet FIPS 140-3 validated. If your organization has a compliance requirement for FIPS 140-3 validated cryptographic modules — which most regulated organizations do — you cannot use unvalidated firmware in production. Get both the firmware availability date and the FIPS validation target date in writing from your vendor today.
Smart cards — employee identity badges, government CAC and PIV cards, hardware authentication tokens — present a migration challenge that is as much a people and logistics problem as a technical one.
A smart card contains a cryptographic chip that generates and stores key pairs. The chip is manufactured with specific algorithm support. You cannot upgrade a smart card's cryptographic algorithms — you must physically replace the card. Every employee. One at a time. In person for many card types. With reactivation required at badge readers and middleware.
For an organization with 10,000 employees using PIV or CAC cards: if you can replace 100 cards per day, full replacement takes 100 working days — 5 months assuming no absences, global distribution challenges, or card printer constraints. For 50,000 employees: over 2 years. Do not discover this constraint in Year 4 of a 5-year plan.
Smart Card Migration Checklist — the ten steps in the correct order:
One important planning note: middleware and badge readers must also be upgraded. A new PQC-capable smart card is useless if the badge reader only supports RSA-2048 or ECDSA-256. Middleware must be updated to support ML-DSA operations before the new cards are issued. Include middleware vendor assessment in your planning from the start.
The federal PIV/CAC smart card migration is one of the most active topics in the US government PQC program. NIST SP 800-217 and FIPS 201 are both being updated to address PQC algorithm support. Understanding the physical logistics dimension of smart card migration — not just the technical algorithm question — is what distinguishes a practitioner who has thought through the problem from one who has only read about it. The DoD alone has roughly 5 million active CAC holders, making their smart card replacement program one of the largest logistics exercises in federal IT history.
IoT and Operational Technology (OT) devices present the most difficult migration challenge. They are typically deployed in large numbers, physically inaccessible for frequent updates, running firmware that cannot support ML-DSA due to memory and processing constraints, designed for 10–20 year operational lifetimes, and critical to operational continuity.
The honest reality: a significant portion of the IoT and OT estate in most large organizations will still be running classical cryptography in 2030 and beyond. The goal is not zero classical IoT devices by 2030. The goal is a classified, risk-assessed, compensating-controlled IoT estate with a credible replacement roadmap.
| Device Category | Typical Lifecycle | Firmware Upgradeable? | Certificate Renewal | Migration Class |
|---|---|---|---|---|
| Enterprise Network Devices Routers, switches, firewalls |
5–8 years | Usually yes | SCEP, EST, or manual | Manageable |
| IP Cameras & Physical Security | 7–12 years | Limited; vendor dependent | Manual or proprietary | Plan & Replace |
| Medical Devices Infusion pumps, monitors |
10–15 years | Rare; FDA re-approval often required | Manual or proprietary | Long-Tail Exception |
| Industrial OT Sensors SCADA, PLCs, process controls |
15–25 years | Almost never | Manual or none | Long-Tail Exception |
| Building Management Systems HVAC, access control |
10–20 years | Vendor dependent; often no | Proprietary; often manual | Long-Tail Exception |
| Consumer IoT Smart locks, printers, displays |
3–7 years | Often yes via OTA | Cloud-provisioned | Manageable |
| Smart Cards / Tokens Employee badges, HSM tokens |
3–5 years | No — physical replacement only | Physical issuance | Plan & Replace |
For Long-Tail Exception devices, the security response is to apply compensating controls that reduce risk while they await replacement: (1) Network segmentation — isolate classical-only IoT on separate VLANs with strict egress filtering; (2) Air-gapping for critical OT systems; (3) Enhanced monitoring — anomaly detection on classical-only device segments; (4) Accelerated replacement planning — include device categories in the next capital expenditure cycle.
For a small business the IoT question is usually much simpler. If your estate is office printers, a few cameras, a smart thermostat, and standard network equipment, those are either consumer-grade devices replaced on normal refresh cycles or enterprise network gear with manageable firmware upgrade paths. The IoT section of your Deliverable B checklist should be: (1) list every non-standard networked device, (2) check whether each has a vendor PQC firmware roadmap, and (3) include any without a roadmap in your next hardware refresh plan. For most SMBs this is a one-day exercise, not a multi-year program.
Hardware is typically the largest single cost category in enterprise PQC migration. These are directional estimates based on PKIC practitioner reporting and the cost model established for this course. Full migration cost modeling is covered in Lesson 4.7.
Organizations that have migrated CA infrastructure to cloud HSM (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM) before PQC migration begins face a significantly lower hardware cost burden. Cloud HSM providers will update their platforms to support ML-DSA, absorbing the hardware upgrade cost into their service fee. If your organization is considering cloud HSM migration for other reasons, the PQC migration timeline is a compelling additional argument to move now.
Click each term to reveal its definition.
The hardware section of the corporate migration checklist in Deliverable B asks you to identify which hardware categories are in scope for your defined organization and estimate replacement timelines. Use the IoT classification table from Section 4 and the cost estimates from Section 5 to complete those items. The single most important annotation you can make: whether your organization has confirmed HSM PQC support and what the upgrade or replacement plan is. That item has more downstream dependencies than anything else on the checklist.
Three questions on HSMs, smart cards, and IoT migration decision-making.