Technology Refresh is the planned replacement of aging hardware, software, or components in a medical device or in the equipment that builds it to address obsolescence, security, and supportability while the product stays on the market. It keeps a compliant device manufacturable and safe without altering its intended use.
What is Technology Refresh?
A technology refresh updates the parts of a device or its manufacturing process that have reached, or are approaching, end of life. The trigger is rarely the clinical function. More often, it is a microcontroller going out of production, an operating system losing security support, a connector that a supplier has discontinued, or a third-party software library (SOUP, software of unknown provenance, under IEC 62304) that no longer receives patches.
A refresh sits inside lifecycle management and sustaining engineering, between routine maintenance and a full redesign. The goal is continuity: keep building and supporting an existing product rather than launching a new one. Because the device is already cleared or certified, the work centers on swapping a part or platform while proving the device still meets its original requirements.
Why Technology Refresh matters in medical device development
Few electronic parts outlive the products that use them. A component can hit end of life in a handful of years, while a Class II or III device may stay on the market for a decade or more. Without a plan, a discontinued part can stop a line and cut off patients who depend on the device.
Security raises the stakes. Under Section 524B of the FD&C Act, in force since March 2023, manufacturers of “cyber devices” must monitor for vulnerabilities and ship updates across the product lifecycle. An unsupported operating system or library becomes a documented liability, and a device not kept to the current state of the art can draw FDA action under Section 518(b), the repair, replace, or refund authority.
Timing also drives cost and audit exposure. A refresh planned ahead of a last-time-buy deadline is a controlled engineering change. A refresh forced by a sudden discontinuation becomes a fire drill that invites shortcuts in verification.
How Technology Refresh works
A refresh runs as a design change inside your quality system, not as an informal swap. Under the FDA Quality Management System Regulation (QMSR), effective February 2, 2026, 21 CFR Part 820 incorporates ISO 13485:2016 by reference, so change control, design controls, and risk management apply to the substitution. Typical steps:
- Identify the trigger and scope. Confirm what is obsolete, the last-time-buy window, and whether the change touches form, fit, function, or software.
- Assess impact and risk. Update the ISO 14971 risk file and decide whether the change affects safety, performance, or essential performance under IEC 60601-1.
- Select and qualify the replacement. Evaluate alternates, second sources, and any firmware or driver differences a new part introduces.
- Verify and validate. Re-run the verification tests the change touches, and revalidate where it reaches validated outputs or processes (IQ, OQ, PQ for production changes).
- Evaluate regulatory impact. In the U.S., changes are screened against FDA’s 510(k) change logic; in the EU, EU MDR 2017/745 significant-change rules govern whether the certificate is affected.
- Update records and release. Revise the device file, drawings, BOM, and labeling, then release under change control.
Software refreshes carry their own thread. IEC 62304 governs the software lifecycle, and a SOUP update or operating-system migration usually means re-running affected software verification and refreshing the SBOM that cybersecurity guidance expects.
Common challenges and best practices
The frequent mistake is treating a refresh as a like-for-like drop-in. A “pin-compatible” replacement can differ in timing, tolerance, or firmware behavior in ways that surface only in testing or in the field. Teams also underestimate revalidation: a small hardware change can ripple into electrical safety, EMC, and biocompatibility evidence.
What good looks like:
- Monitor obsolescence continuously, not at the last-time-buy email, tracking component, and software end-of-life across the BOM.
- Scope the change narrowly and document the rationale, so verification targets only what moved.
- Keep the risk file and design history current as you go, rather than reconstructing them for an auditor later.
- Qualify a second source before you need it, and design for alternates where a part is hard to replace.
How SJML helps with Technology Refresh
SJML supports technology refresh through sustaining engineering and obsolescence management across a device’s life. The team handles component and software end-of-life, second-source qualification, and value analysis and value engineering (VAVE), with change governance designed to keep revalidation scoped and predictable. Regulatory sustenance covers design file remediation, ISO 14971 risk updates, and assessment of FDA or EU MDR submission impact. In-house labs support electrical safety, IEC 60601 testing, EMC, and reliability work when a refresh touches hardware.
Talk to SJML’s engineering team →
Frequently asked questions
Usually a supply or support signal rather than a clinical one: a component reaching end of life, a last-time-buy notice, an operating system or library losing security support, or a discontinued supplier part. Cybersecurity obligations and the need to stay at the current state of the art can also force a refresh before a part formally disappears.
It depends on the change. Manufacturers assess impact under their quality system and screen the change against FDA’s 510(k) change logic in the U.S. or EU MDR significant-change rules in the EU. A like-for-like part may need only internal verification, while a change affecting safety, performance, or software function can require a new submission or certificate review.
A refresh keeps the device’s intended use and architecture, replacing obsolete parts to maintain supportability. A redesign changes the product itself, its function, form, or platform, and usually restarts design controls from inputs. A refresh stays narrow, scoped to what became obsolete, and aims to avoid the cost and regulatory weight of a new device.
Outdated software is a security liability. Section 524B of the FD&C Act expects cyber-device manufacturers to patch vulnerabilities and maintain support across the lifecycle, so refreshing an end-of-life operating system or library is frequently a security requirement as much as a supply one. Each software refresh usually means re-running affected verification and updating the software bill of materials.
Related terms
- Obsolescence Management
- Sustaining Engineering
- Design Change Control
- End of Life (EOL)
- Legacy Device
