By Thomas Wolters · CTO, DUX Healthcare · 17 April 2026
BSI TR-03161 – the Technische Richtlinie (Technical Guideline) of the Bundesamt für Sicherheit in der Informationstechnik (BSI – Germany’s Federal Office for Information Security) titled “Anforderungen an Anwendungen im Gesundheitswesen” – is the regulatory artefact that decides whether a DiGA (Digitale Gesundheitsanwendung) can be filed at the BfArM (Bundesinstitut für Arzneimittel und Medizinprodukte) or not. Since 1 July 2025, a TR-03161 certificate is a formal precondition for application completeness: no certificate, no listing, full stop (DiGA Guide v3.6 Sec. 3.4). International DTx teams entering Germany routinely treat TR-03161 as a side-track they can handle in a final quarter. In practice it is one of the load-bearing architectural decisions of a DiGA project – the cybersecurity standard against which five DiGAs on our mHealth Suite platform have been individually tested. This article is a practitioner’s guide to what TR-03161 actually demands, what certification really costs, where teams stumble, and how the “ohne Auflagen” (without conditions) vs. “mit Auflagen” (with conditions) outcome is decided.
What BSI TR-03161 is – and what it is not
TR-03161 is a technical guideline, not an ordinance or a law. The legal binding for DiGA applicants comes from § 139e Abs. 10 SGB V (Social Code Book V) and the DiGAV (Digitale-Gesundheitsanwendungen-Verordnung), which together require manufacturers to demonstrate data security against the BSI Technical Guidelines. The BfArM’s DiGA-Leitfaden v3.6 (10 December 2025) operationalises that: “Seit dem 01.07.2025 ist die Vorlage [eines TR-03161-Zertifikats] Voraussetzung für die formale Vollständigkeit des Antrags” – “Since 1 July 2025, submission of a TR-03161 certificate is a precondition for the formal completeness of the application” (DiGA Guide v3.6 Sec. 3.4). An ISMS certificate under ISO 27001 is separately mandatory and, per the Leitfaden, explicitly not a substitute for TR-03161.
The guideline comes in three parts, each aimed at a different deployment surface:
- Part 1 – Mobile applications (Anforderungen an mobile Anwendungen im Gesundheitswesen), version 3.0 – native and hybrid apps on iOS and Android (BSI TR-03161-1 Kap. 2.1).
- Part 2 – Web applications (Anforderungen an Web-Anwendungen), version 2.0 – browser-delivered applications including PWAs (BSI TR-03161-2 Kap. 1.1).
- Part 3 – Backend systems (Anforderungen an Hintergrundsysteme), version 2.0 – server side, self-hosted, externally hosted, or cloud (BSI TR-03161-3 Kap. 1.1).
Each part opens with a Security Problem Definition (SPD) – the BSI’s Common-Criteria-borrowed term for the formal statement of assumptions, threats, and Organisational Security Policies (OSPs) against which the application is evaluated. The concrete requirements that follow – categorised as O.Arch (architecture), O.Cryp (cryptography), O.Auth (authentication), O.Data (data security), O.Ntwk (network), O.Org (organisation) – are derived from the SPD. TR-03161 is therefore not a checklist; it is a structured evaluation against a stated threat model, and the evaluator’s judgement is part of the instrument.
What TR-03161 is not: it is not an IT-security assessment of the company as a whole. It is not an ISMS audit. It is not a data-protection assessment in the GDPR sense (those criteria live in the separate BfArM-Datenschutzprüfkriterien under § 139e Abs. 11 SGB V). It is not a clinical-risk or software-safety evaluation (IEC 62304 and ISO 14971 cover that). It is specifically a product-level cybersecurity evaluation of one concrete DiGA version against a defined threat model.
Scope across the three parts – orienting readers in the ~366-requirement surface
A common failure mode is to treat the three parts as three independent audits. In reality a typical DiGA – mobile app plus web admin plus cloud backend – is evaluated against all three parts in a single coordinated assessment. Each part structures its requirements against a set of Prüfaspekte (test aspects). Part 3 lists ten: intended use, architecture, source code, third-party software, cryptography, authentication, data storage and protection, chargeable resources, network communication, organisational security (BSI TR-03161-3 Kap. 3.1). Parts 1 and 2 mirror this structure with surface-appropriate adjustments.
A few concrete requirement examples that international teams routinely underestimate:
O.Arch_1: “Security MUSS ein fester Bestandteil des Softwareentwicklungs- und Lebenszyklus’ für die gesamte Anwendung sein” – security must be a fixed part of the SDLC. The evaluator looks for lived process evidence, not documentation artefacts.O.Cryp_1: no hard-coded secret or private keys. Straightforward in principle, grep-surprising on a three-year-old codebase.O.Data_1: “Die Werkseinstellung der Anwendung MUSS die maximale Sicherheit bieten” – secure-by-default, frequently colliding with product decisions that prioritise first-use friction reduction.O.Ntwk_1(Part 3): end-to-end network encryption, including inside the backend network. Teams running unencrypted intra-VPC traffic fail this cleanly.O.Org_1(Part 3): a certified ISMS under ISO 27001 (or IT-Grundschutz, or equivalent) is an inside-TR-03161 requirement, not just a parallel DiGAV obligation.
The RFC-2119-style keywords matter: MUSS (MUST) requirements are non-negotiable; SOLL (SHOULD) may be omitted only where the manufacturer demonstrates no risk; KANN (MAY) is optional but discoverable (BSI TR-03161-1 Kap. 1.3.2). Treating a MUSS as a SOLL is the most common cause of “mit Auflagen” outcomes.
The certification process – test-lab assessment and BSI confirmation
The formal certification sequence for a DiGA against TR-03161 runs as follows:
- Scoping and part selection. The manufacturer defines the Target of Evaluation (ToE) – which DiGA version, which components, which deployment surfaces. Part selection follows: mobile (Part 1), web (Part 2), backend (Part 3). Components that do not exist are excluded and the rationale documented.
- Evidence preparation. A documentation set: architecture description, authentication and cryptographic concepts, data-flow diagrams, third-party-software inventory, SDLC description, risk analysis. The risk analysis must follow a documented methodology –
BSI-Standard 200-3,ISO 27005, orAnhang B of the Common Criteria Evaluation Methodology (CEM)are the explicitly named references (BSI TR-03161-1 Kap. 5). - Test-lab assessment. A Prüfstelle (test lab) – preferably BSI-accredited, per the DiGA Guide’s recommendation (DiGA Guide v3.6 Sec. 3.4.2) – conducts documentation review, whitebox code review, and penetration testing of all in-scope components including the backend. Methodology references
OWASP Top 10for backend and web,OWASP MASVS/MSTGfor mobile. - Risk analysis and residual-risk judgement. The evaluator performs a methodical risk assessment against each category of processed data, classified by criticality. This is where “ohne Auflagen” vs. “mit Auflagen” is decided – see below.
- Report and certificate. The test lab issues an evaluation report; the resulting certificate is the artefact the manufacturer submits with the BfArM application (Annex I DiGAV) to prove conformity with § 139e Abs. 10 SGB V. It binds to a specific DiGA version.
- Maintenance of certification. Per Leitfaden Sec. 3.4, “Für die Aufrechterhaltung des Zertifikats ist der Hersteller selbst verantwortlich” – maintaining the certificate is the manufacturer’s responsibility. Material changes under § 18 DiGAV generally trigger re-assessment.
The German test-lab market is not huge: a handful of BSI-accredited labs plus a larger set of experienced Common Criteria labs cover the bulk of DiGA certifications. Lab experience with the TR-03161 parts matters materially – we see a 2–3× efficiency difference between labs that have certified dozens of DiGAs and labs approaching a first one.
Passing “ohne Auflagen” vs. “mit Auflagen” – how the outcome is really decided
A frequent misconception is that TR-03161 is a pass/fail instrument. It is not. Table 15 of Part 1 (BSI TR-03161-1 Kap. 5, Tabelle 15) makes the criticality-to-outcome mapping explicit. The operative row, cited verbatim:
“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.”
For data classified as “Hoch” (high criticality), the evaluator documents residual risk after all implemented measures are considered. Where residual risk remains but the evaluator judges the measures “materially reducing” the risk, the certificate can be issued with conditions on its use – the classical “mit Auflagen” outcome. For data at “Sehr hoch” (very high, e.g. unprotectable health data), the standard requires all risk scenarios be eliminated without residual risk – effectively the “ohne Auflagen” bar for the high-sensitivity class.
The practical implication: “ohne Auflagen” is not a universal expectation. It is a specific outcome that requires residual risks on high-criticality data paths to be eliminated. Achieving it is common in well-architected platform-engineered DiGAs and uncommon in retrofitted ones. “Mit Auflagen” is still a valid certificate for BfArM application purposes, but the conditions constrain operational use and typically trigger shorter re-assessment cycles on change.
This is also where TR-03161 differs from BSI TR-03185 (Sicherer Software-Lebenszyklus), which is binary – no “mit Auflagen” axis. The two are different instruments at different levels: TR-03185 certifies a manufacturer’s SDLC as an organisational process; TR-03161 certifies one specific DiGA against a cybersecurity threat model. They are additive, not interchangeable.
Realistic costs – what a DiGA-grade TR-03161 certification runs
From our experience certifying DiGAs on the mHealth Suite platform, the cost envelope breaks down roughly as follows – qualitative ranges drawn from our own projects, not published BSI pricing:
- Test-lab fees (including penetration testing): €30,000–€80,000 per DiGA for a first certification. The range depends on scope (mobile only vs. mobile + web + backend), platform count, and the number of integrated third-party services and backend components.
- Internal preparation – documentation, remediation, evidence gathering: €20,000–€70,000 of internal effort per DiGA. On our platform this is lower because the security architecture is shared; a custom-built DiGA typically pays the full amount.
- Remediation-cycle cost: every finding surfaces to be fixed and re-tested. A well-prepared first-time certification produces 5–15 findings; a retrofitted codebase 30–60.
Summed, the realistic first-certification envelope is €50,000–€150,000 per DiGA. Re-certifications for subsequent versions are materially cheaper – typically 30–50 % of a first – because the documentation, SDLC, and architectural decisions are already in place; the evaluator focuses on the delta.
The cost number that misleads teams is the test-lab invoice in isolation. Public claims of “TR-03161 certification for €30k” almost always quote the test-lab line and ignore internal remediation and evidence-gathering cost, which is the larger share for teams without an established secure SDLC. The cost comparison that matters is not “certification fee vs. no fee” but “architect for TR-03161 from day one vs. rebuild around it in year two”. Retrofitting typically costs 3–5× a first-time certification – not because the certification is more expensive, but because the architectural rebuild (backend identity layer, data-segmentation, logging, intra-VPC encryption, secret management) is.
Where teams stumble – recurring weak points
Across DiGAs we have built and helped certify, the pattern of findings is remarkably consistent. The recurring weak points in a first assessment:
- No documented SDLC aligned to
O.Arch_1/OSP.SecurityLifeCycle. Security must be a fixed part of the development lifecycle, not bolted on. Teams with Jira epics labelled “Security” but no architecture-review gate, threat-modelling step, or security-testing stage in the pipeline fail this. - Unclear purpose binding under
O.Purp_1–O.Purp_9. The Anwendungszweck requirements bind every data collection, processing, and sharing step to a declared legitimate purpose. Teams that ship analytics SDKs or crash-reporting tools with default telemetry typically tripO.Purp_2(“Die Anwendung DARF KEINE Daten erheben und verarbeiten, die nicht dem rechtmäßigen Zweck der Anwendung dienen”). - Third-party library sprawl under
OSP.LibsIn/OSP.LibsOut/O.Purp_7. Dependencies must be scoped to specific necessary functions; unused functions securely deactivated. Heavyweight SDKs imported for a single function fail this disproportionately. - Hard-coded secrets against
O.Cryp_1. Git-history scanning and binary decomposition of the mobile app catch this in the first hour of assessment. - Unencrypted intra-backend traffic against
O.Ntwk_1(Part 3). The requirement explicitly covers communication inside the backend network – unencrypted Kubernetes-internal traffic, unencrypted database connections, and plaintext service meshes fail cleanly. - Weak authorisation separation under
O.Auth_1/OSP.Authorization. Authorisation must be implemented independently of authentication – a common failure where the only access control is “logged in or not”. - No working critical-update mechanism against
OSP.CriticalUpdates. The backend must signal apps about updates and, after a grace period, block outdated versions. Teams relying solely on app-store-driven updates fail this. - Cloud deployment without a
C5-compatible provider attestation. The BSI recommends cloud-hosted DiGA backends run on providers meeting the BSI Cloud-Computing-Kriterienkatalog (C5) or equivalent (BSI TR-03161-1 Kap. 2.3.3). US hyperscalers typically qualify; smaller or self-built infrastructure often does not.
None of these are surprising if you have built a regulated mobile product before. All of them are surprising if you are coming from a consumer-app or B2B SaaS background where the security bar is compliance-posture rather than threat-model-evaluated.
The renewal cycle – staying certified across DiGA updates
Certification is not a one-shot event. Three forces drive renewal:
- Product change. Under § 18 DiGAV, wesentliche Veränderungen (substantial changes) require BfArM notification. Changes that materially affect data security – new authentication flows, changed cryptographic libraries, new backend components, significant architectural refactors – trigger re-assessment of the affected TR-03161 scope. The line between minor and substantial is drawn against
OSP.SecurityLifeCyclecriteria and the manufacturer’s own change-management definition, reviewed at initial certification. - Standard evolution. Part 1 is at version 3.0, Parts 2 and 3 at version 2.0. When the BSI updates a part, new requirements enter the scope at the next re-assessment, even if the product has not changed.
- Vulnerability disclosure obligations under
OSP.CriticalUpdates. The manufacturer must detect exploitable vulnerabilities in the DiGA and in its third-party software, provide timely updates, and ensure the backend signals the app. Failure to meet this at post-market surveillance is grounds for the certification authority to question the original certificate’s validity.
Practically, we treat TR-03161 at DUX as a continuously-running workstream: each DiGA has a named cybersecurity owner, a quarterly review against the current part versions, a vulnerability-monitoring pipeline on the dependency tree, and a change-log that maps product changes against § 18 DiGAV and TR-03161 scope. Table stakes for operating a DiGA past its first listing.
TR-03161 vs. TR-03185 – what is different and why both matter for DiGA
These two BSI Technical Guidelines appear together in market communication often enough that the distinction is worth making precisely.
| Dimension | BSI TR-03161 | BSI TR-03185 |
|---|---|---|
| Subject of evaluation | A specific DiGA version (product) | The manufacturer’s SDLC (process) |
| Evaluation unit | Per DiGA | Per organisation |
| Scope | Cybersecurity across mobile, web, backend | Secure software lifecycle across design, development, deployment, operations |
| Outcome | “Ohne Auflagen” or “mit Auflagen” based on residual-risk analysis | Binary pass/fail |
| DiGA application status | Mandatory for application completeness since 1 July 2025 | Not required; complementary quality signal |
The two instruments answer different questions. TR-03161 tells a BfArM reviewer that this DiGA meets the cybersecurity bar. TR-03185 tells the same reviewer that the organisation producing DiGAs runs a secure lifecycle – which makes every subsequent TR-03161 assessment faster, because the SDLC evidence is already pre-attested. We hold TR-03185 as the organisational process certification for DUX Healthcare – as the first company to do so – and we test each DiGA on our platform individually against TR-03161.
Frequently asked questions
How much does BSI TR-03161 certification cost?
For a single DiGA, €50,000–€150,000 in our experience – including test-lab fees, penetration testing, whitebox code review, and the remediation cycles required to close findings. Timeline is 2–4 months if security architecture is in place from day one of development.
The cost balloons when security is retrofitted. Teams that “consider” TR-03161 after a year of development regularly rebuild backend identity, data-segmentation, and logging layers, and then pay the test-lab fees on top. Re-certifications for subsequent versions are typically 30–50 % of a first certification – the documentation, SDLC, and architectural decisions are already in place. Published third-party quotes in the €20k–€30k range usually reflect the test-lab line only and ignore internal preparation and remediation cost, which is the larger share for most teams.
Can a company be BSI TR-03161 certified, or only a product?
Only a product. Under § 139e Abs. 10 SGB V, the TR-03161 certificate is issued on a per-DiGA basis; the subject of evaluation is a specific DiGA version, not the manufacturer. “DUX Healthcare is TR-03161-certified” is incorrect – the correct phrasing is “our DiGAs are individually tested against BSI TR-03161 per DiGA”.
Platform leverage exists but comes from shared architecture and test evidence, not certificate re-use. A manufacturer running multiple DiGAs on the same backend, authentication layer, and secure SDLC will pass each subsequent certification faster than the first – but each DiGA still receives its own certificate, bound to its own version. For organisation-level recognition of a secure development lifecycle, the relevant instrument is BSI TR-03185, certified per-organisation and complementary to per-DiGA TR-03161.
What is the difference between 'ohne Auflagen' and 'mit Auflagen'?
Both are valid TR-03161 certification outcomes. The difference is whether residual risks on the product’s processed data could be eliminated (“ohne Auflagen” – without conditions) or only materially reduced (“mit Auflagen” – with conditions). For data at the highest criticality level (“Sehr hoch”), Table 15 in Part 1 requires all risk scenarios to be eliminated without residual risk. For data at “Hoch”, the evaluator may accept documented residual risk and issue the certificate with conditions on its operational use.
Both outcomes qualify a DiGA for BfArM application – the formal precondition is an issued certificate, not specifically an unconditional one. “Mit Auflagen” typically ties the certificate to documented constraints – restricted configurations, specific monitoring requirements, or shorter re-assessment cycles. Do not conflate this with TR-03185, which is binary – no “ohne Auflagen” axis, and evaluating a different subject (organisational SDLC, not product cybersecurity).
For the broader DiGA regulatory framework in which TR-03161 sits, see the DiGA knowledge area. For the architectural build pattern that makes repeated TR-03161 certification feasible across multiple DiGAs, see our /build/ page – the platform mechanics are the operational flip-side of the cybersecurity bar discussed here.
Practitioner take