IAM responsibilities must be clearly divided between the client and the development partner. The client remains responsible for policy-level architectural decisions such as IdP configuration and risk acceptance, while the development partner carries out the technical implementation, including secure token storage and API integration. This division should be formally recorded to prevent audit deadlocks and delays.
IAM responsibilities in mobile app development
Effectively dividing IAM responsibilities between the client and development partner is crucial to the success of enterprise mobile apps. This article provides insight into how these responsibilities can be structured to minimize technical and compliance challenges.
- Explicitly define policy-level and technical responsibilities and record them contractually.
- Ensure a clear separation between client-side and server-side authorization to minimize security risks.
- Implement a formal IAM matrix to clarify ownership and responsibilities.
- Manage vulnerabilities proactively with defined remediation timelines and continuous monitoring.
- Ensure robust session management and token storage to prevent unauthorized access.
Why IAM responsibilities are crucial in enterprise mobile apps
In an enterprise mobile app, IAM is not merely part of the login screen. It determines who gets access, under what conditions that access remains in place, and who can demonstrate that those choices align with the organization's risk profile. As a result, IAM often becomes an assessment point before a release. When responsibility for policy choices, evidence, and acceptance is not assigned in advance, a project can be technically ready without the organization being able to release the mobile app.
The context also determines where enforcement should be applied. For centrally managed B2E devices through MDM, central IdP Conditional Access may form the primary layer of access control. For external B2B or BYOD users, the mobile app itself may require additional enforcement, for example through biometrics and binding to the local keystore. This difference affects not only the selected measure, but above all the question of who establishes the principles, who assesses how they work, and who accepts changes. A responsibility overview that does not distinguish between these user and device contexts leaves room for conflicting expectations.
The need becomes more acute when the app processes regulated data. For medical data under NEN 7510 or financial data under DORA, the available principles require strict, irrefutable evidence. Formal STRIDE threat modeling and an explicit sign-off of residual risk must also take place before approval of a mobile release. These are governance actions: a development partner can provide material, but cannot silently determine on the client's behalf what remaining risk is acceptable.
An unanswered authority question becomes apparent in findings arising from limitations of mobile platforms. The internal security department may then refuse to approve, while nobody within the project team is formally authorized to sign a Risk Acceptance Waiver. The result is not a purely technical problem, but a release deadlock. Clear IAM responsibilities therefore make visible in advance who makes decisions, who gathers evidence, and who bears the remaining risk when full mitigation is not possible.
The consequences of unclear IAM responsibilities
Uncertainty about IAM often begins during the scoping of a mobile app. When IAM is then described as a generic SSO login feature, the assignment becomes too limited. The development partner may implement a standard OAuth flow, while fine-grained authorization at API level remains out of scope. The difference only becomes apparent when auditors and the CISO request evidence of segregation of duties shortly before launch. At that point, not only functionality or documentation is missing, but also a previously shared agreement on who should have specified, built, and had this outcome tested.
The delay follows from the order in which the shortfall comes to light. An app may approach release based on the assumption that a successful login is sufficient. It then emerges that the requested substantiation for segregation of duties is unavailable. The project must then return to design, implementation, and assessment, potentially resulting in weeks of delay. Compliance artifacts thus become not a final administrative step, but a late obstacle to the planned launch.
A missing division of roles also causes stagnation after go-live. A security scanner may find a critical vulnerability in an authentication SDK. The client may then demand immediate patching within 48 hours, while the development partner considers the assignment complete because no vulnerability SLA has been agreed. The technical finding is then clear, but the remediation obligation, response time, and funding are not. A discussion about additional costs delays the solution precisely when the exposure is active.
In the described scenario, that delay results in immediate compliance failure under NIS2 and the GDPR. The core problem is therefore not that one party must necessarily own all IAM tasks. It is that, without explicit boundaries, the assignment provides no answer to two operational questions: who initiates and performs the remediation, and who bears the consequence when a security component requires attention after go-live? As long as these questions remain open, approvals and remediation decisions can diverge, even when both parties believe they are acting within their original scope.
When is it crucial to define IAM responsibilities?
The division of IAM responsibilities requires early clarification as soon as the client does not have a standardized central IdP with formal governance. In this situation, internal IAM maturity determines the risk level of the assignment. Without a central foundation, a development partner may in practice begin building custom authorization logic to move the app forward. According to the available guidance, this may later lead to failed ISO 27001 audits. The question is therefore not only whether an app must identify users, but whether the organization has a governance foundation for roles, authorization, and management.
A second situation arises when the app must securely store cryptographic tokens. The available recommendation links this to hardware-backed security through iOS Keychain and Android Keystore, with biometric authentication attestation. In this division, the technical abstraction lies with the software partner, while the client owns the compliance definition according to OWASP MASVS-AUTH. Responsibilities must therefore be defined before technical choices begin functioning as implicit policy decisions.
This point is especially relevant when both parties have a different understanding of what “secure storage” means. The client may need to define the required normative outcome; the partner then translates it into the technical abstraction in the mobile app. Without this separation, the partner may inadvertently determine what level of protection is sufficient, while the client must later explain why that choice was appropriate. Conversely, the client may state a requirement without defining what technical delivery it entails.
These situations show that IAM responsibilities should not be addressed only when accepting a release. They should be discussed as soon as the available central identity, intended authorization governance, or required protection of tokens is uncertain. This keeps visible which decisions remain with the organization and which concrete implementation the development partner takes on.
Key criteria for evaluating IAM responsibilities
Use the criteria below to assess whether the division of tasks covers more than a connection to a central IdP. The table focuses on the verifiable boundary between what the client must establish and what the development partner must demonstrably implement or test. The AAL2/AAL3 reference applies to enterprise applications with elevated risk; it is not a general level for every mobile app.
| Evaluation criterion | Question for the client | Expectation of the development partner | Consequence if the criterion is missing |
|---|---|---|---|
| Meaning of the IdP connection | Has it been established which authorizations the central IdP provides and which controls the app environment itself must support? | Show that the IdP is not used merely as a login widget, but that incoming tokens are checked for permissions and validity at API level. | The organization may assume that integration automatically covers all authorization, while that control is in fact missing. |
| Authentication risk level | Has it been established whether the application carries elevated risk and what authentication level follows from this? | Translate the agreed level into the technical requirements for authenticators and key storage. | An assessment may fail because the chosen authentication does not align with the established risk level. |
| Testable authentication method | Is it clear which methods are permitted within the selected risk class? | Demonstrate that the implemented method meets the agreed requirement. | For AAL2/AAL3 in enterprise applications with elevated risk, the available guideline excludes insecure methods such as SMS OTP. |
| Cryptographic binding | Has it been stated who decides that cryptographically bound authenticators are required? | Demonstrate how the technical implementation supports that binding and hardware-backed key storage. | The division becomes blurred when a security requirement is formulated only as a general preference, without an owner for the decision and implementation. |
| Evidence of API authorization | Has demonstrable permission and validity checking outside the user interface been explicitly requested? | Provide substantiation for the checks performed at API level. | An app that is visually restricted may incorrectly be considered fully authorized. |
Sources for this section: nist.gov
A structured approach to IAM responsibilities
A useful IAM matrix does not merely allocate activities, but links each topic to a formal owner, technical implementer, evidence to be delivered, and production decision-maker. This prevents a policy decision from being interpreted as a technical task, or a technical delivery from being regarded as formal risk acceptance.
- Record the policy boundary contractually. The client owns policy-level architectural decisions: IdP configuration, authorization matrices, and risk acceptance. The development partner owns the technical implementation, including OAuth 2.0 with PKCE and secure token storage. Describe this boundary formally in the agreement, not solely in a backlog or verbal consultation. This ensures that it remains visible that a choice of roles or production acceptance does not automatically shift to the party building the mobile app. In addition to the owner, also record who prepares a decision and what concrete delivery supports it.
- Make vulnerability management a separate matrix row. For vulnerabilities in the software supply chain, the development partner continuously performs dependency scans and generates an SBOM in accordance with NIST SP 800-218. The client then approves the formal risk acceptance and authorization for production deployment. This division distinguishes technical signaling from governance approval. A scan or SBOM is therefore not automatic approval to deploy, while production authorization likewise does not replace the technical obligation to continuously investigate dependencies.
- Link remediation timelines to production authorization. The client's formal approval takes place within agreed remediation timelines. Therefore, include in the same matrix row which remediation timelines apply, who records progress, and what decision follows when a finding is not resolved within that period. This gives the partner a defined implementation responsibility while the client retains the explicit decision on acceptance and deployment. Without this connection, a technical finding may be recorded, but it remains unclear whether it blocks production or falls under risk acceptance.
- Treat evidence as part of the delivery. For both the policy boundary and vulnerability management, evidence belongs to the assigned task: the SBOM and dependency-scan results come from the development partner; the formal approval decision comes from the client. For each matrix row, record where this evidence is stored and to which production deployment it is linked. This makes it possible to trace afterwards which technical information was available and what decision followed from it, without mixing ownership between parties.
Sources for this section: nist.gov
Frequently asked questions about IAM responsibilities
These questions concern two recurring edge cases: where authorization is enforced and the effects of changes to central access policy. Both topics require explicit ownership, because a technically functioning connection offers no guarantee of continued access or effective access restriction.
- “Can the mobile app handle authorization itself by hiding parts of the interface?” No, not as the only measure. A mobile client runs in an untrusted runtime environment. Authorization enforcement must therefore take place on the server side, in the backend or API gateway. Restricting only client-side components based on unvalidated token claims creates direct bypass risks and BOLA vulnerabilities. In the division of responsibilities, this means that the agreement must not end with who makes the role visible in the interface. There must also be an assigned party that implements and substantiates server-side authorization. The client can determine which access is appropriate for each role; the technical implementation must prevent a client from independently bypassing that restriction. This concern is therefore not about a preference for a particular user experience, but about the distinction between presentation in the app and actual access control.
- “Who is responsible if a change in Conditional Access suddenly locks users out?” The change may take place in the central IdP, but this does not automatically guarantee that the mobile app will continue to function. In the described pattern, the client changes the Conditional Access policy, the redirect flow subsequently breaks due to changed authentication parameters, and ownership of compatibility monitoring is absent. This results in both parties referring to the other, while operational field staff cannot log in for hours. Therefore, separately define who assesses changes to central policy, who monitors compatibility of the mobile redirect flow, which signals count as an incident, and who coordinates the initial remediation action. This allocation keeps ownership of central policy with the client without leaving the partner unclear about the app compatibility for which it is responsible.
Important considerations for IAM responsibilities
The final test for an IAM division lies in management after delivery. A matrix is only useful when it also describes what happens if an account is revoked or a role changes later. This is precisely where central identity processes, mobile sessions, and the day-to-day management of permissions come together.
- Assign ownership for session termination. Enterprise session management requires continuous synchronization between the central IdP, where deprovisioning and SCIM events take place, and the mobile app. Therefore, identify who manages events on the identity side, who maintains their processing in the app environment, and who verifies that the chain continues to work. Without explicit API contracts for token revocation and refresh token rotation, revoked accounts may, according to the available guidance, retain unauthorized access for days through active offline tokens. This is a concrete operational risk: an administrative action in the IdP does not then have the intended effect in the mobile app in time.
- Prevent an orphaned RBAC model. Roles and permissions that are hardcoded in the mobile backend under time pressure can become disconnected from central management after delivery. If central management interfaces are absent, permission changes are made manually in databases and without an audit trail. The client then has no regular management point for authorizations, while the development partner may have no ongoing assignment to make these changes. Therefore, include in the division of tasks who manages the authorization model after delivery, how changes are requested, and which party verifies the existence of a management interface and audit trail.
- Link supplier work to demonstrable management. In a supplier relationship, technical delivery is insufficient when the management boundary for sessions and roles remains unclear. The client retains governance responsibility for its own identity and access-rights decisions. The development partner retains a defined responsibility for the agreed processing and manageability in the mobile solution. This boundary makes it possible to assess changes for their impact on revoked accounts and existing roles, rather than only on the original release. Otherwise, manual permission changes without an audit trail remain an operational limitation with direct consequences for auditability.
This article does not provide legal advice. Applicable obligations depend on the purpose, functionality, user context, and risk classification of the system. Have the specific application legally assessed before production use.
