Medizinische Wearables erfassen kontinuierlich Herzfrequenz, Blutsauerstoff, EKG-Signale und Schlafmuster. Diese Daten sind nicht nur datenschutzrelevant – sie beeinflussen klinische Entscheidungen. Die Datenübertragung in medizinischen Wearables muss deshalb bereits in der Systemarchitektur abgesichert sein, nicht als nachgelagertes Feature. Wer das ignoriert, riskiert Zertifizierungsverzögerungen, regulatorische Bußgelder und im schlimmsten Fall kompromittierte Patientendaten.

Dieser Artikel behandelt die zentralen Entscheidungen rund um Datensicherheit in Wearables: welche Mechanismen unter realen Ressourcenbeschränkungen funktionieren, wo Entwickler systematisch Fehler machen und welche regulatorischen Anforderungen konkret umgesetzt werden müssen.

Was sichere Datenübertragung in medizinischen Wearables bedeutet

Gesundheitsdaten müssen zwischen Gerät, Smartphone-App und Backend-Server übertragen werden, ohne dass sie abgehört, verändert oder unbefugt abgerufen werden können. Das erfordert Verschlüsselung, Authentifizierung und kryptografische Integritätsprüfungen – nicht als optionale Schichten, sondern als Grundvoraussetzung für den Betrieb.

Im medizinischen Kontext reicht technische Absicherung allein nicht aus. Daten müssen ausschließlich von autorisierten Empfängern lesbar sein, und jede Manipulation auf dem Übertragungsweg muss erkennbar und abweisbar sein. Ein Wearable, das Vitalparameter an ein klinisches System überträgt, ohne Integritätsschutz zu implementieren, kann zu falschen Therapieentscheidungen führen – ein Risiko, das weit über den Datenschutz hinausgeht.

Sicherheitslücken in dieser Schicht führen in der Praxis zu zwei Konsequenzen: regulatorischen Nachweispflichten, die nicht erfüllt werden können, und Produktrückrufen, die bei Klasse-II- und Klasse-III-Geräten nach MDR erhebliche Kosten verursachen.

Angriffsvektoren, die medizinische Wearables am häufigsten treffen

Die häufigsten Angriffsvektoren sind unsichere drahtlose Verbindungen, schwache Authentifizierungsmechanismen, ungeschützte Firmware-Update-Pfade und unverschlüsselte lokale Datenspeicherung. BLE-Verbindungen und offene API-Endpunkte sind dabei besonders exponiert.

Die relevanten Bedrohungskategorien im Überblick:

• Kommunikationsangriffe: Unverschlüsselte BLE- oder Wi-Fi-Verbindungen ermöglichen Man-in-the-Middle-Angriffe. Ein Angreifer in Reichweite kann Gesundheitsdaten abfangen oder gezielt verändern – ohne dass Gerät oder App dies erkennen, wenn keine Integritätsprüfung implementiert ist.
• Gerätemanipulation: Fehlt ein Secure-Boot-Mechanismus, kann kompromittierte Firmware aufgespielt werden. Das verändert das Messverhalten des Geräts, ohne dass dies für Nutzer oder klinisches Personal sichtbar ist.
• Datenzugriff: Ungeschützte lokale Speicher oder fehlende TLS-Pinning-Implementierungen auf API-Ebene ermöglichen unbefugten Zugriff auf gespeicherte Patientendaten – auch ohne physischen Gerätezugriff.

Geräte mit langer Akkulaufzeit und eingeschränkten Rechenressourcen erzeugen einen realen Druck, Sicherheitsmechanismen zu reduzieren. Dieser Trade-off ist nur dann vertretbar, wenn er auf Basis einer dokumentierten Risikoanalyse nach ISO 14971 getroffen wird. Ohne diese Dokumentation ist er ein Zertifizierungsrisiko.

Verschlüsselungsprotokolle für ressourcenbeschränkte medizinische Wearables

Für die Backend-Kommunikation sind TLS 1.2 und TLS 1.3 der aktuelle Stand der Technik. Für lokale Datenverschlüsselung eignet sich AES-128 oder AES-256. Auf Geräten mit unter 64 KB RAM und begrenzter CPU-Leistung ist ChaCha20-Poly1305 eine technisch begründete Alternative zu AES-GCM.

Verschlüsselung auf Transportebene

TLS 1.3 reduziert den Verbindungsaufbau auf einen Round-Trip, bietet Forward Secrecy per Default und schließt bekannte Angriffsmuster aus TLS 1.2 aus. Für Embedded-Systeme mit eingeschränktem Speicher empfehlen sich optimierte Stacks wie mbedTLS oder wolfSSL. wolfSSL benötigt ab ca. 20–100 KB Flash je nach Konfiguration und unterstützt FIPS 140-2, was für FDA-regulierte Produkte relevant ist.

Ein häufiger Fehler: Teams implementieren TLS korrekt, verzichten aber auf Certificate Pinning. Ohne Pinning bleibt ein kompromittiertes CA-Zertifikat ein valider Angriffsvektor – relevant bei Geräten mit mehrjährigem Feldeinsatz.

Verschlüsselung auf Geräteebene

Lokal zwischengespeicherte Daten müssen mit AES-256 im GCM-Modus verschlüsselt werden. GCM liefert neben Vertraulichkeit einen integrierten Authentifizierungs-Tag, der Datenmanipulation auf dem Speicher erkennbar macht. Schlüssel gehören in ein dediziertes Secure Element oder einen Hardware Security Module – nicht in Flash-Speicher. Geräte ohne Secure Element, die Schlüssel im normalen Flash ablegen, verlieren alle kryptografischen Garantien bei physischem Gerätezugriff.

Die Wahl des Secure Elements beeinflusst auch die Zertifizierungsstrategie: Komponenten mit Common Criteria EAL4+ oder höher vereinfachen den Nachweis gegenüber Benannten Stellen nach MDR.

BLE-Verbindungen in medizinischen Geräten absichern

BLE-Verbindungen erfordern LE Secure Connections mit ECDH-basiertem Pairing, aktivierte Verschlüsselung und Authentifizierung auf GATT-Ebene sowie Bonding, das Verbindungsversuche auf bekannte Geräte beschränkt. Advertising-Pakete dürfen keine Gesundheitsdaten enthalten.

Konkrete Maßnahmen für BLE-Sicherheit in der Medizintechnik:

• Legacy Pairing deaktivieren – es bietet keinen Schutz gegen passive Angriffe
• Numeric Comparison oder Out-of-Band Pairing verwenden, um Man-in-the-Middle-Angriffe beim Pairing-Prozess auszuschließen
• Advertising-Intervalle auf das funktional notwendige Minimum reduzieren, keine Gerätekennungen oder Messwerte in Advertising-Paketen übertragen
• Verbindungsversuche auf gebondete Geräte beschränken und unbekannte Verbindungsanfragen ablehnen
• Schlüsselrotation nach definierten Zeitintervallen oder Verbindungsanzahlen implementieren

Ein spezifisches Fehlerbild: BLE-Stacks vieler Mikrocontroller-Hersteller aktivieren Legacy Pairing als Fallback, wenn der Verbindungspartner LE Secure Connections nicht unterstützt. Ohne explizite Deaktivierung dieses Fallbacks akzeptiert das Gerät unsichere Verbindungen – auch wenn die Firmware korrekt konfiguriert scheint. Das muss auf Protokollebene verifiziert werden, nicht nur im Code-Review.

Regulatorische Anforderungen an die Datensicherheit medizinischer Wearables

In der EU gelten DSGVO und MDR, in den USA HIPAA. Alle drei Regelwerke verlangen technische Schutzmaßnahmen für Gesundheitsdaten und nachweisbare Sicherheitskonzepte. CE-Zertifizierung nach MDR dauert typischerweise 12–24 Monate für Klasse-II-Geräte; fehlende Cybersicherheitsnachweise verlängern diesen Prozess.

Die DSGVO schreibt Privacy by Design vor: Datensparsamkeit, dokumentierte Einwilligungsprozesse und technisch umgesetztes Recht auf Datenlöschung müssen in der Systemarchitektur verankert sein, nicht nur in der Datenschutzerklärung. Die MDR behandelt Cybersicherheit als Teil des Risikomanagements nach ISO 14971 – fehlende Threat-Modeling-Dokumentation ist ein häufiger Grund für Beanstandungen durch Benannte Stellen.

Für den US-Markt schreiben die HIPAA-Anforderungen Zugriffskontrollen, Audit-Logs und verschlüsselte Übertragung aller Protected Health Information (PHI) vor. Verstöße werden mit 100–50.000 USD pro Verstoß geahndet, bei nachgewiesener Fahrlässigkeit bis zu 1,9 Mio. USD jährlich pro Verstoßkategorie. Teams, die beide Märkte adressieren, unterschätzen regelmäßig den Aufwand für die parallele Dokumentation: DSGVO und HIPAA haben überlappende, aber nicht identische Nachweisanforderungen. Eine gemeinsame Sicherheitsarchitektur ist möglich, erfordert aber frühzeitige regulatorische Planung – spätestens ab Systemdesign-Phase, nicht erst vor der Einreichung.

Datensicherheit im Entwicklungsprozess verankern

Sicherheitsanforderungen, die erst nach dem Hardwaredesign ergänzt werden, erhöhen den Entwicklungsaufwand um typischerweise 30–50 % und verzögern die Zertifizierung. Ein Secure-by-Design-Ansatz integriert Sicherheitsanforderungen ab der Konzeptphase in die Systemarchitektur.

Konkrete Maßnahmen im Entwicklungsprozess:

1. Threat Modeling in der Konzeptphase: Systematische Analyse potenzieller Angriffsflächen vor dem ersten Schaltplandesign. STRIDE oder PASTA liefern eine dokumentierbare Grundlage für die MDR-Risikoakte.
2. Schlüsselverwaltung von Anfang an festlegen: Wo werden kryptografische Schlüssel erzeugt, gespeichert und rotiert? Diese Entscheidung beeinflusst die Hardware-Komponentenauswahl und kann nicht nachträglich ohne Redesign geändert werden.
3. Secure Boot und Code Signing: Nur signierte Firmware darf auf das Gerät aufgespielt werden. Die Implementierung erfordert eine Root-of-Trust-Infrastruktur, die in der Produktionslinie verankert sein muss – ein oft unterschätzter Aufwand von 4–8 Wochen.
4. Penetrationstests vor der Zertifizierung: Gezielte Angriffssimulationen identifizieren Schwachstellen, bevor sie in der Zertifizierungsprüfung oder im Feld auftreten. Bei Klasse-II-Geräten nach MDR sind externe Penetrationstests zunehmend Erwartung der Benannten Stellen.
5. OTA-Update-Mechanismen absichern: Over-the-Air-Updates müssen signiert und verschlüsselt sein. Ein unsignierter Update-Pfad negiert alle anderen Sicherheitsmaßnahmen – er ist der direkteste Weg, kompromittierte Firmware auf ein bereits zertifiziertes Gerät zu bringen.

Teams, die Sicherheit als letzten Entwicklungsschritt behandeln, stehen vor dem Problem, dass Hardware-Entscheidungen – fehlende Secure-Element-Unterstützung, unzureichender Flash für TLS-Stacks – nicht mehr korrigierbar sind. Die Konsequenz ist entweder ein Hardwarerework oder eine reduzierte Sicherheitsarchitektur, die den regulatorischen Nachweis erschwert.

Wie Oxeltech bei der sicheren Datenübertragung in medizinischen Wearables hilft

Oxeltech entwickelt Firmware und Embedded-Software für medizinische Wearables mit direktem Fokus auf Sicherheit, Zuverlässigkeit und regulatorische Konformität. Aus über 20 Hardwareprojekten vom Konzept bis zur Serienreife resultiert eine praxiserprobte Methodik, die Sicherheitsanforderungen ab der ersten Designphase in die Systemarchitektur integriert.

Konkrete Leistungen für Kunden:

• Implementierung sicherer BLE-Verbindungen und verschlüsselter Datenübertragung auf Firmware-Ebene, einschließlich Verifikation auf Protokollebene
• Auswahl und Integration geeigneter Verschlüsselungsprotokolle und TLS-Stacks für ressourcenbeschränkte Embedded-Systeme
• Umsetzung von Secure Boot, Code Signing und sicheren OTA-Update-Mechanismen inklusive Produktions-Key-Infrastruktur
• Vorbereitung auf regulatorische Anforderungen nach DSGVO, MDR und HIPAA, einschließlich Dokumentation für Benannte Stellen
• Threat Modeling und Security Reviews über den gesamten Entwicklungszyklus nach STRIDE und ISO 14971

Ob Neuentwicklung oder sicherheitstechnische Verbesserung eines bestehenden Produkts: Oxeltech begleitet von der Konzeptphase bis zur erfolgreichen Zertifizierung. Sprechen Sie uns an und erfahren Sie, wie Ihr Projekt sicher und termingerecht umgesetzt werden kann.