BSI TR-03161 Zertifizierung – Praxis-Guide für DiGA

Von Christoph Eberhardt · CEO, DUX Healthcare · Stand 19. April 2026

Die BSI TR-03161 – die Technische Richtlinie des Bundesamts für Sicherheit in der Informationstechnik (BSI) mit dem Titel „Anforderungen an Anwendungen im Gesundheitswesen" – ist der regulatorische Hebel, der darüber entscheidet, ob eine Digitale Gesundheitsanwendung (DiGA) beim Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) eingereicht werden kann oder nicht. Seit dem 01. Juli 2025 ist das TR-03161-Zertifikat formale Voraussetzung für die Vollständigkeit des Antrags: kein Zertifikat, kein Listing (DiGA-Leitfaden v3.6 Kap. 3.4). Teams, die sich auf Deutschland vorbereiten, behandeln TR-03161 in der Planung oft als Nebenstrang für das letzte Quartal. In der Praxis ist sie eine der tragenden Architekturentscheidungen eines DiGA-Projekts — und der Cybersicherheits-Maßstab, gegen den fünf DiGA-Projekte unter Vertrag auf der mHealth Suite je einzeln geprüft wurden. Dieser Artikel ist eine Praxis-Einordnung dessen, was TR-03161 wirklich verlangt, was Zertifizierung realistisch kostet, wo Teams stolpern und wie der Ausgang „ohne Auflagen" vs. „mit Auflagen" entschieden wird.

Was BSI TR-03161 ist – und was nicht

TR-03161 ist eine Technische Richtlinie, keine Verordnung und kein Gesetz. Die rechtliche Bindung für DiGA-Antragsteller entsteht erst durch § 139e Abs. 10 SGB V und die DiGAV (Digitale-Gesundheitsanwendungen-Verordnung), die gemeinsam verlangen, dass Hersteller die Datensicherheit nach den BSI-Technischen Richtlinien nachweisen. Der DiGA-Leitfaden v3.6 (Stand 10.12.2025) des BfArM operationalisiert das: „Seit dem 01.07.2025 ist die Vorlage [eines TR-03161-Zertifikats] Voraussetzung für die formale Vollständigkeit des Antrags" (DiGA-Leitfaden v3.6 Kap. 3.4↗). Das ISMS-Zertifikat nach ISO 27001 ist separat verpflichtend und laut Leitfaden explizit kein Ersatz für TR-03161.

Die Richtlinie gliedert sich in drei Teile, jeder für eine andere Deployment-Oberfläche:

• Teil 1 – Mobile Anwendungen (Anforderungen an mobile Anwendungen im Gesundheitswesen), Version 3.0 – native und hybride Apps auf iOS und Android (BSI TR-03161-1 Kap. 2.1).
• Teil 2 – Web-Anwendungen (Anforderungen an Web-Anwendungen), Version 2.0 – browserbasierte Anwendungen einschließlich PWAs (BSI TR-03161-2 Kap. 1.1).
• Teil 3 – Hintergrundsysteme (Anforderungen an Hintergrundsysteme), Version 2.0 – Serverseite, selbst gehostet, extern gehostet oder Cloud (BSI TR-03161-3 Kap. 1.1).

Jeder Teil beginnt mit einer Security Problem Definition (SPD) – dem aus den Common Criteria übernommenen Begriff für die formale Beschreibung von Annahmen, Bedrohungen und Organisational Security Policies (OSPs), gegen die die Anwendung evaluiert wird. Die konkreten Anforderungen, kategorisiert nach O.Arch (Architektur), O.Cryp (Kryptographie), O.Auth (Authentifizierung), O.Data (Datensicherheit), O.Ntwk (Netzwerk) und O.Org (Organisation), leiten sich aus der SPD ab. TR-03161 ist damit keine Checkliste, sondern eine strukturierte Evaluation gegen ein benanntes Bedrohungsmodell.

Was TR-03161 nicht ist: keine IT-Sicherheitsprüfung des Unternehmens als Ganzes, kein ISMS-Audit, keine DSGVO-Datenschutzprüfung (die lebt in den separaten BfArM-Datenschutzprüfkriterien nach § 139e Abs. 11 SGB V) und keine klinische Risiko- oder Softwaresicherheits-Bewertung (dafür gelten IEC 62304 und ISO 14971).

Die drei Teile – Mobile, Web, Backend

Eine typische DiGA – Mobile-App plus Web-Admin plus Cloud-Backend – wird in einem koordinierten Assessment gegen alle drei Teile evaluiert. Jeder Teil strukturiert seine Anforderungen nach Prüfaspekten. Teil 3 listet zehn: Anwendungszweck, Architektur, Quellcode, Drittanbieter-Software, Kryptographie, Authentifizierung, Datenspeicherung und -schutz, kostenpflichtige Ressourcen, Netzwerkkommunikation, organisatorische Sicherheit (BSI TR-03161-3 Kap. 3.1). Teile 1 und 2 spiegeln diese Struktur mit oberflächenspezifischen Anpassungen.

Einige konkrete Anforderungen, die internationale Teams regelmäßig unterschätzen:

• O.Arch_1: „Security MUSS ein fester Bestandteil des Softwareentwicklungs- und Lebenszyklus’ für die gesamte Anwendung sein." Der Prüfer sucht nach gelebter Prozess-Evidenz, nicht nach Dokumentations-Artefakten.
• O.Cryp_1: keine hartkodierten Geheimnisse oder privaten Schlüssel. Trivial im Prinzip, grep-überraschend in einer drei Jahre alten Codebase.
• O.Data_1: „Die Werkseinstellung der Anwendung MUSS die maximale Sicherheit bieten." Secure-by-default kollidiert regelmäßig mit Produktentscheidungen, die First-Use-Reibung reduzieren wollen.
• O.Ntwk_1 (Teil 3): durchgehende Transportverschlüsselung, auch innerhalb des Backend-Netzes. Teams mit unverschlüsseltem Intra-VPC-Traffic fallen hier klar durch.
• O.Org_1 (Teil 3): ein zertifiziertes ISMS nach ISO 27001 (oder IT-Grundschutz, oder äquivalent) ist eine innerhalb der TR-03161 geforderte Voraussetzung, nicht nur eine parallele DiGAV-Pflicht.

Die RFC-2119-Schlüsselwörter zählen: MUSS ist nicht verhandelbar; SOLL darf nur entfallen, wenn der Hersteller nachweist, dass kein Risiko entsteht; KANN ist optional, aber erkennbar (BSI TR-03161-1 Kap. 1.3.2). Ein MUSS als SOLL zu behandeln ist eine häufige Ursache für „mit Auflagen"-Ausgänge.

Der Zertifizierungsprozess – Prüfstelle und BSI-Bestätigung

Die formale Zertifizierungssequenz für eine DiGA gegen TR-03161 läuft wie folgt:

1. Scoping und Teilauswahl. Der Hersteller definiert das Target of Evaluation (ToE) – welche DiGA-Version, welche Komponenten, welche Deployment-Flächen. Teilauswahl folgt: Mobile (Teil 1), Web (Teil 2), Backend (Teil 3). Nicht vorhandene Komponenten werden ausgeschlossen und die Begründung dokumentiert.
2. Evidenz-Vorbereitung. Ein Dokumentations-Set: Architekturbeschreibung, Authentifizierungs- und Kryptographie-Konzepte, Datenflussdiagramme, Drittanbieter-Software-Inventar, SDLC-Beschreibung, Risikoanalyse. Die Risikoanalyse folgt einer dokumentierten Methodik – BSI-Standard 200-3, ISO 27005 oder Anhang B der Common Criteria Evaluation Methodology (CEM) sind die explizit genannten Referenzen (BSI TR-03161-1 Kap. 5).
3. Prüfstellen-Assessment. Eine Prüfstelle – vorzugsweise BSI-akkreditiert, nach Empfehlung des DiGA-Leitfadens (DiGA-Leitfaden v3.6 Kap. 3.4.2) – führt Dokumenten-Review, Whitebox-Code-Review und Penetrationstests aller im Scope befindlichen Komponenten einschließlich Backend durch. Referenz: OWASP Top 10 für Backend und Web, OWASP MASVS/MSTG für Mobile.
4. Risikoanalyse und Restrisiko-Beurteilung. Der Prüfer bewertet methodisch gegen jede Kategorie verarbeiteter Daten, klassifiziert nach Kritikalität. Hier wird „ohne Auflagen" vs. „mit Auflagen" entschieden – siehe unten.
5. Report und Zertifikat. Die Prüfstelle erstellt einen Prüfbericht; das resultierende Zertifikat ist das Artefakt, das der Hersteller mit dem BfArM-Antrag (Anlage I DiGAV) zum Nachweis der Konformität mit § 139e Abs. 10 SGB V einreicht. Es ist an eine spezifische DiGA-Version gebunden.
6. Aufrechterhaltung der Zertifizierung. Nach Leitfaden Kap. 3.4 ist „für die Aufrechterhaltung des Zertifikats der Hersteller selbst verantwortlich". Wesentliche Veränderungen nach § 18 DiGAV lösen in der Regel eine Re-Evaluation aus.

Der deutsche Prüfstellen-Markt ist überschaubar: eine Handvoll BSI-akkreditierter Labore plus ein breiteres Feld erfahrener Common-Criteria-Labore tragen den Großteil der DiGA-Zertifizierungen. Die Erfahrung einer Prüfstelle mit den TR-03161-Teilen macht einen materiellen Unterschied – Prüfstellen, die dutzende DiGAs zertifiziert haben, arbeiten effizienter durch das Verfahren als Stellen, die ihr erstes DiGA-Mandat angehen.

„Ohne Auflagen" vs. „mit Auflagen" – wie der Ausgang wirklich entschieden wird

TR-03161 ist kein binäres Pass/Fail-Instrument. Tabelle 15 aus Teil 1 (BSI TR-03161-1 Kap. 5, Tabelle 15) macht die Kritikalitäts-zu-Ausgang-Zuordnung explizit. Die relevante Zeile im Wortlaut:

„Hoch – Eine Verletzung des Schutzbedarfs führt zu einem hohen oder mittleren Schaden für den Dateninhaber. Die realisierten Maßnahmen reduzieren die Risikoszenarien erheblich. … Im Einzelfall ist das Restrisiko darzustellen und kann Auflagen in der Nutzung der Zertifizierung verursachen."

Für Daten der Kritikalität „Hoch" dokumentiert der Prüfer das Restrisiko nach allen implementierten Maßnahmen. Beurteilt er die Maßnahmen als „erheblich risikomindernd", kann das Zertifikat mit Auflagen in der Nutzung ausgestellt werden – der klassische „mit Auflagen"-Ausgang. Für Daten der Stufe „Sehr hoch" (z. B. unschützbare Gesundheitsdaten) verlangt der Standard die Eliminierung sämtlicher Risikoszenarien ohne Restrisiko – faktisch die „ohne Auflagen"-Schwelle für die hochsensitive Datenklasse.

Die praktische Implikation: „Ohne Auflagen" ist keine universelle Erwartung. Es ist ein spezifischer Ausgang, der voraussetzt, dass Restrisiken auf hochkritischen Datenpfaden eliminiert werden. In sauber architektierten, plattform-entwickelten DiGAs ist er erreichbar; in nachgerüsteten Codebases selten. „Mit Auflagen" ist für den BfArM-Antrag ebenfalls ein gültiges Zertifikat – die Auflagen schränken aber den operativen Betrieb ein und lösen bei Änderungen typisch kürzere Re-Evaluationszyklen aus.

Hier endet die Parallelität zu BSI TR-03185 (Sicherer Software-Lebenszyklus), der binär ist – ohne „mit Auflagen"-Achse. Beide Richtlinien sind unterschiedliche Instrumente auf unterschiedlichen Ebenen: TR-03185 zertifiziert den SDLC eines Herstellers als organisatorischen Prozess; TR-03161 zertifiziert eine konkrete DiGA gegen ein Cybersicherheits-Bedrohungsmodell. Sie ergänzen sich, sie ersetzen sich nicht.

Realistische Kosten – was eine DiGA-taugliche TR-03161-Zertifizierung wirklich kostet

Aus DUX-Zertifizierungserfahrung mit DiGAs auf der mHealth Suite verteilen sich die Kosten etwa wie folgt – qualitative Spannen aus eigenen Projekten, keine veröffentlichten BSI-Preise:

• Prüfstellen-Gebühren inklusive Penetrationstest: €30.000–€80.000 pro DiGA für eine Erst-Zertifizierung. Die Spanne hängt vom Scope ab (nur Mobile vs. Mobile + Web + Backend), von der Plattform-Anzahl und der Zahl integrierter Drittdienste und Backend-Komponenten.
• Interne Vorbereitung – Dokumentation, Remediation, Evidenz: €20.000–€70.000 interner Aufwand pro DiGA. Auf einer Plattform ist das weniger, weil die Sicherheitsarchitektur geteilt ist; eine Custom-entwickelte DiGA zahlt typischerweise den Vollbetrag.
• Kosten der Remediation-Zyklen: jeder Befund muss behoben und nachgetestet werden. Eine gut vorbereitete Erst-Zertifizierung erzeugt 5–15 Befunde, eine nachgerüstete Codebase 30–60.

Summiert liegt der realistische Rahmen einer Erst-Zertifizierung zwischen €50.000 und €150.000 pro DiGA. Re-Zertifizierungen für spätere Versionen sind deutlich günstiger – typisch 30–50 % einer Erst-Zertifizierung – weil Dokumentation, SDLC und Architekturentscheidungen stehen; der Prüfer fokussiert auf das Delta.

Die Zahl, die Teams in die Irre führt, ist die Prüfstellen-Rechnung in Isolation. Öffentliche Behauptungen wie „TR-03161-Zertifizierung für €30k" beziehen sich fast immer nur auf die Prüfstellen-Position und ignorieren interne Remediation- und Evidenz-Kosten – den größeren Posten für Teams ohne etablierten Secure-SDLC. Der Kostenvergleich, der wirklich zählt, lautet nicht „Zertifizierungsgebühr vs. keine Gebühr", sondern „von Tag eins für TR-03161 bauen vs. im zweiten Jahr umbauen". Nachrüsten kostet typischerweise 3–5-mal so viel wie eine Erst-Zertifizierung – nicht, weil die Zertifizierung teurer wird, sondern weil der architektonische Umbau teuer ist (Backend-Identity-Layer, Daten-Segmentierung, Logging, Intra-VPC-Verschlüsselung, Secret-Management).

Wo Teams stolpern – wiederkehrende Schwachstellen

Im DUX-Korpus zertifizierter DiGAs wiederholt sich das Befund-Muster konsistent. Häufige Schwachstellen im Erst-Assessment:

1. Kein dokumentierter SDLC gegen O.Arch_1 / OSP.SecurityLifeCycle. Security muss fester Bestandteil des Entwicklungszyklus sein, nicht angeflanscht. Teams mit einem Jira-Epic „Security", aber ohne Architektur-Review-Gate, Threat-Modelling-Schritt oder Security-Test-Stufe in der Pipeline fallen hier durch.
2. Unklare Zweckbindung unter O.Purp_1–O.Purp_9. Die Anwendungszweck-Anforderungen binden jede Datenerhebung, -verarbeitung und -weitergabe an einen deklarierten legitimen Zweck. Teams, die Analytics-SDKs oder Crash-Reporting-Tools mit Default-Telemetrie ausliefern, stolpern regelmäßig über O.Purp_2 („Die Anwendung DARF KEINE Daten erheben und verarbeiten, die nicht dem rechtmäßigen Zweck der Anwendung dienen").
3. Drittanbieter-Bibliothek-Wildwuchs gegen OSP.LibsIn / OSP.LibsOut / O.Purp_7. Abhängigkeiten müssen auf spezifische notwendige Funktionen beschränkt sein; ungenutzte Funktionen sind sicher zu deaktivieren. Schwergewichtige SDKs, die für eine einzelne Funktion importiert werden, fallen überproportional durch.
4. Hartkodierte Geheimnisse gegen O.Cryp_1. Git-History-Scanning und Binary-Analyse der Mobile-App finden das in der ersten Stunde des Assessments.
5. Unverschlüsselter Intra-Backend-Traffic gegen O.Ntwk_1 (Teil 3). Die Anforderung adressiert explizit Kommunikation innerhalb des Backend-Netzes – unverschlüsselter Kubernetes-interner Traffic, unverschlüsselte Datenbankverbindungen und Plaintext-Service-Meshes fallen klar durch.
6. Schwache Autorisierungs-Trennung unter O.Auth_1 / OSP.Authorization. Autorisierung muss unabhängig von der Authentifizierung implementiert sein – ein häufiger Fehler, wenn die einzige Zugangskontrolle „eingeloggt oder nicht" lautet.
7. Kein funktionierender Critical-Update-Mechanismus gegen OSP.CriticalUpdates. Das Backend muss Apps über Updates informieren und nach einer Übergangszeit veraltete Versionen blockieren. Teams, die allein auf App-Store-Updates setzen, fallen hier durch.
8. Cloud-Deployment ohne C5-kompatibles Provider-Testat. Das BSI empfiehlt, dass Cloud-gehostete DiGA-Backends auf Providern laufen, die den BSI Cloud-Computing-Kriterienkatalog (C5) oder eine Äquivalenz erfüllen (BSI TR-03161-1 Kap. 2.3.3). Große Hyperscaler erfüllen das typisch; kleinere oder selbstgebaute Infrastrukturen oft nicht.

Der Re-Zertifizierungs-Zyklus – zertifiziert bleiben bei DiGA-Updates

Drei Kräfte treiben Erneuerung:

1. Produktänderung. Nach § 18 DiGAV lösen wesentliche Veränderungen eine BfArM-Anzeigepflicht aus. Änderungen, die die Datensicherheit materiell berühren – neue Authentifizierungsflüsse, geänderte kryptographische Bibliotheken, neue Backend-Komponenten, tiefe Architektur-Refactors – lösen eine Re-Evaluation des betroffenen TR-03161-Scopes aus.
2. Standard-Evolution. Teil 1 steht bei Version 3.0, Teile 2 und 3 bei Version 2.0. Wenn das BSI einen Teil aktualisiert, gehen neue Anforderungen bei der nächsten Re-Evaluation in den Scope – auch wenn sich das Produkt nicht verändert hat.
3. Vulnerability-Disclosure-Pflichten unter OSP.CriticalUpdates. Der Hersteller muss ausnutzbare Schwachstellen erkennen, zeitnahe Updates bereitstellen und sicherstellen, dass das Backend die App informiert. Ein Versagen im Post-Market-Monitoring ist ein Grund für die Zertifizierungsstelle, die Gültigkeit des ursprünglichen Zertifikats zu hinterfragen.

DUX betreibt TR-03161 als kontinuierlichen Workstream: jede DiGA hat einen benannten Cybersecurity-Verantwortlichen, ein Quartals-Review gegen die aktuellen Teil-Versionen, eine Vulnerability-Monitoring-Pipeline auf dem Abhängigkeitsbaum und ein Change-Log, das Produktänderungen gegen § 18 DiGAV und TR-03161-Scope mappt.

TR-03161 vs. TR-03185 – was sich unterscheidet, warum beides für DiGA zählt

TR-03161 sagt einem BfArM-Prüfer, dass diese DiGA den Cybersicherheits-Maßstab erfüllt. TR-03185 sagt demselben Prüfer, dass die Organisation, die DiGAs produziert, einen sicheren Lebenszyklus betreibt – was jede folgende TR-03161-Prüfung beschleunigt, weil die SDLC-Evidenz bereits vor-attestiert ist. DUX Healthcare hält TR-03185 als organisatorische Prozess-Zertifizierung – als erstes Unternehmen, das sie erhalten hat – und prüft jede DiGA auf der Plattform einzeln gegen TR-03161.

Häufige Fragen

Zum breiteren DiGA-Regulatorik-Rahmen, in dem TR-03161 sitzt, siehe den DiGA-Wissens-Bereich – insbesondere die Datenschutz-Strecke und den Artikel zu den BfArM-Datenschutzprüfkriterien, die parallel zu TR-03161 laufen. Zum architektonischen Bauprinzip, das wiederholte TR-03161-Zertifizierung über mehrere DiGAs tragfähig macht, siehe /build/.