Legacy Ultrasound Cybersecurity 2026: Patch, Segment, Isolate, or Replace?

In this guide

• The letter with two clocks
• Nine in ten cleared designs predate the law
• The catalog that doesn't contain your scanner
• The catalog that does
• What the safety record does and doesn't say
• The threat backdrop, sized honestly
• How do I even find out what this thing runs?
• Patch, segment, isolate or replace, defined precisely
• Where independent service fits, and where it stops
• Procurement clauses for the next system
• Methodology and limitations
• Frequently asked questions
• Conclusion

The letter with two clocks

Takeaway: an end-of-support notice is not one event. The Olympus EU-ME2 letter separates at least five clocks — and the OEM itself says which ones stopped and which ones didn't.

Read the Olympus notice closely, because it states on the record nearly everything this report argues ¹. The trigger was not the device wearing out: "This is necessary because the EU-ME2's underlying software components are no longer supported by their vendors." The risk posture at the moment of the letter was clean: "Olympus has not identified any vulnerabilities in these products and is not aware of any cyber-attacks targeting these products." What ends is the possibility of a future software remedy: no "software-based countermeasures to any future vulnerabilities," and any future software updates "would be for functionality rather than cybersecurity." The compensating controls the manufacturer recommends are physical and network-level — keyed USB port locks, keyed LAN port locks, tamper-evident seals. And hardware support — parts replacement — explicitly continues.

That is five separate clocks in one letter, and they expire at different times:

1. Clinical usefulness — does the system still produce the images its procedures need? (Olympus does not say the EU-ME2 stopped being clinically useful. It didn't.)
2. OEM product support — the commercial support window, which the letter partially closes.
3. Software and component support — the clock that actually triggered the letter: upstream vendors ended support for components inside the device.
4. Security-control supportability — after the letter, the feasible controls are the physical and network ones the OEM lists, not patches.
5. Physical serviceability — "will continued to be offered." Still running.

The International Medical Device Regulators Forum defines "legacy" exactly this way: a legacy device is one that "cannot be reasonably protected against current cybersecurity threats" — a supportability condition, not an age bracket. A new device can be legacy; an old one can be supportable ⁶. The U.S. legal frame reinforces the same structure: Section 524B of the FD&C Act requires a vulnerability-management plan, a patch process and a software bill of materials (SBOM) — but only for covered submissions received on or after March 29, 2023, and it is not retroactive ⁷. FDA's current premarket cybersecurity guidance, finalized in February 2026, governs new submissions; it does not reach backward into the installed base ⁸.

So the question "how old is the scanner?" is the wrong first question. The right ones are: which of the five clocks have expired, which are still running, and who owns each one. The rest of this report answers those questions with data.

Nine in ten cleared designs predate the law

Takeaway: the ultrasound design population overwhelmingly predates every enforceable cybersecurity requirement — and because clearances keep arriving at a flat 55–83 a year against a 10–15-year service life, the pre-statute population does not age out on any planning horizon.

We took FDA's 510(k) database — every premarket clearance ever issued — and filtered it to the two product codes that define a cart/console diagnostic ultrasound system: the machines with an operating system, a network port and a hospital IP address. That yields 2,066 clearance decisions from August 1977 through June 2026 ². Against the three cybersecurity milestones:

Broaden the filter to all eleven ultrasound product codes — probes, transducers, fetal Dopplers — and the shape holds at 91.8% of 2,726 records; the finding is not an artifact of code choice ².

Three load-bearing precision points travel with every number in this section. A clearance is a design, not a unit — FDA does not publish installed-base counts, so nothing here says "N machines in service." Pre-524B does not mean insecure — the statute created an obligation, not a vulnerability, and many manufacturers ran serious security programs long before 2023. And the 204 post-cutover decisions (9.9%) are a ceiling, not a count — 524B binds on the date a submission is received, and decisions lag receipt by months, so some of those 204 cleared under pre-statute submissions.

What the numbers do establish is structural: the legal machinery that forces a patch process and an SBOM into existence was switched on after almost the entire cleared design population already existed.

Now the vintage bands hospitals actually run:

Every console cleared between 2006 and 2020 — the band that dominates in-service fleets, given the 10–15-year real service lives documented in our fleet end-of-service report — predates the statute without exception. Even the newest full decade of cleared designs is 70% pre-524B. A hospital buying a replacement today has roughly a one-in-ten chance that the replacement's design cleared under the cyber-device statute, and even that overstates it.

And the population is not aging out. Clearance volume has sat in a flat band of 55–83 systems a year since 2012, with no surge after 2014 or 2023 ²:

Waiting for the fleet to modernize is not a cybersecurity strategy. It is a multi-decade plan.

One more structural fact, because it sets up everything in the evidence-hierarchy section below: the fleet is multi-vendor by construction, and the vendor tail is very long. 532 distinct applicant names have cleared an ultrasound system since 1977; 238 distinct applicants cleared one in 2011–2026 alone; more than half of all vendors ever to clear a system cleared exactly one ². For 2011–2026, the eight largest OEM families account for just 55.2% of clearances — 349 of 1,005 came from applicants outside the fourteen names everyone recognizes:

Each of those vendors has its own product-security disclosure practice — or none. And a majority of the vendors behind the in-service vintage bands have gone quiet as US filers: of 167 vendors that cleared a system between 2006 and 2018, 116 (69.5%) have no US ultrasound clearance decided in 2020–2026 ². Absence of a new clearance is not proof a company folded — firms get acquired, rename, clear under a parent, or sell elsewhere — but it is a lower bound on how hard the "call the manufacturer for a validated patch" instruction is in practice. The counterparty is frequently not an active US filer.

The catalog that doesn't contain your scanner

Takeaway: CISA's Known Exploited Vulnerabilities catalog is the right prioritization tool for a hospital's IT estate and a category error when applied to a scanner — its 276 vendors include no imaging manufacturer, and its 21-day median remediation clock is one no validated medical device can meet.

If a hospital security team pulls one federal list to drive patching, it is CISA's Known Exploited Vulnerabilities (KEV) catalog — the list of vulnerabilities confirmed to be exploited in the wild, with remediation deadlines that bind federal agencies under Binding Operational Directive 22-01 ⁵¹¹. The August 7, 2026 catalog holds 1,662 entries across 276 distinct vendors. Screen all 1,662 against diagnostic-imaging and medical-device manufacturers and you find zero — no GE HealthCare, no Philips, no Siemens Healthineers, no Canon Medical, no Mindray, no Samsung Medison, no Esaote. The only genuinely healthcare entry in the entire catalog is a health-IT integration engine (NextGen Healthcare Mirth Connect). The Microsoft/Windows backdrop the previous version of this analysis led with — 382 Microsoft entries, 170 labeled "Windows" — is real, but it is context, not a finding about ultrasound ⁵.

Two KEV numbers do matter to an imaging fleet, and neither is the vendor count:

One in five known-exploited vulnerabilities is ransomware-associated. 338 of 1,662 entries (20.3%) carry CISA's known-ransomware-campaign flag — and Microsoft-platform entries run half again higher, at 27.2% ⁵. For a device whose clinical value is its availability, ransomware association is the correct threat framing, not raw CVE counts.

The KEV clock is 21 days. The median window between a KEV entry's addition and its federal remediation due date is 21 days ⁵. A medical device cannot run on that clock: a patch must be validated by the manufacturer against the cleared configuration before a hospital may safely install it, and FDA's own postmarket guidance contemplates 30 days to communicate and 60 days to remediate for uncontrolled risks ¹⁰ — two to three times the KEV window. Where the OEM no longer supports the platform, there is no clock at all. That gap — 21 days of enterprise expectation against an OEM validation cycle measured in months, or never — is the operational reason "segment" and "isolate" exist as dispositions.

The precise statement of what a Windows KEV entry tells you about a scanner: a commodity layer that sits under some medical devices is being exploited in the wild. It does not tell you whether your scanner's validated configuration ships that component, exposes it, or has an OEM-approved fix. Components embedded in devices appear in KEV under the component vendor's name, never the device maker's — which is exactly why SBOMs exist, and exactly why the next section's catalog matters more.

The catalog that does

Takeaway: CISA's ICS Medical Advisories are the device-sector record — and in that record, when an ultrasound product line is named, the remedy has never yet been a complete patch. Half of the verified imaging advisories left at least one product with no software fix; the official instruction was to restrict access, or replace.

CISA runs a dedicated advisory series for medical devices: the ICS Medical Advisories (ICSMA). We enumerated the entire series — 176 advisories across the complete years 2016–2025, plus 10 more through August 9, 2026 — and individually fetched and verified the 18 advisories affecting imaging products ³. (A further 27 imaging-adjacent titles, mostly DICOM viewers and PACS software, were catalogued but not deep-verified; advisory counts measure disclosure activity, not incidence, and a year's total mixes new advisories with revisions.)

The patch-availability outcome across the 18 verified imaging advisories:

Half of the imaging advisories left at least one named product with no available patch. And the narrower, sharper cut: all four advisories that explicitly name ultrasound product lines — GE imaging and ultrasound products, GE ultrasound products, Philips ultrasound systems, Philips HDI 4000 — had incomplete patch coverage for the named ultrasound lines at publication ^312131415. Three of the four had no ultrasound patch at all; the fourth had a released fix for one of five named product lines, with the rest "planned." Four advisories is a small sample, and we present it as exactly that — but the direction could not be clearer, and it comes from the regulator's own remediation text.

Read what the advisories actually instruct, verbatim:

"GE Healthcare recommends organizations restrict physical access to devices by unauthorized individuals." — GE ultrasound kiosk-escape advisory, where the mitigation is physical access control, not a patch ¹⁴

"The support life cycle for the Philips HDI 4000 Ultrasound system ended on December 31, 2013… Users should implement controls to limit access to the network and consider replacing the system." — the end-of-life case, where the remedy is replacement ¹⁵

"If patient safety and treatment is not at risk, disconnect the product from the network and use in standalone mode." — Siemens molecular imaging, the isolate instruction stated as plainly as it can be ¹⁶

Patch, segment, isolate, replace: those are not this report's invention. They are the four remedies the official advisory record already uses. This report's contribution is putting gates and stop conditions on them.

The worked example — with its caveats in the same breath. In May 2024, researchers at Nozomi Networks (an OT-security vendor; label it as such) published 11 vulnerabilities across GE HealthCare's Vivid T9 ultrasound system, its Common Service Desktop web application, and the EchoPAC workstation software — the worst a hard-coded-credentials flaw rated CVSS 9.6 — and demonstrated proof-of-concept ransomware locking the scanner ¹⁷. Three facts make this the most instructive ultrasound-security case on record. First, the chain's doorway was a kiosk-mode escape originally disclosed in 2020 (CVE-2020-6977) — a four-year-old flaw was still the first link, and CISA's response was to reissue the same 2020 advisory as "Update A" rather than open a new one ¹⁴. Second, as trade analysis put it, the Vivid T9 "is essentially a complete PC running a GE-customized version of Windows 10" ¹⁸ — the console is a Windows machine wearing a clinical UI, and the kiosk shell is the security boundary. Age was not the variable; the containment design was. Third — and these caveats are not optional — the Vivid T9 chain requires physical access to the console's keyboard, GE published mitigations through its security portal, GE told reporters it had received no reports of exploitation, and GE's own bulletin lists an extensive set of ultrasound products not vulnerable, including Vivid E9 (all versions) and LOGIQ E9/E8/S8 (all versions) ¹⁷¹⁹²⁰. Quoting the ransomware demonstration without the physical-access precondition would misrepresent the source — and it is precisely the sort of scare framing this report exists to replace.

One disclosure-pattern note, stated carefully: no dedicated ICSMA advisory exists for Canon Medical, Hologic, Sectra, Mindray, Samsung Medison, Hitachi or Esaote. That reflects where security researchers have looked and how coordinated disclosure has gone — it is not evidence those vendors' products are more secure, and this report draws no such inference ³.

What the safety record does and doesn't say

Takeaway: FDA's adverse-event and recall channels are almost perfectly silent on ultrasound cybersecurity — zero cyber mentions in 8,525 reports since 2019, one recall ever — while the same recall channel records 18 cyber events on other device types. The silence measures a reporting pathway, not a risk level. Waiting for a safety signal is waiting for a signal that structurally cannot arrive.

We searched the narrative text of every ultrasound adverse-event report in FDA's MAUDE database — 13,213 reports all-time across eleven ultrasound product codes ⁴. The complete cybersecurity vocabulary produces single-digit hits: "ransomware" twice, "malware" three times, "cybersecurity" five times, "hacked," "unauthorized access," "phishing," "data breach" and "firewall" zero times each. Narrow to 2019 through 2026 — 8,525 reports — and every cyber term drops to zero.

The overlapping non-zero hits trace almost entirely to a single episode: WannaCry, June 2017. Searching the entire MAUDE database — every device type, every year — for "wannacry" returns 12 reports, and five are ultrasound: five Siemens ACUSON-family systems and workstations, reported in a single ten-day window ⁴²¹.

The manufacturer's own narrative in those reports is worth quoting, because it states the threat model better than any security vendor:

"The exploit of the vulnerability allows full remote control of the device without any other prerequisite other than the fact that the attacking computer is on the same network as the ultrasound device." ²¹

That is the segmentation argument, made by the OEM. The same narrative names the actual clinical harm pathway — "a possible delay in a procedure for a sedated patient, a reinsertion of a transesophageal transducer or catheter, or repeat of a stress echo exam" — availability harm, not corrupted diagnoses. And it records the resolution: "The issue was addressed with software patch releases in June 2017" ²¹. One commodity Windows SMB flaw crossed three separate ACUSON platforms; the OEM validated and shipped patches within weeks, filing under FDA's 2016 postmarket guidance ¹⁰. The one real episode in the record argues for patching and segmentation at once — which is the four-option thesis in miniature. ("Injury" in these reports is the manufacturer's reportability classification for potential harm, stated conditionally — not a confirmed patient injury.)

The recall record tells the same story with a sharper control group. Among 542 ultrasound recall records in FDA's database, exactly one is cybersecurity-driven: a 2008 recall of an intravascular ultrasound console that "may be infected with a worm (computer malware)" ⁴²². But the recall channel is demonstrably capable of recording cyber events — it holds 18 distinct cybersecurity-driven recall events across other device types since 2008: infusion systems, patient monitors, ventilators, sequencers, an imaging viewer, a radiotherapy information system, a surgical robot, a circulatory-support controller ⁴. The channel works. Ultrasound cyber events simply do not arrive through it.

Why the silence? Because the reporting pathways point elsewhere. MAUDE captures device-related deaths, serious injuries and malfunctions; a ransomware event that takes a scanner offline for a day without a reportable clinical consequence is generally not an MDR at all. Hospitals report cyber incidents to HHS OCR, to CISA, to the FBI and to their insurers — not to a device-safety database. So the correct uses of this silence are two, and only two: it demolishes the idea that an HTM team can wait for a safety signal before acting, and it justifies making the disposition decision on asset and advisory evidence instead. It must never be inverted into "no reports, therefore safe."

For completeness, the ordinary failure record, recomputed on the current export: across 2,534 ultrasound reports in 2025–2026, 94.3% are malfunctions, 4.9% injuries, 0.6% deaths — and none of it is cyber ⁴. The mix is stable against our July 2026 fleet report's 2020–2026 figures. Software is already the second-largest root cause of ultrasound recalls (125 of 542 records — for functional defects, not security). The reliability story and the security story are different stories.

The threat backdrop, sized honestly

Takeaway: the sector-level numbers justify disciplined inventory, segmentation and monitoring. None of them is an ultrasound statistic, and this report refuses to pretend otherwise — the honest backdrop is alarming enough without inflation.

Every number in this section is labeled with its publisher and its sample, because every one of them comes from either an agency tally or a security vendor's own telemetry — not a census.

Healthcare breach volume (HHS OCR data). For 2025, 772 breaches of 500+ records were on the OCR portal as of June 2026, affecting 139.7 million individuals — a figure that grows for months as the portal backfills (the February 2026 snapshot of the same year showed 710 breaches and 61.6 million individuals; always date the snapshot) ²³. In the most recent cleanly tallied period, hacking/IT incidents were 77.8% of large healthcare breaches (301 of 387, H1 2024) ²³.

Connected-imaging exposure (Claroty Team82, 2025 — vendor telemetry from 351 healthcare organizations running its product; not a census). Of 195,659 imaging devices in Claroty's dataset, 28% carry known exploited vulnerabilities, and 8% both carry ransomware-linked KEVs and are insecurely connected to the internet — a combination affecting 85% of the healthcare organizations in the sample ²⁴. Claroty's "imaging systems" category names ultrasound as a constituent but publishes no ultrasound-only figure — so this is context for the category ultrasound belongs to, not an ultrasound statistic.

Ransomware economics (Sophos, October 2025 — survey of victim organizations). The healthcare picture improved in 2025: 58% of hit providers recovered within a week (up from 21% in 2024), and the median ransom demand fell 91% year-over-year to roughly $343,000–$345,000 ²⁵. Improvement is real; the threat volume is not going away.

The FBI's framing (Private Industry Notification, September 2022). The FBI warned that unpatched and outdated medical devices provide attack opportunities, citing "a research report conducted by a cybersecurity firm" — the FBI does not name the firm — that found 53% of connected medical devices in hospitals had known critical vulnerabilities. The PIN's most durable sentence needs no statistics: "Medical device hardware often remains active for 10-30 years, however, underlying software life cycles are specified by the manufacturer… allowing cyber threat actors time to discover and exploit vulnerabilities" ²⁶. (We deliberately omit two widely repeated figures — "6.2 vulnerabilities per device" and "40% of devices at end-of-life" — because their primary source cannot be traced; the FBI itself attributes them only to an unnamed report.)

Exposed imaging infrastructure (Trend Micro, scan data November–December 2025). 3,627 DICOM servers were directly reachable from the public internet across 100+ countries; only 0.14% used TLS ²⁷. This is the PACS/storage layer around imaging devices, not the scanners themselves — but it is the network those scanners talk to.

And the canonical incident, corrected. WannaCry's NHS impact is the story everyone cites and most people cite wrong. The UK National Audit Office found 34 trusts infected and locked out of devices, with at least 81 of 236 trusts affected in total — two different figures that must not be merged — and 6,912 appointments confirmed cancelled, with roughly 19,500 estimated ²⁸. But the OS lesson is the opposite of the folklore. NHS England's own lessons-learned review: "This was an attack using a specific Microsoft Windows vulnerability, not an attack on unsupported software. The majority of NHS devices infected were running the supported, but unpatched, Microsoft Windows 7 operating system" — Windows XP machines were a minority of infections, down to 1.8% of the estate by January 2018 ²⁹. WannaCry is not an argument that old operating systems get you breached. It is an argument that unpatched supported systems get you breached — which is a patch-governance failure, not an age failure. That is this report's thesis, stated by a national health service. (The NHS record names MRI scanners and blood analysers among affected equipment; no source verifies ultrasound systems specifically in the NHS incident — the ultrasound WannaCry evidence is the separate US MAUDE record above.)

How do I even find out what this thing runs?

Takeaway: you mostly can't — not from public sources. Zero of ten surveyed OEMs publish an ungated per-product OS/support-status document; only 8 of 26 named ultrasound platforms had a publicly sourceable operating system; FDA 510(k) summaries don't disclose it either. The asset record you need must be captured at the device and demanded from the vendor, because it cannot be looked up.

HTM practitioners ask this question in public, in exactly these words — "How do I know if my ultrasound runs Windows 10?"; "Is there a master EOL/EOS list I can check my inventory against?" — and get no real answer ³⁰. We tried to answer it systematically, and the failure is the finding.

The OEM disclosure survey (ten vendors, August 2026). Five of ten publish an ungated, dated security-advisory or bulletin list: Philips, Siemens Healthineers, Canon Medical, GE HealthCare and Olympus. Zero of ten publish an ungated per-product OS or support-status document. Everywhere such a repository exists, it sits behind a customer credential: GE's Product Security Portal ("a secure, web-based global portal providing credentialed customers a centralized repository"), Philips's InCenter and MDS² library (email registration), Siemens's teamplay Fleet (SBOMs and pre-2022 advisories), Mindray's service portal, Fujifilm's secure request form ^19313233. The precise pattern: the vulnerability disclosure is public; the validated patch and the per-product status are behind a login. You can find out for free that your scanner family is affected. You need an account to get the fix.

The platform-to-OS lookup (26 named platforms). Only 8 could be tied to a documented operating system from any fetchable public source, and only three of those rise to an OEM document stating it as a matter of record — Canon's advisory placing Windows 10 IoT Enterprise LTSC 2015 in the Aplio i-series' optional second console, and Esaote's DICOM conformance statement putting the MyLab families on Windows 10 ³³³⁴. For the GE Voluson S-series, LOGIQ E9 and P-series, Vivid E9, the Philips EPIQ/Affiniti/HD11/CX50 families, the Siemens ACUSON S-series and X-series, Hitachi/Fujifilm Arietta, Samsung RS80 — no public source states the OS. We checked two FDA 510(k) summaries directly as a test (a GE LOGIQ E10 and a Canon Aplio clearance): neither discloses the operating system ². Even DICOM conformance statements are inconsistent — Esaote's discloses the OS; Philips's and GE's don't. There is no standard document a biomed can reliably check across brands.

The Microsoft clock, for when you do identify the build. Windows XP is 12.3 years past end of support; Windows 7, 6.6 years; Windows 8.1, 3.6; consumer Windows 10 (22H2) crossed end of support in October 2025 and now runs on paid extended updates through at most 2028 ³⁵. But the IoT/embedded builds many consoles actually ship diverge sharply: Windows 10 IoT Enterprise LTSC 2019 is supported to January 2029, LTSC 2021 to January 2032, and the 2024-generation LTSC is Windows 11-based and supported to October 2034 ³⁵. Two OEM statements from September 2025 make the same point from the manufacturer side: Canon Medical and Philips each published Windows 10 end-of-support responses noting that the only IoT build affected by the 2025 cutoff (LTSB 2015) is either absent from their products or isolated from external networks ³³³¹. "It says Windows 10 on the boot screen" is therefore not an inventory datum — the edition and build separate a platform that expired last October from one supported into the 2030s.

What this means for the asset record. Because none of this can be looked up, it must be captured and demanded. At the device: application software version, OS edition/version/build from the system information screen (with the collection date and method — never a guess from the desktop theme), configured network flows, remote-access state, and local patient-data footprint. From the vendor, in writing: the product's support status with separate dates for hardware service, software maintenance and security support; the current MDS² (Manufacturer Disclosure Statement for Medical Device Security); the SBOM where 524B or contract entitles you to one; advisory access under an organizational account rather than one employee's inbox; and the validated-patch status for the exact build you recorded. "Unknown" is an allowed value in the record — it is a finding with an owner and a due date, not a blank.

Patch, segment, isolate or replace, defined precisely

Takeaway: the four dispositions get used interchangeably in the literature; they are not interchangeable. Each has a definition, evidence gates, and a stop condition — and cost and cybersecurity are decided on different axes than age.

The existing literature — regulator guidance included — slides between these words loosely, and the sliding has consequences: a fleet marked "isolated" in a spreadsheet may in practice be segmented, connected, or merely unplugged until someone needs the worklist. The advisory record above uses all four remedies; here is what each one actually is, what evidence it requires, and what ends it.

Patch means an OEM-authorized software remediation installed on the device under controlled change. Its gates: an advisory or validated update that names your exact model, application version and build; a defined backup and rollback path; and a post-install functional test — boot, probe recognition, acquisition, measurements, worklist, DICOM store — before clinical return. Its stop condition: no authorized package exists for your configuration, or functional validation fails. An enterprise patch pushed to a scanner because the OS name matches is not a patch; it is an uncontrolled modification of a validated medical device.

Segment means the device stays connected, but only through a documented allowlist: named PACS, worklist, DNS/NTP and remote-service destinations, default-deny everything else, enforced at a boundary the hospital actually controls. Its gates: a verified flow map, firewall objects tested against real clinical workflows (worklist query, acquisition, store, downtime recovery), and log review for blocked-but-needed traffic. HHS's sector performance goals name segmentation and asset inventory among the priority practices, and NIST's zero-trust model states the underlying principle — network location alone confers no trust ³⁶³⁷. Its limit, stated honestly: segmentation reduces reachability; it does not remove vulnerable code, and it does not protect against USB media or an allowed protocol carrying a malicious payload. Its stop condition: required flows cannot be bounded, or enforcement does not exist at the relevant boundary.

Isolate is stronger: the system operates without routine network access — the Siemens advisory's "disconnect the product from the network and use in standalone mode," and the physical port locks in the Olympus letter ¹⁶¹. Its gates: a workflow that survives offline (patient demographics in, images out, on managed media), controlled reconnection authority, and disabled or locked secondary interfaces. Its stop condition: the clinical workflow cannot run safely offline, or "isolated" cannot be verified — a cable removed today and reattached tomorrow is not a disposition.

Replace is the disposition when neither software supportability nor compensating controls can carry the residual risk — the Philips HDI 4000 case, where the regulator's own advisory says "consider replacing the system" ¹⁵ — or when the hardware itself is no longer reliably serviceable. Its gates are a funded project with cybersecurity procurement terms (next section) and a controlled retirement: patient data sanitized with evidence, credentials and certificates revoked, network objects removed.

The two axes are scored separately, and never averaged:

A perfect probe cannot compensate for uncontrolled remote access, and a fully patched OS cannot compensate for a failing power supply in a critical-care role. And every compensating-control state needs an expiry: an owner, a review date, and a named event that ends it — a validated patch, a replacement delivery, a risk reassessment. The most dangerous word in a lifecycle program is "temporarily."

If a device shows a suspicious signal — an unexpected destination in the firewall log, an unexplained reboot, a service prompt nobody recognizes — the first move is coordination, not a reflexive power-off: confirm the asset and the signal, protect any patient procedure in progress, choose the least disruptive containment that actually reduces risk (block one destination, disable remote access, restrict the network policy), preserve logs, and contact the manufacturer's product-security channel with the exact model, build and observation. A medical device should not be imaged, scanned or factory-reset with ordinary IT tooling merely because the tooling is available.

Where independent service fits, and where it stops

Takeaway: the Olympus letter draws the boundary better than any consultant: when the software clock stops, the hardware clock keeps running — and somebody has to keep the hardware running. That is the independent-service lane, entered through the same disposition framework, never as a substitute for it.

Every disposition except "replace immediately" assumes the scanner remains clinically dependable while the cyber decision plays out. A hospital that spends a quarter engineering a segmentation exception for a system whose board is failing has solved the wrong problem first. The two-axis matrix needs real evidence on the physical axis: current fault codes and symptoms, probe and connector condition, board-level fault isolation, power and cooling health, parts availability for the model, and repeat-failure history.

That evidence is what an independent multi-brand service operation contributes. Rongtao Medical's verified operating facts define the shape of the lane: 35+ senior engineers doing board-level diagnosis and repair, more than 3,000 parts SKUs across major OEM brands, a 48-hour real-machine test before shipment with photo or video evidence, a 5–8 business-day standard turnaround, a typically 90-day warranty, ISO 13485:2016 and ISO 9001:2015 certification, and bonded-zone shipping to 140+ countries ³⁸. For the extend-versus-replace economics and the parts-provenance questions that sit behind that lane, see our companion reports on the aging fleet after the end-of-service letter, on independent servicing safety, and on board failure patterns.

And the boundary, stated as bluntly as Olympus states its own: a hardware repair does not create an OEM patch, does not make a CVE non-applicable, does not validate an operating-system change, does not certify a network, and does not make a device cybersecure. Rongtao is not OEM-authorized, is not a cybersecurity vendor, does not develop patches and does not assess hospital networks; OEM names in this report are identifiers of service coverage and public evidence, never affiliation. The hospital's HTM, security and clinical owners hold the disposition decision; the service partner supplies one axis of it.

One practical interface rule closes the loop: after any board, drive or module work — by anyone — the return-to-service check should confirm not just image quality but cyber-relevant state: software build unchanged, accounts and network configuration intact, remote-service state as approved, asset record updated. "Hardware repaired" and "asset returned to its approved operating state" are two different sign-offs, held by two different owners.

Procurement clauses for the next system

Takeaway: today's missing evidence is tomorrow's contract clause. Everything this report could not look up — per-product OS status, support end dates, patch entitlements — is exactly what the next purchase order should require in writing.

None of this prevents vulnerabilities. It ensures that when the next advisory lands, the hospital holds the entitlements and the evidence instead of discovering — as the OS-lookup survey above did — that the answer is behind a login it does not have.

Methodology and limitations

Takeaway: every computed number above is reproducible from public data with the filters stated here, and every silence is labeled as a property of the channel that produced it.

FDA 510(k) analysis. FDA's 510(k) database, export of July 22, 2026 (175,559 records). Primary cohort: product codes IYN and IYO — cart/console diagnostic ultrasound systems — 2,066 decisions, August 1977 through June 2026; cross-checked against an 11-code ultrasound set (2,726 records), which reproduces the shape (91.8% pre-524B). Clearances are design decisions, not installed units; no public installed-base count exists, and none is claimed. The 204 post-cutover decisions are a ceiling on 524B-era designs because the statute binds on submission receipt, not decision date ².

CISA analyses. KEV catalog version 2026.08.07 (1,662 entries; vendor screen against imaging and medical-device manufacturer lists; ransomware flag and due-date arithmetic from the feed's own fields) ⁵. ICSMA series enumerated page-by-page from CISA's advisory listing on August 9, 2026 — 176 advisories for complete years 2016–2025, 10 more in partial 2026; 18 imaging-relevant advisories individually fetched and verified; a further 27 imaging-adjacent titles catalogued but not deep-verified. Advisory counts measure disclosure activity, not incidence ³.

FDA safety-record analyses. MAUDE narrative search via openFDA (data updated July 28, 2026) across eleven ultrasound product codes, 13,213 all-time reports; event-mix recomputation on the 2025–2026 export window (2,534 reports). Recall analysis across 542 ultrasound recall records and a whole-database screen for cybersecurity-driven recall events (18 since 2008). MAUDE silence is a property of reporting pathways — hospitals report cyber incidents to OCR, CISA, the FBI and insurers, not to a device-safety database — and is never read here as evidence of safety ⁴.

OEM disclosure survey. Ten manufacturers' public product-security properties surveyed in August 2026; "gated" means the document or repository requires a customer credential. A vendor's absence from KEV, from the ICSMA record, or from public disclosure is not evidence about its products' security in either direction.

Sector statistics are labeled with publisher and sample wherever cited: Claroty's figures are telemetry from its own 351-organization customer base, not a census ²⁴; Sophos's are a victim survey ²⁵; OCR breach counts grow for months as the portal backfills ²³. Two widely repeated figures (6.2 vulnerabilities per device; 40% of devices end-of-life) are omitted because their primary source cannot be traced. One attempted lane is disclosed as empty: a screen of 29,979 EU procurement notice titles (2016–2026) found zero referencing cybersecurity requirements — the five "cyber" hits were the CyberKnife brand name — but tender titles cannot see specification annexes, so the correct statement is "not testable with this data," not "buyers don't ask."

Frequently asked questions

How do I find out what operating system my ultrasound machine runs? Mostly, you cannot look it up — you have to capture it. Only 8 of 26 named platforms had a publicly documented OS in our survey; FDA 510(k) summaries do not disclose it, and no OEM publishes an ungated per-product status document ²¹⁹³¹. Record edition, version and build from the device's own system-information screen, then ask the manufacturer in writing for the support status of that exact build, the current MDS², and advisory access under an organizational account.

Windows 10 support ended — do I have to replace my ultrasound system? Not on that fact alone. "Windows 10" is not one clock: consumer 22H2 ended support in October 2025, but the IoT Enterprise LTSC builds many consoles ship are supported to January 2029 (LTSC 2019) and January 2032 (LTSC 2021), and Canon and Philips both published statements that the one build affected by the 2025 cutoff is absent from or isolated in their current products ³⁵³³³¹. Identify the exact build first; then run the five-clock check, not the birthday check.

Can I install a newer Windows version on the scanner myself? No. The operating system on a cleared ultrasound system is part of a validated medical-device configuration; an unauthorized OS change is an uncontrolled modification that can affect safety, effectiveness and regulatory status. The patch path runs through the manufacturer's validated updates ¹⁰. If no such path exists, the honest options are the other three dispositions — segment, isolate, or replace.

Is an old ultrasound machine automatically a cybersecurity risk? No — age is not the variable, supportability is. IMDRF defines a legacy device as one that cannot reasonably be protected against current threats, explicitly not an age bracket ⁶. WannaCry itself is the proof: NHS England found the majority of infected devices ran supported-but-unpatched Windows 7, not ancient XP ²⁹. An old console with locked ports, bounded flows and a running hardware-service lane can be a managed asset; a new one with unmanaged remote access is not.

What is a "cyber device" under Section 524B? A device that includes sponsor-authorized software, can connect to the internet, and has characteristics that could be vulnerable to threats. For covered submissions received on or after March 29, 2023, the manufacturer must provide a vulnerability-management plan, a patch process and an SBOM ⁷. It is not retroactive — which is why 90.1% of the cleared ultrasound design population sits outside it ².

Where do I find security advisories for my ultrasound model? Three places, in order of authority: the manufacturer's product-security page (five of ten OEMs publish free, dated advisory lists — Philips, Siemens Healthineers, Canon Medical, GE HealthCare, Olympus); CISA's ICS Medical Advisories series; and the manufacturer's credential-gated portal for the validated fix and per-product status ³¹⁹³¹. Assign advisory monitoring to an organizational owner — the record shows the fix consistently sits behind the login.

Does an end-of-support letter mean parts are no longer available? Not necessarily — read which clocks the letter actually stops. The 2025 Olympus ultrasound notice ended software support and future security countermeasures while stating in the same document that "hardware support, such as parts replacement, etc. will continued to be offered" ¹. Software support, parts availability and full service can end years apart, and the independent parts-and-repair market extends the hardware clock further; confirm each date in writing.

Conclusion: the disposition, not the birthday

Four findings carry this report.

The clocks are separable, and the OEMs themselves separate them. Olympus ended an ultrasound system's software clock and continued its hardware clock in one letter ¹. Managing a legacy fleet is the discipline of knowing which of the five clocks has expired on each asset — not sorting by purchase date.

The rulebook arrived after the fleet. Nine in ten cleared ultrasound system designs predate the statute that requires a patch process, the population is not aging out at 55–83 clearances a year, and a third of recent clearances come from a long vendor tail with thin or absent disclosure practices ². Waiting for modernization is a multi-decade plan.

The official record already says patching is often not the remedy. Half of the verified CISA imaging advisories left at least one product without a fix; every ultrasound-naming advisory had incomplete patch coverage; the instructions were restrict, isolate, replace ³. Meanwhile the enterprise patching clock — 21 days — is one no validated device can run on ⁵. Segment and isolate are not failures of nerve; they are the documented remedies.

The safety record's silence is a pathway, not a verdict. Zero cyber mentions in 8,525 recent ultrasound safety reports means the signal will never arrive through that channel ⁴. The decision must be made on asset and advisory evidence — the record you build, because the one you can look up does not exist.

For every system that stays in service under that decision, the hardware clock has to keep running: reliable boards, tested parts, working probes, documented function. If a physical serviceability assessment would help your disposition decision — fault isolation, tested parts availability for your models, real-machine test evidence — that is the conversation Rongtao Medical is built for, as one input to a decision your HTM, security and clinical owners hold.