”Information asymmetry by architecture is built into the regulatory process when the entire evidence base used to assess cybersecurity is constructed by the party with the weakest incentive to expose the full threat surface.”
We were built for a closed world
The veterans who shaped MD and IVD regulatory thinking in the 1990s and 2000s lived in a closed ecosystem. A haematology analyser talked to a data manager. The data manager sat behind a hospital LIS. The LIS sat behind a firewall. The attack surface was close to zero.
That mental model shaped everything. ISO 14971 risk management was calibrated to clinical failure modes: a sensor drifting, a reagent degrading, a cartridge misfiring. IEC 62304 was written for bounded, versioned, waterfall-style development. Cybersecurity, when it appeared at all, was a note in the software risk file. Not a discipline. Not a methodology. A note.
Those frameworks were entirely appropriate for their time. The problem is that the ecosystem blew open, and the regulatory mindset did not move at the same speed.
Look at what that same framework now governs
A connected point-of-care coagulation analyser syncing patient results to a cloud platform via hospital WiFi. A manipulated result there does not crash a system. It corrupts a clinical decision quietly, for weeks, before anyone notices the pattern.
A middleware layer sitting between your IVD analyser and the EHR, translating HL7 messages, touching every result that leaves the instrument. Rarely classified as a medical device under IVDR. Almost never in scope for a cybersecurity review. Entirely capable of data manipulation at scale.
A continuous glucose monitor or a cardiac patch living on a patient’s body, syncing via Bluetooth to a smartphone, sitting on the same home WiFi as a smart TV and a cheap router that has not had a firmware update since 2021. Regulated as though it still lives in a hospital cabinet.
A cloud-inference diagnostic SaMD platform where the model updates silently between versions. The SBOM captures software libraries. It does not capture model weights, inference endpoints, or the API dependencies the platform calls at runtime. Nobody in the regulatory submission asked for those. Nobody on the review team knew to ask.
The structural problem nobody is writing about
A significant friction point in SaMD Quality Excellence is the reconciliation of Agile development methodologies with the structured documentation requirements of IEC 62304. Schmidt and Weyrauch (2026) argue that Agile is not inherently non-compliant; rather, it requires a shift from documentation-heavy Waterfall models to an incremental/evolutionary lifecycle where “Done” includes regulatory verification.
Effective synchronization requires that the Software Safety Classification (Class A, B, or C) be established during initial product discovery to dictate the necessary rigor of unit testing and integration verification. According to Marques et al. (2021), in an Agile environment, this means that every user story or “Epic” must be tagged with its corresponding safety impact, allowing for the automated generation of the Software Development Plan (SDP) and Software Architecture documents with each release. Advanced compliance tools now “wrap” the developer’s stack, automatically writing unit tests that provide the code coverage evidence required for high-risk Classes B and C.Here is what I think is genuinely underexplored in this space….
The regulator evaluates what the manufacturer chooses to document. The manufacturer documents what the software team tells them is the boundary. The software team draws that boundary at the limit of what they are contractually and technically comfortable disclosing.
The entire evidence base that regulators rely on to assess cybersecurity is constructed by the party with the weakest incentive to expose the full threat surface.
This is not malice. It is information asymmetry by architecture. An RA professional reviewing a Technical File has deep expertise in clinical performance, biological safety, risk management methodology. They are not a penetration tester. They did not grow up reading CVE disclosures. They cannot interrogate a threat model the way they can interrogate a clinical study. So they assess what is documented and they assess it well. The gap is in what never gets documented in the first place.
The standards are finally catching up. The audit competency has not, it is still going towards it.
IEC 81001-5-1 is now the de facto harmonised standard for health software cybersecurity, recognised by FDA, EU Notified Bodies under MDR/IVDR Annex I sections 17.2 and 17.4, and PMDA in Japan. The FDA June 2025 final guidance mandates SBOMs with lifecycle metadata, VEX files from March 2026, and a Secure Product Development Framework integrated with ISO 13485. The EU Cyber Resilience Act brings vulnerability reporting requirements in late 2026.
The paper architecture is sound. But a standard is only as effective as the competency of the person reviewing conformity against it. Right now, that review sits with auditors and RA professionals whose training is in biomedical engineering and quality systems, not in threat modelling, secure development lifecycle review, or supply chain attack vectors.
Handing IEC 81001-5-1 to an auditor who has never run a penetration test is like handing a clinical biometrics chapter to someone who has never designed a study. They will check the structure. They will not catch what the structure is hiding.
Three things that actually need to change
First, regulatory auditors need cross-credentialled cybersecurity competency. Not a one-day module on IEC 81001-5-1. Actual depth. The IMDRF principles exist. The standard exists. The people who can interrogate them in a technical file review largely do not yet exist inside notified bodies and competent authorities.
Second, SBOM verification needs an independent layer. Right now a manufacturer submits an SBOM and it is reviewed by the same body assessing their clinical data. In clinical trials, data is audited independently of the sponsor. There is no equivalent mechanism for software transparency documents. A manufacturer with something to hide has very little friction standing in their way.
Third, and this is the one that matters most for IVD specifically: diagnostic data integrity needs to be framed as a cybersecurity outcome, not a quality outcome. The harm pathway from a compromised wearable CGM or a manipulated LIS interface is not device unavailability. It is silent diagnostic error. That is a completely different risk class and the current frameworks do not treat it that way.
The closed ecosystem is gone. The regulation is still standing at the door of a building that no longer exists.
If you are in RA, quality, or clinical affairs and you have ever looked at a cybersecurity section of a technical file and thought “I’m not sure I would know if this was wrong,” you are not alone. That feeling is the gap. And it is worth talking about.
Trending Highlights
IEC 81001-5-1 | IEC 62304 | ISO 14971 | ISO 13485 | EU MDR/IVDR | FDA Section 524B | IMDRF Cybersecurity Principles | EU Cyber Resilience Act | MDCG 2019-16
#MedicalDevices #IVD #Cybersecurity #RegulatoryAffairs #DigitalHealth #SaMD #Diagnostics #MedTech #PatientSafety #Wearables
