Citizens use it to identify themselves, complete procedures and keep documents. If an attacker can pass as them, they can complete procedures in their name or reach their data. The same attack that works against the app works against every citizen who uses it.
Mobile app security for the public sector.
An app for a public administration holds citizens' identity and their data, so an attacker who passes as a citizen can act in their name. We test whether that is possible, and give you the report the app needs to clear its security acceptance before it goes into production.
The app is the administration's front desk.
How attackers abuse a public administration app.
- Identity theft: impersonating a citizen or reusing their session to act in their name.
- Reaching other citizens' data: changing an identifier in a request to see another person's procedures or documents.
- Tampered apps: getting your backend to accept requests from a modified version of the app.
- Traffic interception: bypassing certificate pinning to read or change what the app sends and receives.
The weaknesses behind impersonation and data exposure.
In public administration and digital identity apps, impersonation and citizen-data exposure keep coming back to the same technical weaknesses. These are what we go after.
- Identity and session handling: sessions that can be reused or forged, so an attacker acts as the citizen.
- Broken API authorization: one citizen reading or changing another citizen's procedures or data by changing an identifier in a request.
- Sensitive data on the device: documents, certificates and tokens left in plaintext storage, logs or backups.
- Insecure key and credential storage: identity keys or tokens that another app, or anyone with the phone, can read.
- Deeplink hijacking and intent redirection: a malicious app intercepting identity callbacks or authorization codes.
- Third-party SDKs: analytics or identity components that leak data or widen the attack surface.
You can see several of these worked through end to end on a deliberately vulnerable app in our sample report.
Services for your app.
Mobile app penetration testing
We test the app and its API before it goes into production, and show you what an attacker could reach.
OWASP MASVS assessment
Asked to meet a mobile security standard? We tell you which OWASP MASVS controls the app meets and which it does not.
App protection
testingDoes the app detect modified versions or rooted phones? We check whether an attacker can bypass those checks.
The standards that apply to you.
Public administration and digital identity apps fall under several standards and regulations. We cover the mobile side of each: some we report on directly, others we get you ready for the lab.
ENS
Testing for your app's ENS security acceptance before it goes into production.
EUDI wallet
Pre-evaluation of your EU Digital Identity wallet app before its certification.
Pre-evaluation for an accredited labNIS2
Security testing of your app and its API for your NIS2 risk management.
CRA
Security test reports for your Cyber Resilience Act technical documentation.
Common Criteria and EUCC
Pre-evaluation of your product before the accredited Common Criteria or EUCC laboratory.
Pre-evaluation for an accredited lab
Why vulnit for the public sector.
We have been evaluators
Before vulnit, we worked in security certification laboratories, evaluating products under schemes such as Common Criteria, EMVCo SBMP and LINCE.
We test your protections the way an attacker would
Our team contributes to OWASP Mobile Application Security, the main reference for testing mobile apps. OWASP recognized this work by naming vulnit an OWASP MAS Advocate.
Our own technology
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 teamPublic sector mobile security frequently asked questions.
Can you test in pre-production?
Yes. We test in the environment you prefer, including pre-production, which is where the ENS requires testing for medium and high category systems.
Does your report work for ENS acceptance?
The report sets out the scope, the tests and the results for the app and its API. The decision to accept the app belongs to your organization, which can use the report as evidence.
Do you perform the LINCE or Common Criteria evaluation?
An accredited laboratory performs the evaluation and the certification body issues the certification. We review your product first, drawing on our experience working in those laboratories.
Do you test iOS as well as Android?
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.
Do you need source code?
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 citizens. If you share the source code, we review it too.
Can I combine several services in one project?
Yes. They all start from the same analysis of your app. Tell us what you want to know, for example which vulnerabilities it has, whether your protections stop an attacker or which OWASP MASVS controls it meets, and we combine it into a single project.
How do you handle confidentiality?
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.
Does your app need to go into production?
Tell us about your app and the standards you need to meet. We reply within one business day to arrange a scoping call.
Talk to our team