Cybersecurity & Privacy

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.