Every software argument for post-quantum migration eventually runs into a hardware argument that does not fit. The premise of the migration — that existing systems can be updated to quantum-resistant algorithms before large-scale quantum computers arrive — holds well for cloud infrastructure, software-defined services, and regularly refreshed enterprise hardware. It holds less well for care AI that has been embedded in the physical lives of patients who cannot easily replace their devices.

The problem is not algorithm agility in the software sense. Modern cryptographic libraries can, in principle, swap signature schemes with a firmware update. The problem arises when the cryptographic engine is implemented in hardware — in a silicon-level security module, a dedicated secure element, or a firmware-locked microcontroller — and that hardware was manufactured before post-quantum key agreement primitives were finalized. Classical assumptions are literally wired in. A software update can change which cipher an application calls; it cannot change the physics of the secure element beneath it.

Care AI operates at exactly the deployment edge where this matters most. Wearable continuous monitoring devices, fall-detection pendants, medication dispensers, implanted biosensors, home gateway units that aggregate signals from multiple care devices — none of these refresh on an enterprise hardware cycle. A device placed with a care recipient in 2024 may be expected to remain in continuous use through 2030 or beyond. If that device's hardware security module was designed for RSA and elliptic-curve operations, post-quantum migration cannot happen through software alone. It requires physical hardware replacement, which may mean interrupting continuous monitoring that has been building a personalized clinical baseline for years.

The stakes are not symmetric. An enterprise deploying a classical hardware security module in a server rack can schedule a hardware refresh during a maintenance window with no consequences to any patient. A care recipient whose monitoring pendant has been tracking gait, sleep, and vital-sign patterns for two years — generating a personalized baseline that the clinical team depends on — cannot schedule a maintenance window. Replacing the hardware resets that baseline. The post-replacement calibration period is precisely when the patient is most at risk, because the care AI is operating on insufficient individual data and falling back to population-level defaults that may not fit the person in front of it.

This is the embedded constraint: the physical circumstances of care deployment create a class of hardware that must pass through the quantum transition without the option to migrate its cryptographic layer. The question of whether these devices remain trustworthy — as cryptographic counterparties, as authenticated sources of clinical evidence, as verified nodes in a care accountability chain — cannot be answered by updating their firmware. It has to be answered at design time, before the hardware ships.

The design-time answer has two parts. The first is algorithm agility at the silicon level: secure elements that support multiple key-agreement and signature schemes simultaneously, so that post-quantum algorithms can be activated as certified firmware when standardization and clinical validation are complete, without requiring hardware replacement. This is achievable in devices designed for it today; it cannot be retrofitted. The second is a managed deprecation protocol: a framework by which the care system, the device manufacturer, and the clinical team establish a shared picture of a device's cryptographic status as it approaches the limits of its viability, so that replacement planning can be driven by patient risk windows rather than by infrastructure emergencies.

Neither of these is a research problem. The algorithm families are standardized. The architecture of field-upgradeable secure elements is well understood. What does not yet exist is the care-specific operational framework — the protocol by which a device is declared cryptographically end-of-life, the patient and clinical team are informed, and a replacement plan is developed in a way that accounts for the care risk of interrupting continuous monitoring. That specification needs to be written, piloted, and embedded in procurement standards before the quantum transition forces the question in the field on its own schedule.

The embedded constraint is not a reason to stop deploying care AI hardware. It is a reason to build hardware that does not create the constraint, and to develop the operational protocols that address it for hardware already deployed. The patients who can least afford a cryptographic surprise are the ones whose care is most continuous. Building the cryptographic foundation correctly in the first generation of care AI hardware is not a security feature. It is a care quality decision, and the window to make it correctly is the one open right now.

后量子迁移的软件论证，最终都会遭遇一个不适用的硬件论证。迁移的前提——即现有系统可以在大规模量子计算机到来之前更新至量子安全算法——对于云基础设施、软件定义服务和定期刷新的企业硬件而言成立。对于嵌入患者日常生活、无法轻易更换设备的护理AI而言，则未必。

问题不在于软件层面的算法敏捷性。现代密码学库原则上可以通过固件更新来替换签名方案。问题在于，当密码学引擎以硬件形式实现——集成在芯片级安全模块、专用安全元件或固件锁定的微控制器中——而该硬件是在后量子密钥协议原语标准化之前制造的。经典假设被字面上写入了硬件之中。软件更新可以改变应用程序调用哪种密码算法，但无法改变其下层安全元件的物理结构。

护理AI恰好运行在这一问题最为关键的部署边缘。可穿戴连续监测设备、跌倒检测吊坠、药物分配器、植入式生物传感器、汇总多个护理设备信号的家庭网关——没有一种设备按企业硬件周期进行更换。2024年配置给护理接受者的设备，可能预期持续使用至2030年甚至更久。如果该设备的硬件安全模块是为RSA和椭圆曲线操作设计的，后量子迁移就无法单靠软件完成，而需要物理更换硬件——这可能意味着中断已持续积累数年个性化临床基线的连续监测。

这一问题的风险并不对称。在服务器机架中部署传统硬件安全模块的企业，可以在维护窗口期安排更换，不会对任何患者造成影响。而一位护理接受者——其监测吊坠已连续追踪步态、睡眠和生命体征两年，形成了临床团队所依赖的个性化基线——无法安排"维护窗口"。更换硬件会重置该基线。更换后的校准期恰恰是患者风险最高的时段，因为护理AI正在以不充分的个人数据运行，回退到群体层面的默认值，而这些默认值可能并不适用于眼前这个患者。

这就是嵌入式约束：护理部署的物理条件创造了一类硬件，必须在没有迁移密码层选项的情况下度过量子转型期。这些设备是否仍然可信——作为密码对手方、作为临床证据的经认证来源、作为护理问责链中的验证节点——这个问题无法通过固件更新来回答，只能在硬件出厂前的设计阶段回答。

设计阶段的答案有两个部分。第一：芯片级算法敏捷性——安全元件同时支持多种密钥协商和签名方案，以便在标准化和临床验证完成时，将后量子算法作为认证固件激活，而无需更换硬件。这在专为此设计的设备中今天就可实现；事后追加则无法做到。第二：可管理的弃用协议——一个框架，使护理系统、设备制造商和临床团队能够共同掌握设备密码状态，并在设备接近可用性极限时，根据患者风险窗口而非基础设施紧急事件来驱动更换规划。

这两者都不是研究问题。算法族已标准化。可现场升级安全元件的架构已有充分理解。目前尚不存在的，是护理专项的操作框架——规定设备被宣布密码学生命终结时的协议：如何通知患者和临床团队，以及如何制定一个考虑中断连续监测护理风险的更换计划。这一规范需要在量子转型按其自身节奏在现场强行提出问题之前，被撰写、试点并嵌入采购标准之中。

嵌入式约束不是停止部署护理AI硬件的理由，而是两个理由：构建不会造成此约束的硬件，并为已部署的硬件制定相应的操作协议。最无力承受密码学意外的患者，正是护理最为持续的那些人。在第一代护理AI硬件中正确构建密码学基础，不是一项安全特性，而是一项护理质量决策——而正确做出这一决策的窗口，就是现在。

後量子遷移的軟體論證，最終都會遭遇一個不適用的硬體論證。遷移的前提——即現有系統可以在大規模量子電腦到來之前更新至量子安全演算法——對於雲端基礎設施、軟體定義服務和定期更新的企業硬體而言成立。對於嵌入患者日常生活、無法輕易更換設備的護理AI而言，則未必。

問題不在於軟體層面的演算法敏捷性。現代密碼學庫原則上可以透過韌體更新來替換簽名方案。問題在於，當密碼學引擎以硬體形式實現——整合在晶片級安全模組、專用安全元件或韌體鎖定的微控制器中——而該硬體是在後量子金鑰協議原語標準化之前製造的。傳統假設被字面上寫入了硬體之中。軟體更新可以改變應用程式呼叫哪種密碼演算法，但無法改變其下層安全元件的物理結構。

護理AI恰好運行在這一問題最為關鍵的部署邊緣。可穿戴連續監測設備、跌倒偵測吊墜、藥物分配器、植入式生物感測器、匯總多個護理設備訊號的家庭閘道——沒有一種設備按企業硬體週期進行更換。2024年配置給護理接受者的設備，可能預期持續使用至2030年甚至更久。如果該設備的硬體安全模組是為RSA和橢圓曲線操作設計的，後量子遷移就無法單靠軟體完成，而需要物理更換硬體——這可能意味著中斷已持續積累數年個性化臨床基線的連續監測。

這一問題的風險並不對稱。在伺服器機架中部署傳統硬體安全模組的企業，可以在維護窗口期安排更換，不會對任何患者造成影響。而一位護理接受者——其監測吊墜已連續追蹤步態、睡眠和生命體徵兩年，形成了臨床團隊所依賴的個性化基線——無法安排「維護窗口」。更換硬體會重置該基線。更換後的校準期恰恰是患者風險最高的時段，因為護理AI正在以不充分的個人數據運行，回退到群體層面的預設值，而這些預設值可能並不適用於眼前這位患者。

這就是嵌入式約束：護理部署的物理條件創造了一類硬體，必須在沒有遷移密碼層選項的情況下度過量子轉型期。這些設備是否仍然可信——作為密碼對手方、作為臨床證據的經認證來源、作為護理問責鏈中的驗證節點——這個問題無法透過韌體更新來回答，只能在硬體出廠前的設計階段回答。

設計階段的答案有兩個部分。第一：晶片級演算法敏捷性——安全元件同時支援多種金鑰協商和簽名方案，以便在標準化和臨床驗證完成時，將後量子演算法作為認證韌體啟用，而無需更換硬體。這在專為此設計的設備中今天就可實現；事後追加則無法做到。第二：可管理的棄用協定——一個框架，使護理系統、設備製造商和臨床團隊能夠共同掌握設備密碼狀態，並在設備接近可用性極限時，根據患者風險窗口而非基礎設施緊急事件來驅動更換規劃。

這兩者都不是研究問題。演算法族已標準化。可現場升級安全元件的架構已有充分理解。目前尚不存在的，是護理專項的操作框架——規定設備被宣布密碼學生命終結時的協定：如何通知患者和臨床團隊，以及如何制定一個考慮中斷連續監測護理風險的更換計畫。這一規範需要在量子轉型按其自身節奏在現場強行提出問題之前，被撰寫、試點並嵌入採購標準之中。

嵌入式約束不是停止部署護理AI硬體的理由，而是兩個理由：構建不會造成此約束的硬體，並為已部署的硬體制定相應的操作協定。最無力承受密碼學意外的患者，正是護理最為持續的那些人。在第一代護理AI硬體中正確構建密碼學基礎，不是一項安全特性，而是一項護理品質決策——而正確做出這一決策的窗口，就是現在。