SearchSubscribe

P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

Market and Supply Chain

Forescout's 6% for medical devices is an OpenSSH version test, not proof they cannot be upgraded

Forescout's 6 October healthcare report says 6% of medical devices run OpenSSH versions with post-quantum key exchange, against 50% of IT. The figure dates from April 2026, counts a version number, and the 5,500 exposed systems came from Shodan, not the 2.5 million devices.

By Parminder Kumar Sharma · · 15 min read

A dark hospital corridor at night with, on the right, a wheeled patient monitor with a blank screen, a drip stand carrying a fluid bag and an infusion pump, and in front of them an open laptop on a trolley whose screen shows a device list of eight blank rounded rows, one outlined in amber, to suggest a device inventory with nothing filled in.

The gap is 8.3 times, and in August 2025 it was 21

Forescout's report of 6 October 2026, "PQC in Healthcare: From Data Risk to Migration Readiness", says that 6% of medical (IoMT) devices use OpenSSH versions that support post-quantum cryptography (PQC), against 50% of IT devices. That is a gap of 8.3 times (50 divided by 6). The figures are not new. A Forescout post of 24 June 2026 carries them, for data to April 2026, and its post of 30 September 2025 gave 2% for IoMT and 42% for IT, a gap of 21 times. In about eight months the IoMT share tripled and the gap more than halved. Both ratios are ours.

What that does not establish. It does not show that 94% of medical devices cannot be upgraded: the measure is one software package's version number at one date. It does not show that the 6% was counted on the 2.5 million healthcare devices the report describes, or say what it is a share of. It does not show that any patient data has been recorded; harvest now, decrypt later is a risk model, and the report says quantum attacks are not what is happening now. It dates no quantum computer. Infosecurity Magazine's report of the same day opens with "Most medical devices cannot be upgraded to post-quantum cryptography", which says more than the report does.

Which number is which

The report joins three data sources and two protocols. Wording in quotation marks is Forescout's own, from the report page and its PDF, which carry the same text.

What Forescout's report of 6 October 2026 states about each figure, and what it leaves out. Read 6 October 2026.

  1. Figure
    2.5 million devices, 50+ organisations
    Stated
    "a Forescout Device Cloud dataset containing more than 2.5 million devices across more than 50 HDO networks". Used for the device mix: IoMT 5%, about 120,000 devices.
    Not stated
    Country, selection, period, any UK site. That the SSH percentages came from this set.
  2. Figure
    6%, 16%, 28%, 50%
    Stated
    "In enterprise networks, 50% of IT devices use OpenSSH versions that support PQC", against 28% of IoT, 16% of OT and 6% of IoMT. Linked to a post of 24 June 2026.
    Not stated
    What each is a share of. How many devices run SSH. That a post-quantum exchange was ever negotiated.
  3. Figure
    Over 5,500 exposed systems
    Stated
    Found by querying Shodan: "over 5,500 instances of 50 different medical information systems". 46% EMR, 40% PACS.
    Not stated
    That they are among the 50 organisations, their country, or that any is vulnerable or recorded.
  4. Figure
    31% TLS 1.3
    Stated
    "the average percentage of TLSv1.3 deployments" across exposed system types. PACS 36%, EMR 33%.
    Not stated
    A count of post-quantum exchanges. Whether the base is all systems or only those using encryption.
  5. Figure
    Quantum timing
    Stated
    "cryptographically relevant quantum computers are not yet available"; "as early as 2029", linked to Google.
    Not stated
    An estimate of its own.

Two checks of our own. The 31% reproduces: weighting the report's per-type TLS 1.3 shares by each type's share of systems, as charted, gives about 31%, where a simple mean of the six bars is 19%. And the 5,500 are not part of the 2.5 million. Infosecurity's line, "Across the devices analyzed, the researchers identified more than 5500 internet-exposed systems", joins them. The report does not.

Forescout sells post-quantum readiness dashboards, launched on 24 June 2026, the day of the post the report links for the 6%, and recommends secure remote access gateways. That is a reason to read the figures as a vendor's measurement. It is not a reason to doubt them.

Two populations, two protocols

Panel A is a software version count on devices in enterprise networks. Panel B is a protocol version count on systems seen from the internet. Neither counts a post-quantum connection.

Two bar charts to scale. Panel A: share of devices on an OpenSSH version with post-quantum key exchange, April 2026 against August 2025: IT 50 and 42, IoT 28 and 20, OT 16 and 11, IoMT 6 and 2 per cent. Panel B: TLS 1.3 support on over 5,500 exposed medical systems found with Shodan: all 31, PACS 36, EMR 33, laboratory 13, telehealth 15, medication dispensing 0 per cent. A band says neither panel counts a post-quantum key exchange.
Drawn from Forescout's posts of 30 September 2025 and 24 June 2026 and its report of 6 October 2026. The shares of systems in panel B are as charted in the report.

The denominator matters, and the wording wobbles. The summary of the 2025 post says "IT assets using OpenSSH", which would leave out devices with no SSH and devices on another stack, such as Dropbear. Its body, the June 2026 post and the report say "devices". The report gives no device count under either reading. For scale only: 6% of its roughly 120,000 IoMT devices would be 7,200, if the figure applied to that sample, which is not stated.

A version number is not a device property

The friendly name here is "PQC-ready", or its mirror, "cannot support PQC". Both read as a property of a device. Forescout's test is a property of one library version, on one protocol, on one date. OpenSSH 9.0, released on 8 April 2022, made a hybrid post-quantum exchange its default: its notes say to "use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default". The ML-KEM hybrid was added in 9.9 on 19 September 2024 and became the default in 10.0 on 9 April 2025. Forescout counts 9.x and 10.x as capable and 7.0 to 8.9 as legacy. Version 9.0 is 1,642 days old, so firmware built on an older OpenSSH sits outside the 6% unless the maker changed the exchange another way. That last step is our inference. The notes we read cover key exchange and mention no post-quantum signatures.

The same device can move: the IoMT share went from 2% to 6% in about eight months because suppliers shipped releases. It can also never move, and the sources differ in weight. Forescout lists "regulated medical devices" among systems where changes "depend on vendor release cycles, recertification, or even hardware replacement". MITRE's April 2026 paper says post-quantum algorithms "may require more memory, more code, and longer messages", and that an implant needing physical access to reprogram would need a medical procedure. The FDA's February 2026 premarket guidance lists "Secure and timely updatability and patchability" as a security objective for premarket submissions. None says a given device on a UK ward cannot be updated. That depends on the manufacturer's roadmap, which the report does not collect. It measures capability, not intent.

Judgement. Whether a change by anyone but the manufacturer voids a device's certification is a question for the manufacturer and its conformity assessment body. We found no primary source that says a certified device cannot be changed, and we do not say it.

What harvest now, decrypt later threatens, and what it does not

Harvest now, decrypt later threatens recorded confidentiality: data that must stay secret for decades. The report ranks the data most at risk as EHR and EMR records, imaging, laboratory results, medication and prescription data, and financial data. It also excludes "the medical device telemetry", which it describes as short-lived, and unencrypted legacy traffic such as HL7v2, which it calls "already a confidentiality and integrity risk today". Its table lists smart infusion pumps among devices touching medication data, but the route it describes is electronic prescribing between providers and pharmacies, not a pump's own link.

Our reading. An infusion pump's control traffic loses its secrecy value within the hour. What matters for it is that commands cannot be forged, which needs a quantum computer at the time of the attack, not retrospectively. The NCSC makes the matching point for industrial devices: "the confidentiality of their data might not require strong cryptographic protection, the integrity of the data is likely to be critical".

The 31% is also a version test. TLS 1.3 is, in Forescout's words, "the only TLS version capable of supporting standardized post-quantum cryptography". It is necessary, not sufficient: the server also needs a library and configuration that offer the hybrid exchange, and the report does not measure that for the 5,500. For enterprise networks the June post found devices offering post-quantum key exchange on TLS in 8% of IT devices, 5.6% of IoT and IoMT, and 0.8% of OT. That is a different population, but it is the nearest figure given.

Exposed is not harvested. Systems visible to Shodan show reach, not recording. The report cites no observed interception of healthcare traffic, and says the near-term concern is "not that quantum attacks are already happening". The risk model is sound for long-lived data. A count of exposed servers is not evidence that it has played out.

When a quantum computer might exist: who says what

What each source read says about when a quantum computer could break current public-key cryptography. Read 6 October 2026.

  1. Source and date
    NCSC timelines page, 20 Mar 2025
    What it says
    Migration targets of 2028, 2031 and 2035. The threat is from "future large-scale, fault-tolerant quantum computers".
    What it does not say
    A date for such a computer.
  2. Source and date
    Google blog, 25 Mar 2026
    What it says
    "We're setting a timeline for post-quantum cryptography migration to 2029": Google's own migration.
    What it does not say
    That a machine able to break current key exchange will exist in 2029.
  3. Source and date
    Forescout report, 6 Oct 2026
    What it says
    Such computers "are not yet available". One could break asymmetric encryption "as early as 2029", linking to the Google page.
    What it does not say
    An estimate of its own.
  4. Source and date
    Infosecurity, 6 Oct 2026
    What it says
    Quantum computers are "predicted to be capable of breaking existing encryption methods in the next five years".
    What it does not say
    A primary source. It links an earlier article saying Google "has warned" of 2029.

Google's May 2025 security blog estimated that 2048-bit RSA could be broken by "1 million noisy qubits running for one week", while machines with relevant error rates then had "on the order of only 100 to 1000" qubits. MITRE's April 2026 paper gives no date either. Each step in the chain from Google's target to "the next five years" is looser than the one before, on our reading, and none is a measurement of a machine.

The UK: what the NCSC, NHS England and the regulators say

The report is American in its frame: HIPAA, the US breach portal, and 65% of its ransomware claims against US organisations. It does not say whether any of the 50 networks is in the UK. This briefing keeps to key exchange and devices. Authentication is the other half, set out in an earlier briefing on Cloudflare's post-quantum CA, where the NCSC says a system "will not provide quantum-secure authentication until migration of your PKI is complete". A version test on SSH key exchange says nothing about that.

What UK and US guidance read says about legacy devices and post-quantum cryptography. Read 6 October 2026.

  1. Source and date read
    NCSC, PQC migration timelines (v1.0, 20 Mar 2025)
    What it says
    By 2028: "Carry out a full discovery exercise". By 2031: "early, highest-priority PQC migration activities". By 2035: "Complete migration to PQC of all your systems, services and products". Capture "version information and patch levels". Options include "Tolerate the risk". Of legacy systems that cannot move: "Your strategy will need to account for this."
    What it does not say
    Anything specific to medical devices.
  2. Source and date read
    NHS England Digital, connected medical devices (last edited 17 Oct 2025)
    What it says
    Covers devices "with inadequate support", "sometimes described as 'legacy'". Cites documents reviewed from 2016 to 2020.
    What it does not say
    Any mention of quantum. We searched; none.
  3. Source and date read
    NHS England Digital, DCB 0129 and DCB 0160 applicability (last edited 27 May 2022)
    What it says
    These clinical risk standards "do not apply in the context of software which is incorporated into a physical 'Medical device'".
    What it does not say
    Whether either reaches a device's embedded SSH or TLS software.
  4. Source and date read
    MHRA, Software and AI as a Medical Device roadmap (updated 14 Jun 2023)
    What it says
    Says the MHRA "intend to develop secondary legislation" on cybersecurity and "will produce best practice guidance" on unsupported devices.
    What it does not say
    Finished guidance, or any post-quantum text. None found on gov.uk.
  5. Source and date read
    FDA, premarket cybersecurity guidance (3 Feb 2026, US)
    What it says
    Lists "Secure and timely updatability and patchability" as a security objective.
    What it does not say
    Any mention of quantum. Not UK guidance.

Read together: the NCSC gives dated milestones and tells UK organisations to plan for legacy systems. The NHS England and MHRA material that governs devices on a ward does not yet mention post-quantum cryptography, and the clinical risk standards do not reach embedded software. On our reading that is a gap in the guidance, not a failing of any trust. The dates against the calendar:

A vertical timeline from 2022 to 2035, to scale. OpenSSH 9.0 made a hybrid post-quantum exchange the default on 8 April 2022, 9.9 offered ML-KEM on 19 September 2024, and 10.0 made it the default on 9 April 2025. Forescout's IoMT figure was 2 per cent in August 2025 data and 6 per cent in April 2026 data. Bands mark the NCSC years 2028, 2031 and 2035, and Google's own 2029 target, which is not a forecast.
Drawn from the OpenSSH release notes, the NCSC timelines page, Google's blog of 25 March 2026 and Forescout's posts. Day counts are derived.

From 6 October 2026 the NCSC's 2028, 2031 and 2035 are 2, 5 and 9 calendar years away, or 817, 1,912 and 3,373 days to 31 December of each. Both are our counts, and the NCSC says "by".

A checklist for UK providers, in the order worth doing

This is our judgement, built from the NCSC's milestones and Forescout's recommendations. Items marked NCSC or Forescout rest on them; the ordering and the rest are ours. It is defender level: inventory, contract and design choices.

Take this with you

In the order worth doing

  • Inventory the protocol and the library, not just the device: SSH and TLS versions offered, the library and version behind them, firmware, supplier, end-of-support date, and who may change it. The NCSC asks for version information and patch levels; the other columns are ours. (NCSC, our columns.)
  • Find plaintext first. Forescout notes that unencrypted legacy protocols such as HL7v2 are already a risk today. That is a present problem with a present fix, so it comes before post-quantum work. (Forescout; the ordering is our judgement.)
  • Classify flows by how long the data must stay secret and whether it crosses a boundary: partner links, remote access, cloud, teleradiology, electronic prescribing. The NCSC asks you to record data lifetime. (NCSC, Forescout.)
  • Ask each supplier in writing for the library and version in each device, whether a release with post-quantum key exchange exists, a dated roadmap, whether the change needs recertification, and the end-of-support date. (NCSC, Forescout.)
  • Put it in tenders and renewals: disclosure of cryptographic libraries and versions, a stated upgrade path to post-quantum key exchange, update commitments for the service life, and notice before end of support. Forescout suggests procurement requirements; the clauses are our judgement.
  • Ring-fence what cannot change: segment it, allow remote SSH management only through a controlled jump point, and log what crosses the boundary. Forescout recommends isolating; the specifics are our judgement.
  • Protect data in transit at the boundary: a gateway or VPN concentrator that terminates post-quantum-capable TLS or VPN in front of legacy segments. This is common architecture advice, and Forescout recommends it, but it is a judgement with limits. It protects the outer leg only, the gateway-to-device leg stays classical, the gateway sees plaintext and becomes a high-value target, and the far end must support the exchange. Forescout also sells secure remote access.
  • Decide per class between update, replace, run to end of life, or accept the risk, and date each decision against 2031 and 2035. The NCSC lists these options. (NCSC.)
  • Record each decision with an owner and a date, including accepted risk, and re-measure quarterly. Forescout suggests tracking the share of assets that are post-quantum-capable. (Forescout; the cadence is our judgement.)

What we could not verify

The question this leaves

Forescout's 6% is a measurement of other organisations' networks, and a vendor can count versions only where its sensors sit. Only the organisation that owns the wards knows which device carries which data to whom. For each type of device on your wards, can you say today which SSH and TLS library sits inside it, who is allowed to change it, and by what date you will have chosen between updating, ring-fencing and replacing it?

Key facts

Sources

  1. PrimaryReport page and PDF, 'PQC in Healthcare: From Data Risk to Migration Readiness', stamped 6 October 2026, read in full with curl: the 6%, 16%, 28% and 50% figures, the 2.5 million device sample, the Shodan search for over 5,500 exposed systems, the 31% TLS 1.3 figure, the data-at-risk ranking and the recommendationsForescout Research (Vedere Labs)accessed 2026-10-06
  2. PrimaryBlog of 24 June 2026, data to April 2026, linked from the report: where the OpenSSH percentages first appear, the 9.x and 10.x versus 7.0 to 8.9 split, the post-quantum TLS figures, the product launchForescout Research (Vedere Labs)accessed 2026-10-06
  3. PrimaryBlog of 30 September 2025, data to end of August 2025: the earlier 42%, 20%, 11% and 2% figures and the wording of their baseForescout Research (Vedere Labs)accessed 2026-10-06
  4. PrimaryRelease notes for 9.0 of 8 April 2022: hybrid sntrup761x25519-sha512 key exchange by defaultOpenSSHaccessed 2026-10-06
  5. PrimaryRelease notes for 9.9 of 19 September 2024: ML-KEM hybrid key exchange addedOpenSSHaccessed 2026-10-06
  6. PrimaryRelease notes for 10.0 of 9 April 2025: mlkem768x25519-sha256 used by default for key agreementOpenSSHaccessed 2026-10-06
  7. PrimaryTimelines for migration to post-quantum cryptography, version 1.0 published 20 March 2025: the 2028, 2031 and 2035 milestones, discovery and legacy system textNational Cyber Security Centreaccessed 2026-10-06
  8. PrimaryGuidance for procuring and deploying connected medical devices, last edited 17 October 2025: legacy devices, documents reviewed, no mention of quantumNHS England Digitalaccessed 2026-10-06
  9. PrimaryApplicability of DCB 0129 and DCB 0160, background page last edited 27 May 2022: the standards do not apply to software incorporated into a physical medical deviceNHS England Digitalaccessed 2026-10-06
  10. PrimarySoftware and AI as a Medical Device Change Programme roadmap, updated 14 June 2023: work package 5 on cyber secure medical devices and unsupported devicesMHRAaccessed 2026-10-06
  11. PrimaryCybersecurity in Medical Devices premarket guidance issued 3 February 2026, read as PDF: security objectives including updatability and patchability; no mention of quantumUS Food and Drug Administrationaccessed 2026-10-06
  12. PrimaryDiscussion paper of April 2026 with a post-quantum section for medical devices, read in a browser tab after curl was refused: memory and message costs, legacy interoperability, implants needing a procedureMITREaccessed 2026-10-06
  13. PrimaryFIPS 203 (ML-KEM) page: published 13 August 2024, planning note of 17 November 2025NISTaccessed 2026-10-06
  14. PrimaryBlog of 25 March 2026 setting Google's own post-quantum migration timeline to 2029, linked from the Forescout reportGoogleaccessed 2026-10-06
  15. PrimaryPost of 23 May 2025 on the resources needed to factor 2048-bit RSA: 1 million noisy qubits for one week against 100 to 1000 qubits in machines with relevant error ratesGoogle Security Blogaccessed 2026-10-06
  16. Reported byNews report of 6 October 2026, used as the pointer to the Forescout report and for the wording this briefing testsInfosecurity Magazineaccessed 2026-10-06
  17. Reported byEarlier news article linked for the five-year claim: Google 'has warned' of 2029Infosecurity Magazineaccessed 2026-10-06

Share this briefing

Know someone who owns this problem? Send it to them.

LinkedInXWhatsAppEmail

Related briefings

The briefing, in your inbox

Practitioner analysis of cyber and AI security news. No vendor noise.

How often

Every new briefing in one email, at 7am, or at 7am, 12:30pm and 6pm. Nothing is sent when nothing is new. Unsubscribe any time.