Imagine a hospital where a CT scanner installed in 2010 is still reading chest films today. An infusion pump platform from the early 2000s is still on formulary in dozens of hospitals. Both still earn revenue through service contracts and consumables. Both were built for a threat landscape that no longer exists, and both now sit at the centre of a regulatory and commercial collision manufacturers need to understand now, not next year.
The pressure comes from two directions at once. Regulators in the US and EU have turned cybersecurity from a design nicety into a binding condition of market access. Attackers have gotten better at finding the oldest, least-defended device on the network and using it as the door in. For a manufacturer with a large legacy installed base, the question isn't whether to act—it's whether to modernise a device that still sells, retire it, or wait for a regulator or an attacker to force the decision.
This is also a commercial story, not just a defensive one. A device line with a credible, documented cybersecurity posture protects years of additional sellable life for a product that's already amortised and still generates high-margin service revenue. A device line that can't clear the current bar risks being quietly dropped from hospital procurement shortlists, regardless of clinical quality.
The choice is "spend now to keep a proven revenue line alive" versus "lose it later on someone else's timeline."
Why legacy devices have become the softest target in the hospital
A few incidents make the pattern concrete. WannaCry (2017) exploited an old Windows vulnerability that unpatched imaging and administrative systems across the UK's NHS were still exposed to, forcing ambulance diversions and cancelled procedures. The Medfusion 4000 infusion pump (CVE-2017-12725) was engineered for mechanical safety but trusted its network communications by design, allowing remote manipulation once network access was obtained. Within months of each other in 2023, BD, Insulet, and ZOLL each disclosed vulnerabilities in connected devices — none exotic zero-days, just gaps that appear when a device's security posture hasn't kept pace with how connected it has become; the ZOLL incident alone exposed personal data for just over one million people. And the 2024 Ascension ransomware attack, which disrupted roughly 140 hospitals and pushed providers back onto paper records, shows the downstream cost when any device on a clinical network becomes an entry point.
Attackers increasingly don't need a sophisticated zero-day against the device itself. They need one soft, forgotten, unsegmented system, and an unpatchable legacy device could be the one.
The regulatory floor has moved — and it moved fast
The compliance baseline has shifted sharply in the last two years, and three developments matter most.
- FDA Section 524B is now mandatory. It allows the FDA to require cybersecurity information in premarket submissions for 'cyber devices,' which includes almost any device with software or a network connection—covering most equipment in hospitals today. The guidance has been updated three times since 2023, most recently on February 3, 2026, to match the FDA's new Quality Management System Regulation (QMSR, effective February 2, 2026, which incorporates ISO 13485:2016). The main requirements have stayed the same but are now stricter: a Secure Product Development Framework must be part of the design process, a Software Bill of Materials (often with a VEX statement) is needed, a vulnerability monitoring plan must cover the device's entire commercial life, and cybersecurity risk must be included in the quality system as a 'reasonably foreseeable risk.' Now, missing cybersecurity elements can cause a submission to be rejected. The FDA has issued 'Refuse to Accept' holds for missing SBOMs or threat models, and a non-compliant cyber device is considered adulterated or misbranded, subject to the same enforcement as other quality violations.
-
The EU has built an equivalent, standards-based expectation. MDR/IVDR Annex I §17.2 and 17.4 already require "state of the art" IT security, with MDCG 2019-16 (Rev.1) as the primary interpretive guidance. What's changed is that Notified Bodies now treat IEC 81001-5-1:2022 as the de facto evidence standard for meeting those obligations, alongside ISO 14971 and IEC 62304. Two 2025 MDCG updates extend the picture: one on secure distribution of device software through online platforms, another on the interplay between cybersecurity and the EU AI Act for AI-enabled devices.
-
The EU Cyber Resilience Act (CRA) matters even though medical devices are exempt. The CRA is a horizontal cybersecurity law for connected products, with reporting duties from September 2026 and full application from December 2027, backed by fines up to €15 million or 2.5% of global turnover. MDR/IVDR-regulated devices are carved out because MDR already covers them, but that exemption is narrower than it looks. Connected building infrastructure, non-medical accessories, and general IT components that support a device but aren't themselves classified as one fall squarely inside CRA scope, with IEC 62443 as the reference standard for that overlap. Manufacturers need to map their full estate against both regimes.
The regulatory landscape at a glance:
| Framework | Jurisdiction | What it requires | Where legacy devices fit |
|---|---|---|---|
| FDA Section 524B + Feb 2026 guidance | US | SBOM, SPDF, vulnerability monitoring plan, QMSR-integrated risk management | Applies at next significant change/resubmission; drives "cyber device" reclassification risk |
| ISO 14971 | Global | Risk management across the device lifecycle | The backbone document every other framework plugs into |
| EU MDR Annex I §17.2/17.4 + MDCG 2019-16 | EU | State-of-the-art IT security, lifecycle risk management, postmarket monitoring | Required for continued CE marking and Notified Body renewal |
| IEC 81001-5-1:2022 | Global (EU-referenced) | Secure product development lifecycle for health software/IT | De facto evidence standard for MDR Annex I compliance |
| EU Cyber Resilience Act | EU | Security-by-design, SBOM, vulnerability reporting, CE marking | Medical devices exempt (MDR covers them); applies to non-MD connected components and accessories |
| IEC 62443 | Global | Industrial/network cybersecurity | Reference standard for CRA-scoped, healthcare-adjacent non-MD products |
Together, these frameworks make "do nothing" a real business risk. A device that can't demonstrate a credible cybersecurity story can fail a 510(k) supplement, fail a Notified Body audit, and lose the next hospital tender even if it's clinically excellent.
Why "just patch it" doesn't work for legacy equipment
Most legacy devices weren't designed with the architecture modern controls assume: no secure boot or code-signing chain to verify software integrity; embedded or end-of-life operating systems that no longer receive vendor patches at all; insufficient logging capacity for the audit trails current guidance expects; memory-constrained hardware that can't run modern encryption without a redesign; and the fact that any software change can itself trigger a new regulatory submission.
This is why every current framework converges on the same answer: risk-based controls, segmentation, and deliberate lifecycle decisions, not blanket patching. Some devices are worth bringing current. Others are better served by compensating controls until end-of-life. The job of leadership is to make that call deliberately, on evidence.
A practical remediation pathway for manufacturers
Step 1: Compliance and technical assessment
Before spending a dollar on remediation, establish the facts. This means:
- Correctly classifying each device against current regulatory definitions: is it a "cyber device" under 524B? Does it fall under MDR Annex I cybersecurity obligations? Is any accessory or connected component actually CRA-scoped rather than MDR-scoped?
- Documenting the risk-based justification for that classification, so it holds up under FDA or Notified Body scrutiny.
- Running a gap analysis against the current standards baseline (SPDF/SBOM expectations, IEC 81001-5-1, ISO 14971) to see exactly where each device line stands today.
- A technical feasibility study: can this specific device be updated to close the gaps at a reasonable cost, given its architecture, or is that simply not achievable within its remaining hardware lifespan?
The outcome of this step should be a clear, documented decision for each product line: invest and bring current, apply compensating controls and manage as legacy, or plan a phased retirement.
Make the call: invest, isolate, or retire.
Step 1 ends either in investing, isolating or retiring. Invest and bring current when the installed base is large, and the architecture can plausibly support modern controls. Compensating controls, managed as legacy when the device is still valuable but close to end-of-life; here, the manufacturer's job shifts to publishing segmentation guidance, an accurate SBOM, and staying responsive on disclosure even without shipping new code. Phased retirement when the architecture can't meet the bar at any reasonable cost, done deliberately, with a communicated timeline, rather than forced by a failed audit.
Step 2: Security testing
Documentation and architecture review only get you so far; real vulnerabilities surface under testing. At minimum, this means vulnerability scanning across the device's software, firmware, and network interfaces; penetration testing is strongly recommended and, for devices seeking premarket cybersecurity clearance under the 2026 FDA guidance, effectively expected. This step often surfaces issues the design team didn't know existed, particularly in third-party or open-source components buried deep in the software stack, exactly what an SBOM is meant to make visible.
Step 3: Revise or create the required documentation
Regulatory submissions and audits live or die on documentation. This typically means updating or building, from scratch where necessary:
- The ISO 14971 risk management file, now explicitly covering cybersecurity risk alongside traditional safety risk.
- The usability engineering file under IEC 62366.
- A Software Bill of Materials, built to the format regulators expect (CycloneDX or SPDX), ideally paired with a VEX statement identifying which listed vulnerabilities are actually exploitable in the device's specific configuration.
- Threat models, security architecture views, and the vulnerability monitoring plan the FDA's 2026 guidance and MDCG 2019-16 both expect.
Step 4: Update software and, where necessary, hardware
With the gaps and priorities established, this is the engineering work: closing identified vulnerabilities, implementing missing controls (authentication, encryption, secure update mechanisms, logging), and, where the architecture genuinely can't support modern controls, scoping the hardware revision needed to get there. Biotech and healthcare organisations might also work with a specialised technology provider to create/add secure solutions or update older systems, all while keeping clinical workflows running smoothly. This is usually the most resource-intensive step, and the one where the build-versus-partner decision (discussed below) has the largest financial impact.
Step 5: Certify where relevant
Depending on the scale of the change, this step may mean a new FDA submission, a significant-change notification to a Notified Body under MDR, or formal certification against a specific standard (IEC 62443-4-1 or 4-2, for example, for the security development lifecycle itself). Getting Step 1's classification and justification right up front makes this step far more predictable.
Step 6: Establish an ongoing process
None of this is a one-time project. Regulatory requirements will keep evolving; the FDA has already revised its cybersecurity guidance three times in three years, and the EU's CRA and MDCG guidance are still maturing. A durable program needs:
- A standing process for tracking regulatory and standards changes relevant to the product portfolio.
- Scheduled cadence for updating risk assessments and technical documentation as new information emerges.
- Recurring vulnerability scanning and periodic penetration testing, tied to the vulnerability monitoring plan already committed to in the device's regulatory file.
- A defined coordinated vulnerability disclosure process, since regulators on both sides of the Atlantic now expect one.
For healthcare providers: a shorter, parallel path
Hospitals and health systems face a related but distinct version of this problem: they don't control device design, but they do control the network the device sits on and the decision to keep running it. The pathway is simpler but no less urgent:
- Assess infrastructure, software, and the medical device fleet to identify vulnerabilities, compliance gaps, and specific devices that need replacement, isolation, or a formal vulnerability notification back to the manufacturer.
- Test the infrastructure and device fleet, vulnerability scanning at minimum, penetration testing where feasible to get an evidence-based picture rather than a documentation-based one.
- Remediate: segment networks so legacy devices can't be used as a pivot point, tighten access controls, and track outstanding manufacturer notifications until they're closed.
- Providers carry their own compliance obligations here too HIPAA, and increasingly frameworks like HITRUST, ISO 27001, and SOC 2 as payers and partners demand evidence of a mature security program, not just a policy binder.
Build versus partner: the case for specialised outside capacity
Every step above is achievable internally. The real question is whether that's the fastest or cheapest way to get there, and for most manufacturers managing several legacy lines against a moving target, it usually isn't, for three reasons.
- The expertise is narrow. Security testing against embedded architectures, SBOM/VEX tooling, and current-format regulatory documentation are specialist skills. Hiring and retaining that full stack in-house for what's fundamentally project-shaped work is slow and expensive.
- The target keeps moving. The FDA alone has revised its cybersecurity guidance three times since 2023. A partner whose practice is tracking FDA, MDR/MDCG, and the CRA/IEC 62443 boundary folds that into a standing engagement; an internal team has to build that muscle from scratch on top of regular product work.
- Scale compounds the savings. A manufacturer running simultaneous assessment, testing, and remediation across several product lines faces a real capacity constraint if it routes all of that through an engineering organisation that also has to keep shipping new products. A partner with existing tooling and templates typically moves faster and, with fixed costs already amortised across other clients, does it more cheaply than standing up equivalent capacity for one company's portfolio.
When evaluating a partner, look for experience across the full pathway (not one slice of it), fluency in both US and EU tracks, the ability to scale a team up and down by phase, and a software development lifecycle that's itself compliant with regulations and standards, so the tooling used to build the fix doesn't become its own liability.
The bottom line
The devices in question are not going anywhere soon; they're clinically valuable, they're paid for, and replacing an entire installed base overnight isn't realistic for manufacturers or hospitals. But the regulatory and threat environment around them has shifted permanently in the last two years, and it will keep shifting. Manufacturers that treat this as a structured, risk-based program assess, test, document, remediate, certify, monitor will keep their legacy product lines sellable and compliant well past the point their original architecture was designed for. Manufacturers that treat it as an afterthought will find that a regulator, a Notified Body, or an attacker makes the decision for them, on a timeline and at a cost they didn't choose.
Related Insights
The breadth of knowledge and understanding that ELEKS has within its walls allows us to leverage that expertise to make superior deliverables for our customers. When you work with ELEKS, you are working with the top 1% of the aptitude and engineering excellence of the whole country.
Right from the start, we really liked ELEKS’ commitment and engagement. They came to us with their best people to try to understand our context, our business idea, and developed the first prototype with us. They were very professional and very customer oriented. I think, without ELEKS it probably would not have been possible to have such a successful product in such a short period of time.
ELEKS has been involved in the development of a number of our consumer-facing websites and mobile applications that allow our customers to easily track their shipments, get the information they need as well as stay in touch with us. We’ve appreciated the level of ELEKS’ expertise, responsiveness and attention to details.
