Cybersecurity for medical devices is not optional – it is a regulatory obligation and directly tied to patient safety. The MDR requires a systematic, traceable approach to identifying, assessing, and mitigating cybersecurity risks across all phases of the product lifecycle. VamiSec guides you toward full compliance with MDCG 2019-16, IEC 62304, IEC 81001-5-1, and international best practices (IEC 62443, SAE 21434, ISO 14971).
As soon as a medical device is an AI system or integrates one, it is generally classified as high-risk AI – on top of the MDR, the requirements of the AI Act apply. Our interactive overview shows all 16 core areas, their degree of overlap with the MDR and a high-risk check.
Explore the AI Act for medical devicesSafety vs. security: cybersecurity must go hand in hand with patient safety.
MDCG 2019-16 (Guideline on medical device cybersecurity) is the central European reference for manufacturers and authorities. It operationalizes the MDR requirements and defines which security capabilities, which minimum requirements for the operating environment, and which documentation are expected. At its core is the insight: cybersecurity risks can lead directly to risks of patient harm.
Annex III – Referencing Standards
Annex IV – Risk Management
Annex I & II – Incidents & Vigilance
Risk, security, safety, and shared responsibility under MDR / IVDR – the foundational principles of MDCG 2019-16 at a glance.
Risk = Probability of Harm × Severity of Harm
A unified understanding of risk across MDR / IVDR – for security, safety, and effectiveness.
Security embedded in architecture and development from the start.
Measures aligned with the current state of the art.
Security must not undermine benefit or clinical effectiveness.
The manufacturer bears primary responsibility across the entire lifecycle.
Secure Design, Risk Management, Guidance
Secure Configuration, Training
Secure Operation, Incident Reporting
Intended Use, Cyber Awareness, Data Protection
To support the implementation of the Medical Device Security Lifecycle – the relevant MDCG guidelines, grouped by topic area.
Guidance on Cybersecurity for Medical Devices
Qualification & Classification of Software (MDSW)
Clinical / Performance Evaluation of Medical Device Software
MDSW – Software/Hardware Combinations
Post-Market Surveillance of Medical Devices & IVDs
Q&A on Vigilance Terms & Concepts
Device Specific Vigilance Guidance (DSVG) – Template
Periodic Safety Update Report (PSUR)
Guidance on Standardisation for Medical Devices
Safe Making Available of MDSW Apps on Online Platforms
Person Responsible for Regulatory Compliance (PRRC)
UDI Integration into the QMS
EUDAMED – Interim Administrative Practices (MDR)
UDI Assignment to Medical Device Software
EUDAMED – Interim Administrative Practices (IVDR)
FAQ on EMDN (European Medical Device Nomenclature)
* MDCG guidelines are not legally binding but reflect the common EU interpretation of the requirements under MDR (EU) 2017/745 & IVDR (EU) 2017/746.
"Cybersecurity risks can directly translate into patient safety risks" – MDCG 2019-16
For a long time, IT security and functional safety were treated as separate domains. MDCG 2019-16 overturns this view: a successful cyberattack on a medical device directly endangers patient safety. That is why both risk management systems must be interlinked.
Cyber incidents affecting patient safety
Cybersecurity and safety risk management (EN ISO 14971) run in parallel through the same process steps. The cross-references are decisive: every security risk or control with a potential safety impact must feed into the safety risk assessment – and vice versa.
* MDCG 2019-16 Rev.1, Annex IV: Security risk management has the same elements as safety risk management – both must be considered in an integrated manner.
MDCG 2019-16 defines seven lifecycle phases, each with its own specific cybersecurity objectives. New attack vectors emerge continuously – what is secure today may be compromised tomorrow. Systematic management of these phases ensures proactive security.
VamiSec-Nachweise: Gap Analysis, Security Charter, Requirement Specification
Every phase requires specific documents, processes, and controls. VamiSec supports you in seamlessly integrating these objectives into your existing QMS and development processes.
MDCG 2019-16 Annex I: Minimum security capabilities according to the current state of the art.
The guideline defines concrete security capabilities that medical devices must implement depending on their risk category. At the same time, minimum requirements are placed on the operating environment – because security is a shared responsibility between manufacturer and operator.
Strong Authentication, Multi-Factor Authentication (MFA), role-based access control (RBAC), least-privilege principle.
MDCG 2019-16, Sec. 4.1
End-to-End Encryption, TLS 1.2+, key management, secrets management, Hardware Security Modules (HSM) for sensitive keys.
MDCG 2019-16, Sec. 4.2
Digital signatures, checksums, Code Signing, Firmware Verification, Anti-Tampering Measures.
MDCG 2019-16, Sec. 4.3
Complete logging of security events, Tamper Evidence, Audit Trails, Immutable Logs, Monitoring & Alerting.
MDCG 2019-16, Sec. 4.4
Graceful Degradation, Failover Mechanisms, DoS Mitigation, Business Continuity Planning, Incident Response (CSIRT).
MDCG 2019-16, Sec. 4.5
Multiple security layers (network, application, system), segmentation, firewalls, IDS/IPS, Web Application Firewalls (WAF).
MDCG 2019-16, Sec. 3
The manufacturer must clearly document and communicate these requirements in the IFU. The operator (clinic, hospital) is responsible for implementation – a shared responsibility.
Each layer is designed to be independent and redundant. A breach in layer 1 (network) does not automatically grant access to layer 3 (application). This defense-in-depth approach is not optional – it is a regulatory standard.
Threat Modeling is not optional – it is a regulatorily required activity that you must carry out systematically in order to identify and assess cyber risks. MDCG 2019-16 and IEC 62304 require manufacturers to create and document a formal threat model for their medical device.
From the Data Flow Diagram to the Kill Chain – anticipate attacks in a structured way.
Visualizing the movement of data within the system: processes, data stores, external entities, trust boundaries. DFDs reveal where data is sensitive and where attackers could break in.
Beispiel: A therapy device communicates with a cloud backend. Where does therapy data flow? Who has access? Where do the encryption boundaries run?
VamiSec-Ansatz: VamiSec creates DFDs at multiple levels: system level, sub-system level, network level.
Design Phase: create DFD + STRIDE analysis
Development Phase: attack trees for critical functions
Pre-Release: Kill Chain Mapping + MITRE ATT&CK Assessment
Post-Market: Continuous Threat Monitoring against new ATT&CK techniques
VamiSec-Nachweise: Threat Model Report, Attack Tree Diagrams, Kill Chain Assessment, MITRE ATT&CK Mapping
Security from beginning to end – not as an afterthought, but as a core principle.
A medical device with a secure architecture and good design is only half the solution – the actual implementation is what counts. The SSDLC model integrates security measures into every step of software development: from requirements definition through code reviews to continuous monitoring in operation. DevSecOps automates these controls in CI/CD pipelines.
Tools: Threat modeling tools, Risk Assessment Matrix, Security Requirement Specification
Tools: Architecture Review Board, Design Review Checklist, Security Standards (IEC 62443, SAE 21434)
Tools: Code Review Platforms (GitHub, GitLab), Secrets Scanning Tools, Static Analysis IDEs
Tools: SonarCloud/SonarQube (SAST), Snyk/Veracode (SCA), OWASP Dependency-Check, CycloneDX (SBOM), Burp Suite (DAST)
Tools: Hardening Checklists, Code Signing Certificates, Configuration Management Tools
Tools: SIEM (e.g., ELK, Splunk), Patch Management Systems, CSIRT Tools, EUDAMED Integration
DevSecOps automates security checks within the CI/CD pipeline. Every code commit is scanned automatically; a release can only proceed once the quality gates have been passed.
Full transparency over dependencies and exposure – compliance through automation.
Three tools are essential for a modern Secure SDLC: SBOM (Software Bill of Materials) for transparency, SAST (Static Analysis) for code vulnerabilities, and SCA (Software Composition Analysis) for open-source risks. Together they form the foundation for automated security assessments in CI/CD pipelines.
An SBOM is a machine-readable inventory of all software components, their versions, and dependencies. It is increasingly required by regulation (CRA, MDR) and is essential for vulnerability management.
SAST analyzes source code WITHOUT executing it. It identifies typical vulnerabilities (SQL injection, XSS, buffer overflows, insecure cryptography, etc.) early in the development cycle.
SCA scans dependencies and open-source components for known vulnerabilities (CVEs). It also measures license conformance and provides patch recommendations.
SBOM, SAST, and SCA must be automated in the CI/CD pipeline. Quality gates ensure that code with critical vulnerabilities is not released.
VamiSec-Nachweise: SAST reports, SCA reports, SBOM (CycloneDX format), quality gate logs, remediation tracking
Structured risk identification, assessment, and mitigation across all lifecycle phases.
ISO 14971 is the international standard for risk management of medical devices. It requires a systematic, documented assessment of all risks associated with the product – including cybersecurity risks. The MDR obligates manufacturers to establish and demonstrate a formal ISO 14971 risk management system.
Systematic identification of all risks: design flaws, component failures, user errors, cyberattacks, environmental factors.
Assessment of each risk by likelihood × severity = risk value. Definition of acceptance criteria.
Implementation of measures to reduce risk: design changes, warnings, training, software updates.
Re-assessment after implementation of controls. Is the residual risk acceptable?
Periodic review and updating of the risk analysis (particularly after new CVEs, attack patterns, market changes).
Cybersecurity risks differ from traditional safety risks: they are non-deterministic, adaptive, and constantly evolving. MDCG 2019-16 specifies how they are to be integrated into ISO 14971:
| Risiko-Kategorie | Beispiele | Mitigation |
|---|---|---|
| ● Authentication Risks | Unauthorized access through stolen credentials; Brute-force attacks on passwords; Session hijacking & token theft | Multi-Factor Authentication (MFA); Strong password policy & rate limiting; Secure session management, JWT expiration |
| ● Integrity Risks | Manipulation of therapy parameters or patient data; Tampering with firmware or configuration; Man-in-the-Middle (MITM) attacks | End-to-end encryption (TLS 1.2+); Digital signatures & code signing; Intrusion detection & tamper alerts |
| ● Availability Risks (DoS/DDoS) | Device failure due to a cyberattack; Overload of the cloud infrastructure; Ransomware-based shutdown | Rate Limiting & DDoS Mitigation; Redundancy & Failover Mechanisms; Backup & Recovery Processes |
| ● Confidentiality Risks | Theft of patient data or therapy information; Disclosure of trade secrets; GDPR violations | Encryption at Rest & in Transit; Access Control & Data Minimization; GDPR Compliance & Privacy by Design |
| ● Supply Chain Risks | Malware in open-source components; Compromised Dependencies or Vendors; Counterfeit Hardware | SBOM & Software Composition Analysis (SCA); Vendor Security Assessment; Code Signing & Integrity Verification |
ISO 14971 requires regular review of the risk analysis. In the post-market state, the following triggers must be monitored:
VamiSec helps you monitor these triggers and continuously update the risk analysis – a process that is interlinked with CSIRT and Post-Market Surveillance.
VamiSec-Nachweise: Risk Register, Risk Analysis Report (ISO 14971-compliant), Risk Control Measures, Residual Risk Evaluation, Post-Market Risk Review Log
Early detection, fast response, regulatory compliance – 24/7 readiness.
A Computer Security Incident Response Team (CSIRT) is not optional – it is the operational heart of an MDR-compliant cybersecurity management. The CSIRT is the interface between vulnerability detection, CVE processes, product teams, and regulators. You must establish a CSIRT or work with an external CSIRT service provider.
The CSIRT continuously monitors CVE databases (NVD, OSV, CISA KEV), security mailing lists, and threat intelligence feeds. The goal is to detect new vulnerabilities as early as possible – ideally before they are actively exploited.
Not all CVEs are equally critical. The CSIRT assesses every identified vulnerability based on: Exploitability (how easy is the flaw to exploit?), Impact (what damage is possible?), Affected Systems (which products are affected?), and the availability of patches.
The CSIRT coordinates when you discover vulnerabilities yourself or when external security researchers contact you. You must request CVE numbers (via CISA or CNA partners), document vulnerabilities correctly, and release patches in a timely manner.
The CSIRT is the interface between threat intelligence and technical teams. They must have understood the vulnerabilities and be able to make fast, well-informed decisions: Patch now? Workaround? New release? Recall?
VamiSec-Nachweise: CSIRT Charter, Incident Response SOP, CVE Monitoring Log, Vulnerability Assessment Reports, Patch Management Log, Customer Advisory Templates, EUDAMED Submission Records
Continuous monitoring, fast response, regulatory transparency – the real work begins after the release.
A medical device is not "finished" after release. In the post-market stage, you must continuously respond to security issues, customer complaints, new attack patterns and changes in the threat landscape. The MDR mandates formal post-market surveillance processes (PMS) and vigilance reporting to the authorities in the event of serious incidents.
Vigilance is the reporting system for patient-safety events. When a cybersecurity incident leads to, or could have led to, patient harm, it must be reported to the authority.
Detection of a cybersecurity incident through monitoring, customer reports, threat intelligence or a CSIRT alert.
Rapid assessment: Is this a serious incident? Is there a patient-safety risk? The CSIRT together with the quality and regulatory teams assess this jointly.
Initiate immediate measures: patch development, customer notification, product recall if necessary, communicate workarounds. For critical incidents: notification within 24–48h.
For serious incidents: submit a vigilance report to the competent authority (Germany: BfArM), create an EUDAMED entry and publish a customer advisory.
Post-mortem analysis: How could this happen? What would have prevented it? Root-cause analysis and improvement of processes & controls.
The European Database on Medical Devices (EUDAMED) has been the reporting platform for all incidents in the EU since 2022. All submitted reports are publicly accessible.
VamiSec helps you establish EUDAMED processes, standardize incident classification and implement the technical integration.
On average, how long does it take until a cybersecurity incident is detected? Target: < 1 week for critical incidents.
How long does it take to deliver a patch or workaround? Target: < 2 weeks for critical CVEs.
What percentage of customers have deployed the patch within X weeks? Target: > 80 % within one month.
How punctually are serious incidents reported to authorities? Compliance: ≤ 30 days.
How many CVEs are classified as "relevant to our product" but are not? Target: < 10 %.
VamiSec-Nachweise: PMS Plan, Incident Detection Log, Risk Assessment Reports, Patch Deployment Log, EUDAMED Submissions, Customer Advisory Archive, Vigilance Report Templates, Post-Mortem Analysis Reports
Compliance with MDCG 2019-16, IEC 62304 and the cybersecurity standards is a structured process. VamiSec guides you through four clearly defined phases, from analyzing your starting position to final audit preparation. Each phase is measurable and documented.
Comprehensive, structured assessment: What is your current status? Which processes already exist? Where are the gaps?
Development and harmonization of missing or incomplete processes. Focus on SSDLC, Vulnerability Management and regulatory-compliant documentation.
Live implementation: processes are operationally embedded, tools are actually deployed and security activities are documented.
Final preparation for audits (internal or regulatory). Documentation is consolidated, consistency is reviewed, remaining gaps are closed.
Analysis → Design → Implementation → Support – a proven, iterative method.
VamiSec has years of experience guiding medical technology companies through the compliance journey. Our method is structured, iterative and oriented toward real product development processes – not idealized models.
Comprehensive assessment and target-actual comparison.
Definition of the target document structure, process definition, and tool selection.
Live implementation: SOPs are written, tools are configured, teams are trained.
After go-live: support, monitoring, and adaptation to new regulations/threats.
Your program is led by a multidisciplinary team:
Cybersecurity for medical devices is embedded in a complex web of standards and guidelines. Each standard governs a specific aspect: MDR regulates market surveillance, MDCG 2019-16 details the security requirements, IEC standards define the technical implementation, and ISO 14971 governs risk management.
European regulation for all medical devices. Defines requirements for manufacturers, quality management system, clinical evaluation, post-market surveillance, vigilance reporting, and EUDAMED.
Annex I requires "state-of-the-art cybersecurity" (detailed in MDCG 2019-16). Cybersecurity risk management is an integral part of the QMS.
Official European guideline from the Medical Device Coordination Group. Details the MDR requirements on cybersecurity.
Lifecycle phases, security capabilities, operating environment requirements, defense-in-depth, threat modeling, post-market surveillance, vigilance, and references to IEC standards (62304, 81001-5-1, 62443, etc.).
International standard for the software lifecycle in medical devices. Defines activities in every phase: planning, design, implementation, testing, release, maintenance.
MDCG 2019-16 references IEC 62304 for SDLC requirements. Cybersecurity must be integrated into every phase.
International standard for network and communication security in connected medical devices (IoT devices, cloud-based systems).
Authentication, encryption, integrity, access control, logging, update management, network segmentation.
International standard for cybersecurity in critical systems (automotive, energy, automation). Frequently applied to medical devices with a high security requirement profile.
4-level maturity model: Level 1 (basic) through Level 4 (advanced). Security Capability Levels (SCL) define the required technical measures.
Standard for product security engineering, originally from the automotive industry. Increasingly applied to medical devices.
Risk-based approach: threat modeling, vulnerability assessment, secure design, secure development, security testing, post-launch monitoring.
International standard for risk management in medical devices. Mandatory under the MDR.
MDCG 2019-16 requires: cybersecurity risks must be integrated into the ISO 14971 risk register. There is no separate cybersecurity risk management process – everything is a single risk analysis.
European regulation for the cybersecurity of digital products & services. Complementary to the MDR; enters into force in 2025/2026.
Expands the cybersecurity requirements beyond pure safety: integrity and availability must be protected as well.
European General Data Protection Regulation. Governs the handling of patient data.
Medical devices that collect, store, or process patient data must be GDPR-compliant: privacy by design, data minimization, encryption, retention, breach notification.
Regulatory Know-how + Technical Depth + Operational Excellence
VamiSec is not just a security consulting firm – we are specialists in medical technology & GRC with years of hands-on experience in MDR, MDCG compliance and Secure SDLC. We combine deep regulatory know-how with technical security expertise and operational pragmatism.
You benefit from lessons learned across numerous implementations – without having to take the detours yourself.
Compliance that works & is integrated into your day-to-day operations – not additional bureaucracy.
Single point of contact, integrated thinking across security, compliance & risk – no fragmented knowledge.
Advice based on your needs, not on commission structures.
VamiSec introduces structured threat modeling based on DFD, STRIDE, and attack trees. After 4–6 weeks: a comprehensive, documented threat model per product.
SBOM generation + SCA tool integration into CI/CD. Within 2 weeks: a complete inventory of all dependencies with CVE checks and established patch management.
CSIRT setup + vulnerability management SOP. Now: CVE detection < 24h after release, assessment < 48h, patch decision in < 72h.
VamiSec maps MDCG requirements 1:1 to your existing processes or proposes additions. No extra bureaucracy – everything is integrated into your SDLC/QMS.
Cybersecurity for medical devices is not a single project – it's a continuous process. VamiSec is your partner in walking this path sustainably and successfully.
Request assessment
