Medical device compliance safety under QMSR, MDR and cybersecurity rules

Why compliance safety now means lifecycle evidence

Medical device compliance safety means being able to show, with current records, that a device remains safe and effective from design through production, distribution, use, servicing and postmarket monitoring. In 2026, that evidence burden is more connected than it was under older checklist-style quality systems. The FDA’s Quality Management System Regulation became effective on February 2, 2026 and incorporates ISO 13485:2016 into 21 CFR Part 820. In the EU, the regulatory framework continues to push manufacturers toward stronger clinical evidence, traceability, post-market surveillance and EUDAMED registration. For connected devices, cybersecurity is now part of the patient safety case, not a separate technical topic.

The practical conclusion is clear: compliance teams need integrated evidence that stays current across the device lifecycle, not isolated binders prepared for one audit or submission.

For ongoing coverage of regulatory updates and device safety topics, see our safety and compliance section.

The 2026 regulatory baseline quality teams should recognize

As of September 2026, the most important compliance safety issue is not one single rule. It is the interaction between quality management, risk management, digital traceability, postmarket monitoring and product security. The dates below are based on FDA, European Commission and EUR-Lex materials that describe current or recently implemented obligations.

Area	Current position	Safety implication
FDA quality system	The QMSR became effective on February 2, 2026 and incorporates ISO 13485:2016 and ISO 9000:2015 Clause 3 by reference, while U.S. statutory and regulatory requirements still control where they apply.	Quality records need to map to the ISO 13485 structure and to U.S.-specific requirements such as complaint handling, UDI and FDA inspection authority.
FDA inspections	FDA stopped using the Quality System Inspection Technique on February 2, 2026 and began using the updated Inspection of Medical Device Manufacturers Compliance Program 7382.850.	Inspection readiness should be based on the current inspection program, not on legacy QSIT assumptions.
EU MDR transition	Regulation (EU) 2017/745 has applied since May 26, 2021. Regulation (EU) 2023/607 extended transition periods for certain legacy devices, generally to December 31, 2027 for higher-risk categories and December 31, 2028 for many medium and lower-risk categories, subject to conditions.	A legacy certificate is not enough by itself. Teams must confirm eligibility conditions, device risk status, QMS progress and notified body arrangements.
EUDAMED	The first four EUDAMED modules became mandatory from May 28, 2026: actor registration, UDI/device registration, notified bodies and certificates, and market surveillance. The vigilance/post-market surveillance and clinical investigation/performance study modules remain on a later rollout path.	Registration data, UDI governance and certificate information are now operational compliance controls, not future database work.
Supply interruption in the EU	Regulation (EU) 2024/1860 introduced an obligation, applying from January 10, 2025, to inform relevant authorities and supply-chain recipients when an anticipated interruption or discontinuation could create serious harm or serious public-health risk.	Business continuity, discontinuation planning and regulatory notification should be connected to patient-risk assessment.
Cybersecurity	FDA’s February 2026 final cybersecurity guidance addresses quality system considerations and premarket submission content for devices with cybersecurity risk, including section 524B of the FD&C Act for cyber devices.	Security planning, vulnerability monitoring, secure development and software component visibility need to be treated as safety evidence.

What QMSR changes in day-to-day quality work

The QMSR does not mean that every medical device company can simply replace one regulatory label with another. FDA has said the ISO 13485 requirements are substantially similar to the former Quality System Regulation when taken as a whole, but the operating focus is different. Procedures, records and management reviews should now show how the organization controls risk throughout the product lifecycle.

The rule applies to finished device manufacturers that intend to commercially distribute devices, including manufacturers of accessories that meet the finished-device definition. Certain devices may have CGMP exemptions, but exemption from CGMP requirements does not automatically remove complaint file obligations or other record requirements. Devices manufactured under an investigational device exemption also remain subject to design and development requirements.

Inspection readiness has moved upstream

FDA’s QMSR FAQ states that investigators may review QMS records created before February 2, 2026 when those records are relevant to QMSR compliance. The same FAQ notes that internal audit reports, supplier audit reports and management review reports are no longer protected by the former QS Regulation inspection exception. That is a practical shift for teams that previously treated those records as separate from the inspection file.

A strong response is not to rewrite history. It is to maintain a clear comparative analysis showing how legacy records, procedures and risk controls align with current QMSR requirements. This crosswalk should be dated, approved and linked to any remediation plan. If gaps remain, the record should show risk-based prioritization and completion status rather than broad promises without owners or timelines.

Risk management needs to appear in more than one file

Under modern quality expectations, risk management is not a single spreadsheet owned by regulatory affairs. It should be visible in design inputs, verification and validation, supplier controls, production acceptance, labeling, complaint handling, CAPA and postmarket surveillance. ISO 14971 is commonly used as the medical device risk-management framework, but regulators and auditors are looking for evidence that the method actually influenced decisions.

For example, a software hazard that depends on network connectivity should not appear only in a design risk table. It should connect to cybersecurity requirements, software architecture, verification tests, labeling, residual risk evaluation, complaint coding and vulnerability monitoring. A sterile device packaging hazard should connect to supplier qualification, process validation, shelf-life evidence, transport studies and complaint trending.

How to connect safety evidence across the device lifecycle

Compliance safety becomes credible when the file can answer a simple question: how does each safety claim remain true after the device leaves the design phase? A technical file or design history record may support market access, but the QMS has to keep that claim current as production lots change, suppliers update processes, software libraries age and real-world complaints accumulate.

Safety claim	Evidence that should connect	Common weakness
The device performs as intended	Intended use, user needs, design inputs, V&V, clinical or performance evidence, acceptance criteria and release records.	Verification tests exist, but they do not clearly trace back to the current intended use or risk controls.
Residual risks are acceptable	Risk analysis, benefit-risk rationale, labeling, usability validation, clinical evaluation and postmarket data review.	Risk files are updated after design changes, but complaint trends and field actions are not fed back into risk evaluation.
Manufacturing remains controlled	Process validation, equipment maintenance, environmental controls, supplier qualification, incoming acceptance and nonconformance records.	Production records are complete, but supplier changes are not assessed for patient-safety impact.
Users can use the device safely	Use-related risk analysis, human factors evidence, labeling, training materials, complaint coding and usability-related CAPA.	Usability is treated as a premarket activity only and is not monitored through postmarket signals.
Software remains safe and secure	Software requirements, architecture, hazard analysis, cybersecurity threat modeling, SBOM, testing, release notes and vulnerability response records.	Cybersecurity evidence exists in engineering tools but is not controlled within the QMS.

This lifecycle view is also useful for management review. Instead of treating quality metrics as separate dashboards, management should be able to see whether complaint trends, nonconformances, supplier issues, audit findings and regulatory changes alter the risk profile of marketed devices.

Cybersecurity is now a patient safety control

FDA’s current cybersecurity guidance is framed as guidance rather than a regulation, but it addresses expectations that matter in submissions and postmarket planning. For devices with cybersecurity risk, FDA recommends cybersecurity design documentation, labeling information and evidence that marketed devices are resilient to cybersecurity threats. For cyber devices covered by section 524B, manufacturers must address items such as postmarket vulnerability monitoring, secure development processes and a software bill of materials.

Security requirements should be managed like design requirements

For a connected device, cybersecurity requirements should not sit outside design control. Authentication, access control, encryption, secure update mechanisms, logging and fail-safe behavior can all affect safety. If a loss of availability, integrity or confidentiality could lead to delayed therapy, incorrect diagnosis or unsafe operation, the cybersecurity control belongs in the safety argument.

Threat modeling is most useful when it is linked to realistic clinical use. A hospital-connected device, a home-use wearable and a cloud-connected diagnostic platform have different exposure pathways and user assumptions. The file should show why selected controls are appropriate for the intended environment, expected user capability and foreseeable misuse.

Postmarket cybersecurity needs ownership

Security evidence ages faster than many traditional device records. Third-party software components can become vulnerable after clearance or certification. Hospitals may deploy devices on networks that differ from the manufacturer’s assumptions. Attack methods evolve. Because of this, postmarket cybersecurity needs defined owners, vulnerability intake procedures, triage criteria, update pathways, customer communication and escalation into CAPA when necessary.

The strongest programs do not wait for a major incident to test the process. They define how vulnerability reports are received, how exploitability is assessed, who approves remediation, how residual risk is documented and how field communication is handled. In practical terms, compliance safety means evaluating a security issue through patient-risk consequences, not only through IT severity. See also: clinical equipment.

Why U.S. and EU compliance evidence should be compared, not blended

Global manufacturers often want one quality system for all markets, and QMSR alignment with ISO 13485 helps. However, alignment is not equivalence. FDA says it will not require ISO 13485 certificates, will not issue them and will not treat a certificate as an exemption from FDA inspection. MDSAP remains a voluntary third-party audit program, while FDA inspections assess compliance with FDA regulations based on FDA priorities and risk factors.

The EU system adds different operational pressures. MDR technical documentation, clinical evaluation, post-market surveillance, vigilance, UDI, EUDAMED registration and notified body certification all need to remain synchronized. The extended MDR transition under Regulation (EU) 2023/607 is conditional. At a high level, eligible devices must continue to comply with the previous directives, must not present an unacceptable risk, must not undergo significant changes in design or intended purpose, and manufacturers needed to take defined transition steps by 2024, including QMS and notified body milestones.

This means a single global QMS should include market-specific overlays. A design change might be acceptable under one regulatory pathway but trigger different documentation, notification or conformity-assessment consequences in another. A supplier change might be a QMS event in the United States and also a technical documentation or notified body issue in the EU. Blending the rules into one generic checklist can hide those differences.

A practical compliance safety checklist for 2026 reviews

The following checklist is not a substitute for legal or regulatory advice, but it reflects the controls most likely to reveal whether compliance safety is working as a system.

• Maintain a QMSR crosswalk. Map legacy QSR procedures and records to ISO 13485:2016 clauses, QMSR additions and U.S.-specific requirements.
• Update management review content. Include complaint trends, CAPA effectiveness, supplier risk, audit results, regulatory changes, cybersecurity signals and resource needs.
• Make audit records inspection-ready. Internal audits, supplier audits and management review records should be accurate, professional and connected to corrective action where needed.
• Trace hazards to controls. Confirm that each significant hazard links to design inputs, verification, validation, labeling, production controls and postmarket monitoring.
• Strengthen supplier change control. Require notification and risk assessment for changes in critical components, sterilization, software, cloud services, manufacturing processes and test methods.
• Integrate cybersecurity into design control. Keep threat models, secure development evidence, SBOM records, security testing, vulnerability response and update plans under document control.
• Review EUDAMED responsibilities. Assign owners for actor registration, UDI/device registration, certificate data and reconciliation with internal regulatory databases.
• Test postmarket escalation. Confirm that complaints, serious incidents, reportability decisions, field actions, trend signals and CAPA triggers have clear timelines and decision records.
• Plan for supply interruptions. In the EU, discontinuation or interruption that could create serious harm needs early assessment and, where applicable, timely notice to authorities and supply-chain recipients.
• Separate facts from assumptions. For EU legacy devices, document the exact transition basis, certificate status, notified body agreement and any design or intended-use changes.

Common pitfalls that weaken compliance safety files

One common pitfall is treating the ISO 13485 certificate as the answer to every regulatory question. Certification can support quality maturity, but it does not replace FDA inspection readiness, U.S. reporting duties or EU technical documentation.

A second pitfall is keeping risk management too close to design engineering and too far from postmarket data. If complaint trends, service data, cybersecurity vulnerabilities or supplier nonconformances do not trigger risk-file review, the safety case becomes stale.

A third pitfall is underestimating administrative data. UDI records, EUDAMED entries, certificates, device registrations and labels may look clerical, but wrong or inconsistent data can affect traceability, field safety actions and regulator confidence.

A fourth pitfall is delaying cybersecurity ownership until submission preparation. By that point, architecture decisions may already be fixed, third-party components may already be embedded and update pathways may be difficult to justify. Secure design is safer and easier to defend when it is planned from the start.

Frequently asked questions

Does ISO 13485 certification satisfy FDA QMSR?

No. ISO 13485 alignment is central to QMSR, but FDA has stated that it will not require or issue ISO 13485 certificates and that a certificate does not exempt a manufacturer from FDA inspection. A manufacturer still needs to meet applicable FDA requirements.

Do EU legacy devices automatically benefit from extended MDR transition dates?

No. The 2027 and 2028 transition periods introduced by Regulation (EU) 2023/607 are conditional. Manufacturers should confirm certificate status, device class, absence of significant design or intended-purpose changes, risk status, QMS progress and notified body arrangements.

Which QMS records need extra care after February 2, 2026?

Internal audit reports, supplier audit reports and management review reports need particular care because FDA’s QMSR FAQ says the previous QS Regulation inspection exception for these records was not maintained. They should be factual, complete and connected to corrective action where needed.

How should software teams support compliance safety?

Software teams should connect requirements, architecture, verification, validation, cybersecurity controls, SBOM records, release management, anomaly handling and vulnerability response. For connected devices, cybersecurity evidence should be managed as part of the safety case, not as a separate IT attachment.

What is the main takeaway for 2026 compliance planning?

The main takeaway is that regulators increasingly expect a living safety system. Procedures matter, but stronger evidence comes from the connections between risk, design decisions, supplier controls, production data, user feedback, cybersecurity monitoring and postmarket action.