Software and Cybersecurity Updates: When Servicing Becomes Remanufacturing

Clinical engineering departments, Healthcare Technology Management (HTM) teams, and independent service organizations (ISOs) face an ongoing stream of software updates, operating system patches, security remediations, and configuration requests. As connected medical devices become ubiquitous across clinical fleets, the operational boundary between routine equipment servicing and federal remanufacturing is tested whenever code or configuration files are touched. The legal definition of remanufacturer lives in 21 CFR 820.3. The Food and Drug Administration's (FDA) May 2024 remanufacturing guidance is current Agency thinking on how to classify activities; it does not establish rights and is not binding on FDA or the public. Classify the activity before any installer is run, boot medium is inserted, or network push is executed.

Under current 21 CFR 820.3—governed by the Quality Management System Regulation (QMSR) that took effect on February 2, 2026, harmonizing FDA requirements with ISO 13485:2016—a remanufacturer is defined as any person who processes, conditions, renovates, repackages, restores, or does any other act to a finished device that significantly changes the finished device's performance or safety specifications, or intended use. The regulation explicitly establishes that the term manufacturer encompasses remanufacturing. Conversely, FDA's final guidance Remanufacturing of Medical Devices (issued May 10, 2024) defines service as the repair and/or preventive or routine maintenance of one or more parts in a finished device, after distribution, for purposes of returning it to the safety and performance specifications established by the original equipment manufacturer (OEM) and to meet its original intended use. Servicing expressly excludes any activity that significantly changes those performance specifications, safety parameters, or intended clinical use.

FDA focuses on the objective activity performed on the finished device, not whether an organization self-identifies as an in-house biomedical department, an independent ISO, or an OEM field contractor. When the activity significantly changes the finished device's performance or safety specifications, or intended use, the entity meets the 21 CFR 820.3 remanufacturer definition and is a manufacturer of that finished device for FDA purposes.

This guide provides biomedical equipment technicians, service managers, and clinical engineering leaders with an actionable decision framework for evaluating software and firmware activities against Section VII of the May 2024 guidance. It establishes clear criteria for distinguishing authorized servicing from regulated remanufacturing, details the three public software examples in Appendix A, unpacks the intersection with manufacturer 510(k) and Section 524B duties, and defines the audit-ready documentation and Centers for Medicare & Medicaid Services (CMS) inspect-and-test gates required before releasing updated devices back to clinical service.

When service teams evaluate physical replacement parts—such as valves, power supplies, motors, or structural enclosures—they apply the risk-based decision logic set forth in Section VI of the May 2024 remanufacturing guidance. In our companion analysis, Replacement Parts After Repair: Compatibility Evidence and Remanufacturing Risk, we examine FDA Figure 1, the Section VI flowchart for components, parts, and materials. That hardware path is a different reader job from software classification.

However, when dealing with software, firmware, or digital configuration files, Figure 1 must not be applied. Section VI states that Figure 1 and its accompanying text should not be applied to software because of the nature of software and the methods used to evaluate software changes. Section VII repeats that the Section VI risk-based assessment should not be applied to software changes, because the probability of a software failure cannot be determined using traditional statistical methods.

Section VII states that many software changes are likely remanufacturing because of their impact on a product's software architecture, software requirements specifications, unresolved anomalies, and other key characteristics. Software activities therefore follow Section VII, not Figure 1.

While Figure 1 is inapplicable to code, Section VII anchors its classification framework to three core regulatory principles established in the broader guidance (and analyzed in our foundational guide, Medical Device Servicing vs Remanufacturing: How to Draw and Document the Boundary):

• Intended Use Preservation: Any software change that significantly modifies intended use would be remanufacturing.

• Documented Rationale for Unlisted Changes: If an entity undertakes a software change that is not on the Section VII likely-not-remanufacturing list, but believes the activity does not significantly change the finished device's performance or safety specifications, it should adequately document that determination consistent with Guiding Principles 5 and 6. Documentation of an unlisted change is not the same as being on the public list.

• Cumulative Effects Evaluation: Guiding Principle 2, which Section VII does not repeal for cumulative-effect documentation, treats change as including enhancement and calls for evaluation of each activity and of cumulative effects. Multiple software changes that look minor in isolation can still significantly change performance or safety specifications when taken together.

Do not invent a second software flowchart. FDA Figure 1 is the hardware aid; Section VII is a public activity list plus documentation, not a software version of Figure 1. If the planned activity is on the list and meets the listed conditions—documented OEM authorization when the list requires it, connectivity consistent with OEM intended use, assessment rather than unofficial remediation code—it is likely not remanufacturing. Other software changes that significantly change performance or safety specifications are likely remanufacturing. If the entity still believes an unlisted change does not significantly change those specifications, it should document that determination before installing; the record does not convert the activity into a listed servicing item. Any software change that significantly modifies intended use would be remanufacturing. Then close the documentation and CMS inspect-and-test gates below.

Section VII of the May 2024 guidance lists software activities that FDA considers likely not remanufacturing. Those activities generally do not significantly change the legally marketed device's performance or safety specifications. The 10 September 2024 CDRH webinar restates the same list under "Software Activities that are likely not Remanufacturing." The list is not a statutory safe harbor, and it is not exhaustive.

While Section VII provides substantial latitude for daily maintenance, biomedical teams must recognize the strict operational boundaries attached to these items. Four specific conditions require rigorous clinical engineering governance:

• Documented OEM Authorization: OEM authorization is documented authorization to return or maintain the legally marketed device's specifications and intended use, not a verbal claim that a third-party image is 'the same build.' Keep the bulletin, portal receipt, contract clause, or other written authorization in the service file. Do not treat a forum post or a matching version string as authorization.

• Malware Assessment Versus Custom Remediation: Item 4 authorizes assessing for viruses, malware, and other cybersecurity-related issues. It does not authorize writing or installing a non-OEM remediation payload. Assessing for malware is on the list; unofficial code changes are not. If no OEM-authorized update or restore is available, keep the device off the affected network until an authorized update can be implemented. This article does not provide isolation architecture or access-bypass steps.

• Connectivity Features and Intended Use: Item 8 permits turning on or off connectivity features (such as Wi-Fi or Bluetooth) only consistent with OEM intended use. Turning a labeled OEM radio on or off according to OEM intended use is the listed activity. Adding a connection the legally marketed device was not intended to use is not on the list and should be evaluated as an unlisted software change; it is likely remanufacturing if it significantly changes performance or safety specifications or intended use.

• Cybersecurity Regulatory Evolution: Footnote 45 of the May 2024 guidance notes that the cybersecurity landscape rapidly evolves and points readers to FDA's cybersecurity page for updates on statutory and regulatory requirements. Assessing malware or installing an OEM-authorized cybersecurity update still has to stay inside the listed activity and the legally marketed device's specifications and intended use.

Other activities involving changes to software are likely to significantly change a device's performance or safety specifications, such that the activity is likely remanufacturing. Section VII notes the impact of many software changes on software architecture, software requirements specifications, unresolved anomalies, and other key characteristics. FDA considers such unlisted activity likely remanufacturing. If an entity believes an unlisted software change does not significantly change those specifications, it should adequately document its decision-making, pointing to Guiding Principles 5 and 6. Appendix A of the May 2024 guidance provides three public software examples (S.1, S.2, and S.3).

Appendix A states that these software examples are generalized and should not be taken as definitive for every device; real-world decisions depend on the specific facts. The three public rows still set useful comparison points:

• The S.1 Benchmark (Authorized Maintenance): Example S.1 is an OEM-authorized patch on a specular microscope intended to maintain original specifications. FDA's decision in that example is not remanufacturing.

• The S.2 Benchmark (Expanded Remote Control): Example S.2 starts from a device that already allows real-time remote customer service to view current status, then adds the ability for a technician to manipulate the device, including changing settings, resetting it, delivering energy, and positioning it. FDA's analysis in that example is that the new remote-control functionality introduces new risks and significantly changes performance and safety specifications. Decision: remanufacturing. Do not treat every remote-viewing feature as remanufacturing, and do not treat S.2 as a how-to for adding remote control.

• The S.3 Benchmark (Operating System Swaps): Example S.3 is a networked device designed to run Microsoft Windows that is altered to run a Linux OS. FDA describes that change as a redesign, including device-driver integration and OS-specific features, that introduces new risks and may impact mitigations for existing risks. Decision: remanufacturing. Do not treat S.3 as permission or as a procedure for an OS swap.

During the September 10, 2024 CDRH webinar, Agency officials addressed whether upgrading an older distributed unit in the field to match a newer, 510(k)-cleared model's hardware and software revision is servicing. The Agency answered: “it depends.” An entity cannot assume that because the OEM later cleared a hardware-and-software version, an independent shop may upgrade already-distributed product to match. The webinar answer does not create a second flowchart; situations outside the Section VII list are assessed with the guiding principles and the facts of the change.

A frequent point of confusion in hospital technology management stems from conflating three distinct regulatory frameworks: the servicing-versus-remanufacturing boundary, manufacturer 510(k) software-change evaluation, and postmarket cybersecurity patch obligations under Section 524B of the FD&C Act. Technicians and clinical leaders must understand that these frameworks apply to different entities, govern different life-cycle stages, and carry completely different legal meanings.

Biomedical engineers must never use manufacturer 510(k) policies to justify unauthorized servicing. Under FDA's October 25, 2017 software-change guidance, Flowchart Question 1 asks whether a software change is “made solely to strengthen cybersecurity and does not have any other impact on the software or device.” In many cases, FDA does not require a manufacturer to submit a new 510(k) for routine security patches. However, this policy is an administrative flexibility granted to the manufacturer—who maintains the design history file, source code, and full verification/validation test suites. It is not a license for a hospital or ISO to write, compile, or inject custom patches into a medical device.

Similarly, 21 CFR 807.81(b)(1)(ii) provides an exception from 510(k) filing for software changes made pursuant to a Predetermined Change Control Plan (PCCP) cleared under Section 515C of the FD&C Act. A PCCP is an exclusive regulatory instrument established between the device manufacturer and FDA. Third-party service organizations cannot invoke an OEM's PCCP to authorize third-party code modifications.

Section 524B of the FD&C Act is a sponsor duty for enumerated premarket submissions for a cyber device, not a hospital HTM classification test. Section 524B(b)(2) requires those sponsors to make available postmarket updates and patches on a reasonably justified regular cycle for known unacceptable vulnerabilities and as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risks. FDA's 3 February 2026 premarket cybersecurity guidance, which supersedes the 27 June 2025 final of the same title, recommends labeling for devices with cybersecurity risk that can include, as examples:

• Authorized Download Instructions: A description of systematic procedures for users to download version-identifiable manufacturer-authorized software and firmware, and how users will know when software is available.

• Secure Deployment Guidance: Instructions for secure network deployment and servicing, as listed among the 3 February 2026 labeling examples.

• Software Bill of Materials (SBOM): SBOM information in a machine-readable format, as recommended in the 3 February 2026 labeling examples.

• Backup and Restore Specifications: Backup and restore of authenticated configurations, as listed among the 3 February 2026 labeling examples.

Hospital HTM departments can use those labeling items as the public place to look for the manufacturer-authorized update path. They do not convert section 524B into a hospital obligation or a license to write a patch.

Executing a compliant software update requires closing two mandatory operational gates before releasing the medical device back to clinical use: establishing an audit-ready Section VI.B determination record, and satisfying CMS post-service inspect-and-test requirements.

Section VII of the May 2024 guidance explicitly directs service entities back to Guiding Principle 6 and Section VI.B for software documentation standards. Whenever a software activity is performed, the service record must capture sufficient technical evidence to enable an FDA investigator, accreditation surveyor, or third-party auditor to understand the classification conclusion. The service file must contain:

1. Product name: Product name, including model number and serial number if applicable.

2. Dates: Date of activities performed, assessment, and determination.

3. Device description: Description of the device.

4. Activities performed: Description of activities to be performed, including documentation of components, parts, or materials involved. For software, record version, source, and authorization identity.

5. Remanufacturing determination: Determination of whether the activity is remanufacturing, using Section VII rather than Figure 1.

6. Supporting documents: Reference to related documents supporting the decision-making process.

7. Signatures: Signature(s).

Those are the Section VI.B recommended minimum fields, which Section VII points back to for software. Additional CMMS fields such as an asset number can help operations; they are not a substitute for the guidance fields. If an identical activity was previously determined not to be remanufacturing, is being performed by the same entity, and is on the same version or model, the documentation may reference the previous determination.

If the classification determination concludes that a proposed software change is remanufacturing, do not perform it as routine servicing. Under FDA Compliance Program 7382.850 (Inspection of Medical Device Manufacturers), independent service organizations performing legitimate third-party servicing are not subject to the QMSR. However, any entity that undertakes remanufacturing becomes a manufacturer under 21 CFR 820.3(a). As an established remanufacturer, the entity becomes legally subject to:

• Quality Management System Regulation compliance under 21 CFR part 820 / ISO 13485:2016 (including design controls and software validation).

• Medical Device Reporting (MDR) under 21 CFR part 803 for adverse events.

• Reports of Corrections and Removals under 21 CFR part 806.

• Annual Establishment Registration and Medical Device Listing under 21 CFR part 807, independent of the OEM's listing.

• Unique Device Identification (UDI) labeling and GUDID submission under 21 CFR parts 801 and 830.

• Applicable premarket submissions (510(k), De Novo, or PMA) before conducting remanufacturing activities on the OEM's legally marketed finished device, where the device class requires marketing authorization.

Even when a software activity is properly classified as servicing, hospital clinical engineering departments remain subject to a parallel CMS inspect-and-test gate before return to service.

Under the Medicare Conditions of Participation (42 CFR 482.41(d)(2)), hospital facilities, supplies, and equipment must be maintained to ensure an acceptable level of safety and quality. Historical CMS survey guidance in S&C 14-07 (December 20, 2013) established that “all equipment must be inspected and tested for performance and safety before initial use and after major repairs or upgrades.” In the current survey interpretive guidance under QSO-25-24 Tag A-0724 (originally released September 5, 2025), CMS instructs surveyors that equipment “should be inspected and tested for performance and safety before initial use and after major repairs or upgrades,” while maintaining the strict mandate that equipment must be inspected, tested, and maintained to ensure its safety, availability, and reliability.

Use OEM labeling acceptance criteria and the manufacturer-authorized update instructions as the source of limits; this article does not invent numeric software pass/fail values. In our accompanying operational standard, Medical Equipment Service Records: What a Work Order Must Contain, we detail the mandatory fields required to defend clinical work orders during Joint Commission and CMS surveys.

Finally, once an OEM-authorized software restore or update is completed, service teams must accurately capture the resulting configuration state in the CMMS. As analyzed in MedDeviceGuide: Recording Configuration After a Software Restore, technicians must maintain strict distinction between the physical chassis serial number, the UDI-DI/PI structure, and the newly restored software build version. Conflating hardware identity with software revisions undermines clinical traceability during subsequent field safety notices and recall responses (detailed in Medical Device Recall Response for HTM: Corrections, Removals, and Close-Out).

By adhering strictly to Section VII classification, avoiding the inapplicable hardware flowchart, maintaining audit-ready Section VI.B records, and completing rigorous CMS post-service testing, clinical engineering departments can confidently maintain device cybersecurity and software integrity while remaining firmly within the boundaries of safe, compliant medical device servicing.