Digital health applications (DiGA) process some of the most sensitive data in existence – medical diagnoses, treatment histories, medication records. German law treats penetration testing for these apps not as a recommendation but as a hard requirement. Get it wrong, and BfArM rejects your Fast-Track application. Get it right, and you protect patient data while clearing the regulatory path to market.
Table of contents
Why Pentesting Is Mandatory for DiGA
DiGA (Digitale Gesundheitsanwendungen) are CE-marked medical devices – mobile apps, web apps, or hybrid solutions that physicians prescribe and statutory health insurance reimburses. Once listed in the official DiGA directory, these applications become available to millions of insured patients.
That scale raises the bar significantly. DiGA apps routinely collect medical diagnoses, symptoms, treatment histories, and behavioral health data over extended periods. Unlike financial data, which can be reset or reimbursed after a breach, compromised medical records stay compromised forever. The consequences – discrimination, psychological harm, erosion of trust in digital healthcare – are irreversible.
This is why the Digital Health Applications Ordinance (DiGAV) makes penetration testing a legal requirement, not a best practice. BfArM enforces it during the Fast-Track assessment. If your pentest report shows gaps in scope, outdated results, or unresolved findings, expect delays or outright rejection.
The Regulatory Framework
Three layers of regulation govern DiGA pentesting. Understanding how they interact saves manufacturers from scoping mistakes that derail their Fast-Track applications.
DiGAV, DVPMG, and BfArM
The Digital Health Applications Ordinance (DiGAV), expanded by the Digital Supply and Care Modernization Act (DVPMG), explicitly requires penetration testing for all DiGA regardless of protection class. Annex 1 of DiGAV defines detailed data security requirements, and regulators name pentesting as a mandatory control.
BfArM enforces these requirements during the Fast-Track assessment. They expect evidence showing:
- The pentest targeted the exact version submitted for approval
- All relevant components were in scope
- Identified vulnerabilities were properly remediated
BfArM can request detailed documentation at any point. Vague summaries without technical substance will not pass.
BSI and OWASP requirements
DiGAV requires tests to follow the BSI implementation concept for penetration testing and consider the current OWASP Top 10 security risks. For DiGA, that typically means:
- OWASP Top 10 for web and API components
- OWASP Mobile Top 10 or MASVS for mobile apps
BSI defines the testing methodology – structured, manual, attacker-oriented. OWASP provides the detailed technical focus areas. In practice, testers combine both.
When pentests must be repeated
This is not a one-time requirement. DiGAV mandates retesting when security-relevant changes occur:
- New APIs or internet-facing interfaces
- Significant functional changes to existing components
- Updates to libraries affecting external communication
- Architectural changes to data processing or authentication
BSI Testing Methodology
The BSI implementation concept sits at the core of DiGA pentesting. It defines a structured, six-phase approach built around realistic attack scenarios and manual testing – not automated scan-and-report exercises.
BSI-aligned testing must be:
- Clearly scoped with all relevant components and interfaces identified
- Based on realistic threat scenarios, not theoretical risks
- Conducted using techniques that reflect real-world attacker behavior
- Thoroughly documented with findings, risk ratings, and remediation guidance
Automated vulnerability scans are explicitly not sufficient on their own. BSI expects skilled testers to manually explore attack paths, chain weaknesses, and validate whether security controls actually hold up in practice.
What Must Be Tested
Regulatory requirements state that a pentest must cover all components of the DiGA. Testing only the mobile app – a common mistake – does not meet DiGAV requirements and creates dangerous blind spots.
Mobile applications
Both iOS and Android versions must be tested separately despite sharing backend services. Focus areas include secure local storage, protection against reverse engineering, token handling, secure backend communication, and platform-specific risks.
Backend systems and APIs
Backend APIs handle core business logic, data processing, and long-term storage of health data. Many of the most severe DiGA vulnerabilities originate here – missing authorization checks, insecure object references, improper role enforcement. Excluding APIs from scope directly undermines patient data protection and will not satisfy BfArM.
Authentication, data storage, and third parties
Testers must examine how the application establishes identities, manages sessions, and enforces access rights across patient, clinician, and admin roles. Data storage testing covers encryption at rest, key management, tenant isolation, and data lifecycle management.
Third-party integrations – cloud providers, analytics, notification services, identity management – also fall within scope. Even when third-party services are not directly testable, testers must evaluate how they are integrated, what data is shared, and whether they introduce additional attack paths.
How DiGA Pentesting Works
White-box testing and code review
Since February 2024, DiGA pentests must include white-box testing and mandatory manual code review. Black-box approaches alone no longer meet the requirements.
White-box testing means testers get architecture diagrams, API documentation, test credentials, and source code access. This lets them find issues invisible from the outside: authorization logic flaws, insecure error handling, edge cases, and code-level weaknesses that could expose health data at scale.
Manual code review catches vulnerabilities at the source level – improper input validation, insecure cryptographic implementations, flawed access control logic. For DiGA, where subtle implementation errors can lead to mass data exposure, code review is not optional.
Manual testing vs automated tools
Automated scanners play a supporting role but cannot detect the vulnerability classes that matter most in DiGA: broken access control, business logic flaws, subtle authorization errors. Manual testing is the core of the engagement.
Skilled testers actively explore the application, manipulate API requests, chain multiple weaknesses, and test access control enforcement across user roles. A scanner cannot replicate an attacker’s ability to reason about a healthcare app’s business logic.
We see manufacturers submit vulnerability scan reports thinking they satisfy DiGA requirements. They do not. BfArM expects evidence of manual, human-driven security testing aligned with the BSI methodology.
Threat modeling for DiGA
Effective testing starts with a DiGA-specific threat model that maps out user roles (patients, clinicians, admins), data flows between mobile apps and backend services, trust boundaries, and abuse scenarios targeting health data. This grounds the pentest in real risks rather than generic checklists.
Common Vulnerabilities in DiGA Apps
While DiGA apps vary in architecture, pentests consistently reveal the same vulnerability patterns. Their impact is amplified by the sensitivity of health data.
Broken access control and IDOR top the list. When an app exposes internal identifiers without verifying authorization, one patient can access another’s health records. These vulnerabilities require little technical skill to exploit and can result in mass data exposure.
Authentication and session flaws – weak authentication mechanisms, insecure token handling, missing expiration, credentials exposed in logs or client storage – give attackers unauthorized access to patient or clinician accounts.
API authorization issues are a frequent high-impact finding. APIs correctly authenticate users but fail to enforce granular authorization. Attackers craft direct API requests, bypass the frontend entirely, and access data or admin functions they should never reach.
Data exposure risks round out the common findings: unencrypted data at rest, misconfigured TLS, excessive data in API responses, sensitive information in logs. Health data cannot be “reset” once exposed, making these findings especially severe under DiGAV.
Evidence and Reporting for BfArM
Running the pentest is only half the job. BfArM places heavy emphasis on documentation and follow-through.
Your pentest report must demonstrate that testing covered the submitted product version, included all relevant components, followed BSI methodology with OWASP coverage, and was performed by qualified testers using manual techniques. The report should clearly describe scope, assumptions, limitations, and approach. BfArM treats vague, high-level summaries as insufficient.
Identifying vulnerabilities is not enough – BfArM expects remediation evidence. For critical and high-risk findings, especially those affecting access control or data confidentiality, manufacturers must fix issues before the application can progress through Fast-Track. Document what was fixed and how.
Retesting confirms that fixes work and did not introduce regressions. BfArM may request updated results at any time, particularly after changes made post-approval.
Ongoing Compliance
DiGA apps are rarely static. New features, dependency updates, and infrastructure changes all shift the attack surface. Pentesting must be an ongoing process, not a one-time Fast-Track hurdle.
Plan retesting after introducing new APIs or user flows, modifying authentication or authorization logic, changing data storage or hosting, or upgrading security-relevant libraries. Embedding retesting into your release cycle catches vulnerabilities before they become audit findings.
Penetration testing also fits naturally within an ISO 27001 ISMS. Pentest results feed into risk assessments and treatment plans, vulnerabilities get tracked through defined processes, and management gains visibility into actual security posture rather than theoretical risks.
BfArM can request updated evidence at any time. Manufacturers who treat pentesting as continuous – scheduled tests based on risk and change frequency, ongoing vulnerability monitoring, up-to-date documentation – are in a far stronger position than those scrambling to produce reports on demand.
How FORTBRIDGE Can Help
FORTBRIDGE provides comprehensive penetration testing for DiGA and other digital health applications. We combine regulatory knowledge with hands-on technical testing to cover mobile apps, backend systems, APIs, and third-party integrations – all aligned with BSI methodology and OWASP standards.
Beyond testing, we help you remediate findings, prepare evidence packages, and get through the BfArM Fast-Track process without surprises.
Contact us today to discuss how we can help secure your DiGA application.
About Post Author
