Company · Certifications
Four pieces of evidence. Four effects. One platform.
ISO 13485, BSI TR-03185, BSI TR-03161 per DiGA, BfArM Data Protection Criteria – each piece of evidence works at a different level. Three implement legal requirements; TR-03185 is a voluntary process certificate. Here is what each concretely means for your product, and where we stand on ISO 27001.
What this is about
What certifications really mean in the DiGA market.
The German DTx market is full of certification claims that do not hold up on closer inspection: “GDPR-compliant” is not a certification, “BSI-compliant” without a TR reference is not a statement, “ISO-like QMS” is nothing at all. This page describes which evidence DUX carries, which each DiGA needs itself (TR-03161), what each of them means for a Digital Health Application (DiGA) – and where one piece of evidence ends and the next begins.
Each of the four works at a different level: three implement legal requirements (MDR, § 139e SGB V), TR-03185 is a voluntary process certificate. The TR-03161 certificate and the data protection evidence are application prerequisites. ISO 13485 and TR-03185 work upstream: in the QMS and in the development process. The BfArM requests missing documents with a deadline of up to three months (DiGAV § 16 (2)).
Evidence · N°01 · Edition MMXXVI
Four pieces of evidence in one sentence.
QMS, process, product, data protection.
- ISO 13485 – certified (TÜV Hessen). The MDR requires the manufacturer to have a QMS (Art. 10(9)); ISO 13485 is the established way to demonstrate it.
- BSI TR-03185 – first company certified (certificate BSI-K-TR-0900-2026, issued 17 July 2026). Covers the secure software development process at the organizational level.
- BSI TR-03161 – assessed per DiGA; our DiGAs assessed so far passed without conditions. Formal application prerequisite since 01.07.2025.
- BfArM Data Protection Criteria – evidence in the QMS. Criteria under § 139e (11) SGB V; the evidence is part of our QMS.
The four pieces of evidence
Each solves a different regulatory problem.
BSI TR-03185
Secure software lifecycle.
What it is. BSI TR-03185 is a Technical Guideline from the Federal Office for Information Security that assesses a manufacturer’s entire software development process – from requirements analysis and architecture decisions through implementation, testing, release, and maintenance to post-market upkeep. What is examined is how software is created, not how it looks at the end.
What you get from it. For your DiGA this means: the development process in which your product is built is BSI-certified. Since February 2026 the BSI offers a procedure for TR-03161: manufacturers holding a valid TR-03185 certificate need no new product assessment for updates under defined conditions (BSI, 4 Feb 2026). New products are still assessed individually under TR-03161.
Our status. DUX Healthcare was the first company to hold a BSI process certificate based on TR-03185 – the BSI lists it under TR-03161, with TR-03185 as the assessment basis. The BSI issued it on 17 July 2026 under the identifier BSI-K-TR-0900-2026; it is valid until 16 July 2029. The certified object is the software development process for digital health applications (DiGA). The assessment was carried out by the BSI-recognised test lab secuvera GmbH. Verifiable in the BSI list of products certified against a Technical Guideline.
Why this matters for DiGA. TR-03185 is not formally required in the DiGA application today, but it is the structural foundation on which TR-03161 per DiGA becomes tenable. Anyone who does not run the software lifecycle on a demonstrable process level rebuilds the TR-03161 evidence per product – and pays three times for three DiGAs. Medical devices are excluded from the Cyber Resilience Act (Regulation (EU) 2024/2847) (MDCG 2025-6); for DiGA the MDR and TR-03161 remain decisive.
BSI TR-03161
Cybersecurity per DiGA.
What it is. BSI TR-03161 is the product-specific data security assessment for DiGAs – a technical certificate for a concrete product version, divided into Part 1 (Mobile Clients), Part 2 (Web Applications), and Part 3 (Backend/Cloud). It is assessed against around 366 test requirements across three parts (Part 1 mobile 138, Part 2 web 115, Part 3 backend 113), in ten or eleven assessment aspects per part – from architecture through cryptography, authentication, data storage, to network communication.
What you get from it. Since 01.07.2025, a TR-03161 certificate has been a prerequisite for formal completeness of the BfArM application (DiGA Guide v3.6 ch. 3.4). Without this certificate there is no listing in the DiGA directory – and under § 139e (10) SGB V it is issued product-specifically, not company-wide.
Our status. BSI TR-03161 is assessed per DiGA; our DiGAs assessed so far passed without conditions.
Why this matters for DiGA. For your product this means: if it builds on the mHealth Suite, the TR-03161 audit starts on a platform whose DiGAs assessed so far passed without conditions. The cybersecurity hurdle is thus no longer a project risk but a platform property. The product-specific evidence is still required; but it becomes calculable in time and cost.
ISO 13485
Quality management for medical devices.
What it is. ISO 13485 is the international standard for quality management systems in medical device development. It covers design controls, change management, supplier evaluation, production, post-market surveillance, and documentation – the core processes of a QMS; MDR-specific elements under Art. 10(9) such as clinical evaluation and vigilance come on top.
What you get from it. The MDR requires the manufacturer to have a QMS (Art. 10(9)); ISO 13485 is the established way to demonstrate it. For your DiGA this means: technical documentation under MDR Annexes II and III, risk management to ISO 14971, clinical evaluation, post-market clinical follow-up, and the conformity proof (Class I: manufacturer’s Declaration of Conformity; Class IIa: additionally with a Notified Body certificate) are not improvised per project but built on a QMS that has been audited for years.
Our status. DUX is ISO 13485 certified – audited by TÜV Hessen, with ongoing surveillance and re-certification on the normal three-year cycle. The QMS is the foundation on which every other piece of evidence rests.
Why this matters for DiGA. In the European medical software world, ISO 13485 is a prerequisite, not a differentiator. If it is missing, the provider cannot be taken seriously. The added value for your DiGA is that the interface between therapeutic concept and MDR CE documentation is not built up individually but arises from an existing, audited QMS process.
ISO 27001 · in progress
Information Security Management System (ISMS).
What it is. ISO 27001 is the standard for information security management systems. It assesses how an organization handles information assets: access controls, incident response, vendor management, physical security, business continuity. An ISMS is organizational and procedural, not product-specific.
Our status. DUX is working towards ISO 27001 certification. We do not hold a certificate yet. We will name a date once it is fixed.
Why this matters for DiGA. For DiGA manufacturers, a certified ISMS under ISO 27001 – including on the basis of IT-Grundschutz – has been mandatory since 1 April 2022 (DiGAV Annex 1). The obligation lies with the DiGA manufacturer. Independently, supplier audits ask about the platform provider’s ISMS; that is why we are working towards certification.
BfArM Data Protection Criteria
DiGA-specific data protection.
What it is. The BfArM Data Protection Criteria are a catalog of criteria under § 139e (11) SGB V that the BfArM has published as a concrete interpretation of the GDPR requirements for DiGA. They are worded in RFC 2119 grammar (MUST, MUST NOT, SHOULD, MAY) and distributed across twelve topic blocks – from responsibility and legal bases through technical-organizational measures to deletion and logging. Since 01.08.2024 they are formally binding. Implementation must be demonstrated by a certificate under Art. 42 GDPR (§ 139e (11) SGB V). No accredited bodies exist yet (BfArM, October 2026); until then, per the BfArM, the requirements of § 4 and Annex 1 DiGAV apply and the criteria serve as interpretation aid.
What you get from it. For international DTx teams this is the assessment level that operationalizes GDPR requirements and makes them testable. “We are GDPR-compliant” is not an answer; “we have established DMN_4 (user account and grace period), TOM_3.1 (push notifications) and ACC_1–3 (logging) in the sense of GLSR_2.4” is a verifiable statement.
Our status. Evidence for the BfArM data protection criteria is part of our QMS. In the application, the manufacturer submits the declaration under DiGAV Annex 1.
Why this matters for DiGA. Because the BfArM criteria consistently distinguish between “documented” and “established”: documentation alone is not enough, the criteria have to be lived in practice. Anyone building on our platform takes over the platform’s technical evidence; the controller’s processes are established by the manufacturer.
Interplay
How the four pieces of evidence work together.
The four pieces of evidence are not redundant – they operate at different levels and solve different regulatory problems. ISO 13485 forms the base on which everything else rests: no QMS, no medical device. BSI TR-03185 certifies how software is created securely in that QMS – at the process level, organization-wide, reusable. BSI TR-03161 certifies the product itself on cybersecurity – per DiGA, for the assessed version. The BfArM Data Protection Criteria finally translate GDPR and DiGAV into a testable set of individual requirements documented per DiGA in the application.
The effect is cumulative: each level reduces the effort at the one above. A team building on the mHealth Suite develops in a TR-03185-certified process, with an ISO 13485 QMS and existing TR-03161 evidence per DiGA. It not only saves time in the individual project – it avoids rebuilding the same structures for every follow-on DiGA. That is the economic difference between platform and custom build.
Technical depth in the knowledge area
The detailed practice guides are in the knowledge base.
This page explains what the four pieces of evidence mean for a customer project. The technical depth – requirement IDs, RFC 2119 grammar, assessment aspects per BSI part, OWASP Top 10 mapping – is in the knowledge area:
Next step