Dynamic Testing

Expanded Definition

Dynamic testing is the practice of observing an application while it executes, rather than only inspecting source code or configuration. For mobile security, that means validating runtime behaviour on a real device or emulator, including network destinations, feature flags, permission prompts, storage access, and security controls that only appear once the app is active. This makes it distinct from static analysis, which can reveal risky code paths that may never be reached in production. Definitions vary across vendors on how much instrumentation is acceptable, but the core idea is the same: measure what the app actually does when launched, authenticated, and driven through its functions. For governance and control mapping, NIST Cybersecurity Framework 2.0 is the most relevant high-level reference because it frames validation, monitoring, and risk treatment as ongoing security disciplines. The most common misapplication is treating a single clean test run as proof of safety, which occurs when teams test only one path, one account state, or one device profile.

Examples and Use Cases

Implementing dynamic testing rigorously often introduces coverage and environment constraints, requiring organisations to weigh realistic runtime visibility against the cost of device matrices, test orchestration, and repeatable setups.

• Security teams launch a mobile banking app on an emulator and inspect whether API calls expose session tokens, secrets, or sensitive identifiers in transit.
• Testers interact with a health app to confirm whether camera, microphone, and location permissions are requested only when a feature genuinely needs them.
• AppSec reviewers compare feature activation in the codebase with runtime behaviour to identify dormant functionality that becomes enabled only after remote configuration changes.
• QA and security teams validate jailbreak or root detection logic by running the app in controlled conditions and checking whether it blocks access as expected.
• Analysts use runtime observation alongside guidance from NIST Cybersecurity Framework 2.0 to document how testing evidence supports risk decisions and remediation tracking.

Why It Matters for Security Teams

Dynamic testing matters because many mobile risks are behavioural, not merely structural. An app may look secure in code review yet still leak data, over-request permissions, or call unapproved endpoints once a user logs in and the full workflow starts. Security teams need runtime evidence to confirm whether protections such as certificate validation, access restrictions, and feature gating actually operate under real conditions. This is especially important when mobile apps integrate with identity flows, because token handling, session binding, and device trust decisions often occur only at execution time. Where non-human identity or agentic workflows are involved, dynamic testing also helps verify whether an app or client is safely interacting with APIs, secrets, and automation endpoints. The control value becomes clearer when aligned with a broader governance view such as NIST Cybersecurity Framework 2.0, because runtime validation supports detection and response as much as prevention. Organisations typically encounter the operational cost of missed runtime issues only after a breach, failed audit, or exposed test assumption, at which point dynamic testing becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Should organisations use dynamic testing for GraphQL security?
• Dynamic Application Security Testing
• What is the difference between static and dynamic credentials?
• How do I migrate from static credentials to dynamic credentials?