Mobile app security must follow the full SDLC, not just release

At a glance

What this is: This is Guardsquare’s view that mobile app security has to be built across the entire SDLC, with testing, hardening, runtime protection, attestation, and monitoring working together.

Why it matters: It matters because IAM, PAM, and application security teams increasingly have to govern mobile apps as trusted clients, especially where authentication, secrets, and backend access depend on app integrity.

By the numbers:

• Today, over 60% of all global web traffic comes from mobile devices, and 90% of mobile internet time is spent using apps.
• Nearly 70% of organisations are not currently obfuscating their code, leaving their mobile apps vulnerable to static analysis.
• The majority of organisations, 60%, do not have runtime application self-protection enabled, leaving their apps open to dynamic analysis.

👉 Read Guardsquare's analysis of mobile app security across the full SDLC

Context

Mobile application security is not a single control problem. It is a lifecycle governance problem because mobile apps are compiled, distributed, reverse engineered, instrumented, and abused in ways that web controls do not fully cover. The key issue in this article is that mobile app security has to be designed into the SDLC if teams want to protect authentication flows, APIs, and runtime integrity.

That matters to identity programmes because mobile apps often act as trust anchors for user sessions, API calls, attestation signals, and access decisions. If the app can be cloned, modified, or instrumented, identity controls downstream inherit that weakness. Guardsquare’s examples are typical of the broader mobile security challenge: teams usually recognise the risk, but they still operationalise protection too late in the lifecycle.

Key questions

Q: How should security teams govern application security across the SDLC?

A: They should treat the SDLC as a chain of trust, not a sequence of isolated review steps. That means combining vulnerability scanning with provenance checks, secret governance, pipeline identity controls, and runtime monitoring. The goal is to know which identity can change code, which dependencies were introduced, and whether anything suspicious reached production.

Q: Why do mobile apps create identity and secret exposure risk?

A: Mobile apps often carry authentication flows, API tokens, and session material that connect directly to enterprise systems. If storage, transport, or certificate handling is weak, those secrets can be intercepted or reused. That turns app security into identity governance, because the app becomes a path to downstream access rather than just a user interface.

Q: What do teams get wrong about mobile runtime protection?

A: They often place too much trust in a single visible control point. If a hook, debugger, or instrumentation tool can identify where the check lives, that control becomes easy to target. Runtime defence works better when checks are distributed, varied, and backed by server-side validation rather than treated as a single barrier.

Q: How should organisations decide when to block a mobile client?

A: They should block or step up controls when attestation fails, runtime tampering is detected, or the device environment indicates instrumentation, rooting, or emulation. The decision should be based on the risk of the action being attempted, not on login alone. High-risk transactions deserve stricter client trust checks than low-risk app usage.

Technical breakdown

Why mobile app hardening has to happen before release

Mobile app hardening is about making the compiled application harder to inspect, modify, and reuse. Techniques such as obfuscation, control flow hiding, code virtualization, and encryption raise the cost of reverse engineering, but they do not eliminate the attack. They work best when paired with build-time validation and tested continuously because hardening is only one layer in a broader assurance model. In mobile environments, late-stage protection is especially important because shipped binaries can be copied, analysed, and tampered with outside the developer’s control.

Practical implication: add hardening to the release pipeline, not as a post-release patch.

How RASP changes the runtime trust model for mobile apps

Runtime application self-protection, or RASP, embeds checks inside the application so the app can detect tampering, debugging, hooks, emulators, root access, and other hostile conditions while it is running. That matters because mobile threats often emerge after installation, not just during development. RASP does not replace testing or attestation; it extends protection into execution where the app can react to abuse in real time. In governance terms, it turns runtime behaviour into a security signal rather than assuming the client device is trustworthy.

Practical implication: use RASP to trigger containment actions when runtime integrity is lost.

Why app attestation is an identity control as much as a security control

App attestation verifies that the frontend app calling an API is genuine, unmodified, and running in an acceptable environment. That makes it an access control input, not just a malware signal, because backend services can deny requests from cloned or instrumented clients. This is important where mobile apps participate in authentication, transaction approval, or sensitive API access. The article’s emphasis on bot blocking and dynamic policy enforcement reflects a broader point: the client application itself has become part of the trust decision, so identity assurance must extend to the app instance.

Practical implication: treat attestation results as part of API authorisation decisions, especially for high-risk actions.

Threat narrative

Attacker objective: The attacker wants to turn a trusted mobile client into a reusable access path for API abuse, credential theft, fraud, or tampering.

1. Entry occurs when an attacker installs a copied or modified mobile app, or instruments a legitimate build on a rooted or emulated device.
2. Escalation happens when the attacker bypasses integrity checks, extracts secrets, or manipulates runtime behaviour through hooks, malware injection, or dynamic analysis.
3. Impact follows when tampered clients abuse APIs, clone accounts, or automate fraudulent activity against backend systems.

NHI Mgmt Group analysis

Mobile app security is now an identity assurance problem, not only an AppSec problem. When a mobile app is the front end for authentication, transactions, or API access, its integrity becomes part of the trust chain. If the app can be cloned, instrumented, or repackaged, the downstream identity decision is weakened before the request reaches IAM or PAM controls. Practitioners should treat app integrity as a trust prerequisite, not a cosmetic hardening layer.

Lifecycle security is the only realistic response to mobile-specific attack surfaces. Static analysis, runtime protection, and attestation solve different failure modes, and none of them is sufficient alone. The article’s central point is that mobile risk spans design, development, deployment, monitoring, and maintenance. That aligns with broader security governance thinking: controls that appear late are usually the least effective against mobile abuse.

Runtime visibility creates a new feedback loop for mobile governance. Monitoring is not just detection after compromise. It is a source of evidence for prioritising future hardening, deciding where attestation should be stricter, and identifying which client behaviours should trigger response. For identity teams, this is where mobile telemetry starts to inform session trust, fraud detection, and adaptive access decisions.

Code hardening fatigue is a real governance risk. The article implicitly shows that many organisations know the controls exist, but still fail to operationalise them at scale. That gap is not about awareness alone. It is about fragmented ownership between app teams, security teams, and identity teams, which leaves mobile protection inconsistent. Practitioners should align engineering ownership with runtime trust requirements.

Mobile trust boundaries should be explicit, not assumed. Mobile apps routinely sit inside access flows where authentication, attestation, and API authorisation blur together. The governance mistake is to assume the device or the app is inherently trustworthy once a user logs in. Teams should instead define what evidence is required before a mobile client is allowed to act on behalf of the identity.

What this signals

Mobile app teams should expect tighter coupling between application integrity and access governance. The practical shift is toward treating attestation, runtime telemetry, and backend authorisation as one control chain rather than separate disciplines, especially where apps carry sensitive identity signals or secrets.

Client trust drift: as mobile apps become part of access decisions, the boundary between device trust, app trust, and user identity gets harder to police. That creates a governance problem for IAM and fraud teams, not just mobile developers, because failures in the client layer now affect session assurance and transaction confidence.

A sensible next step is to align mobile security telemetry with identity risk scoring and response workflows. That means using runtime signals to decide when a client should be constrained, challenged, or denied, rather than assuming a successful login proves the whole chain is trustworthy.

For practitioners

• Map mobile trust dependencies across the SDLC Identify where the mobile app influences authentication, API access, transaction approval, or session trust, then assign controls to plan, build, test, deploy, monitor, and maintain phases.
• Add hardening to build and release gates Require obfuscation, code virtualization, and integrity protections before release for any mobile app that exposes sensitive APIs or credentials.
• Use attestation as a policy input Tie app attestation results to backend authorisation decisions so cloned, modified, or hostile clients cannot access protected services.
• Feed runtime telemetry into maintenance decisions Use RASP and threat monitoring data to prioritise version updates, refine detection logic, and decide where runtime controls need to be tightened.

Key takeaways

• Mobile app security fails when teams treat it as a release problem instead of a lifecycle governance problem.
• Reverse engineering, tampering, and API abuse remain viable because many organisations still skip obfuscation and runtime protection.
• Identity programmes should treat app attestation and runtime integrity as part of the trust decision for sensitive mobile access.

Key terms

• App Attestation: App attestation is a trust decision that checks whether a mobile app and its device environment meet policy before sensitive actions are allowed. It can use device integrity, app integrity, and telemetry to decide whether requests should be trusted, restricted, or denied.
• Runtime Application Self-Protection: RASP is a runtime control that detects and can block suspicious application behaviour as it happens. In NHI contexts, it can contain abuse from service accounts or tokens, but it does not replace identity ownership, entitlement review, rotation, or deprovisioning.
• Code Hardening: Code hardening adds defensive logic to software so it is harder to inspect, tamper with, or instrument after delivery. In practice, it is a runtime integrity measure that raises the cost of reverse engineering without changing the core function of the application.
• Mobile SDLC Security: The practice of placing security controls across the full mobile software development lifecycle, from planning and design through build, deployment, monitoring, and maintenance. It recognises that mobile risks emerge before and after release, not only during coding.

What's in the full article

Guardsquare's full article covers the operational detail this post intentionally leaves for the source:

• Phase-by-phase mobile SDLC guidance for teams deciding where to place security controls
• Implementation detail on code hardening, RASP checks, and app attestation in production builds
• Examples of how monitoring signals feed maintenance and version update decisions
• Guardsquare's product-specific workflow for AppSweep, DexGuard, iXGuard, and ThreatCast

👉 Guardsquare's full post covers the runtime protection, attestation, and monitoring detail behind the lifecycle model.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It is built for practitioners who need to connect identity controls to broader security decisions.