A Quantum-Resilient and Forensic-Aware Security Lifecycle Framework for AI-Driven Edge Sensing in Intelligent Healthcare IoT Systems

1. Introduction

Artificial intelligence (AI) enabled edge sensing is transforming the delivery of continuous, real-time patient monitoring for healthcare [1]. Wearable cardiac monitor devices exist that can automatically provide alerts for arrhythmias without requiring clinician review of all readings [2]. Implantable glucose sensors provide real-time data to AI-controlled insulin pumps, which automatically adjust dosages based upon readings taken directly from the body [3]. In addition to providing autonomous monitoring of individual patients, ambient sensors in intensive care units can continuously monitor 20+ patients, identifying potential deterioration before it is recognised by the clinical team caring for multiple patients [4]. All these devices are comprised of the following architectural design: (i) A sensor that collects either physiological information about a person or environmental information; (ii) an edge gateway that performs AI-based inference on the collected data; and (iii) the data stored in either the cloud or the hospital’s back-end system with support for long-term storage and clinical review [5].

The architecture supporting several categories of AI-driven Internet of Things (IoT) sensing in healthcare has developed much faster than the necessary infrastructure for security and accountability [5]. There are three separate problems that compound each other within this landscape and are discussed in detail below. First, the majority of current IoT sensing systems for healthcare use Rivest–Shamir–Adleman (RSA) [6] and Elliptic Curve Cryptography (ECC)-based encryption [7], which can be broken by Shor’s algorithm when implemented on a sufficiently capable quantum computer [8]. A computer’s ability to break these algorithms is not concerning, but rather, the risk to a healthcare system arises when an adversary uses a “harvest-now-decrypt-later” strategy [9]. However, these can also encrypt the recorded sensor data from a patient’s sensors now and then decrypt that data later, after exposing confidential information for many years, typically measured in decades. Therefore, there is a risk that an implantable device may reach the end of its service life cycle (typically 15 years or more) without having had the opportunity to be updated to new encryption methods [10].

Secondly, while edge inference models today are making or significantly informing clinical decisions in real-time [11], the decision-making pipelines [12] that produce those decisions are typically developed with no complementary mechanism for explaining, auditing, or investigating those decisions once these have been made [13,14]. Thirdly, when a healthcare IoT sensing system has been attacked via sensor spoofing [15], firmware tampering [16] or some of the many additional types of attacks identified in recent deployments [17], there is no way for a deployment to be able to capture and retain forensic evidence as part of the post-attack investigation process or to reconstruct the attack timeline (which would provide necessary information for establishing accountability) [18] under Health Insurance Portability and Accountability Act (HIPAA) [19], the General Data Protection Regulation (GDPR) [20] or similar regulations. Thus, it is not just a problem within individual products, but also represents a larger issue with the structure of existing frameworks and standards for securing healthcare IoT.

1.1. The Critical Gap

In the existing literature, the first two challenges have been addressed individually. For example, post-quantum cryptography (PQC) research has made significant advances in developing practical cryptographic algorithms and is beginning to explore how to deploy these effectively on resource-constrained devices [21]. Furthermore, this body of work typically does not include how these deployments may integrate into an IoT forensic logging system or use AI-based threat detection systems. On the other hand, digital forensic research has provided numerous frameworks for collecting and preserving evidence from IoT devices [22,23,24,25,26,27,28,29]. However, it usually does not consider many of the specific challenges associated with using these devices within a healthcare environment such as the limited lifespan of implantable medical devices and regulations surrounding data management. Furthermore, it fails to consider the potential for collected evidence to be compromised by a future quantum attack. Finally, broad survey-based approaches [30,31,32,33,34,35] to addressing healthcare IoT security have also provided some important contextual and regulatory awareness of both quantum threats to IoT systems and the need for forensic readiness. However, these survey-based approaches to IoT security have historically treated quantum threats and forensic readiness separately rather than together as part of a larger IoT system lifecycle.

Therefore, by highlighting critical gaps in the existing framework and approaches, this work has a structural implication rather than simply being an issue of insufficient coverage. For instance, an inadequacy introduced into a healthcare IoT sensor system over its lifetime can create weaknesses in subsequent stages of the system [4]. Similarly, there are several types of attacks that can compromise any secure system lacking forensic logging or the use of quantum-safe evidence integrity[34]. If such a system is compromised through another attack vector, it lacks reliability and accountability. Likewise, if a system includes both forensic logging and uses quantum-safe evidence integrity, the resulting investigation has an inherent “shelf life” (in other words, an expiration date). To the best of our knowledge, none of the existing frameworks addresses this type of propagation.

1.2. Paper Contributions

This research has the following contributions.

• We propose a quantum-resilient, forensic-aware security lifecycle framework for AI-driven edge-sensing healthcare IoT. To the best of our knowledge, it is the first time a life cycle has two related but different concepts, quantum-resilient cryptography and forensic-aware readiness, as part of the same life cycle. The previous work treated these separately.
• We utilised a taxonomic approach to create a threat model and gap analysis identifying attack vectors and forensic-deficient areas in each phase of the life cycle. As such, we provide evidence supporting the structure of our proposed life cycle by referencing prior work.
• We perform a systematic component-by-component analysis of each element of the proposed framework to meet the eight explicit design criteria. Next, we evaluate how well our proposal aligns with four categories of prior work in this area. Finally, we describe the use of this framework with the four example use cases for AI-based healthcare IoT sensing applications.
• We also suggest possible future directions for research that could help improve our developed framework. Specifically, we address the limitations of our current formulation of the framework, most notably its lack of a method to correct (remediate) a known cryptographic weakness after such an issue is discovered in implantable medical devices.

This paper is offered as a conceptual framework contribution, not as an empirical or deployment study of the proposed component. In addition, this paper did not present any comparative analysis and showed no real application of the proposed components to hardware. The objective of this paper is to establish a baseline for the entire architecture, provide insight into why this architectural structure has developed, and outline future research that can be conducted based on the architectural definition presented in this paper.

1.3. Paper Organisation

The remainder of this paper is as follows: Section 2 provides context for the subsequent sections’ arguments, offering an overview of the healthcare Internet IoT sensing environment, the AI and quantum computing concepts used within the framework, and digital forensic-related terms. Section 3 outlines the threat environment/gap analysis that led to the development of the framework and establishes eight specific design criteria based on that threat environment. Section 4 describes each stage of the proposed security lifecycle framework in detail. Section 5 evaluates the security lifecycle framework components against the established design criteria, compares these with other frameworks/technologies, and shows how these can be applied to various examples/scenarios. Section 6 provides a balanced assessment of the advantages and disadvantages of the security lifecycle framework, along with possible implementation stages and regulatory implications. Section 7 establishes a formalised agenda for future research based upon all identified limitations from Section 6. Finally, Section 8 concludes the paper.

2. Background and Preliminaries

This section establishes the theoretical foundation and technical framework necessary to understand the core methodologies of this study. It provides an overview of the fundamental concepts surrounding AI and edge computing, quantum computing, PQC, digital forensics, and the security lifecycle concepts and schemas.

2.1. Healthcare IoT Sensing Ecosystem

The devices used as sensors in healthcare IoT are very diverse. Also, each device type has several limitations, such as its power generation capacity, how often it can be replaced, and the sensitivity of the data it collects [36]. A summary of the different device classes is provided in Table 1.

Data from all of the device classes flows through an identical process. Data generated by a sensor is transmitted via a gateway located near where the sensor is placed (most commonly using a cell phone, bedside unit, or a specific hospital gateway) to perform some form of localised computation and then select portions of the data to forward to either a cloud service or an internal back end at the hospital for long-term archival, for clinicians to view, and for further data analytics. This paper later describes one constraint that has the largest influence on the proposed framework in terms of the physical replacement capability of each of the device classes.

2.2. AI and Edge Computing Concepts Utilised

2.2.1. TinyML

The term “TinyML” refers to using Machine Learning (ML) inference in real-time and locally on the device. In this case, on a microcontroller-class of hardware [43] (in other words, constrained resources) that would otherwise need to send each inference request via an edge gateway or cloud backend. The advantage of deploying TinyML in such environments is that it enables gross anomaly detection at the point of generation, eliminating the power consumption associated with continuous data transmission [44].

2.2.2. Federated learning

Federated learning is a type of distributed training for shared models that trains on the local sensor deployment without transmission of raw data to a centralised location. The federated learning environment only allows for model updates and gradients to be transferred and aggregated. This also enables clinical AI models to train across distributed sensor deployments without collecting patient data centrally [45,46].

2.3. Quantum Computing Concepts Utilised

In this paper, two specific concepts from quantum computing theory motivate the approach of this framework to cryptography, as discussed below:

2.3.1. Shor’s Algorithm

Shor’s algorithm [47] is a quantum algorithm designed to solve large integer factorisation, as well as discrete log problems, with efficiency in time for a sufficiently large and reliable quantum computer. However, the two major problems facing Shor’s algorithm are purely based on the secure cryptographic systems known as Rivest–Shamir–Adleman (RSA) and Elliptic Curve Cryptography (ECC). The RSA and ECC could be broken if there is enough computational power to perform Shor’s algorithm on large numbers.

2.3.2. Grover’s Algorithm

Grover’s algorithm [48] is a quantum computer algorithm that allows searching an unstructured space with a quadratic speedup in terms of how much you need to increase your symmetric key length to keep the same level of security as before; the symmetric keys are doubled. It is the asymmetric cryptography threat posed by Shor’s algorithm and not the symmetric cryptography threat presented by Grover’s algorithm that presents the greater challenge when migrating to more secure cryptography.

In summary, together these two findings provide evidence of the “harvest now, decrypt later” attack. For example, an attacker that cannot breach the current RSA/ECC encryption mechanisms today may be able to collect (encrypted) sensor data from healthcare sensors in the form of encrypted messages today and then will be able to decode these at some point when they have access to a powerful enough quantum computer.

2.4. Post-Quantum Cryptography Schemes

Three National Institute of Standards and Technology (NIST) standardised post-quantum algorithm families are referenced later in this paper, which have an associated brief summary of the underlying mathematics.

2.4.1. CRYSTALS-Kyber

This is a lattice-based key encapsulation mechanism selected by NIST as the preferred standard for general-purpose post-quantum key exchange. The security of CRYSTALS-Kyber is based upon the conjectured difficulty of a variety of lattice problems, which should be hard against both classical and quantum attacks [49].

2.4.2. CRYSTALS-Dilithium

This is a lattice-based digital signature scheme that has the same underlying mathematical assumptions as CRYSTALS-Kyber. Dilithium is standardised by NIST as the first general-purpose post-quantum signature algorithm [50].

2.4.3. SPHINCS+

This is a hash-based digital signature scheme whose security relies entirely on the use of a hash function. Unlike Dilithium or Kyber, SPHINCS+ does not rely on the less well-tested lattice assumptions. Also, SPHINCS+ is a stateless algorithm, which means that no records of previous signing states need to be maintained by the signer. SPHINCS+ does not suffer from a category of catastrophic failures resulting from improper management of its signing state if its signing state is properly managed [51].

2.5. Digital Forensics Concepts

2.5.1. Chain-of-Custody

Chain of custody is the documented, unbroken sequence of who took possession of, dealt with, transported, and examined a piece of physical evidence (from when it is taken into custody by one person until it is presented as evidence during a legal proceeding). If there is a break at any point along the chain of custody, the evidence is considered inadmissible or less than credible. It does not matter whether the evidence has been properly obtained [52].

2.5.2. IoT Forensics

The main difference in IoT-based network forensics compared with traditional digital forensics is based on three factors. Firstly, volatile data found in limited memory devices may overwrite log records prior to their ability to be collected. Secondly, the diversity of manufacturing-provided devices and firmware makes it difficult to standardise evidence collection methods. Thirdly, the placement of limitations on the logging capabilities of the device and the preservation of evidence could adversely affect its primary clinical operation [53].

2.6. The Security Lifecycle Concept

A security lifecycle is defined as treating security as a dynamic and continuous process (not as a one-time event) that includes all phases of a system’s life cycle [54]. In other words, the lifecycle begins with initial design and continues during all stages of development, including ongoing operations. It also covers threat detection, incident response, and the lessons learned, which are fed back into future designs [55]. This definition aligns with a fundamental principle of security engineering, namely, that security properties eventually degrade or fail due to operational stress, and therefore need to be continually addressed by all parties involved in a system’s lifecycle instead of being treated as a single point in time [56].

The primary objective of this paper is to fully explore quantum-resilient cryptography and forensic knowledge, which are each integral to the two parts of this cycle (proactive/reactive), and, when treated as sequential components of the same cycle, these together provide a complete life cycle, whereas individually neither does.

3. Motivation and Problem Analysis

This section establishes the core rationale behind the study by identifying key limitations and gaps in an AI-driven healthcare IoT sensing system. It critically analyses all such existing challenges that are addressed in Table 2. By defining these core issues, the section lays out the explicit motivation for promoting a need for a Secure Lifecycle Framework.

3.1. Threat Landscape for AI-Driven Healthcare IoT Sensing

The sources of the various threats that exist in a healthcare IoT sensing system can be categorised into three contexts: the cryptography layer [57], AI landscape parts that reside at the edge of the network [40], and the traditional IoT attack surface prior to all of these [58]. Although these attacks represent different categories of threats, these threat types have historically been reviewed in their respective bodies of literature separately. Table 2 identifies representative attacks within these categories and indicates the lifecycle stage primarily responsible for mitigating each type of attack.

There are two points about the attack types. First, there is a type of attack called “harvest now, decrypt later” in which an attacker records the encrypted sensor data today (and has no way to decrypt it) but keeps it for later use when they have access to a powerful enough quantum computer to decrypt it. The quantum-enabled category contains the single type of attack most likely to motivate the author’s focus on designing systems to be resilient against threats from quantum computers at design time instead of waiting until those threats become current.

Secondly, the forensic gap does not really describe an attack in a traditional way. The forensic gap describes the lack of a feature or function. In other words, anyone could build a healthcare IoT system as per the first three categories of attacks listed above, which could be technically inviolate. However, the violation of the fourth category by the attacker could be false because there is no prior investigative method to identify whether the incident happened before or after the attack.

3.2. Limitations of Existing Approaches

Table 3 identifies how each of the four categories of current research works within the threat model provided, and what each does well.

In general, there is a common theme among all four categories: while each has identified a true and required part of the problem space, no category has addressed the relationships among parts of the problem. A PQC proposal that is provided to an organisation but never integrated into their forensic logging process provides an organisation that can defend itself from some types of attacks but has little or no ability to conduct investigations when those attacks are successful. A forensics framework that is created without consideration of quantum-safe evidence integrity creates an evidentiary record that is also susceptible to the same “harvest now, decrypt later” exposure mentioned previously. In other words, an adversary that may be able to decrypt archived sensor data at some future time may use the same method to create a false signature on evidence signed using only classical cryptography or repudiate signatures already generated.

To the best of our knowledge, this relationship is often implicit in much of the forensic literature and generally treats evidence integrity as if it had already been solved rather than as having latent quantum vulnerabilities.

3.3. Why a Security Lifecycle Framework Is Needed

The limitations discussed above are interdependent with each other. As such, these are part of a larger causal chain in which a failure to address a limitation in one stage (e.g., lifecycle) results in a cascading effect that negatively impacts subsequent stages. For example, if we develop “quantum-safe” encryption methods that do not include “forensic logging” then there is a need to develop a system that is resistant to most of the attacks; however, once an attacker successfully exploits a vulnerability using another method, there is no ability to determine how or why this happened. Furthermore, if we implement “forensic logging” but fail to ensure the integrity of the evidence collected via “forensic logging” then the data collected may become unreliable over time. In other words, the record collected today can be certified as valid today, but not in years or even decades. If someone uses “AI-based” detection systems and connects these to neither “forensic logging” nor “quantum-safe” encryption methods, then we generate alerts regarding suspicious behaviour that are presently unactionable by both the investigative team and the security team, such as potentially useful for making clinical decisions but irrelevant to ensuring accountability.

A lifecycle framework is the architecture for making those relationships apparent and addressing these as a connected design requirement rather than as two independent research problems that can be resolved separately and then brought together. Thus, this paper addresses the gap in how to organise existing techniques into an architectural relationship in such a way that architectural relationships can identify the weaknesses in the existing systems rather than just completely fix these. However, this paper is not about the development of some single new cryptographic or forensic technique.

3.4. Design Requirements for the Framework

The discussion above motivates the development of eight functional requirements for the proposed framework to address the previously described gaps.

• R1 — Quantum-safe: All encryption functions in the sensing pipeline must remain secure from an adversary who has access to a quantum computer capable of breaking the current state-of-the-art cryptography techniques used today and has exfiltrated all prior collected data using a “harvest now, decrypt later” approach. [8,9].
• R2 — Forensic integrity: Data relevant to an incident must be protected, tamper-evident, and verifiable, including being able to verify evidence years after it is collected.[31,52].
• R3 — AI detection: AI-based threat detection should be possible in near real time based on the type of device(s) utilised by the threat actors’ method of attack.
• R4 — Privacy compliance: All functionality must be compliant with HIPAA, GDPR, etc., when dealing with patient information, including during investigations into incidents.[19,20].
• R5 — Scalability: Functionality must work seamlessly over various types and sizes of IoT deployments in healthcare, such as one device at a time to large-scale, multi-device, multi-site, wide-area-networked sensors.
• R6 — Energy-aware: Functionality must respect the extreme limitations of available energy in wearables and implants, where there is no practical way to replace batteries in these devices through anything other than invasive surgical procedures [8,56].
• R7 — Interoperable: Functionality must be compatible with a variety of device manufacturers and allow for functionality to be added to existing “long tail” devices regardless of their age [18,55].
• R8 — Auditable: Each phase of the life cycle must create records that can provide evidence supporting clinical governance and/or regulatory inquiry (not just during investigation phases) [13,31].

Each of these eight needs does not arise by chance. Rather, each can trace back to an area identified as a “gap” within the previous section, with each being evaluated on an individual basis for consistency with the components of the framework later in this paper.

4. Proposed Security Lifecycle Framework

This section outlines a comprehensive, end-to-end proposed quantum-resilient and forensic-aware security lifecycle framework for secure development and deployment in AI-driven edge sensing in healthcare IoT systems. The following discussion details the phases, including Quantum-Resilient Design Foundation, Secure AI-Driven Edge Sensing Operations, AI-Driven Threat Detection, and Forensic-Aware Incident Investigation that drive this framework’s operational effectiveness.

4.1. Framework Overview

This paper presents a framework for organising sensor security in the context of Healthcare IoT systems into four sequential, interdependent lifecycle stages: Design, Operate, Detect, and Respond. The proposed framework is illustrated in Figure 1. These stages are specific moments in time that occur throughout the operational life of each sensor. This spans the time from when the sensors are designed, manufactured, installed, and operating through the investigation of an event or incident in which one of these sensors is involved.

All of these layers are horizontal cuts through each phase. The Quantum Resilience Layer guarantees that any cryptographic operations (key creation, authentication, signing, encryption) carried out in any phase will be resistant to a malicious actor who has access to a computationally capable quantum machine. The Forensic Awareness Layer guarantees that each phase produces and retains appropriate forensic data, which can be used to assist in an investigation if one is needed, and it does not treat forensic readiness as an afterthought, something added after a breach is identified. The AI-driven Edge Intelligence Layer indicates that there are AI models active in each phase of the lifecycle, and these perform inference during normal operation, perform anomaly detection during the Detect phase, and aid humans during the Respond phase.

Below both layers is a privacy/regulatory compliance substrate. This substrate satisfies all HIPAA, GDPR, and Food and Drug Administration (FDA) medical device cybersecurity requirements.

The reasoning behind this approach comes from Section 3. Forensic mechanisms are responsible for accountability, yet do not protect against a potentially cryptographically compromised system once an adversary has developed quantum capabilities. Similarly, quantum-resistant cryptography offers both confidentiality and integrity protections but does not offer any mechanism to account for actions taken or unauthorised access if an attack is to occur. Together, these address each other’s shortcomings. These are functionally treated as separate proactive and reactive elements to solve the same ongoing problem, while they are connected through AI-driven detection capabilities.

4.2. Phase 1 — Quantum-Resilient Design Foundation

The goal of this stage is to create quantum-resistant cryptographic and forensic bases for all healthcare IoT sensor units prior to their deployment on the Internet. Security is to be built into the hardware and firmware of these systems rather than being an add-on post-deployment.

4.2.1. Post-Quantum Cryptographic Algorithm Selection for Sensor Hardware

When selecting PQC primitives for healthcare IoT sensors, we must consider the extreme resource limitations of most medical devices, especially those that are implantable. Since replacing batteries with new ones typically involves surgery and energy budgets are measured in microwatts, the framework has recommended a two-tiered strategy:

• CRYSTALS-Kyber (lattice-based key encapsulation): It is used in this application due to a relatively acceptable computation/security trade-off compared to other standardised algorithms offered by NIST.
• CRYSTALS-Dilithium: It is utilised as a digital signature method when the sensor has enough computational resources (i.e., edge gateways and ambient clinical sensors).
• SPHINCS+: It is used on ultra-restricted, resource-constrained implanted medical devices that require stateless, hash-based signatures. Although SPHINCS+ generates larger signature sizes than Dilithium, the potential loss of security from corruption and duplication of the internal state of a stateful signature mechanism would be an unacceptable risk.

The criteria for selecting, such as energy used per operation, the ratio of signatures to ciphertexts as compared to available memory (and therefore limited), and latency as related to clinical “real-time” constraints, need to be made explicit and on a device-by-device basis for each type of sensor so that these are not applied uniformly by one algorithm over all different types of sensors.

4.2.2. Quantum-Safe Authentication and Identity Architecture

Every sensor must have a quantum-safe identity generated when it is manufactured:

• Device certificates based on PQC used within an after-quantum PKI, in place of using RSA- or ECC-based device identities [59].
• QKD is being considered only for use along the hospital backbone networks (connecting all the edge gateway devices to the main centralised resources), as it is cost-effective in comparison to other solutions due to the fixed high-value connections. It is not used on point-to-point (sensor-to-gateway) links since it would require impractically large amounts of QKD hardware [60].
• Secure bootstrapping protocols are designed to create a new sensor’s quantum-safe identity upon clinical onboarding of each sensor and define the procedures by which keys can be rotated and revoked over a sensor’s many years of operation.

4.2.3. Forensic-by-Design Principles at the Hardware Level

All forensic capabilities must be integrated into early product development phases so that these cannot be an “add-on” feature.

• Design sensors for evidence of tampering. In other words, if someone physically interferes with your sensor, you want it to show some form of indication (signal) and not just quietly pass by unnoticed.
• Capability for immutable (append-only) logging within the firmware of the sensor. The log needs to be sufficient for its storage capacity. This way, there is always a minimum, non-tampered-with, operational record available for the most limited of implanted devices.
• Quantum-resistant digital signature(s) applied directly to the output of each sensor as it generates data. This is helpful specifically after the completion of the original communication session. This provides a means to verify the integrity of the data being sent.

4.2.4. Hybrid Classical-to-Quantum Transition Strategy

Hospitals are using large numbers of legacy systems where the hybrid mode is one of the options for these. In this mode, classical RSA / ECC methods are run alongside PQC methods until a specified date. At that time, both methods must authenticate successfully before access is granted to a system or network. This allows healthcare organisations to protect their networks from potential compromises by quantum computers, but it does not allow them to migrate their systems to PQC at their own pace.

4.3. Phase 2 — Secure AI-Driven Edge Sensing Operations

The goal of this phase is to ensure that the quantum-safe and forensic auditing attributes developed during Phase 1 are preserved for all daily clinical operations and also to provide real-time processing capabilities for AI inference.

4.3.1. Quantum-Safe Edge Communication Pipeline

• All transmissions between the sensor and the edge device and then from the edge device to the cloud use the same PQC key exchange and signature schemes used in Phase 1.
• Edge devices serve as translators between less capable, resource-constrained sensor devices, which have lightweight PQC parameters, and cloud backend systems that could support stronger parameters. This is done without exposing any data to be transmitted in a classical encrypted-only form.
• Secure enclaves in an edge gateway protect the inference computations performed by AI inference from being impacted by a compromised inference pipeline and from being able to compromise the cryptographic keys.

4.3.2. Privacy-Preserving AI Sensing at the Edge

• Federated ML using a variety of techniques in order to ensure privacy as well as security when data is being transmitted from multiple remote sensors. It uses quantum-resistant cryptographic methods to protect model updates from potential attacks through the quantum computer in the near future [61].
• Apply differential privacy to all sensor analytics outputs prior to transmission, based on each data sensitivity level (for example, higher privacy budget levels should be applied to sensitive information such as mental health or reproductive health, versus less stringent privacy levels for general fitness/health monitoring).
• Quantum-safe homomorphic encryption may also be used for select high-value analytics (population-wide environmental health correlations), but would likely be too computationally intensive to apply uniformly to all real-time sensor feeds.

4.3.3. Blockchain-Anchored Sensor Data Integrity

• The data is anchored using post-quantum signatures in a permissioned distributed ledger. This allows for an immutable proof of origin for each batch of sensor data, as well as the results of the AI inference.
• The smart contract is used to automate the compliance check on all sensor data (verify that it has not passed the maximum time allowed to retain the data), then send any violation to a human reviewer.

4.3.4. Operational Forensic Readiness

• Data will be continuously logged for forensics on devices during regular operation. The granularity of logs collected from devices will adapt based on available resources. For example, there would be rich logging occurring at edge gateway devices, while minimal, but still cryptographically signed, events would occur in constrained implantable devices.
• Metadata documenting chain-of-custody will be automatically generated and added to the data if it is transferred from sensors to edge devices to cloud-based storage. This allows for the preservation of evidence value without requiring an additional forensic data capture process to be initiated manually by users.

4.4. Phase 3 — AI-Driven Threat Detection

The goal for Phase 3 is to deliver real-time, explainable detection of all types of anomalies and threats; it will also serve as an interface between the proactive prevention of Phases 1-2 and the reactive investigations of Phase 4.

4.4.1. Multi-Layer Anomaly Detection Architecture

• Sensor Level: TinyML, which is lightweight and runs on devices, collects the most basic information possible and can identify obvious, gross anomalies, e.g., completely impossible physiological measurements, clear patterns of dropouts due to manipulation of the signals, and uses minimal processing resources.
• Edge Level: Federated Threat Intelligence Sharing enables edge gateways in a hospital or hospital network to share intelligence regarding detected anomalies at each gateway without sharing raw patient data.
• Network Level: Traffic pattern analysis on the entire end-to-end sensor-to-gateway-to-cloud communications pipeline identifies anomalous behaviours related to how sensors communicate through this pipeline (i.e., abnormal retransmission behaviours indicative of an attack in progress, i.e., man-in-the-middle).

4.4.2. Quantum-Enhanced Detection Capability

The reason why we can position the Quantum Machine Learning (QML) technology as a long-term add-on to the existing layer of the architecture is that, when it has been proven and tested with the data sets we are working with, this technology offers better ways of classifying patterns in higher-dimensional spaces than traditional Classical Machine Learning (CML). The CML will remain our “baseline” since we do not currently know how to deploy any of these technologies for a clinical application in real-time.

4.4.3. Explainable AI for Clinical Accountability

In addition to triggering an alert intended to inform clinical staff who will take action based on the alert, every decision made by the system that generates an alert includes an explanation from a person. For example, if an alert is triggered by a sensor anomaly, the system should highlight the specific combination of readings that contributed most to the detection. There are two needs satisfied simultaneously by generating an explanation of an alert. First, there is a practical need, i.e., clinical staff need to understand what it means for an alert to be triggered so they may react accordingly. Second, there is a regulatory requirement for explanations for each AI-based decision, e.g., clinicians and others may require documentation of the basis for alerts so that they may verify decisions or audit past decisions.

4.4.4. The Forensic Trigger Mechanism

There exists a structural relationship between Phases 3 and 4 of this architecture. Upon detecting sufficient confidence in the presence of an anomaly, the system will initiate automated evidence collection. This involves making a copy of all applicable sensor and edge gateway states at the moment the detection is made, prior to the loss of that transient information. The system will then send an escalated version of the alert through a secure communications path to clinical staff and, if warranted, to a group responding to potential cyber threats.

4.5. Phase 4 — Forensic-Aware Incident Investigation

The fourth phase represents the conclusion of this model. It provides for a compliant, private, evidence-based inquiry into all aspects of security breaches once these have been identified, utilising protected evidence from the first phase.

4.5.1. Multi-Layer Forensic Investigation Pipeline

This inquiry is performed across the three layers where evidence is generated and recorded, i.e., sensor, edge, and cloud layers. A single incident report will provide evidence of correlation across all three layers. These three layers reflect the real-world scenario in that an attacker may create various traces of their actions at each level. For example, there could be physical evidence of a sensor being tampered with at the sensor layer, abnormal network activity at the edge gateway layer, and a variety of unusual access patterns within the cloud-based backend.

4.5.2. Quantum-Safe Evidence Integrity

• All the forensic evidence will be signed using the quantum-resistant signature schemes developed for Phase 1. This ensures all evidence gathered today can be verified by the public long-term (many years), as this is especially important as many healthcare litigation & regulatory inquiries do not occur until many years after a healthcare incident.
• Any past attempts to alter the evidentiary record can be detected using quantum-resistant hash chains that link each piece of evidence together.

4.5.3. Privacy-Compliant Investigation

• Using federated forensic analytics, law enforcement can perform pattern matching on distributed logs from sensors at different sites without having access to the original patient’s information. This enables a single agency to investigate multiple site occurrences as well as provide for HIPAA/GDPR compliance.
• Differential privacy will be applied to all forensic data, and it will be shared with agencies outside the clinical security team. For example, aggregated incident data could be sent to a regulatory body.

4.5.4. AI-Assisted Forensic Analysis

Automated machine learning provides assistance, but there is no way it can provide a replacement for human forensic investigators. The machine can aid by narrowing down the focus area (or time frame) that an investigator will need to investigate with regard to their forensic artefact collection. In addition, it allows them to create more efficient attack timelines through using graphs of events reconstructed from data logged at both the edge and the sensors.

4.6. Synthesis: How the Four Phases Form a Continuous Security Lifecycle

The four phases that have been discussed do not represent independent security mechanisms applied during separate time frames provide an ongoing lifecycle where each phase relies upon and supports the others. The quantum-safe identity and cryptographic primitives implemented in Phase 1 establish the keys, signatures, and certificates for all communications in Phase 2, support the generation of alerts for detection from Phase 3, and also support the integrity of all data/evidence evaluated in Phase 4. Additionally, forensic logging, a hardware requirement from Phase 1, captures data with low overhead during Phase 2. It switches to preservation mode when malicious activity is detected in Phase 3 and is used to build the evidentiary record in Phase 4.

The framework’s continuum is what differentiates the proposed framework from considering the application of quantum-resilient cryptographic methods and digital forensic techniques on the same sensors as a loosely coupled combination of two distinct research areas. If a single phase fails, all subsequent phases are compromised: e.g., a sensor without a quantum-safe identity (failure at Phase 1) generates operational data of unknown or unreliable origin (threatens Phase 2), subsequently generates detection alerts that can’t be trusted (weakens Phase 3), and ultimately generates forensic evidence whose integrity in the chain of custody cannot be traced back to a reliable source (renders Phase 4 useless.) Lifecycle frames the interdependence among these phases explicitly and, therefore, considers this dependence as part of the design requirements and not as an implied condition.

These three crosscutting layers, such as (i) quantum resiliency, (ii) forensic knowledge, and (iii) AI-based edge intelligence, are the vehicle for realising the continuity across these four phases. Each phase, therefore, leverages the same set of quantum-resistant primitives, adds to the same forensic record, and is mediated by the same set of AI-based components but at different stages of their life cycle (during inference during Operate, during anomaly detection during Detect, and during supporting evidence analysis during Respond). The private/compliance layer underlies all four phases in order to realise continuity without increasing regulatory risk through the HIPAA/GDPR compliance requirements being met as an attribute of the entire lifecycle versus being separately verified at each phase.

The true innovation lies with the overall framework itself (the fact it provides a continuous life cycle) as opposed to just either the use of post-quantum crypto or the use of forensic logging individually. Section 5 reviews the entire components of the framework relative to the design requirements presented in Section 3.4, then assesses how the complete proposed framework fits into current frameworks that only attempt to deal with pieces of this lifecycle.

5. Framework Component Analysis

This section breaks down core structural components and underlying mechanisms that constitute the proposed framework. By systematically analysing each technical layer and specific operational function, it clarifies how these individual elements interact effectively to process data for Framework applicability across healthcare sensing scenarios. Ultimately, the detailed decomposition provides a clear architectural blueprint and establishes a theoretical foundation for the overall system. Table 4 also maps framework components to design requirements.

5.1. Detailed Framework Architecture

The last section used the lifecycle stages (phases) and their corresponding components in a story format. Figure 2 displays all of the components as an architectural view, it shows each stage as a container containing its subordinate components, along with a feedback loop from response to design indicating that forensic results from one event are often used to make design changes to the next generation of fielded sensors, i.e., if a forensic analysis identifies a previously unknown method of tampering, that information should be fed back into the forensic-by-design requirements applied to future sensor hardware.

This architectural view serves as the foundation for the rest of this section. In that section, we will map the components from the architecture to the framework’s design specifications, compare our developed architecture to other architectures that have been proposed, demonstrate how the architecture can be applied to various healthcare sensing use cases, and discuss the tradeoffs (in terms of both energy consumption and resources) associated with implementing those components on limited medical hardware.

5.2. Mapping Framework Components to Design Requirements

Table 4 assigns each of the sixteen elements depicted in Figure 2 to the eight design criteria (R1-R8) for this framework. An “X” indicates the element satisfies that criterion. Each element may be used to satisfy more than one criterion. Most of the eight criteria are satisfied by two or more elements. This is an example of redundancy within a system, as opposed to duplicate points of failure; a failure at one point in the system will not eliminate all satisfaction for one of the design requirements.

From Table 4, we can make two observations about the given information. First, the auditability requirement (R8) shows the highest compliance, with ten of the sixteen components successfully audited. This indicates that there is a focus on auditing throughout the majority of the process for this particular criterion, as opposed to other requirements, which could potentially be audited solely during the response portion of the process. Secondly, while it appears that there are only four components that meet the “energy aware” (R6) criteria, these are all identified in either the design or operating phases. These results reflect actual energy costs, i.e., those associated with cryptographic operations and continuously logging on devices with constrained resources, rather than an attempt to de-emphasise energy awareness in detection/response portions of the process when the computational load will occur at edge gateways or in cloud backend systems that are equipped with relatively generous power allocations.

5.3. Comparative Analysis with Existing Approaches

Table 5 compares our proposed framework with other works that are categorised into four types: (i) General-purpose IoT security frameworks, (ii) PQC proposals for constrained devices, (iii) Digital forensic frameworks for IoT systems, and (iv) Surveys on healthcare IoT security. This comparison has been organised using the same dimensions as those used in Table 4. These dimensions are, however, collapsed to a checkmark/partial/cross scale that can be appropriately compared across various bodies of literature (heterogeneous) versus one named system.

The emerging pattern is not that current research lacks strength in their respective areas; it is just that while PQC designs are clearly well-suited to be “quantum safe” and IoT forensic frameworks have clear forensic awareness capabilities, there is no single category or paradigm that incorporates both of these elements in an integrated way across the entire lifecycle of device development (i.e., design) through post-incident investigation. This comparison highlights the gap motivating this paper and, therefore, situates the paper’s contribution as being integrative, rather than claiming the invention of some specific underlying technique.

5.4. Framework Applicability Across Healthcare Sensing Scenarios

In order to illustrate how the model can be applied in practice to a wide variety of devices (each with its own characteristics), Table 6 illustrates four examples of various devices and indicates which of each phase’s instantiations apply to those particular devices.

In addition to illustrating this use case-based walk-through, it has provided another illustration of an important pattern in how the degree of constraint on design phase decisions (for example, SPHINCS+ vs a larger Dilithium parameter set) is tied to the physical replaceability of the device. Sensors implanted inside the body that require surgery for battery replacement receive the lightest, lowest-overhead cryptography. The same applies to the ICU sensors that have a main electrical connection and will be easily physically accessible. These may be allowed to contain heavier mechanisms such as a QKD-secured gateway.

5.5. Energy and Resource Overhead Analysis

One of the major drawbacks to utilising both PQC and continuous forensic logging for Healthcare IoT (HIoT) devices is the additional amount of power required and memory used by such mechanisms compared to the classical encryption methods these are replacing. We will explore this tradeoff conceptually; we do not intend to provide a comprehensive analysis or experimental study of HIoT device performance using PQC and Certificate Revocation List (CRL).

PQC signature and key-encapsulation schemes differ significantly in terms of their resource utilisation. Classical lattice-based methods such as Dilithium and Kyber allow for faster computations, but these have larger keys and ciphertexts when compared to classical RSA/ECC-based methods. Although this can be absorbed by the resources available at edge gateway systems using traditional power supplies and ambient sensor applications, it is much more difficult to absorb these increased costs on implantable devices due to limitations on their permanent storage capacity. Further, hash-based methods like SPHINCS+ have the advantage over stateful signature methods because these provide an additional layer of protection against failures related to managing states. However, hash-based methods also produce longer signatures and are more time-consuming during the signing process. This tradeoff is determined by the frameworks to be acceptable from the perspective of use cases involving implantable medical devices. The reason is that the consequences of a state management failure (i.e., accepting a forgery as valid) would likely be worse than the consequences of having a larger or slower-to-produce signature.

Continuous forensic logging brings another new dimension in terms of overhead, where it will be from the perspective of the amount of data that you need to store versus how much computation is needed. The first step toward mitigating the problem introduced by continuous forensic logging, which would be the main method of reducing the overall impact on your system (in terms of size), would be to adjust the level of detail (granularity) within your logs as a function of what kind of device you are running on. Minimal, cryptographically signed event-based logging should occur upon the most resource-constrained devices, while richer, less sparse logging occurs upon an edge gateway, where there exists significantly more storage space available. In terms of designing systems such as these, there can exist many different “tradeoffs” that one may make. In this case, we have made a conscious decision to reduce the level of forensic granularity associated with our constrained (e.g., implantable), yet viable, system, whereas we intend to compensate by creating a larger and therefore more detailed record of events across the same time frame at the edge gateway.

The choices made within the design phases presented here are not fully resolved by this framework, which can represent a major direction for future empirical work.

6. Discussion

This section interprets the findings of the proposed lifecycle framework and its benefits that combine quantum-resistant cryptography and digital forensics as an autonomous layer for sensing IoT in healthcare systems. The section also covers the gaps in the proposed framework alongside a deep pathway. Additionally, this section addresses the study’s key limitations and provides actionable insights for sensing IoT in healthcare systems.

6.1. Framework Strengths

The proposed security lifecycle framework provides numerous benefits compared to addressing quantum-resistant cryptography and digital forensics as independent layers on top of sensing IoT in healthcare systems.

6.1.1. Unified Lifecycle Coverage

The proposed security lifecycle framework addresses the gap between securing a system upon deployment, then having an accountable, capable investigation, versus providing forensic capabilities on a cryptographic basis, which is subject to eventual attacks from quantum-enabled adversaries. However, none of the categories of existing works spans the entire scope [18,30].

6.1.2. Quantum Resilience and Forensic Awareness as Complementary, Not Competing, Concerns

We are aware of no existing research [8,21,31] that articulates an argument that a weakness that is developed during the design phase will propagate into all subsequent investigations so that the value of evidence from those investigations will be diminished [32]. Treating these two concerns as inseparable rather than as separate alternatives for future research is also a conceptual contribution, regardless of any single technique being suggested by this framework.

6.1.3. AI as Connective Tissue Rather than an Isolated Add-On

Positioning AI-enabled detection as the linkage structure that spans both proactive defence mechanisms and reactive investigative methods allows an AI system to be used in a manner consistent with its deployment in many contemporary healthcare IoT systems [11,35,40] and provides a method of linking detection to evidence preservation without needing an additional user-initiated action.

6.1.4. Practical Applicability Across Heterogeneous Device Classes

The framework does not prescribe a single solution for every wearable or implantable; instead, it allows for a range of resource-constrained devices (wearable, implantable, and ambient) and scales cryptographic and forensic mechanisms for each class rather than expecting equal capabilities.

6.1.5. Compliance Treated as a Foundational Property Rather than a Retrofit

Embedding HIPAA and GDPR into each of the four stages, instead of being merely a post-architecture compliance checklist [20,56], will help ensure the development of a technically sound solution that can operate within the confines of a regulatory clinical environment.

6.2. Framework Limitations and Honest Gaps

The following highlights the limitations and gaps in our paper.

6.2.1. No Empirical Validation

The above discusses a conceptual architecture and performs an analysis of it. This paper does not implement or measure the performance (with real-world devices) of either component of the proposed architecture. The qualitative nature of the energy and resource overhead is discussed elsewhere in this paper. Claims about feasibility, such as “SPHINCS+ is appropriate for implantables” are based on the general properties of these algorithms in constrained environments rather than healthcare-specific benchmarks [43,51].

6.2.2. Quantum Key Distribution Scalability Is Asserted, Not Demonstrated

The proposed framework believes Quantum key distribution (QKD) [62] should be used in the backbone of hospitals (as opposed to sensor-to-gateway), as it would be too expensive to implement point-to-point QKD at sensor scales. While it’s consistent with the known constraints of QKD architectures, there is no assessment of the actual cost associated with implementing backbone-level QKD deployments, nor are there assessments related to integration with other hospital networks.

6.2.3. No Mechanism for Mid-Lifecycle Recovery from a Design-Phase Failure

The identification of a potential downstream issue through the detection & response (D&R) phase in this framework will allow for investigation into the effects that arise from a flaw in a design-phase decision, i.e., a device with a poorly configured cryptographic scheme. However, the D&R phase does not include any remedial actions to address previously deployed products [8,38,39] to address a newly identified design vulnerability; the system relies exclusively on a hybrid mechanism to transition from the legacy configuration to the new one.

6.2.4. The Federated Forensics Privacy-Utility Tradeoff Is Not Resolved

The framework provides methods of conducting federated investigations so that incident information can be obtained by a law enforcement agency (without requiring access to the hospital’s database) and suggests that no data should ever be centrally collected; however, it does not discuss at all how much investigative detail would be lost as compared with having full centralised access to the hospital’s data system. Also, it does not provide guidance on when such an investigative detail loss would be operationally acceptable to a hospital’s security team.

6.2.5. The Quantum Threat Timeline Is Inherently Uncertain

It is assumed in this paper that there will be a multi-year transition time frame where both classical and PQC-based systems are operational. If the actual development of quantum computers with cryptographic relevance occurs sooner or later than expected by experts currently, then design priorities, particularly the importance assigned to deploying QKD as a “backbone” vs using only PQC-based systems, would need to be revised.

6.2.6. Quantum Machine Learning Is Treated as a Future-Horizon Capability, Not a Present One

It is intentionally excluded from the framework’s claims that QML provides an operational benefit in performing real-time detection of clinical anomalies [8], now using CML as the standard for comparison during the detection process. That is a limitation because one of the three layers (quantum resilience) identified by the authors as being ’cross-cutting,’ i.e., being applicable across multiple layers of abstraction, can offer very limited additional value toward detecting threats compared to the protection of the detection alert channel and model updates via cryptography.

6.3. Implementation Pathway

A phased implementation strategy provides a grounded reference for both healthcare organisations and medical device manufacturers to consider the components of the proposed framework.

6.3.1. Short Term (One to Two Years)

Healthcare organisations may first start by making the NIST PQC algorithm [63] support a required procurement specification for future medical device procurements. At the same time, forensic logging capability could be enabled with minimal granularity in edge gateway software (since gateways are generally easier to update than the implanted/wearable devices). This represents an opportunity to improve their forensic-readiness capabilities quickly.

6.3.2. Medium Term (Two to Four Years)

The organisations will also have the opportunity to expand the PQC protection in the entire data flow from a sensor through an edge system to a cloud, due to replacing old devices with new ones over time and using AI for detecting anomalies that may be indicative of malicious attacks on the PQC mechanisms used for forensics triggering.

6.3.3. Long Term (Four or More Years)

The backbone of hospitals will eventually be based on QKD security, and then, as technology advances, the sensing architectures will become “quantum native” based on quantum hardware that has matured [60,62]. This timeline is speculative at best and should be revised as we learn about both the quantum threats and how standards-based PQC evolves.

This path is proposed as an efficient place to begin the conversation about how to implement this solution, not as a proven way to do so; this path illustrates that each component can be adopted incrementally compared to being required to be implemented all at once.

6.4. Regulatory and Standardisation Implications

NIST standardisation for PQC is selected to align with the development of regulatory expectations for the use of cryptographic solutions, not because it is anticipated that there will be some future requirement. As NIST PQC standards are more fully developed and FDA guidance on the cybersecurity of medical devices evolves [64], additional implementation guidance specific to healthcare will be needed from domain-specific standards organisations (i.e., acceptable parameters for implantable devices and acceptable minimums for forensic logging). The framework explicitly maps each component to HIPAA and GDPR considerations as a starting point for that discussion, but it is not a replacement for that discussion. This paper does not purport to have legal or regulatory authority over compliance issues, and organisations implementing any component(s) of this solution should review compliance requirements in their jurisdiction with their respective legal counsel.

7. Future Research Directions

The constraints described above provide an operational research agenda for this framework compared to simply limiting its applicability. The purpose of this section is to organise the research agenda in terms of time and then summarise all the directions into a single table that associates each direction with the constraint that generates it.

7.1. Short-Term Research Priorities (One to Two Years)

7.1.1. Empirical Benchmarking of PQC Algorithms on Real Healthcare IoT Hardware

Specifically, our immediate claim regarding the feasibility of using PQC algorithms in healthcare depends on generalised characterisations of PQC algorithms running on constrained devices, compared to any measurements made specifically in healthcare [10]. Therefore, the first step towards realising these feasibility claims is to develop benchmarks for those candidate algorithms (i.e., both SPHINCS+ and lightweight Kyber [49,51]) that we have identified in prior sections, to run these on appropriate classes of implantable/wearable hardware devices, and to measure their energy consumption per operation, their memory usage, and their latency against the specific clinical real-time performance requirements associated with each device class.

7.1.2. Forensic Logging Protocols for Energy-Harvesting and Battery-Constrained Medical Sensors

To concretely address the granularity tradeoff we previously described in an abstract manner, it would be necessary to develop concrete protocol methods for (a) determining a minimum logging granularity per device type that will remain evidentially valuable with a specified storage and energy budget, and (b) defining the amount of evidential detail lost as a result of each level of granularity reduction.

7.1.3. Lightweight PQC Algorithm Variants Specifically Targeting Implantable Devices

In addition to measuring the performance of standard NIST algorithms, developing specific parameters or variations using NIST algorithms tailored for implants, which trade a small security margin for substantial energy savings, is the best approach for these ultra-constrained devices [65].

7.2. Medium-Term Research Priorities (Two to Four Years)

7.2.1. Quantum-Safe Federated Learning Clinical Testbeds

As part of the proposed operational phase, we recommend using federated learning with post-quantum secure aggregation [24,66]. However, there are no standardised test beds available today to measure how many different federated learning designs can perform when these have been tested using real-world clinical data distribution, device variation, and network configurations. The creation of a shared test bed would enable the research community to evaluate the performance of different federated learning designs at one time, as the existing federated learning benchmarks are outside of healthcare.

7.2.2. Formal Privacy-Utility Characterisation of Federated Forensics

As part of the proposed operational phase, we recommend using federated learning with post-quantum secure aggregation [24,66]. However, there are no standardised test beds available today to measure how many different federated learning designs can perform when these have been tested using real-world clinical data distribution, device variation, and network configurations. The creation of a shared test bed would enable the research community to evaluate the performance of different federated learning designs at one time, as the existing federated learning benchmarks are outside of healthcare. There is no current quantification of the privacy-utility tradeoff in the area of federated forensic investigation in the proposed framework [66]. Empirical research that establishes a formal (and empirically validated) privacy-utility tradeoff for multi-site forensic incident cases will enable healthcare security teams to make informed decisions as to when federated investigation can provide sufficient resolution to an investigation and whether there are real-world circumstances in which centralised forensic investigation with associated costs to privacy is truly required.

7.2.3. Standardised Forensic Evidence Formats for Healthcare IoT

The multi-layered investigative process envisioned within this proposed framework is contingent upon the ability to correlate data from sensors, edges, and clouds. Correlation of such data would be significantly enhanced by the existence of standard, non-proprietary formats for evidence generated through various healthcare IoT devices, as exists, for example, with digital forensic tools (in general) in other sectors [23]. This would convert what currently amounts to a “best effort” into a structured process.

7.2.4. Explainable AI Frameworks Suited to Real-Time Clinical Constraints

The framework indicates that real-time clinical alerting requires timely and low-latency detection alerts with human-interpretable explanations. However, it does not reconcile the tradeoff between explanation quality (fidelity) and the requirement for timeliness [11]. Real-time compatible explainable AI (XAI) approaches are needed for physiological anomaly detection to fill the gap in the framework regarding explanation fidelity versus the timeliness required for clinical real-time alerting.

7.3. Long-Term Research Priorities (Four or More Years)

7.3.1. Quantum Network-Ready Hospital Infrastructure

In addition, while the framework recommends that a QKD backbone be deployed based on an architectural standpoint, there is no modelling or costing for deploying QKD at the scale of the hospitals’ networks. As such, longer-term research and pilot deployments will be required to determine realistic cost models and also realistic integration and maintenance models for QKD deployment within hospital network infrastructures.

7.3.2. Remediation Pathways for Mid-Lifecycle Cryptographic Failures in Non-Replaceable Devices

The most structurally important open issue in this paper is that the existing structure does not provide a means to fix a flawed cryptographic design choice made during the design phase for an implanted device that cannot be removed from the body or updated through reprogramming. Research into cryptographic agility [67] may enable future implants to update algorithms after deployment. This would help bridge a gap that the current framework can identify and analyse, but cannot resolve.

7.3.3. Maturation and Validation of QML for Real-Time Anomaly Detection

The proposed framework views QML as an emerging horizon in the future, relative to the current detection phase. Whether QML transitions from an aspirational concept to an actionable capability depends on tracking advancements in the field and benchmarking QML against classical ML approaches [30] for specific health-sensing tasks.

7.4. Research Roadmap Summary

Table 7 is a consolidation of the identified areas of research listed above, and relates each area of research to the limitations which motivate these.

An important pattern can be derived from this table as follows: there are a number of highly significant open problems. However, one of these (the lack of a remediation pathway for products that have a defective design) has no near-term research-based solutions. We want to make clear that this did not represent a failure to address this issue through research but rather reflects the basic engineering reality, and we believe that this represents a major type of gap that should be surfaced by a conceptual framework paper.

8. Conclusions

Trustworthy intelligence from healthcare IoT sensing systems cannot be realised without the simultaneous development of quantum-resilient cryptography and forensic readiness. This paper proposes a security lifecycle framework that is quantum-resilient and forensic-aware, the first integrated architecture that coordinates the entire lifecycle of the system using AI-based edge intelligence while ensuring quantum-resistance (protection against threats) and forensic awareness (accountability and recovery from threats). For device manufacturers, the framework identifies cryptographic flexibility as the most significant unresolved challenge in designing non-replaceable implantables. For healthcare organisations, it lays out an incremental path towards PQC adoption, beginning with Phase 1 PQC at the gateway level and followed by the deployment of edge gateways to support forensic logging. For regulatory bodies, it exposes a critical gap in current standards: no existing guideline addresses how to preserve the integrity of forensic evidence in post-quantum healthcare environments. Implementing such a standard before systems are widely deployed is the best opportunity for shaping practice with low implementation costs; before systems are deployed at scale, they would be exposed to much higher risk.

Although this framework is intended to provide an overall structure that can guide practitioners working in this space, it is also apparent that there are significant limitations. The framework has not been tested or verified in terms of real-world performance using physical hardware; the framework cannot address the fundamental privacy-utility trade-off that exists in federated forensics; and finally, the framework provides no solution for patients who currently possess implantable medical devices that were designed with inadequate cryptography. Therefore, future research should focus primarily on validating the use of this framework using real-world physical hardware as well as developing privacy preserving federated forensic protocols suitable for resource-constrained healthcare IoT environments.