When Device Software Support Ends: The Customer Transition Plan

When Device Software Reaches End of Support: The Core Decision and Definitions

Consider a standard scenario confronting medical device manufacturers today: A connected physiological monitor or diagnostic imaging console was deployed widely across hospital systems five years ago. Its underlying embedded operating system and software release will reach its manufacturer-designated end of support in approximately 18 months. Yet hospital capital cycles, asset depreciation schedules, and operational dependencies dictate that thousands of these physical units will remain in daily clinical service for another three to seven years. RA/QA and cybersecurity leadership must determine: What exact contents must the customer transition plan deliver, when must each milestone be communicated, and what documented evidence must substantiate every claim presented to hospital IT departments and regulatory authorities?

The foundational answer is straightforward but demanding: When medical device software approaches end of support while units remain in active service, the compliance work is not the announcement itself—it is the evidence behind the risk transfer. In regulated medical technology, a manufacturer cannot unilaterally extinguish safety and cybersecurity responsibilities by issuing a unilateral sunset letter. If a device continues to deliver patient care, unaddressed software vulnerabilities directly threaten clinical performance, diagnostic integrity, and patient safety.

To establish a defensible transition program, regulatory teams must first resolve the divergence between definitions established by the U.S. Food and Drug Administration (FDA) and international bodies such as the International Medical Device Regulators Forum (IMDRF):

• FDA Definition of End of Support: In its final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (issued February 3, 2026, superseding the June 2025 final guidance), FDA formally defines End of Support (EOS) as the point beyond which the product manufacturer ceases to provide support, which may include cybersecurity support, for a product or service. Crucially, FDA emphasizes that if a device remains in service following EOS, the manufacturer should have a pre-established and pre-communicated process for transferring the risks, and the guidance highlights that cybersecurity risks for end-users can be expected to increase over time. That process is a guidance recommendation, not a separate statutory deadline.

• IMDRF Total Product Life Cycle (TPLC) Stages: Under IMDRF/CYBER WG/N70FINAL:2023 (Principles and Practices for the Cybersecurity of Legacy Medical Devices), medical device lifecycles progress through four sequential stages: Development, Support, Limited Support, and End of Support. IMDRF defines End of Life (EOL) as the milestone where the manufacturer terminates commercial marketing and sales; EOL triggers entry into the Limited Support stage. Conversely, End of Support (EOS) occurs when the manufacturer terminates all service and maintenance activities, which marks the exact time point where primary responsibility for device cybersecurity transfers to the healthcare provider.

A frequent practitioner error is confusing FDA's definition of EOS with IMDRF's EOL milestone. While IMDRF treats EOL as the end of marketing and sales, FDA guidance focuses squarely on the cessation of cybersecurity and maintenance support. FDA conditions valid risk transfer on a stringent prerequisite: risk transfer should only occur when all relevant risk information is known, assessed, and appropriately communicated to users, including whether and how the user is actually capable of assuming that role. Under FDA's human factors expectations, tasks transferred to users—such as implementing compensating network controls or applying isolated firewall configurations—should be treated as tasks in usability testing so the manufacturer can show whether the intended users can perform them. FDA does not pre-judge that every hospital IT team can do so.

Three Evidence Classes: What Is Legally Required, What Is a Standard, and What Is Commercial

A defensible customer transition plan requires strict architectural segregation among three distinct categories of statements: statutory legal mandates, voluntary consensus standards and regulatory guidance recommendations, and discretionary commercial options. Conflating these categories compromises regulatory audits, alienates hospital procurement teams, and creates severe product liability exposure.

Class 1: Legally Required Mandates (Statute and Binding Regulation)

Class 1 encompasses non-negotiable statutory duties and enforceable regulations in major markets. Failure to substantiate these elements exposes the manufacturer to regulatory holds, warning letters, mandatory recalls, or civil penalties:

• FD&C Act Section 524B(b)(3) SBOM Requirements: For devices meeting the statutory definition of a cyber device under Section 524B of the U.S. Federal Food, Drug, and Cosmetic Act (FD&C Act), maintaining and providing a Software Bill of Materials (SBOM)—including commercial, open-source, and off-the-shelf components—is a federal statutory mandate. For deeper guidance on SBOM compilation, review our detailed guide on Medical Device Software Bill of Materials (SBOM).

• Labeling and Misbranding Provisions (FD&C Act §§ 502(f) & 502(j)): Sections 502(f) and 502(j) are the misbranding hooks FDA cites. The February 2026 guidance states that inadequate cybersecurity information in labeling may render a device misbranded. Omitting known or anticipated end-of-support and end-of-life information, or secure decommissioning instructions, is the exposure the guidance describes. It is not an automatic misbranding finding for every missing date.

• Quality Management System Requirements (FDA QMSR / 21 CFR Part 820 & ISO 13485:2016): With FDA's Quality Management System Regulation (QMSR, effective February 2, 2026) harmonizing 21 CFR Part 820 with ISO 13485:2016, design change controls (Clause 7.3.9), complaint handling (Clause 8.2.2), and Corrective and Preventive Action (CAPA, Clause 8.5.2) apply throughout the commercial and post-commercial lifecycle. Software changes made during the Limited Support phase remain regulated design changes requiring formal verification and validation.

• 21 CFR Part 806 Reporting and Analysis: Ending software support is not automatically a correction or removal. If an uncontrolled cybersecurity vulnerability could cause serious adverse health consequences, and the response is a correction or removal, 21 CFR Part 806 has to be analyzed. FDA routes that analysis to the 2016 Postmarket Management of Cybersecurity in Medical Devices guidance and its controlled-risk and uncontrolled-risk framework.

• EU MDR Post-Market Vigilance and Surveillance: Under the European Medical Device Regulation (Regulation (EU) 2017/745, MDR), manufacturers remain legally bound by Post-Market Surveillance (PMS) plans and systems (Articles 83 and 84), trend reporting (Article 88), and analysis of serious incidents and Field Safety Corrective Actions (FSCA, Article 89) for all devices that remain in clinical use, irrespective of internal commercial status.

Class 2: Voluntary Consensus Standards and Regulatory Guidance Recommendations

Class 2 comprises international consensus standards, IMDRF frameworks, and regulatory guidance documents that reflect state-of-the-art expectations ('what good looks like'). While non-binding unless formally codified into national law or binding customer contracts, deviations must be justified through risk management:

• IEC 62304 Software Maintenance Planning: Clause 6.1 of IEC 62304 requires manufacturers to establish and maintain a documented Software Maintenance Plan referencing feedback analysis, problem resolution, and modification procedures. The IEC 62304 Edition 2 change rationales (IEC SC62A N0166) add clause 5.1.14 so that software maintenance planning starts early in development. That rationale does not set end-of-support dates or require a specific obsolescence plan. IEC 62304 remains a voluntary standard unless a regulation, contract, or conformity assessment invokes it. For broader lifecycle alignment, see our analysis of IEC 62304 Software Lifecycle Management.

• IMDRF N70 Legacy Framework Recommendations: IMDRF N70 provides benchmark practice recommendations, such as issuing lifecycle milestone notices at least two years in advance and initiating responsibility transfer planning two to three years prior to EOS. While frequently treated by hospital procurement teams as industry standards, these timelines represent voluntary consensus practice rather than statutory filing deadlines.

• Standardized Security Disclosure Formats (MDS2 and JSP2): The Manufacturer Disclosure Statement for Medical Device Security (MDS2, ANSI/NEMA HN 1-2019) and the Joint Security Plan 2 (JSP2) customer security documentation provide structured mechanisms to convey technical capabilities, port requirements, and cryptographic configurations to healthcare delivery organizations (HDOs).

• FDA Guidance 'Should' Recommendations: In the February 2026 guidance, FDA recommends that SBOMs include component-level support statuses (actively maintained, no longer maintained, or abandoned) and specific component EOS dates. These recommendations guide agency review but are distinct from statutory provisions.

Class 3: Commercial Assumptions and Discretionary Service Offerings

Class 3 covers commercial and operational arrangements between manufacturers and purchasers. These include paid extended security maintenance agreements, proprietary monitoring services, hardware trade-in credits, and prioritized migration service-level agreements (SLAs). Manufacturers must never represent commercial options as regulatory requirements. Do not tell a hospital that buying a newer console or a paid service tier is what FDA or the EU MDR requires. Extended support, trade-in credits, and migration service levels are commercial choices.

The Configuration-to-Claim-to-Evidence Map

The central engineering artifact of an end-of-support program is the Configuration-to-Claim-to-Evidence Map. For every operational configuration deployed across customer networks, this matrix links the specific assertion made in customer communications or regulatory submissions directly to the verified technical evidence required to substantiate it:

Notice how every single claim maps directly to concrete engineering and quality records. If an auditor asks, 'On what basis did you assert that hospital IT can isolate this console without degrading telemetry data?', the manufacturer must present the usability test records and penetration testing logs referenced in Row 2, rather than subjective marketing assurances.

Staged Timeline: Transitioning From Limited Support to End of Support

Software end of support needs a multi-year runway so healthcare providers can budget, test compensating controls, and plan replacement. A short-notice letter does not meet FDA’s recommendation for a pre-established, pre-communicated risk-transfer process, or IMDRF’s recommendation for early active outreach.

IMDRF N70 and the HSCC HIC-MaLTS guide support a phased transfer of cybersecurity responsibility. The month markers below are an operational example built on IMDRF’s roughly two-to-three-year transfer start and at-least-two-year milestone notice. They are not FDA or EU legal deadlines.

1. T minus 24 to 36 Months — Responsibility Transfer Program Initiation: Establish the internal cross-functional transition team comprising Regulatory Affairs, Quality Assurance, Product Cybersecurity, Clinical Engineering Support, and Legal Counsel. Map all fielded software versions across active customer sites. Conduct preliminary usability evaluations to determine whether prospective customer-transferred security tasks are feasible for typical biomedical and IT personnel.

2. T minus 24 Months — Milestone Announcement & Customer Notification: IMDRF N70 describes current practice as communicating key lifecycle milestones, including cybersecurity end-of-life and end-of-support dates, at least two years in advance. IMDRF recommends active outreach. Posting dates on a website without notifying customers is not the recommended practice. Certified bulletins and portal notices are examples of active communication, not a legally prescribed form.

3. Illustrative midpoint — Entry into Limited Support when sales stop: When the manufacturer stops selling the product and completes its end-of-life notice, IMDRF’s model moves the device into Limited Support. Publish an updated public support-status webpage accessible to primary purchasers, second-hand equipment brokers, and Independent Service Organizations (ISOs). Distribute device-specific compensating-control advisories, detailed network hardening requirements (ports, IP filtering, protocol restrictions), and updated machine-readable SBOMs.

4. Illustrative final window — Upgrade and decommissioning guidance: Deliver formal transition documentation packets to all active accounts. Outline available migration pathways (software upgrades, partial modular retrofits, or full device replacement) alongside validated NIST SP 800-88 Rev. 1 media sanitization and decommissioning instructions.

5. T Zero — End of Support Milestone Handover: Primary responsibility for ongoing cybersecurity posture transfers to the healthcare facility. Publish the permanent public EOS notice. Archive baseline engineering records while maintaining active surveillance pipelines for adverse event and incident tracking.

A critical technical challenge during the Limited Support phase involves component-level obsolescence. The diagram below is an operational reading of IMDRF N70 when an open-source or commercial third-party component reaches EOS while the medical device remains supported. It is not an official IMDRF figure:

flowchart TD
    A["Third-Party Component (SOUP/OS) Reaches EOS"] --> B["Perform Comprehensive Security Risk Assessment"]
    B --> C{"Impact on Clinical Function or Patient Safety?"}
    C -- "No Safety Impact" --> D["Document in Risk Management File (RMF)<br/>Maintain Baseline Controls"]
    C -- "Safety / Clinical Impact" --> E{"Can Manufacturer Deploy Validated Update / Patch?"}
    E -- "Yes: Feasible" --> F["Execute Regulated Design Change (QMSR/ISO 13485)<br/>Deploy Validated Security Patch"]
    E -- "No: Unsupported Dependency" --> G{"Can Device Be Reasonably Protected with Compensating Controls?"}
    G -- "Yes: Controls Feasible" --> H["Transition Device to Limited Support<br/>Publish Compensating Control Advisory & Network Rules"]
    G -- "No: Cannot Protect" --> I["Accelerate Transition to End of Support (EOS)<br/>Issue Public Notice & Safety Corrective Action Analysis"]

What Every Customer Communication Artifact Must Contain

When drafting customer communication packages, regulatory and product security teams must replace vague marketing notices with precise, actionable technical disclosures. Regulators and hospital security operations centers (SOCs) evaluate whether customer packets provide concrete engineering utility.

A complete customer packet should be able to show the elements below. Cyber-device SBOM content and accurate labeling are legal duties where they apply. Support-level fields, MDS2, network rules, and the IMDRF communication items are recommendations unless a contract or conformity assessment makes them mandatory:

• Exact Device Identification & Configuration Bounds: Specify exact Unique Device Identification Device Identifiers (UDI-DI), commercial model names, affected catalog numbers, hardware revisions, and specific firmware/software release version numbers. Define clearly which configuration combinations are governed by the notice.

• Definitive Lifecycle Milestone Dates: State the exact calendar dates for: Commercial EOL (cessation of sales), start of Limited Support, and formal EOS. Eliminate ambiguous terms such as 'sunset in late 2027' in favor of precise calendar milestones.

• Scope and Limitations of Remaining Support: Clearly define what maintenance activities the manufacturer will and will not perform during Limited Support and post-EOS. For example, explain whether critical vulnerability patches will be developed, whether customer support call centers will answer technical inquiries, and how spare hardware parts availability relates to software support.

• Machine-Readable SBOM with Component Lifecycle Metadata: Provide an updated, machine-readable Software Bill of Materials (in SPDX or CycloneDX format) compliant with FD&C Act § 524B(b)(3). In accordance with FDA's February 2026 guidance recommendations, include for each software component its active support level (e.g., actively maintained, no longer maintained, abandoned) and its anticipated component EOS date.

• Updated Security Disclosure Documents (MDS2 and JSP2): Provide a current Manufacturer Disclosure Statement for Medical Device Security (MDS2). Ensure sections governing anti-malware capability, remote access controls, audit logging, and data backup are updated to reflect the frozen software configuration.

• Actionable Compensating Controls & Network Hardening Rules: Deliver exact network specifications so hospital network engineers can configure firewall access control lists (ACLs). Detail all required inbound and outbound TCP/UDP port numbers, protocol bindings, internal IP ranges, recommended VLAN segmentation parameters, and instructions for terminating deprecated remote-service connections.

• Explicit Migration and Upgrade Pathways: Detail viable clinical pathways to maintain uninterrupted service: (1) a software-only upgrade path to a fully supported release, (2) partial hardware-plus-software modular upgrade options, or (3) complete platform replacement models.

• Sanitization and Decommissioning Protocols: Provide explicit, step-by-step technical procedures for secure decommissioning. Incorporate clear directions for sanitizing, purging, or destroying sensitive electronic protected health information (ePHI), proprietary algorithms, network credentials, and digital certificates using methods consistent with NIST SP 800-88 Rev. 1 (Guidelines for Media Sanitization). That guideline is a voluntary sanitization method, not a device-manufacturer HIPAA duty.

Evidence Duties That Survive the End-of-Support Date

A dangerous misconception within medical device commercial organizations is the belief that once the EOS date passes, the manufacturer's regulatory obligations cease. Under both U.S. FDA and European Union legal frameworks, statutory postmarket duties survive the EOS date as long as devices remain deployed in clinical environments. Reaching the EOS milestone shifts how support is delivered, but it does not extinguish the legal responsibility to monitor and mitigate patient risks.

Specifically, manufacturers must maintain continuous quality and regulatory operations across four enduring domains:

1. Complaint Handling and Servicing Analysis (QMSR: ISO 13485 Clause 8.2.2 and 21 CFR 820.35): Manufacturers must continue receiving, reviewing, and evaluating complaints involving unsupported devices. If a hospital reports that an unsupported infusion pump or ventilator malfunctioned due to a software crash, the manufacturer must log the complaint, initiate an investigation to determine root cause, and evaluate whether the failure represents a broader systemic hazard.

2. Mandatory Adverse Event Reporting (21 CFR Part 803 & MDR Article 87): Medical Device Reporting (MDR) obligations remain in full legal force. If an unpatched software vulnerability or cyber incident on an EOS device contributes to a death, serious injury, or a reportable malfunction that would likely cause serious injury upon recurrence, a mandatory MDR report must be submitted to FDA within 30 days (or 5-day / 10-day emergency timelines where applicable). In the EU, serious incident reporting under MDR Article 87 applies with equal vigor.

3. Corrections, Removals, and Recalls (21 CFR Part 806 & MDR Article 89): If an unpatched flaw on an EOS device presents an unreasonable risk of substantial harm to public health, FDA retains statutory authority to mandate safety alerts or product recalls. Manufacturers cannot decline to take corrective action on the grounds that 'the device software was sunset last year.' In Europe, Field Safety Corrective Actions (FSCAs) and Field Safety Notices (FSNs) must be executed under Article 89 regardless of commercial support status.

4. Reactive Vulnerability Management and ISAO Participation: FDA's Postmarket Management of Cybersecurity in Medical Devices guidance (issued December 28, 2016, operating alongside the QMSR) provides the authoritative framework for evaluating postmarket vulnerabilities. The guidance establishes a clear dichotomy:

FDA's Postmarket Cybersecurity Guidance differentiates between controlled risk and uncontrolled risk:

• Controlled Risk (Acceptable Residual Risk): When an assessment confirms that the residual risk of patient harm remains sufficiently low due to existing compensating controls and risk mitigations, routine cybersecurity updates, patches, and hardening steps are classified as device enhancements. These routine updates do not require notification or reporting under 21 CFR Part 806.

• Uncontrolled Risk (Unacceptable Residual Risk): When a vulnerability presents an unacceptable residual risk of patient harm, remediating the vulnerability is considered a correction. However, FDA exercises regulatory enforcement discretion regarding Part 806 reporting if the manufacturer meets four strict conditions: (1) no known serious adverse events or deaths have occurred; (2) within 30 calendar days of learning of the vulnerability, the manufacturer communicates with customers and user communities, providing interim compensating controls and a documented remediation plan; (3) within 60 calendar days, the manufacturer develops, validates, and distributes a fix; and (4) the manufacturer actively participates in a recognized Information Sharing and Analysis Organization (ISAO), such as Health-ISAC.

For devices past EOS, developing a validated software fix within 60 days may be technically impossible if underlying toolchains and compilers are deprecated. Interim compensating controls belong in the 30-day customer communication. They do not replace the 60-day validated fix or workaround, and they do not by themselves meet FDA's enforcement-discretion conditions. If a validated fix or workaround that brings residual risk to an acceptable level cannot be distributed within 60 days, the Part 806 reporting analysis still has to be completed. Useful containment steps include verified interim controls (such as network disconnection, port filtering, or physical access restrictions), communicated with a clear statement of what risk remains.

The EU Regulatory Boundary: MDR Article 10a vs. Software EOS on Fielded Devices

In the European Union, navigating end of support requires careful demarcation between product supply interruptions and software lifecycle maintenance. A frequent compliance failure among global regulatory teams is confusing the notification duties under Regulation (EU) 2024/1860 with standard postmarket cybersecurity governance.

The Purpose and Scope of MDR Article 10a

Introduced by Regulation (EU) 2024/1860 and applying across EU Member States since January 10, 2025, Article 10a amends both the EU Medical Device Regulation (Regulation (EU) 2017/745, MDR) and In Vitro Diagnostic Medical Device Regulation (Regulation (EU) 2017/746, IVDR). Under Article 10a, manufacturers must notify their relevant competent authority and directly supplied economic operators, health institutions, and healthcare professionals at least six months in advance of an anticipated interruption or discontinuation of device supply.

However, Article 10a is governed by a precise statutory threshold: it applies only where the interruption or discontinuation of supply could foreseeably result in serious harm or a risk of serious harm to patients or public health in one or more Member States. The European Commission's Q&A guidance on Article 10a clarifies that this provision is designed to prevent clinical device shortages—such as the sudden market withdrawal of critical dialysis consumables, specialized cardiac catheters, or essential pediatric implants. For comprehensive coverage of supply discontinuation rules, consult our guide to EU MDR Article 10a Supply Discontinuation and Shortage Prevention.

Software EOS vs. Supply Discontinuation: Drawing the Regulatory Line

Medical device software end of support intersects with European law along two distinct regulatory pathways:

• Pathway A: Discontinuing Supply of the Device Model (Article 10a Trigger): If an end-of-support decision coincides with the complete commercial withdrawal and discontinuation of shipments of a physical medical device or standalone Software as a Medical Device (SaMD) product, and alternative substitute devices are unavailable in the clinical market, Article 10a is directly triggered. The manufacturer must lodge the formal Article 10a notification at least six months prior to halting supply, providing clinical rationales and downstream shortage mitigations.

• Pathway B: Ceasing Software Updates for Installed Fielded Units (MDR PMS / Vigilance Route): When a manufacturer ceases software updates for a device model while physical units remain operational in European hospitals, Article 10a does not directly govern the software support termination. Instead, the event is governed by standard MDR Post-Market Surveillance (Articles 83 and 84), Trend Reporting (Article 88), and Vigilance / FSCA procedures (Article 89). Guidance document MDCG 2019-16 Rev.1 (Guidance on Cybersecurity for Medical Devices) advises manufacturers to avoid the use of end-of-life third-party components in operating environments and to mandate additional protective measures, such as network isolation, where unsupported components cannot be avoided. Manufacturers must recognize that MDCG guidance is legally non-binding and currently subject to revision pressure to align with the EU Cyber Resilience Act (CRA).

Publishing Support Dates for Procurement and Fleet Governance

A transition plan achieves regulatory and clinical value only if its parameters are easily ingested and operationalized by hospital clinical engineering and IT departments. In real-world hospital environments, capital constraints prevent immediate replacement of aging technology.

Empirical evidence underscores this operational reality. In RunSafe Security's 2026 Medical Device Cybersecurity Index (a survey of 551 healthcare technology and procurement professionals across the United States, United Kingdom, and Germany), 28 percent of healthcare organizations report operating medical devices past the manufacturer's formal end-of-support date, and 44 percent acknowledge running end-of-support devices with known, unpatched vulnerabilities. Treat those figures as demand context only: unsupported fielded devices persist, so the transition plan has to say how those configurations are handled. Attack-rate findings from the same survey belong to the procurement-gate discussion and are not reused here.

To empower hospital asset management platforms and Computerized Maintenance Management Systems (CMMS) to govern legacy inventory, manufacturers should adopt machine-readable disclosure standards:

• Continuous Machine-Readable SBOM Feeds: FDA recommends making SBOM information available to users on a continuous basis, in a machine-readable form such as SPDX or CycloneDX. The February 2026 guidance does not prescribe SPDX 3.0, CycloneDX 1.6, or a particular portal. Include per-component support levels (actively maintained, no longer maintained, abandoned) and component EOS dates as recommended by FDA's February 2026 guidance.

• OpenEoX Lifecycle Information Exchange: An emerging international initiative backed by OASIS Open, OpenEoX standardizes the exchange of end-of-life and end-of-support data in an automated, machine-readable format. OpenEoX structures lifecycle milestones so that hospital vulnerability scanners, procurement systems, and CSAF/VEX (Common Security Advisory Framework / Vulnerability Exploitability eXchange) processors can automatically flag aging devices approaching support boundaries.

• Permanent Public Support-Status Portals: IMDRF N70 recommends a permanent public support-status resource, updated when the lifecycle stage changes, so resellers and later buyers can see whether a model is still supported. This portal ensures that secondary-market buyers, refurbishers, and independent service providers can verify lifecycle boundaries and access decommissioning guidance.

• Alignment with Federal Procurement Signals (CISA BOD 26-02): Buyer-side scrutiny over end-of-support technology is accelerating rapidly. The Cybersecurity and Infrastructure Security Agency's (CISA) Binding Operational Directive (BOD) 26-02 (issued February 5, 2026) mandates that federal civilian agencies inventory, isolate, and replace end-of-support edge devices within strict timeframes. BOD 26-02 is legally binding only on U.S. federal civilian executive branch agencies, and it covers network edge devices rather than medical devices. It is a buyer-side signal that lifecycle management is being formalized. It does not impose those deadlines on device manufacturers or on hospitals.

For a deeper analysis of how institutional buyers evaluate cybersecurity during RFP and procurement phases, see our dedicated report on Medical Device Cybersecurity Procurement Gates. For practical strategies on managing legacy fleets from the healthcare provider side, review our companion guide on Managing End-of-Service Ultrasound Fleet Risks.

In summary, building an end-of-support customer transition plan is a fundamental design control and risk management discipline. By anchoring every customer assertion in verified engineering records, structuring clear multi-year communication milestones, and maintaining enduring postmarket surveillance, manufacturers protect patient safety, preserve customer trust, and keep a postmarket record that customers and regulators can check.