The analyser on your network: assuring connected point-of-care devices

The request usually arrives late. A new analyser has been chosen, the evaluation is done, operators are booked for training, and then someone from the trust's IT security team asks what nobody on the project had thought to ask: what exactly are we plugging into the network? What operating system does it run, who patches it, what does it talk to, and how does it prove it is who it says it is? The answers are often not in the tender response at all.

I have been on both sides of that conversation. Recently I read a communications manual for a connected analyser, the document a supplier gives an integrator so results can flow into a record system. It contained a single encryption key, printed in the manual and identical on every unit. Its worked checksum examples did not compute. Fields shifted position between one example message and the next, and decimal commas sat alongside decimal points. None of it was hidden; nobody had been asked to check it. Separately, and as a far better sign of where the NHS is heading, a trust I worked with would not allow phone-based device gateways onto its estate until it had seen Data Security and Protection Toolkit and Digital Technology Assessment Criteria evidence. That is the right instinct, and it should be routine.

This piece is for POCT leads and procurement teams, not security specialists, and it is defensive throughout: what to ask a supplier and what to check before go-live. A connected point-of-care analyser is a networked computer with a clinical job, and it should be bought, accepted and governed with the same evidence we would demand of any other clinical system.

Why a point-of-care analyser is now a network citizen

For most of the history of point-of-care testing the analyser was an island. It printed a slip, the slip went into the notes, and the worst a fault could do was print a wrong number. Now results travel from the device to a gateway or data manager and on into the laboratory or patient record, where they can be seen, audited and acted on. These are real quality gains. They also turn each analyser into a computer on a clinical network, with an operating system, a software stack, credentials and a communications protocol, each with a life cycle of its own.

Diagnostic equipment and general IT age at very different speeds. An analyser may stay in service for many years, while the operating system and libraries inside it fall out of support well before the device is retired. Who validates and deploys a patch has to be agreed with the manufacturer, following its instructions and local clinical change control, so a trust often cannot simply patch it. The National Audit Office's investigation into WannaCry described exactly this: equipment such as MRI scanners with Windows XP embedded was "generally managed by the system vendors and local trusts are not capable of applying updates themselves", and vendor support was "often poor" according to NHS England and NHS Digital. About 5% of the NHS IT estate, including medical equipment, was still on Windows XP on the day of the attack^[1].

Unit 42, the threat research arm of Palo Alto Networks, analysed 1.2 million connected devices in US enterprise and healthcare organisations in 2018 and 2019. It reported that 83% of medical imaging devices ran unsupported operating systems, that 72% of healthcare VLANs mixed connected devices with ordinary IT assets, and that 98% of connected-device traffic was unencrypted^[7]. These are vendor telemetry figures from a US sample, and imaging is not point-of-care testing, so I use them as an order of magnitude, not a measurement of any NHS estate. The mechanism transfers directly: long-lived devices, short-lived software and flat networks.

What WannaCry and the 2024 pathology attack taught diagnostic services

The NAO called WannaCry, in May 2017, relatively unsophisticated, and every organisation it infected shared the same weakness: unpatched or unsupported Windows. At least 80 of 236 trusts in England were affected. Thirty-four were infected and locked out of devices, 25 of them acute trusts, and 46 more were not infected but reported disruption, often because they shut systems down on their own initiative. Five acute trusts diverted emergency ambulances, and NHS England estimated that more than 19,000 appointments would have been cancelled^[1].

The detail that matters most for diagnostics is that infected trusts had medical equipment "locked, or isolated from trusts' IT systems to prevent them being locked", which disrupted radiology and pathology because they relied on that equipment "for diagnostic imaging (such as MRI scanners) and for testing blood and tissue samples". By 19 May NHS England had identified 1,220 infected pieces of diagnostic equipment, 1% of all such NHS equipment, and the NAO noted the figure excluded devices disconnected to prevent infection^[1]. A small share of devices produced a disproportionate clinical effect, and isolation was itself a cost.

The ransomware attack on the IT of the pathology services provider Synnovis, beginning on 3 June 2024, showed the same dependency from the other side. It was not an attack on point-of-care devices. It showed how completely modern care depends on diagnostic results flowing through software. In the first week, NHS England reported blood test services at approximately 10% of normal capacity, with 814 elective procedures and 736 hospital outpatient appointments postponed at the two most affected trusts^[2]. Capacity recovered slowly through mutual aid: around 30% in the second week, 45% in the third, a plateau of about 54% for three weeks, then 60% and 67% by late July^[3].

Because the hospitals could not match patients' blood at their usual frequency, they relied more heavily on group O blood under emergency arrangements. On 10 June NHS Blood and Transplant asked O negative and O positive donors to book urgently, noting that 8% of the population is O negative but that it makes up around 15% of hospital orders^[4]. NHS England later recorded that this contributed to a national shortage of O-type blood, and that 10,152 acute outpatient appointments and 1,710 elective procedures were postponed at the two trusts^[5].

A diagnostic service is now only as available as the software it depends on. A connected analyser either adds to that resilience or becomes one more door into it.

Point-of-care capacity can add resilience when central IT fails, which argues for devices that keep testing and recording safely offline. Every connected device also widens the estate that must be defended. Neither argues against connectivity; both argue for buying it with eyes open.

The rules that apply, and who each one binds

The most useful thing a POCT lead can know is which obligations sit with the manufacturer and which with the deploying organisation. MDCG 2019-16 treats cybersecurity as a responsibility shared between manufacturers and the organisations that integrate and operate devices, preferring the term joint responsibility, and states that when a healthcare organisation mandates an integrator to connect a device to its network, information security obligations for that integration remain with the healthcare organisation^[10]. The deploying service cannot outsource its share.

On the manufacturer side, EU MDR Annex I section 17.2, and its IVDR equivalent 16.2, require software to be developed according to the state of the art, taking into account the development life cycle and risk management "including information security". Section 17.4 (16.4 in the IVDR) requires manufacturers to set out minimum requirements for hardware, IT network characteristics and IT security measures, "including protection against unauthorised access"^[10]. Ask every supplier for that minimum-requirements statement. Great Britain accepts UKCA-marked IVDs under the UK MDR 2002 and CE-marked IVDs under either the older directive or the IVDR until 30 June 2030 at the latest^[25], so identify the device's conformity route before treating a missing statement as an IVDR nonconformity. Either way, its absence is a procurement finding.

Great Britain is in transition. The MHRA's Software and AI as a Medical Device Change Programme says existing regulations "do not currently consider the evolving state of the art" for cyber security risk, describes a shared responsibility between manufacturer, systems manufacturers and local deploying organisation, and commits to secondary legislation and clearer vulnerability reporting^[6]. Note what does not apply. The UK consumer connectable product regime, in force since 29 April 2024, bans universal default passwords and requires a vulnerability reporting contact and a stated security update period^[8], but products covered by the Medical Devices Regulations 2002 are excepted^[9]. A smart doorbell sold in the UK may not ship with a shared default password; a medical device is not caught by that rule. Buyers have to ask for that protection themselves.

In the United States, section 524B of the Federal Food, Drug, and Cosmetic Act has applied to premarket submissions for "cyber devices" since 29 March 2023. Manufacturers must submit a plan to monitor and address postmarket vulnerabilities, including coordinated disclosure; maintain processes that give reasonable assurance the device is cybersecure, with updates and patches made available; and provide a software bill of materials covering commercial, open-source and off-the-shelf components^[11]. For devices also sold in the US, these documents may already exist.

IEC 81001-5-1:2021 defines the life cycle requirements for developing and maintaining health software needed to support conformance to IEC 62443-4-1^[12]. It is the most direct answer to "how do you build securely". IEC 80001-1:2021 is addressed to the healthcare organisation, setting requirements for risk management before, during and after connecting a health IT system to a health IT infrastructure^[13]. The 62443 series, written for industrial control systems, supplies the underlying vocabulary^[14].

In England, DCB0129 requires manufacturers of health IT to run clinical risk management with a hazard log, a clinical safety case report and a clinical safety officer^[15]; DCB0160 places the equivalent duty on the deploying organisation under section 250 of the Health and Social Care Act 2012^[16]. All organisations with access to NHS patient data and systems must complete the DSPT assessment that applies to them: NHS trusts, ICBs and several other bodies now use a version aligned to the NCSC Cyber Assessment Framework, while IT suppliers continue with the non-CAF assessment^[17]. DTAC covers clinical safety, data protection, technical security, interoperability, and usability and accessibility; a refreshed form in March 2026 cut the questions by a quarter and removed duplication with the DSPT^[18]. Whether DTAC formally applies to an analyser's software depends on classification; settle that early.

Software bills of materials and end-of-support dates

A software bill of materials is "a formal record containing the details and supply chain relationships of various components used in building software". The US NTIA's minimum elements are supplier name, component name, version, other unique identifiers, dependency relationships, the author of the SBOM data and a timestamp^[19]. When a serious weakness is announced in a widely used component, every trust's first question is whether it is affected. Without an SBOM the answer means emailing every supplier and waiting; with one, your security team can search the list the same day. You need to know it exists, is updated with each release, and reaches the people who monitor vulnerabilities.

The partner question is the end-of-support date: the date until which the manufacturer will provide security updates for the device software and its platform, and the window between a fix existing and it reaching your units. Compare that date with the service life you are planning for. If the operating system inside the device leaves support halfway through your contract, you are buying the WannaCry problem in instalments. That need not disqualify a device, but it should be priced, recorded in the hazard log and mitigated, most obviously by segmentation.

Segmentation as a design principle, not an afterthought

The most effective control a deploying organisation owns is where the device sits on the network and what it may talk to. The NCSC's secure connectivity principles for operational technology put it simply: by dividing the network into smaller, functionally isolated segments, organisations can contain threats within the zone where they originate^[20]. The NAO made the same point in 2017: trusts running Windows XP on medical equipment could have protected themselves by isolating those devices, though this might require manual workarounds^[1].

Analysers live in a dedicated segment and talk to one thing, the gateway or data manager, on the ports and protocols the supplier documents. The gateway talks onward to the laboratory or record system. Nothing on the staff network, and nothing from the internet, reaches the analysers directly. Remote support uses a logged route your organisation switches on. A device that needs broad network access or an always-on inbound connection was not designed to be segmented. That is a procurement finding for the evaluation, not a go-live escalation.

The interface specification is evidence of engineering quality

Nobody reads the communications specification except the integrator, yet it is one of the few pieces of direct evidence a buyer can obtain about how carefully the device's software was engineered. A specification produced by a disciplined team tends to be internally consistent, because it is generated from, or tested against, the real implementation. One full of contradictions does not prove the code is defective, but it is a reason to investigate and to test the implementation harder.

Point-of-care connectivity has had consensus standards for a long time: CLSI POCT01, in its second edition since 2006, provides the basis for multivendor interoperability between devices, data managers and results systems^[21], and CLSI LIS01 describes the low-level protocol between laboratory instruments and computer systems over serial links and TCP/IP^[22]. Conformance to a standard helps. It is not the same as a specification that is correct. These are the generic red flags I would ask any reviewer to look for.

Worked examples that do not compute

Framed instrument protocols commonly carry a checksum, a short value calculated from the bytes of each frame, which the receiver recalculates to detect corruption. If your integrator recomputes a worked example and gets a different answer, either the example was typed by hand rather than produced by the device, or the algorithm description is wrong. A likely failure is a receiving system rejecting frames it believes are corrupt. Rejected frames delay delivery, and become lost results if retry, recovery and escalation fail.

Fields that move and decimals that change shape

Message formats depend on fields appearing in fixed positions. If the examples place the result in one position in one message and another in the next, an interface built from the document will sometimes read the wrong field. Decimal conventions are worse, because the error is quiet. Consider a potassium result sent as "4,5" by a device set for a decimal comma and received by a system expecting a decimal point. Depending on the parser, it may be rejected, truncated to 4, or read as 45 mmol/L, a tenfold error. A specification that mixes "4,5" and "4.5" in its own examples, or never states the units and decimal convention for each field, leaves a clinical safety hazard for the integrator to find.

Shared static secrets

The most serious red flag is a credential or key identical on every unit, and worse, printed in a document. A secret shared by every device protects none of them once known, and a manual is not a secret. Ostermann and colleagues, comparing EU and US premarket guidance against the weaknesses most often found in medical devices, identified hard-coded credentials as one of the most common and noted that the EU guidance addresses them only implicitly^[23]. The consumer rule is a useful benchmark even though it does not bind medical devices: unique credentials per device or set by the owner, never a universal default^[8]. Ask how keys are provisioned per unit, rotated and revoked when a device is retired.

The communications manual is the one piece of the device's software engineering a buyer can read. If it is careless, test the implementation harder before you trust it.

None of these flags proves a device unsafe in use today. They mean the evidence that it is safe has not been produced, and the burden of producing it will fall on your integrator, IT team and clinical safety officer after contract signature, when you have least influence. Raise them in writing during evaluation and ask for a corrected specification.

A worked hazard assessment in the DCB0160 style

The DCB0160 implementation guidance gives an example five-by-five clinical risk matrix. Severity runs from minor to catastrophic and likelihood from very low to very high, and the two are combined by looking up a cell, not by multiplying, to give a clinical risk from 1 to 5. In the guidance's example acceptability table, 1 is acceptable, 2 is acceptable where further reduction is impractical or disproportionate, 3 is undesirable, and 4 and 5 are unacceptable^[16]. Each organisation sets its own criteria, so treat the example as illustrative.

The numbers are judgements; the value is the discipline of giving each hazard a cause, a control and an owner, and seeing which ones procurement is best placed to remove. The manufacturer's DCB0129 safety case should already contain most of them.

What a service should ask and check before go-live

Put these questions in writing during evaluation and attach the answers to the hazard log. Score each 0 (no answer or evidence), 1 (partial) or 2 (complete with evidence). The pattern matters more than the total: a device can score well overall and still fail a question that matters, such as number 4.

1. Software bill of materials. Will you provide a current, machine-readable SBOM for the device and any gateway software, updated with each release?
2. Patch window. When a security fix exists for a component, how long until it is validated and deployable to our units, and who deploys it?
3. End-of-support date. Until what date will you provide security updates for the device software and its platform?
4. Credentials per device. Are all credentials and keys unique to each unit or set by us? Is any secret shared across devices or published in documentation?
5. Encryption in transit. Are results and configuration encrypted between device, gateway and record system, and how are keys and certificates managed?
6. Segmentation-friendly design. Which ports, protocols and destinations does the device need, and will it work in an isolated segment that reaches only the gateway?
7. Remote access. Can remote support be enabled only when needed, and is every session logged?
8. Logging. What security and audit events are recorded, can we export them to our monitoring, and for how long are they kept?
9. Vulnerability disclosure. Do you publish a disclosure policy and reporting contact, and how will you notify us of vulnerabilities affecting our devices?
10. Minimum IT requirements. Provide your documented minimum hardware, network and IT security requirements for the operating environment.
11. Interface specification quality. Are the worked examples generated by the device, and are units and decimal conventions stated for every numeric field?
12. Clinical safety case. Provide your DCB0129 clinical safety case report, hazard log and the name of your clinical safety officer.
13. DTAC and DSPT evidence. Provide a completed DTAC on the current form where it applies, and current DSPT status for any service touching NHS data.
14. Secure development. Which secure life cycle do you follow, for example IEC 81001-5-1, and what independent testing has the current release had?
15. Offline behaviour. If the network is down, can the device keep testing, hold results securely and send them later, as its instructions for use describe?

On the deploying side the matching actions are short. Open a DCB0160 hazard log for the connection before go-live. Agree where the device will sit and what it may reach, and test that it works there before training starts. Document interface verification against written acceptance criteria before introduction and after relevant changes, covering patient identity, units and decimals, flags, corrected results and downtime recovery; ISO 15189:2022 now carries the POCT requirements formerly in ISO 22870, in its Annex A^[24]. Reconcile results individually, not just by daily totals, for the first weeks. Put the end-of-support date in your asset register with a review well before it arrives. And make sure the people who monitor vulnerabilities in your organisation know the device exists.

When I first connected point-of-care devices, everyone asked whether the result would arrive. That is still the right first question. The second, which our field has been slower to ask, is what else arrives with it, and who is responsible when something goes wrong between the analyser and the record. The services that answer it well will not be those with the most security tooling. They will be the ones that treated a communications manual, an end-of-support date and a shared password as clinical safety evidence, and asked for better before they signed.

Sources and notes

This article is a governance and procurement guide, not security engineering advice, and it deliberately contains no technical detail about attacking any device. The field observations about a communications manual and a trust's DSPT and DTAC requirement are anonymised and generalised; no device or manufacturer is identified. The Unit 42 figures come from vendor telemetry on a US sample of connected devices in 2018 and 2019 and are used to indicate scale, not to describe any UK estate. The capacity figures in Figure 2 are the approximate weekly values stated in NHS England's public updates. Figure 1 and Figure 2 plot published numbers; Figure 3 is a schematic; Figure 4 uses the example matrix from the DCB0160 implementation guidance with hypothetical hazards and scores. Regulatory positions, particularly in Great Britain, are changing, so confirm current requirements with the MHRA and your organisation's clinical safety and information governance teams.

1. National Audit Office. Investigation: WannaCry cyber attack and the NHS. NAO, 2017 (at least 80 of 236 trusts affected, 34 infected and locked out; 1,220 infected diagnostic devices, 1% of such equipment; about 5% of the NHS IT estate on Windows XP; 6,912 cancelled appointments identified, over 19,000 estimated).
2. NHS England (London). Update on cyber incident: clinical impact in south east London, 14 June 2024. NHS England, 2024 (week 3 to 9 June: blood tests at approximately 10% of normal capacity; 814 elective procedures and 736 hospital outpatient appointments postponed).
3. NHS England (London). Weekly updates on the cyber incident clinical impact in south east London, 20 June, 27 June, 4 July, 11 July, 19 July, 25 July and 1 August 2024. NHS England, 2024 (approximately 30%, 45%, then about 54% for three weeks, 60% and 67% of normal capacity).
4. NHS Blood and Transplant. O Positive and O Negative donors asked to urgently book appointments to give blood following London hospitals IT incident. NHSBT, 10 June 2024 (8% of the population is O negative; around 15% of hospital orders).
5. NHS England (London). Latest media statement on Synnovis cyber-attack. NHS England, 2024 (10,152 acute outpatient appointments and 1,710 elective procedures postponed; contribution to a national shortage of O-type blood).
6. Medicines and Healthcare products Regulatory Agency. Software and AI as a Medical Device Change Programme roadmap. GOV.UK (work package 5, Cyber Secure Medical Devices).
7. Unit 42, Palo Alto Networks. 2020 Unit 42 IoT Threat Report. 2020 (1.2 million devices; 83% of imaging devices on unsupported operating systems; 72% of healthcare VLANs mixing IoT and IT; 98% of IoT traffic unencrypted).
8. Department for Science, Innovation and Technology. The UK Product Security and Telecommunications Infrastructure (PSTI) product security regime. GOV.UK, 2024 (in force 29 April 2024; no universal default passwords; vulnerability reporting; update period).
9. UK Government. The Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023, Schedule 3. legislation.gov.uk (products to which the Medical Devices Regulations 2002 apply are excepted).
10. Medical Device Coordination Group. MDCG 2019-16 Rev.1, Guidance on cybersecurity for medical devices. European Commission, December 2019, revised July 2020 (MDR Annex I 17.2 and 17.4; IVDR Annex I 16.2 and 16.4; joint responsibility).
11. US Food and Drug Administration. Cybersecurity in medical devices: frequently asked questions. FDA (section 524B requirements including SBOM; applies to submissions from 29 March 2023).
12. International Electrotechnical Commission. IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, activities in the product life cycle. IEC, 2021.
13. International Electrotechnical Commission. IEC 80001-1:2021, Application of risk management for IT-networks incorporating medical devices, Part 1. IEC, 2021.
14. International Society of Automation. ISA/IEC 62443 series of standards. ISA (parts 4-1 secure product development life cycle and 4-2 component requirements).
15. NHS England Digital. DCB0129: Clinical risk management, its application in the manufacture of health IT systems.
16. NHS England Digital. DCB0160: Clinical risk management, its application in the deployment and use of health IT systems, and its implementation guidance v4.2, 2018 (Table 9 example clinical risk matrix; Table 10 example acceptability definitions).
17. NHS England. Data Security and Protection Toolkit, and CAF-aligned DSPT guidance (all organisations with access to NHS patient data and systems; NHS trusts, ICBs, CSUs, arm's length bodies and others use the CAF-aligned version; IT suppliers use the non-CAF assessment in 2025/26).
18. NHS Innovation Service. Updated NHS England Digital Technology Assessment Criteria (DTAC) form and guidance. March 2026 (25% fewer questions; de-duplicated with the DSPT and pre-acquisition questionnaire).
19. National Telecommunications and Information Administration. The minimum elements for a software bill of materials (SBOM). NTIA, July 2021.
20. National Cyber Security Centre. Secure connectivity principles for operational technology, principle 6: limit the impact of compromise. NCSC, 2026.
21. Clinical and Laboratory Standards Institute. POCT01, Point-of-care connectivity. CLSI, 2nd edition, 2006.
22. Clinical and Laboratory Standards Institute. LIS01, Standard specification for low-level protocol to transfer messages between clinical laboratory instruments and computer systems. CLSI, 2nd edition, 2008.
23. Ostermann M, Mathias R, Jahed F, Parker MB, Hudson FD, Harding WC, Gilbert S, Freyer O. Cybersecurity requirements for medical devices in the EU and US: a comparison and gap analysis of the MDCG 2019-16 and FDA premarket cybersecurity guidance. Computational and Structural Biotechnology Journal, 2025 (hard-coded credentials among the most common weaknesses in medical devices; covered only implicitly by MDCG 2019-16).
24. UKAS. Point of care testing (POCT) accreditation (ISO 15189:2022, published December 2022, incorporates POCT requirements; POCT requirements in Annex A, formerly ISO 22870).
25. Medicines and Healthcare products Regulatory Agency. Regulating medical devices in the UK. GOV.UK (UKCA self-certification for general IVDs; IVDD-compliant IVDs accepted until the sooner of certificate expiry or 30 June 2030; IVDR-compliant IVDs until 30 June 2030).