Point us at your app, API, cloud or network — and let us write the report.
We used to say "mobile apps only". We don't any more. The team that built a device nothing can fingerprint tests web applications and APIs, cloud accounts and Kubernetes, external and internal networks, and the mobile apps that defeat everyone else's tooling — as a scoped penetration test, an objective-led red team, or a retained programme across releases. Every finding arrives with the proof, the path we took, and the fix.
What we test
How an engagement runs
- Scope and authorize. A short call plus whatever exists — architecture diagram, API spec, role matrix, app build. You get a fixed price, a fixed window and a test plan. We get a signed engagement agreement and a written authorization naming the in-scope assets, the dates and the authorizing individual.
- Map before attacking. Enumeration and attack-surface mapping first, so the testing time is spent where the surface actually is rather than on whatever the scanner found first.
- Test manually, report continuously. Anything critical reaches you the day we find it, not in three weeks when the report lands. Nothing is sat on for narrative effect.
- Prove it, minimally. We prove the bug, we don't exercise it: one record rather than a dump, a read rather than a write, no pivoting past the first proof unless the engagement objective requires it and the authorization covers it.
- Report for two readers. An executive summary for whoever decides what gets funded, and technical findings with reproduction steps, evidence and severity reasoning for the engineer who has to fix them. Remediation ranked by attacker cost removed per hour of engineering.
- Retest and attest. One retest round after your fixes, an updated report, and an attestation letter you can hand to customers and auditors.
Track record
Our researchers report through public bug bounty programmes, and the work has been accepted by programmes run in aerospace, digital-asset custody and identity infrastructure — organisations with mature security functions, internal red teams, and a constant stream of other researchers already looking at the same assets. Among them:
Programme names describe our own research activity and are used for identification only. No affiliation, sponsorship or endorsement by these companies is implied, and no detail of any report, finding or affected asset is disclosed here or anywhere else. Trademarks belong to their respective owners. Client engagements are confidential by default; references are available on request under NDA.
Why a bug-bounty background matters for a paid test
Bounty work selects for one thing: finding something real on an asset that many competent people have already looked at, where a theoretical finding earns nothing. That is a different habit from working through a checklist, and it is the habit you want on a target that has already been tested twice. It also means we come to your engagement already knowing which classes of bug survive a mature security programme — and those are precisely the ones a coverage-driven test tends to miss.
What this is not
This is not an automated scan presented as a test — if a scanner could find it, it is in an appendix, not the body of the report. It is not a compliance certificate: it is the technical evidence an auditor asks for, which is a different and more useful thing. It is not a claim that we defeat hardware-backed attestation, because no virtual device does; what we test is how your application handles attestation, which is where the real defects live. And we do not test systems a client does not own or is not contractually entitled to have tested — including anything that would amount to defeating a third party's identity verification, platform controls or anti-fraud stack.
Buying this as part of compliance?
Every TajApps compliance engagement — SOC 2 Type I or II, ISO/IEC 27001, ISO/IEC 42001 — includes one of these penetration tests at no additional charge, because every one of those frameworks expects technical testing and most companies end up buying it separately anyway. How the compliance engagement runs →
Questions buyers ask
What can you test?
Web applications and APIs, mobile applications on Android and iOS, cloud environments on AWS, Azure and GCP including Kubernetes, external and internal network infrastructure, and objective-led red-team engagements against a named goal. We also run purple-team exercises where your detection team watches and tunes while we work.
How is scope and price agreed?
We scope from a short call plus whatever documentation exists — an architecture diagram, an API specification, a role matrix, an app build. You get a fixed price and a fixed window before anything starts. Scope changes mid-engagement are quoted, never absorbed silently, because silent absorption is how a test ends up thin everywhere.
Do you need credentials or source code?
For an application test, yes to credentials: an unauthenticated test of an authenticated product covers a fraction of the attack surface, and two accounts per role let us test authorization properly. Source code is optional. Black-box matches what an attacker has; grey-box finds more in the same number of days and is usually better value if you can share.
Is a retest included?
One retest round of the findings is included in every engagement, with an updated report showing what was fixed and what still stands. Teams shipping continuously usually move to a retainer that re-tests each release instead of once a year.
What does the report look like?
An executive summary written for someone who has to decide what to fund, a technical findings section with reproduction steps, evidence and a severity rating with the reasoning behind it, and a remediation section ranked by attacker cost removed per hour of engineering. Plus an attestation letter suitable for customers and auditors. Findings are delivered as they are found, not held back for the report.
What makes your mobile testing different?
We build the device. Privara is our own de-emulated Android build that defeats emulator, root and instrumentation detection, which means we test the resilience layer with the environment your controls were designed to stop rather than with a stock emulator your app detects in the first second. We can also read an app's TLS traffic without a proxy, a CA or a hook in the process, by recovering session keys from hypervisor memory — so certificate pinning and anti-instrumentation defences do not hide the API from us.
Do you do red teaming, or just penetration testing?
Both, and they answer different questions. A penetration test asks how much of this is broken, with coverage as the goal. A red team asks whether a motivated adversary can achieve a specific objective without being caught, with stealth and a named goal. If your detection capability has never been tested against someone who is trying not to be seen, the red team is the one that teaches you something.
What authorization do you require?
A signed engagement agreement and a written authorization to test naming the in-scope assets, the dates and the individual authorizing it. Where a third party hosts or operates an in-scope asset, we need their permission too. We decline anything we cannot establish authorization for, and we do not test systems a client does not own or is not contractually entitled to have tested.
Tell us the target, get a fixed quote
What the system is, what you are worried about, and whether a customer, an auditor or a board is waiting on the answer. We will come back with scope, timeline, team and a fixed price — usually within a day.
Email support@tajapps.com →