Is your app a medical device, does it drive one, or does it pair with one? We test the app and review its code for the security evidence your MDR technical documentation needs, the way the state of the art expects.
For manufacturers of medical device software and of connected medical devices with a companion app.
If your app is a medical device, or is software that drives one, it falls under the Medical Device Regulation (EU) 2017/745. Annex I requires it to be developed and manufactured according to the state of the art, with information security built in:
The accepted way to verify this is security testing. The MDCG 2019-16 cybersecurity guidance and the harmonized state of the art (IEC 81001-5-1, IEC 62304) expect penetration testing and static source code analysis. Your technical documentation has to carry that test evidence.
Depending on your product, testing can cover:
States what we tested: the app on each platform, the build and the interfaces in scope, and the result for each applicable Annex I requirement, whether or not we found vulnerabilities. Every finding includes evidence, reproduction steps, impact, a CVSS score and vector, CWE and, where they apply, OWASP MASWE references, and how to fix it.
For the parts the state of the art expects it for, a review of the source code alongside the black-box testing, with the findings and how to fix them.
Covers the scope and build tested, the results and the priorities, for management and non-technical readers.
If you include the retest, we send a new version of the report with the status of each finding on the new build, so your technical documentation reflects the fixed version.
Our team comes from security certification laboratories, with experience in schemes such as Common Criteria, EMVCo SBMP and LINCE. We write reports with their reviewers in mind: your own team, your notified body and, if it comes to that, a market surveillance authority.
We map your tests to OWASP MASVS and MASTG, the standard and testing guide our team helps write. OWASP recognized this work by naming vulnit an OWASP MAS Advocate.
Chameleon gives us deep visibility into what your app does inside the operating system, which makes the analysis faster and more thorough. The controls that usually slow testing down, such as root, pinning and anti-instrumentation checks, are handled at the OS level by default.
Meet the teamNo. For a medical device in Class IIa or above, a notified body issues the CE certificate after auditing your quality management system and technical documentation. The notified body does not perform the security testing itself. We are not a notified body: we produce the security test evidence that goes into the technical documentation it reviews.
The MDR asks for the state of the art. For medical device software, the harmonized state of the art (IEC 81001-5-1, MDCG 2019-16) expects static source code analysis as well as penetration testing, so for MDR evidence we include a source code review alongside the black-box testing. For an app that is not a medical device, black-box testing is enough.
IEC 81001-5-1 expects you to manage the known vulnerabilities in your third-party and SOUP components. When they flag CVEs, we analyze which are actually exploitable in your device (a VEX analysis), so you remediate the real risks and document the rest as not affected, instead of re-validating the whole product over vulnerabilities that never reach it.
It depends on its intended purpose. Software that diagnoses, monitors, treats or drives a medical device is generally a medical device and is classified by its risk (Rule 11 often puts it at Class IIa or above). A general health or wellness app is usually not, and may fall under the Cyber Resilience Act instead. We help you place it in the scoping call.
We map the agreed tests to the applicable Annex I requirements, using OWASP MASVS and MASTG as mobile security references and IEC 81001-5-1 and MDCG 2019-16 as the cybersecurity state of the art.
Yes. We test both, to the same depth. On Android we work with Chameleon; on iOS we test on physical devices. If your app runs on both platforms, we deliver one report per platform.
For medical device software, yes: the state of the art expects a source code analysis, so we ask for it for the parts in scope. For anything that is not a medical device, source code is optional.
When needed. On Android we mainly work with Chameleon, our analysis environment: it gives us deep visibility into what the app does in the operating system, and handles root, pinning and anti-instrumentation checks at the OS level by default. If we hit a limitation that matters for your app, we use physical devices. On iOS we use physical devices.
It depends on the number of apps and platforms, their complexity, the source code and backend interfaces in scope and whether a connected device is involved. We send you a proposal with a fixed price and the schedule. We can usually start the same week you accept the proposal; the start date depends on our team's workload and is stated in the proposal.
Retesting is quoted separately at a reduced rate. In the proposal we give you two options, testing only or testing with one retest round, so you know the total cost from the start.
English by default. If you need it in Spanish, just tell us.
We agree confidentiality terms before you share builds, documentation or source code. We have a standard NDA, but if you prefer to use yours, we are happy to review it.
Tell us about your app and the device it belongs to. We reply within one business day to arrange a scoping call.
Talk to our team