Pre-market Services
Support secure and compliant medical device development with cybersecurity and privacy strategies aligned with MDR, IVDR, FDA, and international standards.
Software now sits at the heart of modern healthcare, and that raises real questions about how privacy and security are protected. Strong security and privacy controls are essential to keep personal (health) information confidential and patients safe. But because both fields are horizontal, cutting across many laws rather than being centralised within medical device regulation, it is often difficult to identify which regulations, standards, and guidance documents actually apply to a given organisation or product.
The picture differs not only between the European Union and the United States, but from one (member) state to another. Compliance is rarely straightforward and calls for expert understanding of how the legislative approaches diverge. Privacy, for example, is governed in the EU by the GDPR 2016/679 and in the US by HIPAA/HITECH, while medical devices are regulated in the EU under the MDR 2017/745 and IVDR 2017/746.
Crucially, complying with privacy law and medical device regulation does not automatically mean you comply with cybersecurity legislation. In the EU, cybersecurity obligations increasingly come from horizontal frameworks such as the Cyber Resilience Act and the NIS2 Directive, and from national rules that vary by country: Spain has implemented Royal Decree 311/2022 (the National Security Framework), the Netherlands applies NEN 7510-1 for information security management in healthcare, and France requires HDS certification for hosting health data.
In the US, cybersecurity is increasingly holding up FDA product registrations, and the requirements keep growing. Manufacturers are now expected to perform threat modelling (using a data flow diagram to define security requirements and mitigations), evaluate threats with STRIDE and score them with CVSS, maintain and review a Software Bill of Materials (SBOM), and carry out verification and validation testing — including a penetration test to demonstrate the product is secure. Comparable expectations apply in the EU through the IEC 81001-5-1 standard, which is used to demonstrate a securely developed health software product.
MedQAIR helps manufacturers navigate this landscape end to end — from privacy and data protection assessments (DPIAs) and data processing agreements, through threat modelling, secure development, and IEC 81001-5-1 implementation, to FDA cybersecurity documentation, vulnerability management, and full cybersecurity lifecycle planning.
Explore our blog posts on MDR, IVDR, and EU AI Act medical device compliance to stay ahead of regulatory changes.
ISO/IEC 27001 has been the reference standard for information security management systems since 2005, and its third edition, ISO/IEC 27001:2022, was published on 25 October 2022 (ISO/IEC 27001:2022 and Amendment 1:2024). The transition from
Manufacturers have been able to register in EUDAMED, the European database on medical devices, since December 2020 for the Actor module and since October 2021 for UDI and device data, but only on a voluntary basis. That changed on 28
Using the EUDAMED UDI/Devices module became mandatory on 28 May 2026. This follows the Commission Decision (EU) 2025/2371, which formally declared the first four modules functional. Published in the Official Journal back on 27 November 2025, that decision kicked off
We are pleased to welcome Eva Kurilova-Sahin to the MedQAIR team. Eva brings a background in medicine, clinical science, radiology, and oncology research, together with experience in AI-enabled medical technology. Over the past 10 years, her work has brought her
The regulatory landscape for medical devices is becoming more complex as artificial intelligence becomes part of diagnosis, monitoring, treatment, and clinical decision support. For manufacturers, understanding the EU AI Act medical devices requirements is now essential alongside the existing Medical
Artificial intelligence is evolving faster than the regulatory frameworks around it. But that gap is beginning to close, with a growing body of AI medical device standards now moving towards publication and wider regulatory recognition.
Find answers to common questions about our services, compliance processes, and how we can assist your business.
Cybersecurity and privacy are now core regulatory expectations for connected medical devices and digital health software, not optional extras. Regulators such as the FDA and EU notified bodies expect manufacturers to show that security risks, unauthorised access, data breaches, and software vulnerabilities, are identified, controlled, and monitored across the entire product lifecycle.
Weak security can delay market approval, trigger recalls, and put both patient safety and personal health data at risk.
Requirements usually come from several frameworks at once. In the EU these include the Medical Device Regulation (MDR 2017/745), the In Vitro Diagnostic Regulation (IVDR 2017/746), the GDPR (2016/679) for data protection, and IEC 81001-5-1 for the secure software lifecycle, with the Cyber Resilience Act (CRA) and AI Act increasingly relevant.
In the US, the key requirements come from FDA premarket and postmarket cybersecurity guidance and section 524B of the FD&C Act, alongside HIPAA/HITECH for health data privacy. Which requirements apply depends on the device type, software functionality, connectivity, and target markets – MedQAIR helps manufacturers map this for their specific product.
No. Even standalone software and locally deployed systems can carry cybersecurity obligations, depending on how data is processed, stored, updated, or accessed. Regulators increasingly focus on the full software and device lifecycle, including updates, maintenance, and end-of-support, rather than only internet-facing products. An offline device that still receives software updates or handles health data remains in scope.
Cybersecurity is tightly integrated with risk management (ISO 14971), the software lifecycle (IEC 62304), and post-market surveillance. Manufacturers are expected to build security into design, development, verification and validation, maintenance, vulnerability management, and incident response. A strong quality management system (QMS) keeps cybersecurity evidence traceable and audit-ready.
IEC 81001-5-1 is the international standard for security activities across the health software product lifecycle, covering secure design, development, verification, and maintenance. In the EU it is widely used to demonstrate that a health software product is developed securely in line with MDR and IVDR expectations, and it is increasingly referenced by notified bodies. Any manufacturer of health software or software as a medical device (SaMD or SaIVD) placing products on the EU market should plan for it. MedQAIR provides IEC 81001-5-1 implementation support.
For “cyber devices,” section 524B of the FD&C Act requires manufacturers to submit a cybersecurity plan, a Software Bill of Materials (SBOM), evidence of secure development and testing, and a process for identifying and patching vulnerabilities after release. FDA premarket guidance also expects threat modeling, a security risk assessment, and verification & validation testing such as penetration testing. Submissions that lack this documentation can be stopped at the “refuse to accept” stage, delaying clearance. MedQAIR supports manufacturers in preparing submission-ready FDA cybersecurity documentation.
An SBOM is a structured inventory of all software components, libraries, and dependencies in a product, including third-party and open-source code. The FDA requires it so that manufacturers and regulators can quickly identify which devices are affected when a new vulnerability is discovered in a known component. Maintaining an accurate, machine-readable SBOM is now a baseline expectation for FDA submissions and good practice in the EU.
Threat modeling is a structured analysis of how a device could be attacked and how those risks are reduced. It typically starts with a data flow diagram that maps how information moves through the system, then applies a framework such as STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) to identify threats and CVSS to score their severity. The output defines the device’s security requirements and mitigations. MedQAIR builds threat models that meet FDA and IEC 81001-5-1 expectations.
In most cases, yes. The FDA expects security verification and validation testing, including penetration testing, to provide objective evidence that a device’s security controls work as intended, and similar testing is expected under IEC 81001-5-1 for the EU market. A penetration test should be planned early so findings can be remediated before submission, rather than triggering late-stage delays.
The US approach is centralised: the FDA sets expectations through section 524B and its premarket and postmarket cybersecurity guidance. The EU is more layered, MDR and IVDR set the baseline, IEC 81001-5-1 provides the lifecycle method, the CRA and AI Act add horizontal requirements, and individual member states add national healthcare security rules. Complying in one region does not guarantee compliance in the other, which is why a market-specific strategy matters.
The GDPR (Regulation 2016/679) is the EU’s broad data protection law covering all personal data, with strict rules on health data as a special category. HIPAA, together with the HITECH Act, is the US framework governing protected health information held by covered entities and their business associates. They differ in scope, consent, breach notification, and enforcement, so a product sold in both markets must satisfy both, privacy compliance in one does not transfer to the other.
Yes. Beyond EU-level regulation, several member states impose national requirements. Spain applies Royal Decree 311/2022 (the National Security Framework, ENS), the Netherlands uses NEN 7510 for information security management in healthcare, and France requires HDS (Hébergeur de Données de Santé) certification for hosting health data. These local rules mean a single EU-wide approach is rarely enough, and requirements should be confirmed per target country.
Generally, products already regulated as medical devices under MDR or IVDR are excluded from the CRA where their cybersecurity is covered by those regulations, avoiding double regulation. However, the CRA can still apply to other digital products and components within a health software ecosystem. Because the boundaries are nuanced, it is worth confirming which framework governs each part of a product.
As early as possible – ideally at the design and requirements stage. Cybersecurity is a lifecycle activity under both FDA guidance and IEC 81001-5-1, and retrofitting security late in development is slow, costly, and a common cause of submission delays. Building threat modeling, secure development, and testing into the plan from the start keeps a project on schedule. MedQAIR offers cybersecurity lifecycle planning to help teams integrate these activities from day one.
Yes. MedQAIR supports manufacturers across the cybersecurity lifecycle – including secure software development, threat modeling and risk analysis, privacy and data protection assessments, IEC 81001-5-1 implementation, vulnerability management, and FDA cybersecurity documentation. The team helps prepare submission-ready evidence and align security and privacy strategy across EU and US markets. You can schedule a free consultation with MedQAIR’s experts to review your specific product and target markets.
IEC 81001-5-1 specifies a secure software development lifecycle for health software and is the harmonized standard for cybersecurity under the EU MDR. It requires a security risk management process, threat modeling, secure coding practices, vulnerability management, software bill of materials (SBOM) maintenance, and post-market security monitoring. It complements (rather than replaces) IEC 62304 and is also referenced by FDA’s 2023 premarket cybersecurity guidance.
ISO/IEC 27001 establishes a strong information security management system foundation that addresses many HIPAA Security Rule and GDPR Article 32 requirements, but it is not a substitute for either. HIPAA imposes specific administrative, physical, and technical safeguards on covered entities and business associates that go beyond ISO/IEC 27001’s controls. GDPR adds data subject rights, lawful basis for processing, DPIAs, and data residency obligations. The most efficient path is usually ISO/IEC 27001 as the backbone, extended with ISO 27701 (privacy) and a gap analysis against HIPAA and GDPR.