Safety and compliance in medical devices in 2026 and what quality teams should update
What safety and compliance mean in 2026
For medical devices, safety and compliance now means showing that quality, risk, regulatory, software, supplier, and post-market activities work together across the device lifecycle. As of August 27, 2026, this is already an operating reality. In the United States, the FDA Quality Management System Regulation became effective on February 2, 2026, aligning 21 CFR Part 820 more closely with ISO 13485:2016. In the European Union, the first four EUDAMED modules became mandatory to use from May 28, 2026. For connected and software-enabled devices, FDA cybersecurity expectations also make security evidence part of safety evidence.
A focused safety and compliance program therefore cannot rely on a static procedure library. It needs controlled, current, traceable evidence that the device remains safe, effective, and compliant after launch.
The practical question for manufacturers, sponsors, importers, distributors, and quality teams is straightforward: can the organization show how requirements, risks, design decisions, supplier controls, production records, complaints, cybersecurity activities, and regulatory data connect to each other? If the answer is no, the program may look compliant on paper while remaining weak during inspection, audit, submission review, or post-market surveillance.
Three regulatory signals reshaping compliance work
Regulatory authorities and standards bodies are moving in the same general direction: more lifecycle accountability, better data consistency, and stronger evidence that quality systems control risk in practice. The main 2026 signals are not isolated regulatory changes. They affect how teams manage daily records, not only how they prepare submissions.
| Regulatory signal | Key date | What it changes | Evidence teams should update |
|---|---|---|---|
| FDA QMSR | Effective February 2, 2026 | 21 CFR Part 820 now incorporates ISO 13485:2016 by reference, with FDA-specific provisions still relevant. | Procedure maps, internal audit checklists, management review inputs, complaint handling links, design and production records, and training evidence. |
| EU EUDAMED rollout | First four modules mandatory from May 28, 2026 | Actor registration, UDI and device registration, notified bodies and certificates, and market surveillance data become operational compliance work. | SRN records, Basic UDI-DI data, UDI-DI records, certificate information, economic operator data, and data governance controls. |
| FDA cybersecurity expectations | Section 524B took effect on March 29, 2023; updated FDA final guidance was issued on June 27, 2025 | Cybersecurity documentation is part of premarket and lifecycle evidence for devices that meet FDA’s cyber device scope. | Threat modeling, security risk management, software bill of materials, vulnerability monitoring, coordinated disclosure procedures, and update plans. |
The shared message is clear: safety is no longer assessed only through design validation or final product checks. Compliance now depends on whether the organization can maintain reliable evidence as products, suppliers, software components, labels, certificates, and field information change.
Why QMS evidence matters more than standalone policies
A quality management system can fail even when every required procedure exists. The weakness often appears in the links between records. A design input may not connect to a verified output. A complaint trend may not feed back into the risk file. A supplier change may be approved without assessing cybersecurity, sterility, labeling, performance, or regulatory filing impact. A training record may exist, but not for the version of the procedure actually used.
The FDA QMSR makes these links more visible because ISO 13485:2016 is built around documented processes for organizations involved in medical device design, production, storage, distribution, installation, servicing, and related activities. However, ISO 13485 certification alone should not be treated as a full substitute for FDA compliance. The FDA regulation remains a legal requirement, and organizations still need to address FDA-specific expectations, definitions, records, labeling, packaging, complaint handling, and inspection readiness.
For quality leaders, the useful starting point is not to rewrite every procedure at once. A better approach is to build a traceability map. Each core process should show its inputs, outputs, required records, responsible functions, applicable market requirements, escalation triggers, and links to risk management. This turns the QMS from a document set into an operating system for safety decisions.
Risk management connects safety claims to design decisions
Risk management is central to a credible safety and compliance program. ISO 14971:2019 describes a risk management process for medical devices, including software as a medical device and in vitro diagnostic medical devices. In practice, the risk file should not be treated as a form completed near the end of development. It should be a living record that influences design inputs, design outputs, verification, validation, labeling, usability engineering, production controls, supplier decisions, and post-market monitoring.
A strong risk file answers practical questions. What hazards are associated with the intended use and reasonably foreseeable misuse? What sequence of events can lead to a hazardous situation? Which design controls, protective measures, information for safety, alarms, training, maintenance actions, or cybersecurity controls reduce risk? How was implementation verified? How was effectiveness checked? What residual risks remain, and how are they communicated and monitored?
The most common weakness is not a missing hazard list. It is the absence of feedback loops. Complaints, service reports, nonconforming product, cybersecurity vulnerabilities, usability findings, manufacturing deviations, and literature signals should be reviewed for possible risk file updates. If the post-market process closes individual complaints without asking whether the risk profile has changed, the compliance system is incomplete.
Software and cybersecurity are now part of product safety
Connected devices, cloud-supported devices, mobile medical applications, firmware-controlled equipment, and software as a medical device create a different compliance challenge. The device may change after release through patches, configuration updates, operating system dependencies, cloud service changes, third-party libraries, and newly discovered vulnerabilities. Safety evidence therefore cannot stop at initial validation.
For devices that fall within FDA’s cyber device requirements, sponsors are expected to address cybersecurity across the product lifecycle. A practical program includes security requirements tied to clinical risk, threat modeling, secure architecture documentation, vulnerability testing, a software bill of materials, coordinated vulnerability disclosure, monitoring for post-market vulnerabilities, and a plan for updates and patches. The goal is not to create a separate cybersecurity binder. The goal is to connect cybersecurity decisions with design control, risk management, complaint handling, servicing, CAPA, and post-market surveillance.
A software bill of materials is useful, but it is not enough by itself. Teams also need a way to decide which component vulnerabilities are relevant to the device configuration, whether exploitation could affect essential performance or patient safety, how fixes will be validated, and how users will be informed. For long-life medical equipment, end-of-support planning is also a compliance issue because unsupported software can become a safety risk even when the original device design was acceptable. See also: clinical equipment.
EU compliance is becoming more data operational
The EU MDR and IVDR already require extensive technical documentation, post-market surveillance, vigilance, economic operator controls, and device identification. EUDAMED makes a significant part of that information more operational. From May 28, 2026, the first four mandatory modules cover actor registration, UDI and device registration, notified bodies and certificates, and market surveillance. This increases the need for clean regulatory data, consistent identifiers, and clear ownership of device records.
For manufacturers placing devices on the EU market, data governance is now a compliance control. Basic UDI-DI, UDI-DI, certificate scope, risk class, intended purpose, label information, authorized representative details, importer information, and market status should not live in disconnected spreadsheets that are manually reconciled at the last minute. Inconsistent EUDAMED data can create delays, questions from partners, and avoidable regulatory risk.
EU transition periods for certain legacy devices under Regulation (EU) 2023/607 should also be handled carefully. Extended dates, including December 31, 2027 for certain higher-risk legacy devices and December 31, 2028 for certain other device categories, are not a blanket exemption from MDR obligations. Conditions still apply, and post-market surveillance, vigilance, quality management, and contractual progress with notified bodies remain important. Regulation (EU) 2024/1860 also added attention to supply interruption or discontinuation communication in certain situations, reinforcing the connection between market availability and safety oversight.
A practical update checklist for quality and regulatory teams
The following checklist is designed as an operational review, not as legal advice. Teams should adapt it to device class, markets, technology, notified body status, and product lifecycle stage.
| Area | Questions to ask | Records to review |
|---|---|---|
| Regulatory map | Do current procedures identify all active markets, device classifications, applicable regulations, recognized standards, and transition dates? | Regulatory strategy, standards list, classification rationale, market authorization records, and change impact templates. |
| Design and risk | Can each safety claim be traced to design inputs, risk controls, verification, validation, labeling, and residual risk evaluation? | Design history file, risk management file, usability records, verification protocols, validation reports, and labeling reviews. |
| Supplier and outsourced processes | Are critical suppliers, contract manufacturers, sterilization providers, software vendors, cloud providers, and service partners controlled according to risk? | Supplier qualification files, quality agreements, purchasing controls, service level agreements, change notifications, and supplier monitoring. |
| UDI and regulatory data | Are device identifiers and regulatory data consistent across labels, certificates, technical documentation, EUDAMED records, and distribution records? | UDI records, Basic UDI-DI assignments, label masters, certificate data, EUDAMED entries, and distribution controls. |
| Post-market surveillance | Do complaints, service data, adverse events, literature, trend reports, and CAPA inputs feed back into risk management? | PMS plan, PSUR where applicable, complaint files, vigilance reports, CAPA records, trend analyses, and management review minutes. |
| Cybersecurity | Can the team monitor vulnerabilities, assess exploitability, validate updates, communicate risk, and maintain support commitments? | Threat models, SBOM, vulnerability logs, penetration test summaries, update validation records, disclosure procedures, and support policies. |
Common mistakes that weaken safety and compliance programs
Many compliance failures are not caused by a lack of effort. They happen because teams solve the visible document problem while missing the evidence problem. The following issues deserve close attention in 2026:
- Treating QMSR as only a renumbering exercise instead of checking whether ISO 13485-based processes are actually implemented.
- Keeping risk management separate from complaints, service records, cybersecurity, usability findings, and production data.
- Updating procedures without training people on the exact version that applies to their work.
- Approving supplier or software changes without documenting safety, regulatory, validation, and cybersecurity impact.
- Waiting until a submission, audit, or EUDAMED deadline to clean device master data.
- Using a software bill of materials as a static attachment rather than a maintained vulnerability management tool.
- Closing CAPAs based on procedural correction without verifying whether the correction was effective in real operations.
The corrective action is usually not more paperwork. It is clearer ownership. Each recurring data set should have a responsible function, a controlled source, a review frequency, and a defined trigger for escalation. Each major process should show how it affects patient safety and regulatory commitments.
Frequently asked questions
Is ISO 13485 certification enough for FDA compliance?
No. ISO 13485:2016 is central to the FDA QMSR because it is incorporated by reference into 21 CFR Part 820, but FDA compliance remains a regulatory obligation. Organizations should also address FDA-specific provisions, inspection expectations, complaint requirements, labeling and packaging controls, records, and any applicable device-specific requirements.
What should a smaller medical device manufacturer update first?
Start with a risk-based gap assessment. Map current procedures and records against the markets where the device is sold, then focus on high-impact areas such as design controls, risk management, complaint handling, supplier controls, cybersecurity, UDI data, and management review. A smaller team should avoid rewriting everything at once if the larger risk is missing objective evidence.
Does EUDAMED change the design of a medical device?
EUDAMED does not directly redesign a device, but it changes how device and operator information is registered, maintained, and checked. Poor data control can affect market readiness, partner coordination, certificates, traceability, and regulatory communication. For that reason, EUDAMED preparation should be treated as a quality and regulatory data governance task.
How often should risk management files be updated?
There is no single universal interval that fits every device. The file should be reviewed when design changes, manufacturing changes, supplier changes, complaints, service data, adverse events, cybersecurity vulnerabilities, usability findings, standards updates, or regulatory changes suggest that the risk profile may have changed. Periodic review can help, but event-driven review is essential.
Are cybersecurity controls only relevant to hospital network equipment?
No. Cybersecurity can be relevant to many devices that include software, connectivity, update mechanisms, data exchange, removable media, cloud services, mobile interfaces, or third-party components. The compliance task is to determine whether a cybersecurity issue could affect safety, effectiveness, data integrity, availability, or required performance, and then maintain evidence that the risk is controlled.
