A mobile penetration test is not complete merely because a tester ran a scanner against an APK or IPA. The application that a customer experiences is a chain: packaged code, operating-system controls, local storage, runtime decisions, network communication, authentication and backend services. A provider must be able to follow an identity and a business action through that chain.

The most reliable vendor evaluation uses a small architecture pack and concrete scenarios. Ask candidates what they would inspect, manipulate and prove on each platform.

Start with the real mobile delivery model

Give every candidate the same concise facts: native or cross-platform frameworks, supported OS versions, distribution channel, environments, login methods, device-integrity assumptions, sensitive local data and high-impact workflows. State whether test builds, source maps, symbols or debug entitlements are available.

  • Supported platforms, OS versions and representative devices.
  • Release and test builds with provenance and matching backend environment.
  • User roles, tenants and account state needed for realistic workflows.
  • Third-party SDKs, deep links, push notifications and web views in scope.

Validate static binary-analysis depth

Ask what the tester learns before running the app. Useful analysis maps permissions, entitlements, exported components, URL schemes, deep links, network-security configuration, cryptographic use, local persistence, embedded secrets and third-party libraries. It should trace findings to reachable behaviour instead of dumping strings from a decompiler.

  • Android manifest, signing, exported components and intent filters.
  • iOS entitlements, privacy declarations, URL schemes and keychain use.
  • Embedded keys, endpoints, feature flags and environment indicators.
  • Native and framework-specific code paths that affect sensitive operations.

Require instrumented runtime testing

Runtime testing determines whether controls survive an attacker-controlled device. Ask how the provider observes file writes, inter-process communication, logs, clipboard use, screenshots, backups, keyboard caching, web views and cryptographic operations while a real workflow executes.

The vendor should describe safe use of proxies, debuggers, emulators, rooted or jailbroken devices and runtime instrumentation. It must separate a test technique from a vulnerability: bypassing a client check is meaningful when it exposes data, authority or a server-side gap, not simply because a hook was possible.

  • Evidence ties runtime manipulation to an observable security consequence.
  • Device and OS versions used are recorded for repeatability.
  • Root or jailbreak conditions are stated as prerequisites, not hidden.
  • Crashes and stability effects are controlled and reported immediately.

Examine local data and platform boundaries

Ask candidates to map every sensitive artefact at rest: tokens, personal data, cached API responses, database rows, downloaded documents, screenshots and diagnostic logs. The assessment should cover normal use, logout, account switching, backup, upgrade and uninstall behaviour where applicable.

  • Logout and account switching remove or isolate prior-user material.
  • Backups and shared storage do not expose protected business data.
  • Secrets are not recoverable from logs, notifications or crash output.
  • Biometric gates protect the intended server action, not only a screen.

Test inter-app entry points and web content

Deep links, universal links, app links, intents, activities, extensions and custom schemes create external entry points. Ask how the vendor discovers them and tests origin validation, parameter handling, authorization state and unsafe data return. Include push-notification actions and document handlers.

Embedded browsers and web views need both mobile and web reasoning. The tester should inspect JavaScript bridges, navigation policy, cookie and token sharing, untrusted content and fallback to external browsers. The goal is to prove whether another app or hostile page can cross a meaningful trust boundary.

  • Unauthenticated links cannot invoke privileged workflows.
  • Competing apps cannot capture sensitive callbacks or login results.
  • Web content cannot reach unsafe native bridge functions.
  • Returned data is scoped to the correct user, tenant and transaction.

Connect transport testing to application behaviour

A proxy screenshot alone does not demonstrate transport coverage. Ask how the provider inventories hosts, protocols, background jobs, analytics endpoints and certificate-validation paths. It should test failure behaviour and sensitive requests rather than declaring success only because TLS is present.

  • All first- and third-party destinations are included in the traffic map.
  • Hostname and certificate failures are handled safely.
  • Background sync and offline retry receive the same scrutiny as foreground calls.
  • Sensitive payload evidence is minimized and protected.

Make backend API testing explicit

The app is only one client of the backend. Require API testing with multiple identities and tenants, direct request manipulation and comparison of allowed and prohibited actions. The provider should not stop because a button is hidden or a mobile control blocks the request.

Give a scenario such as changing a payout account, retrieving another customer document or replaying an approved transaction. Ask how the tester follows tokens, identifiers, device signals and workflow state to the authoritative server effect. This exposes whether the team can test BOLA, function authorization and business logic together.

  • API inventory includes calls discovered dynamically and in the binary.
  • Role, object, tenant and state matrices drive authorization tests.
  • Rate limits and automation are tested within agreed safety ceilings.
  • Server-side evidence confirms whether the prohibited effect occurred.

Probe attestation, integrity and client trust carefully

Ask what decision the backend makes from device integrity, application attestation, signing or jailbreak detection. The vendor should test replay, binding, freshness, failure modes and inconsistent enforcement without claiming that any client-side signal is impossible to bypass.

The relevant question is how much authority the server grants to the signal. A mature tester identifies where a forged, stale or missing assertion changes risk and recommends layered controls. It should avoid generic advice that breaks accessibility, legitimate devices or operational recovery.

  • Assertions are bound to the app, device, user and requested action as designed.
  • Stale or replayed assertions do not authorize new high-risk effects.
  • Failure and degradation paths are documented.
  • Server authorization remains effective when client controls are bypassed.

Run a practical evaluation scenario

During the technical call, provide a fictional app with local tokens, a deep link, a pinned API and two customer accounts. Ask the lead tester to outline the first day, the hypotheses, required access, stopping conditions and evidence. Follow with one complication such as an offline queue or a cross-platform module.

Strong candidates move coherently between binary, device, network and backend layers. They ask about risk and authority, not merely which scanner can open the package. Record answers against a pre-issued scorecard so a polished presentation does not outweigh technical substance.

  1. Score platform knowledge separately for Android and iOS.
  2. Score the connection between client observations and backend effects.
  3. Review one sanitised mobile finding for reproducible evidence.
  4. Confirm the named lead tester will perform or directly supervise the work.

Define the evidence and retest standard

Require a coverage matrix that maps application surfaces and test identities to completed work, constraints and evidence. Each finding should identify build, OS, device condition, account context, request or local artefact, impact and a safe reproduction path. Screenshots without state are not sufficient.

Retesting must use the relevant layer. A local-storage fix should be checked across lifecycle events; an authorization fix should compare identities against the final backend effect. The vendor should state whether related endpoints, builds and platforms are sampled or fully re-executed.

Use the official OWASP Mobile Application Security Testing Guide for test techniques and the OWASP Mobile Application Security Verification Standard for control objectives. Use the OWASP API Security Top 10 to frame backend API risks. Tailor all three to the actual app and threat model.

Appoint a team that can test the whole transaction

Mobile assurance fails when separate reviewers inspect a package, a device and an API without joining their evidence. The buyer should demand one accountable coverage model and a lead tester who can explain the complete path.

WIMD evaluates mobile providers using architecture-specific scenarios, platform-aware techniques, identity and tenant matrices, operational safety gates and retestable evidence. The result is a selection decision tied to the risk of the released product rather than a generic mobile checklist.