How does Mobile Application Vetting (MAV) work?

What Mobile Application Vetting actually checks before approval

Mobile Application Vetting is most useful when it is treated as a structured pre-admission review, not a one-time checklist. The vetting team is trying to answer four practical questions: what the app does, what data it touches, what privileges it requests, and whether its behaviour matches its stated purpose. That makes it a control over mobile app risk, not just a code review.

The review usually combines static inspection of the package, dynamic observation of runtime behaviour, and policy checks against what the business is willing to allow. Static analysis looks for suspicious code patterns, embedded secrets, risky libraries, insecure storage and overly broad permissions. Dynamic analysis looks for runtime network calls, local data handling, device interactions and behaviour that only appears after launch or user interaction.

Vetting also works better when it uses reputation and provenance signals. A clean scan does not prove trustworthiness, because a benign-looking app can still misuse permissions, load risky third-party components, or change behaviour after installation. That is why many organisations treat vetting as a decision pipeline: if an app fails policy or exceeds a risk threshold, it is blocked, quarantined, or approved only with restricted access.

Why static and dynamic analysis need to be paired

Static analysis and dynamic analysis answer different questions, so either one alone leaves blind spots. Static analysis is good at spotting embedded credentials, hard-coded endpoints, SDK risk, suspicious permissions, and insecure coding patterns before the app ever runs. Dynamic analysis is better at revealing what the app actually does with user data, what it transmits over the network, and whether it behaves differently once it has runtime context.

That pairing matters because mobile apps often hide their real behaviour behind obfuscation, conditional execution, feature flags, or delayed loading of modules. A package that looks ordinary on inspection can still exfiltrate data, call risky services, or activate functionality only after it reaches a live device. The best vetting programmes compare the declared purpose of the app, the permissions it requests, and the behaviour it shows under test.

For defenders, the useful output is not “passed” or “failed” in the abstract. It is a decision backed by evidence, such as whether the app requests access that is not needed for its stated function, whether it handles sensitive data safely, and whether its third-party dependencies introduce unacceptable uncertainty. That is what makes vetting operationally useful rather than just informational.

How vetting turns findings into a deployment decision

Mobile Application Vetting only reduces risk when the result changes what happens next. In practice, organisations define acceptable thresholds before review begins, then map findings to an action such as allow, allow with constraints, isolate in a managed container, require remediation, or deny. This prevents inconsistent approvals and makes the control repeatable across many apps and teams.

The decision usually depends on context, not just on the presence of a finding. A low-risk productivity app with a minor excess permission may be acceptable if it is wrapped by mobile device management and does not touch sensitive systems. A consumer app with the same permission pattern may be rejected if it cannot be governed, monitored, or limited in production use. Vetting is therefore strongest when it is tied to device policy, app management, and data classification.

That is why approval should be paired with post-approval constraints where possible. If the app is allowed, it should still be limited by containerisation, selective wipe, network controls, and baseline mobile security policy. The point is to reduce the blast radius of the app’s access, not to assume that approval eliminates the need for control.

Risk and Threat Considerations

Mobile app vetting reduces exposure, but it is not a guarantee of benign behaviour. The main risk is false confidence: an app can pass initial review and still become dangerous through later updates, SDK changes, new permissions, or server-side behaviour that was not visible during testing. The threat is especially material when the app handles credentials, personal data, corporate data, or device-level permissions.

Failure mechanism: Attackers and risky developers exploit the gap between what an app appears to do during review and what it does at runtime, after an update, or when combined with third-party code. Obfuscation, delayed payload activation, hidden data flows, and dependency changes can all bypass a shallow approval process.

Impact: The result can be data leakage, credential exposure, silent over-collection of device or user information, or an app becoming a foothold for broader mobile compromise. If vetting does not include ongoing reassessment, the organisation can end up trusting an app long after its risk profile has changed.

Practitioner Guidance

What to verify: Validate that your vetting criteria explicitly cover permissions, data handling, runtime behaviour, third-party SDK risk, and update drift. If the app’s observed behaviour is broader than its stated business purpose, treat that as a decision point, not a documentation issue.

Decision rule: If the app needs broad access to data, sensors, or enterprise resources to function, require stronger isolation and tighter approval thresholds. If the app can function with limited permissions, deny any unnecessary access rather than accepting “just in case” requests.

What practitioners underestimate: Vetting is not a substitute for lifecycle control. Re-review apps after major updates, new SDK adoption, permission changes, or changes in distribution channel, because the safest app at approval time can become the riskiest app later.

Practitioner takeaway: Treat mobile application vetting as an evidence-based access decision that must stay current, because the real control failure is often not the first approval, but the unreviewed change that follows it.

Related resources from NHI Mgmt Group

• Guide: Mobile App Security Guide
• What is the difference between mobile application security testing in CI/CD and periodic mobile app vetting?
• How does Mobile Application Management (MAM) work?
• How should IAM teams govern mobile application access in BYOD environments?
• What do organisations get wrong about mobile application management?