How should identity and appsec teams share responsibility for mobile app risk?

Why Identity and AppSec Ownership Must Meet in the Middle

Mobile app risk sits at the boundary between access governance and application behaviour. Identity teams usually control the app’s authentication paths, token lifetimes, service accounts, and secret handling, while appsec teams see whether the app leaks data, over-requests permissions, or trusts inputs it should not. If either side owns the problem alone, the result is a blind spot: the identity layer may be well governed, yet the app still moves sensitive data in unsafe ways, or the app may be hardened while weak access paths remain open. For a broader control view, NIST Cybersecurity Framework 2.0 is useful because it frames security as coordinated governance, protection, detection, response, and recovery rather than a single-team task. In practice, many organisations discover this split only after a mobile release has already exposed an access path or unexpected data flow.

How Shared Responsibility Works Across the Mobile Stack

Shared responsibility works best when each team is accountable for the part of the mobile trust boundary it can actually see and influence. Identity teams should own the design and governance of identity-bound controls: app-to-backend trust, device or user authentication, secrets used by the app, token issuance, rotation, revocation, and the service identities that mobile features call. Appsec teams should own the security of the code path itself: input handling, storage of sensitive material, transport security, permission usage, runtime tamper resistance, and whether the app sends data to approved destinations only.

The practical failure point is handoff ambiguity. A mobile app may use a valid token in exactly the wrong place, retain data after logout, or call a backend with a service credential that was never meant for that client path. Identity teams can govern the credential, but they cannot verify the app’s internal logic alone. Appsec teams can inspect the logic, but they cannot safely bless a weak identity pattern that grants the app more privilege than its use case requires. That is why the boundary must be explicit.

• Identity teams define who and what the app can authenticate as, and under which conditions.
• Appsec teams verify that the app only requests, stores, and transmits what the business need justifies.
• Both teams review high-risk flows such as embedded secrets, delegated access, and backend API calls from the client.
• Both teams agree on the evidence needed before release, especially for changes that alter trust, scope, or data movement.

NIST SP 800-53 Rev. 5 Security and Privacy Controls is relevant here because it supports this split view of access control, secure configuration, and application protection. Where this guidance breaks down is when teams treat a mobile app as “just a client” and assume the backend or IdP will compensate for insecure client-side behaviour.

Where the Boundary Gets Messy in Real Mobile Apps

Tighter ownership boundaries often improve accountability, but they also increase coordination overhead, so organisations must balance clearer responsibility against slower release decisions. The messy cases are the ones where mobile apps behave like both identity consumers and data-processing systems.

That includes apps with offline mode, embedded APIs, device-bound credentials, federated login, push notification channels, or features that pass through third-party SDKs. In those cases, it is not enough for identity teams to say the token is valid or for appsec to say the code is scanned. Valid tokens can still be over-scoped, and clean static analysis can still miss risky runtime behaviour such as unexpected API calls, telemetry leakage, or client-side storage of sensitive data.

There is also a governance split that teams often underestimate. Identity teams need to know which mobile clients are authorised to request which scopes, and appsec teams need to know whether those scopes are actually necessary in the app’s use cases. If the scope model and the feature model do not match, the app inherits privilege it never needed. That is usually a design problem, not a defect that can be fixed by testing alone.

For teams that need a common control language, the right question is not who “owns” mobile security overall, but which team can prove the control is effective at the point where the risk appears. That means identity owns trust and entitlement, appsec owns behaviour and data handling, and neither should sign off on the other’s domain without evidence.

Practitioner Guidance

What to prioritise: Start by mapping the mobile app’s trust paths, not the team org chart. The most useful split is usually identity for credentials, tokens, scopes, and service identities, and appsec for code paths, storage, transport, and data egress.

What to verify: Before release, verify that every privileged mobile flow has both an identity decision and a runtime decision. If a flow can reach sensitive data, teams should be able to show who authorised it, what scope it uses, and how the app prevents misuse in execution.

Common mistake: The usual error is to treat successful authentication as proof that the app is safe. That assumption fails whenever the app can reuse credentials too broadly, call unapproved endpoints, or move data in ways the access policy never intended.

Practitioner takeaway: Mobile app risk is managed well only when identity governance and application behaviour are both testable, because either one without the other leaves a gap that release checks often miss.

Related resources from NHI Mgmt Group

• How do identity and cloud teams share responsibility for agentic AI risk?
• Who should own enterprise identity risk reduction when security and identity teams share responsibility?
• Why do app-native identity workflows create governance risk for IAM teams?
• How should IAM teams respond when identity tools do not share risk context?