Key considerations: How to build compliant software update practices for medical devices

For medical device OEMs, regulatory compliance is a set of concrete technical requirements impacting every software lifecycle activity, cybersecurity control, and process in the development pipeline. The gap between understanding regulations and implementing compliant practices is where most manufacturers encounter friction, delays, risk, and exposure – including those from the US Food and Drug Administration (FDA) and the EU Medical Device Regulation (MDR).

Whether updating therapeutic logic in an implantable neurostimulator, expanding remote monitoring capabilities for a peritoneal dialysis system, or integrating third-party data into a wearable hydration patch, every software modification carries regulatory implications. Both the FDA and the MDR frameworks set expectations around software lifecycle management, risk control, and documentation; while neither explicitly mandates IEC 62304 by name, it is difficult to meet the frameworks’ expectations without aligning to it in practice. For most OEMs, IEC 62304 compliance isn't a choice so much as the most direct path to demonstrating that your software development processes are fit for purpose. OEMs must understand how IEC 62304 maps to their processes, how cybersecurity controls integrate across the device’s lifecycle, and how to build a system that supports continuous safety, security, and compliance rather than periodic audit preparation.

IEC 62304: Mapping software lifecycle activities

IEC 62304 defines the software lifecycle processes that medical device manufacturers must follow. Each clause translates directly into engineering activities that teams must execute and document with every software update. Understanding how the software lifecycle maps to IEC 62304 is essential for building processes that comply with both FDA and MDR regulations.

Under IEC 62304 clauses 5.1 through 5.3, the process begins with requirements and risk assessment. Every software update must start with formally documented system requirements and a corresponding risk assessment. Whether the update involves a new prediction algorithm, expanded connectivity, or modified alert logic, the engineering team must capture new or changed requirements in a requirements management platform and trace them to actionable development tasks. IEC 62304 ties software risk management to ISO 14971, the overarching standard for medical device risk management. The two standards are designed to work in tandem, with ISO 14971 providing the broader risk management framework that software-specific activities under IEC 62304 must feed into and remain consistent. Risk assessments conducted in accordance with ISO 14971 must be updated to reflect any changes in the device's risk profile, and the traceability between requirements, risks, and implementation must be bidirectional.

Software architecture documentation, addressed by IEC 62304 clause 5.4, must be updated to reflect the specific changes introduced by each update. Regardless of whether the update is significant, like modifying therapeutic logic, or minor, such as altering the user interface, the architectural documentation must capture these changes. The software architecture documentation should reside in a centralized knowledge management system accessible to all relevant stakeholders, including regulatory affairs and quality assurance teams.

Verification and validation activities, governed by clauses 5.5 and 5.6, require updated integration and system-level testing for each software change. Test cases must cover both simulated and real-world conditions relevant to the device's clinical context. For example, testing a neurostimulator includes tests against actual and simulated electrocorticography (ECoG) data streams. For a remote monitoring system, tests should validate alert logic with both simulated and real clinical events. Or for a wearable device integrating third-party data, test cases must account for edge scenarios, such as incomplete data synchronization and device sync failures. All verification evidence must be documented and traced back to the originating requirements.

Version control and release management (IEC 62304 clauses 7.4 and 8) require that all code changes be maintained under version control with signed commits, tested builds, and release tags. Every build that moves toward deployment must be validated and cryptographically signed, ensuring the integrity and authenticity of the software from development through delivery. While a general best practice, cryptographical signing and verification is also a regulatory mandate under both the FDA design control requirements (21 CFR Part 820) and the MDR technical documentation standards.

Finally, IEC 62340 clause 9 addresses problem resolution and maintenance. When a software update deprecates legacy functionality, such as replacing an older algorithm with a new one, the rationale for deprecation must be formally documented and reviewed. Problem resolution records must capture what was changed, why it was changed, and what risk controls are in place for the transition.

Integrating cybersecurity across the lifecycle

Cybersecurity is no longer a standalone initiative in medical device development. Under the FDA Premarket Cybersecurity Guidance and MDR General Safety and Performance Requirements (GSPR), cybersecurity controls must be integrated directly into the software update process and documented in the Software Update File (SUF).

Secure data transmission is the foundation. Every device that communicates therapy data, patient information, or telemetry to external systems must implement the latest Transport Layer Security (TLS) protocols. For devices that interact with cloud platforms, clinician dashboards, or companion mobile applications, mutual authentication is also required, verifying the identities of both device and receiving system before exchanging data.

System hardening and isolation must extend to the software update itself. When an update modifies safety-critical components such as therapeutic algorithms or alert logic engines, memory protections and sandboxing techniques should isolate the updated components from the rest of the system. Hardening and isolation limit the potential impact of any defect or exploit introduced through the update.

The update delivery mechanism itself must be secure. Over-the-air (OTA) updates for medical devices require cryptographic signing to verify that the update originates from an authorized source and has not been tampered with in transit. Cryptographic signing and verification applies whether the update is delivered to a clinician's programming system, a patient-facing mobile application, or the device itself.

Threat modeling must evolve with each software update. New features introduce new attack surfaces, and threat models must be updated accordingly. For example, an update that introduces Bluetooth Low Energy (BLE) connectivity to a neurostimulator creates new vectors for data interception that must be assessed. A wearable patch that begins ingesting third-party sleep data introduces risks of API hijacking, stale data injection, and mobile application spoofing. A remote monitoring system that adds alert functionality must address the risk of alert flooding and man-in-the-middle (MITM) attacks. Each new threat vector must be identified, assessed, and mitigated as part of the software update lifecycle.

For devices that integrate third-party data, additional controls are necessary. Granular application-level permissions must govern access to external data sources, with each user authorization logged and access revocable. Data integrity checks must verify the validity of imported data before it influences clinical outputs. Privacy risk mitigation, including anonymization and segregated storage of imported data, must be implemented to protect patient information.

All cybersecurity measures must align with the FDA Premarket Cybersecurity Guidance and MDR GSPR 17.4. Including the documentation of these measures in the SUF ensures that the cybersecurity posture of the device is transparent to regulators and supports both premarket submissions and post-market surveillance activities.

Post-market obligations shape engineering workflows

Cybersecurity integration does not end at deployment. Both the FDA and MDR impose post-market obligations directly influencing how engineering teams design and maintain their software infrastructure.

Post-Market Surveillance (PMS) plans must incorporate metrics generated by the device's software and connectivity features. For a remote monitoring system, this includes tracking false-positive and false-negative alert rates alongside real-world performance data from clinical deployments. Under the MDR, device findings feed into Periodic Safety Update Reports (PSURs) aligned with Article 86. Under the FDA, PMS documentation must conform to 21 CFR 820.100 and 820.198.

Clinical evaluation and Post-Market Clinical Follow-up (PMCF) reports must assess the usability, reliability, and safety of any new software functionality. These reports are referenced in FDA submissions such as 510(k) or Premarket Approval (PMA) filings, and the traceability between clinical evaluation data and the corresponding software update must be maintained.

Labeling and Instructions for Use (IFU) must also be updated to reflect new functionality introduced by the update, including remote access procedures, alert protocols, and troubleshooting guidance. IFU updates are a compliance requirement under MDR GSPRs 14 and 23, as well as FDA labeling requirements under 21 CFR 801.

Building a compliance-ready infrastructure

A compliant software process depends on more than good engineering habits. It requires an integrated digital chain of trust that supports end-to-end traceability, automated verification, and continuous audit readiness.

Therefore, the infrastructure must address several distinct functions:

• Structured task management to handle the tracking of change requests, defect reports, user stories, and regulatory action items so that every task can be traced back to a requirement and forward to a test result.
• A centralized documentation platform maintaining architectural specifications, system requirements, cybersecurity strategy documents, and risk management files.
• Accessibility across engineering, regulatory, and quality departments, with support version-controlled documentation.

Requirements and risk traceability is arguably the most critical function regarding compliance. The infrastructure and processes must enable bidirectional traceability across requirements, risks, test cases, and verification evidence, aligned with IEC 62304 and ISO 14971. Every requirement must link to its risk assessment, implementation, test case, and verification result. The traceability matrix is what regulators examine during audits, and it must be current and complete at all times.

Version control and build automation ensure that each code change is captured, every build is reproducible, and all releases are traceable. Automated testing pipelines enforce consistency by running integration, regression, and safety-critical path tests. The version control and build automation should produce logs and reports that serve as verification evidence.

Quality management system (QMS) integration ties the engineering processes to the broader regulatory infrastructure. The QMS maintains the Design History File (DHF), supports change control workflows, and logs the audit trails that demonstrate compliance. Without a tight integration between the engineering processes and the QMS, documentation gaps are inevitable, and those gaps become audit risks.

The final integrated ecosystem must enable three capabilities that regulators expect:

• bidirectional traceability from requirements and risks through to implementation, verification, and release;
• automated audit reporting that streamlines inspection readiness and regulatory submissions; and
• continuous compliance monitoring that proactively detects process deviations or gaps before they become risks.

Moving from compliance to continuous security

The purpose of the US FDA, EU MDR, IEC 62304, and ISO 14971 is ultimately to ensure the safety and security of medical devices. The most effective medical device OEMs embrace the spirit of regulations and do not treat regulatory compliance as a mere checkbox activity that occurs before a submission or an audit. These OEMs embed security and safety in their work culture and into the core of their daily workflows, from the way they design to the way they support products post-deployment.

Cybersecurity is a discipline that evolves with every feature, every update, and every new threat vector. Beyond a collection of disparate tools, the infrastructure is an integrated ecosystem that either supports continuous security or undermines it through fragmentation and unmitigated risks.

For manufacturers navigating the requirements of the US FDA and EU MDR, the investment in designing a cybersecure and compliant engineering infrastructure pays dividends beyond regulatory approval. Instilling security and safety throughout the infrastructure and practices accelerates update cycles, reduces audit preparation effort, strengthens the security posture of deployed devices, and builds trust that patients, clinicians, and regulators expect.

Check out our comprehensive regulatory overview for detailed analysis and actionable best practices to help you navigate FDA and MDR compliance with confidence.

Read the overview