Does your app apply strong customer authentication? We test whether it holds against a real attacker, and give you an independent report that your PSD2 auditor can rely on.
For payment service providers and the apps that apply strong customer authentication (SCA).
The PSD2 regulatory technical standards on strong customer authentication (Delegated Regulation 2018/389) set what your SCA has to do, and how it is checked:
The audit evaluates the measures and reviews the evidence that they have been tested. The auditor does not run the test. We perform that testing against a real attacker, and our report is the evidence the audit relies on.
We check whether an attacker can defeat or sidestep your strong customer authentication. Depending on the agreed scope, testing can cover:
States the scope, the build and the interfaces tested, and the result, written so your auditor can use it as evidence. 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.
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.
Our team comes from security certification laboratories, with experience in mobile payment standards such as EMVCo SBMP and in Common Criteria. We know what strong customer authentication has to resist in practice.
Our team contributes to MASVS-RESILIENCE, the part of OWASP MAS that covers platform integrity and resistance to tampering, reverse engineering, emulators and dynamic instrumentation. 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, so our time goes into finding issues in your app instead of getting past them.
Meet the teamThe SCA security measures must be tested and then audited by an independent auditor with IT security and payments expertise. The audit evaluates the measures and reviews the evidence: the auditor reviews the evidence rather than running the test, so our penetration test report is what that review relies on. We are an external, independent team.
No. The audit of the SCA measures is a separate role, performed by an independent auditor. We perform the security testing and give you the report; your auditor uses it as part of their review. There is no accredited laboratory that issues a product certificate here.
Yes. Getting past those protections is part of our daily work, and with Chameleon, our own Android, it is handled at the operating-system level by default, so those checks do not get in the way of the analysis. If you also want to know whether your protections stop an attacker, we check that in app protection testing.
They can be, and we generally recommend it: much of a mobile app's risk lies in the APIs it uses. We decide it with you case by case, depending on the type of app and what its backend exposes.
No. By default, testing is black-box: we attack your app with the same information an attacker would have, using the same build you release to your users. If you prefer, we can also review the source code.
Yes. Download our sample report, a real deliverable from a full assessment of a deliberately vulnerable app.
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, the complexity of your app and the backend interfaces in scope. We send you a proposal with a fixed price and the schedule. It usually takes one to two weeks per platform, report included. 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.
You receive one report per platform, with every finding detailed. If you also want to use them in your own tools, we provide them as CSV or JSON too.
English by default. If you need it in Spanish, just tell us.
We agree confidentiality terms before you share builds or documentation. We have a standard NDA, but if you prefer to use yours, we are happy to review it.
Tell us about your app and how it applies strong customer authentication. We reply within one business day to arrange a scoping call.
Talk to our team