BSI TR-03161 for DiGAs: Requirements, Mandatory Certification, and What Applies to Identity Management

Since January 1, 2025, self-declarations are a thing of the past: DiGA manufacturers must prove compliance with data security requirements via an official certificate according to BSI TR-03161 to be included in the DiGA directory. This has turned a recommendation into a strict admission requirement – and for many teams, the critical path to reimbursement.

This article explains what the BSI TR-03161 is, what requirements it sets, how the certification works, and what specifically matters regarding authentication and identity management.

What is the BSI TR-03161?

The Technical Guideline BSI TR-03161 "Requirements for Applications in the Healthcare Sector" is published by the Federal Office for Information Security (BSI). It defines concrete, testable security requirements for healthcare applications – with the goal of protecting highly sensitive health data right from the start (Security by Design).

The guideline consists of three parts, depending on the architecture of your application:

• TR-03161-1 – Requirements for mobile applications (iOS, Android)
• TR-03161-2 – Requirements for web applications
• TR-03161-3 – Requirements for background systems (Backend Services)

For a typical DiGA with an app, web component, and backend, several parts are usually relevant simultaneously. The requirements are structured into thematic blocks – including architecture, secure source code, cryptography, authentication, session management, data storage, and network communication.

Legal Framework and the Mandatory Certification Since 2025

The legal basis lies in § 139e SGB V in conjunction with the DiGA Ordinance (DiGAV), anchored via the Digital Healthcare Act (DVG) and the DVPMG. With the 1st Ordinance Amending the DiGAV (1. DiGAVÄndV) and the adaptation of § 139e SGB V, the legislator has made the submission of a data security certificate based on the BSI TR-03161 mandatory.

Specifically, this means:

• New DiGA Applications: For inclusion in the DiGA directory, certification according to BSI TR-03161 is now strictly required.
• Already Listed DiGAs: Currently, the BfArM only tolerates a missing certificate as long as the manufacturer can prove they are already in an ongoing certification process – meaning they have at least contacted an auditing body. This practice can change at any time.

So if you want to list newly or plan a significant change, you should schedule the certification early on – it is not a subsequent formality, but part of the critical path.

How Does the Certification Process Work?

The audit is conducted by accredited auditing bodies (e.g., large testing organizations) and subsequently confirmed by the BSI. The final decision on inclusion and remaining in the directory is made by the BfArM.

Important to understand: The evaluation is risk-based. The basis for the audit judgment is a documented risk management procedure – the protective measures implemented in the product and their effectiveness flow into the assessment. Failing a single audit aspect does not automatically lead to failure if the residual risk is comprehensibly evaluated and treated.

A certificate according to BSI TR-03161 is usually valid for up to five years. After expiration or after significant, security-relevant changes to the product, a recertification is necessary, the scope of which can be limited to the changed parts.

Furthermore, the BSI TR-03161 does not stand alone: For listing, an Information Security Management System (ISMS) certified according to ISO/IEC 27001 and – for outsourced hosting – a C5 attestation (Type 2) from the cloud or infrastructure providers are typically required. Outsourced components must also comply with the requirements of TR-03161.

Requirements Around Identity and Authentication

A significant and often underestimated part of the TR-03161 concerns exactly the area where most DiGAs make early mistakes: Authentication, session management, and secure storage of identity data. The relevant requirement blocks:

• Authentication: Secure login procedures, protection against brute force, appropriate factors (MFA), passwordless procedures. A central point: The requirement O.Auth_4 explicitly opens up the connection to a sectoral identity provider within the scope of certification – uniformly regulated via the gematik "Specification Sectoral Identity Provider", coordinated with the BSI and BfDI. Thus, the GesundheitsID is directly intertwined with the TR-03161.
• Session Management: Secure session handling, timeouts, clean invalidation of tokens, protection against session hijacking.
• Cryptography: Use of suitable, current procedures and key lengths – both for stored data and for communication.
• Device Binding & Secure Storage: Protection of keys and tokens on the end device, use of the platform's secure hardware elements. The hardware-based binding of identities to end devices is a recurring theme in the guideline.
• Secure Communication: Encrypted transmission (TLS) with correct certificate validation.

Precisely because O.Auth_4 bridges the gap to the GesundheitsID, it is worth looking at both topics together – we have described in detail how the GesundheitsID connection works technically in the article Integrating GesundheitsID into a DiGA.

How a Compliant IAM Module Reduces the Audit Scope

This is where the practical leverage lies. The TR-03161 audits the entire application – but a large, independently auditable part of the requirements falls on identity and authentication. Anyone who covers this block via a module already developed according to BSI TR-03161 significantly reduces both the development and the audit effort.

This is exactly what azuma doa is built for: a Health IAM that provides the identity and authentication-related requirements out-of-the-box – MFA, Device Binding (a core requirement of TR-03161 for medical apps), Passkeys and FIDO2 biometrics, secure session and token management, pre-built registration and recovery flows. Furthermore, the GesundheitsID federation from O.Auth_4 is covered by azuma mimoto.

That this holds up in practice is shown by looking at the field: At the time of this post, several azuma customers have already successfully passed the certification process according to BSI TR-03161 using azuma doa as their IAM – to our knowledge, currently the only third-party SaaS IAM that has provided this proof in DiGA projects.

To be honest: An IAM module does not certify your entire DiGA – the responsibility for the overall product remains with the manufacturer. But it takes a demanding, error-prone part out of your scope and provides the documentation you need for exactly this area for the auditing body.

Checklist: BSI TR-03161 for Your DiGA

1. Classify Architecture – Which parts (1 mobile / 2 web / 3 backend) apply to you?
2. Contact Auditing Body Early – Appointments and processing times are the bottleneck; early contact is also relevant for listed DiGAs.
3. Document Risk Management – It is the basis of the audit judgment, not an appendix.
4. Clarify Identity/Auth Scope – Build it yourself or cover it via a compliant module (incl. GesundheitsID/O.Auth_4)?
5. Accompanying Proofs – Have ISO/IEC 27001 ISMS and C5 (Type 2) ready for outsourced hosting.
6. Consider Recertification – Plan for validity (up to five years) and security-relevant changes in the lifecycle.

Frequently Asked Questions

Is the BSI TR-03161 mandatory for DiGAs?

Yes. Since January 1, 2025, DiGA manufacturers must prove compliance with data security requirements via a certificate according to BSI TR-03161. For new applications, it is a prerequisite for admission; for already listed DiGAs, an ongoing certification process is currently temporarily tolerated.

What is the difference between TR-03161-1, -2, and -3?

Part 1 concerns mobile applications, Part 2 web applications, and Part 3 background systems (backend). A DiGA with an app, web, and backend usually must fulfill several parts simultaneously.

Who issues the certificate?

The audit is performed by accredited auditing bodies and confirmed by the BSI. The BfArM makes the final decision on inclusion and remaining in the DiGA directory.

How is the BSI TR-03161 related to the GesundheitsID?

Via the requirement O.Auth_4: It opens up the connection to a sectoral identity provider within the scope of certification – regulated by the gematik specification. Thus, authentication according to TR-03161 and GesundheitsID integration are closely linked.

Is an IAM module sufficient for certification?

No – the certification concerns the entire product. However, an IAM module developed according to BSI TR-03161 covers the identity and authentication part, reduces the audit scope, and provides the associated documentation.

---

Are you preparing the certification of your DiGA and don't want to build the identity and authentication part yourself? Schedule a call or secure a free developer access and see how azuma doa covers the TR-03161 requirements for identity management.