Veröffentlicht am 15. Oktober 2026

Sicherheit bei Medizinprodukten ist mehr als Compliance. Ein Medizinprodukt kann alle Normen erfüllen und trotzdem angreifbar sein. Normen wie IEC 81001-5-1 oder die Anforderungen der MDR beschreiben, was ein Hersteller nachweisen muss. Sie garantieren nicht, dass ein Angreifer scheitert. Compliance belegt also, dass Prozesse eingehalten wurden, sie ist aber nicht das Ziel. Ob ein Produkt tatsächlich sicher ist, entscheidet sich über den ganzen Lebenszyklus: im Design, in der Entwicklung und im Markt. Wer Security by Design ernst nimmt, setzt deshalb früh an und denkt über die Checkliste hinaus. Dieser Beitrag zeigt, wo Scheinsicherheit entsteht und wie Hersteller sie vermeiden. Dieser Beitrag zeigt, wo Scheinsicherheit entsteht und wie Hersteller sie vermeiden.

Wer nach Sicherheit fragt, bekommt meist vier Antworten: kein Patientenschaden, Daten geschützt, CE-Kennzeichnung, bestandener Pentest. Die ersten beiden beschreiben eine Wirkung, die anderen beiden sind nur Nachweise. Dahinter stehen drei Fragen:

Compliance ist der Nachweis, nicht das Ziel. Das Ziel liegt dort, wo sich alle drei treffen: sicher und nachweisbar. Scheinsicherheit entsteht am Rand. Compliance ohne Schutz wirkt sicher, ist es aber nicht, und Schutz ohne Nachweis lässt sich nicht belegen. Wo Safety und Security zusammentreffen, wird ein Angriff zum Patientenschaden: Ein manipulierter Messwert führt zu einer falschen Therapieentscheidung.

Je später Security in ein Projekt kommt, desto teurer und weniger wirksam wird sie. Security by Design beginnt deshalb bei den Anforderungen. Aus Intended Use, Einsatzumgebung und Regulatorik entstehen Security-Anforderungen, die mit der Cybersecurity-Risikoanalyse in einem iterativen Kreislauf stehen. Die Analyse ist nie zu Projektbeginn fertig, weil sie neue Anforderungen erzeugt.

Die Prinzipien lauten Secure Defaults, Least Privilege, Defense in Depth und testbar formulierte Anforderungen. „Das System muss sicher sein” lässt sich nicht prüfen. „Updates sind signiert und werden vor der Installation geprüft” schon.

Die Architektur legt früh fest, was später schützbar ist. Zwischen Gerät oder App, Cloud-Backend und möglicher Klinik-IT verlaufen Vertrauensgrenzen. Dazu gehören Segmentierung, Authentisierung zwischen den Komponenten, Autorisierung im Backend, signierte Updates, Kryptoagilität und bei der Cloud die geklärte Shared Responsibility.

Ein Fallbeispiel ist der Login. Angreifende ohne Zugang müssen erst Lücken finden. Angreifende mit gültigem Login agieren wie normale Nutzende: Die Kontrollen greifen nicht, und die Logs sehen normal aus. Entscheidungen wie „MFA optional”, „Passwortregeln legt der Betreiber fest” oder „keine Sperre nach Fehlversuchen” sind oft unbewusste Risikoakzeptanz. Passwörter bedeuten Merken, Tippen, Zurücksetzen, Phishing und den Post-it am Monitor. Der sichere Weg muss der einfachste sein und dabei gibt es viele Systeme, die einen helfen:

Ziel muss es sein, dass die Verwendung eines sicheren Login-Systems für den Anwender einfacher ist, als eine Passworteingabe. Das schafft Akzeptanz und Sicherheit zugleich. Und Passwort-Reset und Kontowiederherstellung gehören genauso abgesichert.

Wer Angriffe kennt, entwickelt anders. Das gelingt produktnah statt mit Pflicht-E-Learning, mit Beispielen aus dem eigenen System, mit Security im Code Review, mit den OWASP Top 10 als Referenz und mit einer Fehlerkultur, in der Findings willkommen sind.

Ein Security Expert braucht ein echtes Mandat. Die IEC 81001-5-1 gehört in den Software-Entwicklungsprozess, Security in die Definition of Done. Die Dokumentation entsteht mit dem Produkt und wird nicht rückwärts geschrieben. Ihr Rückgrat ist die Traceability von der Bedrohung über die Anforderung zum Test.

Tools gehören in die CI-Pipeline: Secret Scanning beim Commit, statische Codeanalyse (SAST) und Dependency-Scanning (SCA) im Build, Fuzzing und dynamische Tests (DAST) im Test, IaC-Scanning und Pentest zum Release. Ein Tool ohne Triage-Prozess ist Scheinsicherheit.

Schnelle Erfolge bringen Dependency-Scanning, Secure Defaults, moderne Login-Verfahren und ein benannter Security Champion. Dauerhaft wirken Ownership im Team, Security in der Definition of Done und eine Fehlerkultur. Wenig Nutzen bringen Pflicht-E-Learning, rückwärts geschriebene Dokumentation und Tools ohne Triage.

Eine Software Bill of Materials (SBOM) ohne Monitoring ist ein Dokument, keine Maßnahme. Der Kreislauf läuft kontinuierlich: SBOM im Format CycloneDX oder SPDX, Abgleich mit der National Vulnerability Database und CSAF-Advisories, Bewertung mit VEX (ist die Schwachstelle ausnutzbar?) und Maßnahme: Patch, Hinweis oder Akzeptanz.

Die Post-Market Surveillance für Cybersecurity speist sich aus Threat Intelligence, BSI- und CERT-Meldungen, Logging und Anomalieerkennung, einer Policy für koordinierte Schwachstellenmeldungen (CVD) und den Rückmeldungen der Betreiber.

Bei einem Vorfall läuft die Incident Response in sechs Schritten: erkennen, bewerten (durch das PSIRT), melden, patchen, wiederherstellen, lernen. Bei den Meldepflichten sind die MDR-Vigilanz, die DSGVO mit 72 Stunden und NIS2 zu prüfen, falls der Hersteller betroffen ist. Zur Wiederherstellung gehören Backup und Restore, Disaster Recovery in der Cloud und die Kommunikation an die Betreiber. Üben, bevor es ernst wird.

Akzeptiert heißt nicht für immer. Eine neue Angriffstechnik, eine neue CVE, eine Architekturänderung oder ein festes Intervall lösen die Neubewertung aus. Auch das Lebenszyklusende gehört dazu: Bei angekündigtem End-of-Support und Legacy im Feld muss das geplant und an die Betreiber kommuniziert werden.

Die Bedrohungslage verschiebt sich in drei Richtungen: KI-gestützte Angriffe (perfektes Phishing, automatisierte Schwachstellensuche, schnellere Exploits), Cloud-Abhängigkeit (Ausfall als Versorgungsrisiko, Fehlkonfiguration, Shared Responsibility) und Supply Chain (Bibliotheken, Build-Pipeline, Dienstleister). Die Regulatorik zieht nach.

Bereits relevant:

Kommt:

• Cybersecurity – Risikomanagement über den Produktlebenszyklus, sichere Softwarearchitektur und Dokumentation nach EU-, FDA- und BSI-Vorgaben.
• Post-Market Surveillance – Wir begleiten Dich auch nach dem Inverkehrbringen: Überwachung von Fehlerprotokollen, Marktbegleitern und Cybersecurity-Informationen, um Risiken früh zu erkennen.

• Verordnung (EU) 2017/745 (MDR), konsolidierte Fassung
• BfArM, Cybersicherheit von Medizinprodukten
• MDCG 2019-16 Rev. 1, Guidance on Cybersecurity for medical devices
• FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, Februar 2026
• Verordnung (EU) 2024/2847 (Cyber Resilience Act), insbesondere Artikel 2 Absatz 2, Artikel 14, Artikel 69 und Artikel 71
• Verordnung (EU) 2024/1689 (KI-Verordnung)
• Richtlinie (EU) 2022/2555 (NIS-2-Richtlinie)
• Gesetz über das Bundesamt für Sicherheit in der Informationstechnik (BSIG), neue Fassung
• BSI, Fragen und Antworten zu NIS-2
• Verordnung (EU) 2016/679
• ISO 14971, IEC 62304 und IEC 81001-5-1