IT-Sicherheit im Gesundheitswesen: Warum Software für Kliniken und Praxen angreifbar bleibt
IT-Sicherheit im Gesundheitswesen: Was das BSI im März 2026 gefunden hat
Drei BSI-Studien, neun Penetrationstests, ein Gesamtbild: Das Bundesamt hat am 17. März 2026 seine Ergebnisse veröffentlicht und bescheinigt der Branche deutliche Lücken. Unter den Namen SiPra, SiKIS und DiPS liefen Sicherheitsanalysen für Praxisverwaltungssysteme, Krankenhausinformationssysteme und Pflegedokumentationssoftware — also für den Kern dessen, was im Behandlungsalltag zwischen Patient und Leistungserbringer steht. Gefunden wurde in allen drei Kategorien dasselbe Muster: fehlende Verschlüsselung, veraltete kryptografische Verfahren, unsichere Authentifizierung, unzureichende Überprüfung von Software-Updates und Architektur-Schwächen. Die Branchensoftware für Praxen und Kliniken wurde von unabhängigen Teams getestet — mit ähnlich unerfreulichem Resultat. Die Übersicht zur Branchensoftware zeigt, wie sich das Feld strukturiert.
Sicherheit von Praxisverwaltungssystemen: Drei von vier angreifbar
SiPra untersuchte vier exemplarische Praxisverwaltungssysteme. Drei von vier Produkten waren aus dem Internet angreifbar — also genau das, was in einer typischen Praxis-Umgebung am meisten weh tut. Im Kern standen folgende Probleme:
- Keine Verschlüsselung der internen Datenübertragung
- Veraltete kryptografische Algorithmen
- Unsichere Authentifizierung von Anwendern
- Ungeprüfte Software-Updates auf Hersteller-Seite
- Architektur-Schwächen bei der Nutzerautorisierung
Die Hersteller wurden über Coordinated Vulnerability Disclosure informiert und haben die gemeldeten Lücken überwiegend behoben. Das ist die gute Nachricht. Die schlechte: In der nächsten Release-Generation tauchen vergleichbare Muster oft erneut auf — weil die Ursachen im Entwicklungsprozess liegen, nicht in einzelnen Codezeilen.
Kliniksysteme und Pflegedokumentation im Vergleich
SiKIS hat ein Fraunhofer-Team auf Krankenhausinformationssysteme angesetzt. Auf der Fraunhofer-SIT-Seite zur Studie sind die Ergebnisse für zwei getestete KIS zusammengefasst. Die Folgen im Klinikalltag sind unmittelbar spürbar:
❗ Aufnahmestopp in der Notaufnahme
❗ Manuelle Dokumentation als Rückfallebene
❗ Verschobene oder abgesagte Operationen
❗ Ausfall zentraler Labor- und Radiologie-Abfragen
❗ Störung kritischer Medikationsprozesse
DiPS widmete sich der Pflegedokumentation in der ambulanten Versorgung und fand bei drei Systemen Schwächen in Kommunikationsverschlüsselung, Authentifizierung und Update-Kontrolle. Die Muster wiederholen sich quer durch die Produktkategorien. Die meisten Lücken waren bei Veröffentlichung behoben — strukturell bleibt die Gefahr aber, weil die zugrundeliegenden Prozesse gleich sind.
BSI Gesundheitssoftware: Warum die Muster strukturell sind
Eine Erklärung über böswillige Einzelentwickler wäre bequem, aber falsch. Die BSI-Gesundheitssoftware-Befunde zeigen Muster, die in der Branche systematisch entstehen: gewachsene Code-Bases über zwei Jahrzehnte, fragmentierte Anbieterlandschaft, schmale Margen und eine lange Wartungspflicht bei gleichzeitig hoher Regulierung. Praxissoftware und KIS basieren oft auf einer technischen Grundlage, die älter ist als ihre aktuelle Produktversion. Updates stoßen auf schwer überblickbare Abhängigkeiten. Dazu kommt eine regulatorische Gemengelage — Medizinprodukterecht, §75b SGB V, KRITIS und NIS-2 — die Hersteller zwar diszipliniert, aber nicht automatisch sicher macht. Die Branche hat nicht zu wenig Regeln, sie hat zu viele ohne gemeinsamen Durchgriff.
Wer trägt die Verantwortung für die IT-Sicherheit im Gesundheitswesen?
Das BSI ist hier ungewöhnlich deutlich: Verantwortung verteilt sich auf Hersteller, Betreiber und Regulatoren gleichzeitig. Hersteller müssen Security-by-Design einbauen und Schwachstellen zeitnah schließen. Betreiber — also Kliniken, Praxen und Pflegedienste — sind für sichere Konfiguration, Monitoring und regelmäßige Updates zuständig. Regulatoren setzen den Rahmen, müssen ihn aber auch prüfen und durchsetzen. Keine dieser drei Ebenen kann die anderen ersetzen. In der Praxis scheitert die Verantwortung oft an der Schnittstelle: Hersteller liefern ein Update aus, aber ein Arzthaus in der Provinz installiert es erst Monate später. Der zentrale Leitfaden zur Software im Gesundheitswesen ordnet diese Rollen für den Einsatz in deutschen Einrichtungen praxisnah ein. Dieser Dreiklang spiegelt die Realität eines fragmentierten Marktes.
Das Zertifizierungs-Paradox
Paradox ist, dass die zertifizierungspflichtigen Teile der Kette oft die sichersten sind. Die Telematikinfrastruktur und KIM durchlaufen harte Prüfungen. Die umliegende Umgebungssoftware — Praxisverwaltung, Dokumentation, Schnittstellen-Clients — aber nicht. Ein sicherer Kernkanal nützt wenig ohne geschützten Anrufer. Genau an dieser Naht zwischen zertifiziertem Protokoll und nicht-zertifizierter Anwendung lagen die Schwachstellen, die das BSI dokumentiert hat. Ein reiner Blick auf Siegel übersieht diesen Bruch regelmäßig. Die zentrale Frage lautet daher nicht, ob ein Produkt zertifiziert ist, sondern was außerhalb der Zertifizierungsgrenze passiert — und wer dort prüft.
Telematikinfrastruktur, KIM und die unsichere Peripherie
Die BSI-Befunde stehen nicht isoliert. Sie treffen auf eine Gesundheits-IT, die gerade einen massiven Umbau erlebt: ePA, E-Rezept, DiGAs, TI-Gateway. Spezifische Prozesse des Umbaus beschreibt unser Beitrag zur Telematikinfrastruktur 2026. Die Kernprotokolle wie KIM sind solide — auf sie fallen die neuen Dienste zu Recht auf. Eingebettet sind diese Dienste aber in Softwareumgebungen, die teilweise auf demselben Fundament laufen, das die BSI-Studien jetzt angreifbar machen. Jede neue Anwendung — vom Medikationsplan bis zum Patientenportal — erbt die Sicherheitshaltung ihrer Hostsoftware. Das bekannteste Beispiel: E-Rezept und DiGA-Installation laufen beide in PVS-Umgebungen, die im BSI-Test auffällig wurden. Der Einblick in KIM zeigt, wo der Übergang von Protokoll zu Anwendung kritisch wird.
Sicherheit der Praxisverwaltungssysteme im KIM-Kontext
Die Sicherheit der Praxisverwaltungssysteme entscheidet darüber, wie gut die neue TI-Ebene im Alltag wirkt. Eine E-Rezept-Verordnung nützt wenig, wenn die umgebende PVS den Signaturprozess mit ungesicherten Tokens abwickelt. Ein Medikationsplan ist nur so vertraulich wie das Endgerät, das ihn abruft. Sicherheit in der Peripherie ist keine Zusatzaufgabe, sondern Voraussetzung für jede neue Telematik-Funktion, die im Versorgungsprozess ankommen soll. Die BSI-Befunde sind ein Weckruf: Nicht die Kernarchitektur ist das Problem, sondern das, was darum herum gebaut wurde. Nötig ist eine Sicherheitskultur, die jede Schnittstelle als potenziellen Angriffspunkt begreift. Auch im klinischen Alltag ist diese Haltung ein Gewinn — sie macht Sicherheit zur Selbstverständlichkeit, nicht zur Ausnahme.
IT-Sicherheit im Gesundheitswesen praktisch absichern
Was heißt das konkret für die IT-Sicherheit im Gesundheitswesen? Drei Rollen müssen handeln: Hersteller, Betreiber und Regulatoren. Aktuelle Entwicklungen zu IT-Sicherheit, Datenschutz und Digitalisierung sammelt der TenMedia Newsletter regelmäßig als eingeordnete News zu Cybersicherheit im Gesundheitswesen und Regulatorik. Die Kommentierungsfrist für die BSI-Handlungsempfehlungen läuft bis zum 17. Juni 2026 — ein seltenes Fenster, in dem die Branche die Praxis-Empfehlungen selbst mitgestalten kann. Zwei Handlungsfelder sind besonders konkret, wenn das Thema aus der Theorie in die Praxis finden soll. Die Zeit der Einzelstudien ist vorbei; die Zeit der praktischen Umsetzung beginnt.
Welche IT-Sicherheitsanforderungen gelten für Gesundheitssoftware?
Die regulatorische Landschaft ist dicht gewebt. Für Hersteller und Betreiber gelten parallel mehrere Regelwerke, die sich überlappen, aber nicht identisch sind:
- Medizinprodukterecht (MDR) — für Software mit medizinischem Zweck
- §75b SGB V — IT-Sicherheitsrichtlinie für Vertragsärzte
- KRITIS-Verordnung und BSIG — für größere Krankenhäuser
- NIS-2 Umsetzungsgesetz — neue Pflichten auch für Mittelgroße
- DSGVO — Schutz personenbezogener Gesundheitsdaten
- BSI IT-Grundschutz — als methodischer Rahmen
Jedes dieser Regelwerke hat eigene Nachweis- und Berichtspflichten. Eine gute Nachricht immerhin: Security-by-Design als Fundament deckt einen Großteil der Anforderungen automatisch ab. Ergänzend bietet der Leitfaden zum Schwachstellenmanagement für KRITIS eine strukturierte Hilfestellung für Kliniken, die unter das BSIG fallen.
Handlungsfelder für Hersteller und Betreiber
Zwei Akteursgruppen stehen besonders in der Verantwortung: die Hersteller der Software und die Einrichtungen, die sie einsetzen. Für beide gibt es konkrete nächste Schritte — keine fünfjährige Strategie, sondern Dinge, die sich noch in diesem Jahr spürbar umsetzen lassen.
Was Hersteller jetzt tun können
Hersteller haben zwei Baustellen: laufende Produkte und Entwicklungsprozesse. Bei den laufenden Produkten zählen schnelle Reaktion auf BSI-Funde, transparente Release Notes und eine saubere Coordinated Vulnerability Disclosure. Ein strukturiertes Patch Deployment auch für KRITIS-Betreiber ist die Voraussetzung dafür, dass Updates überhaupt bei den Anwendern ankommen. Bei den Entwicklungsprozessen geht es um Secure Coding, automatisierte Tests und ein SBOM für jede Auslieferung. Nicht mehr die Frage ist, ob Schwachstellen auftreten, sondern wie lange sie unentdeckt bleiben — und wie schnell sie geschlossen werden. Gerade bei Produkten für §75b-SGB-V-pflichtige Praxen gilt: Schnelligkeit schützt auch vor Haftungsfragen. Die Ressourcen sind knapp, aber die Prioritäten lassen sich setzen.
Was Kliniken und Praxen jetzt tun können
Betreiber sind bei der Konfiguration am Zug. Updates zeitnah einspielen, Admin-Konten separieren, Log-Daten zentral auswerten — das sind die minimalen Hygienemaßnahmen. Größere Einrichtungen bewegen sich bereits in Richtung Zero-Trust-Architektur, in der kein Netzwerksegment pauschal vertrauenswürdig ist.
Für kleinere Praxen reicht oft schon konsequente Segmentierung: Behandlungsnetz, Verwaltungsnetz, Besucher-WLAN getrennt. Sicherheit entsteht durch viele kleine Entscheidungen, die in der Summe einen Unterschied machen. Der BSI-Befund vom März 2026 ist dafür ein guter Anlass, diese Entscheidungen neu zu sortieren. Am Ende zählt nicht das schönste Sicherheitsprodukt, sondern die Disziplin, dran zu bleiben — über mehrere Jahre, quer durch Personalwechsel und Update-Wellen.
