IAM-verantwoordelijkheden moeten duidelijk worden verdeeld tussen de opdrachtgever en de ontwikkelpartner. De opdrachtgever blijft verantwoordelijk voor beleidsmatige architectuurbesluiten zoals IdP-configuratie en risicoacceptatie, terwijl de ontwikkelpartner de technische implementatie uitvoert, inclusief veilige tokenopslag en API-integratie. Deze verdeling moet formeel worden vastgelegd om audit-impasses en vertragingen te voorkomen.
IAM-verantwoordelijkheden in mobiele app-ontwikkeling
Het effectief verdelen van IAM-verantwoordelijkheden tussen opdrachtgever en ontwikkelpartner is cruciaal voor het succes van enterprise mobiele apps. Dit artikel biedt inzicht in hoe deze verantwoordelijkheden kunnen worden gestructureerd om technische en compliance-uitdagingen te minimaliseren.
- Definieer beleidsmatige en technische verantwoordelijkheden expliciet en leg deze contractueel vast.
- Zorg voor een duidelijke scheiding tussen client-side en server-side autorisatie om beveiligingsrisico's te minimaliseren.
- Implementeer een formele IAM-matrix om eigenaarschap en verantwoordelijkheden te verduidelijken.
- Beheer kwetsbaarheden proactief met vastgelegde hersteltermijnen en continue monitoring.
- Zorg voor een robuust sessiebeheer en tokenopslag om ongeautoriseerde toegang te voorkomen.
Waarom IAM-verantwoordelijkheden cruciaal zijn in enterprise mobiele apps
Bij een enterprise mobiele app is IAM niet slechts een onderdeel van het inlogscherm. Het bepaalt wie toegang krijgt, onder welke voorwaarden die toegang blijft bestaan en wie kan aantonen dat die keuzes aansluiten op het risicoprofiel van de organisatie. Daardoor wordt IAM vaak een beoordelingspunt vóór een release. Wanneer de verantwoordelijkheid voor beleidskeuzes, bewijsvoering en acceptatie niet vooraf is belegd, kan een project technisch gereed zijn zonder dat de organisatie de mobiele app kan vrijgeven.
De context bepaalt bovendien waar de handhaving hoort te liggen. Bij centraal beheerde B2E-toestellen via MDM kan centrale IdP Conditional Access de voornaamste laag voor toegangscontrole vormen. Bij externe B2B- of BYOD-gebruikers kan de mobiele app juist zelf aanvullende handhaving nodig hebben, bijvoorbeeld met biometrie en binding aan de lokale keystore. Dat verschil raakt niet alleen de gekozen maatregel, maar vooral de vraag wie de uitgangspunten vaststelt, wie de werking beoordeelt en wie wijzigingen accepteert. Een verantwoordelijkheidsoverzicht dat geen onderscheid maakt tussen deze gebruikers- en apparaatcontexten, laat ruimte voor tegenstrijdige verwachtingen.
De noodzaak wordt scherper wanneer de app gereguleerde gegevens verwerkt. Voor medische gegevens onder NEN 7510 of financiële gegevens onder DORA is volgens de beschikbare uitgangspunten strikte, onweerlegbare bewijslast nodig. Ook formele STRIDE threat modeling en een expliciete ondertekening van restrisico horen dan vóór goedkeuring van een mobiele release plaats te vinden. Dat zijn bestuurlijke handelingen: een ontwikkelpartner kan materiaal opleveren, maar kan niet stilzwijgend namens de opdrachtgever bepalen welk overblijvend risico aanvaardbaar is.
Een oningevulde bevoegdheidsvraag wordt zichtbaar bij bevindingen die voortkomen uit beperkingen van mobiele platforms. De interne securityafdeling kan dan weigeren akkoord te gaan, terwijl binnen het projectteam niemand formeel gemachtigd is om een Risk Acceptance Waiver te ondertekenen. Het resultaat is geen zuiver technisch probleem, maar een release-impasse. Heldere IAM-verantwoordelijkheden maken daarom vooraf zichtbaar wie besluiten neemt, wie bewijs verzamelt en wie het resterende risico draagt wanneer volledige mitigatie niet mogelijk is.
De gevolgen van onduidelijke IAM-verantwoordelijkheden
Onduidelijkheid over IAM begint vaak al tijdens de afbakening van een mobiele app. Wanneer IAM dan wordt omschreven als een generieke SSO-inlogfunctie, ontstaat een te beperkte opdracht. De ontwikkelpartner kan een standaard OAuth-flow realiseren, terwijl fijnmazige autorisatie op API-niveau buiten beeld blijft. Het verschil wordt pas zichtbaar wanneer auditors en de CISO vlak voor de lancering bewijs van functiescheiding vragen. Op dat moment ontbreekt niet alleen functionaliteit of documentatie, maar ook een vooraf gedeelde afspraak over wie dit resultaat had moeten specificeren, bouwen en laten toetsen.
De vertraging volgt uit de volgorde waarin het tekort aan het licht komt. Een app kan richting release gaan op basis van de aanname dat een geslaagde inlog voldoende is. Vervolgens blijkt dat de gevraagde onderbouwing voor functiescheiding niet beschikbaar is. Het project moet dan terug naar ontwerp, realisatie en beoordeling, met wekenlange vertraging als mogelijk gevolg. Compliance-artefacten worden hierdoor geen afrondende administratieve stap, maar een late blokkade voor de geplande lancering.
Ook na ingebruikname leidt een ontbrekende rolverdeling tot stilstand. Een securityscanner kan een kritieke kwetsbaarheid aantreffen in een authenticatie-SDK. De opdrachtgever kan vervolgens onmiddellijke patching binnen 48 uur verlangen, terwijl de ontwikkelpartner de opdracht als afgerond beschouwt omdat geen SLA voor kwetsbaarheden is overeengekomen. De technische bevinding is dan duidelijk, maar de herstelverplichting, reactietijd en financiering zijn dat niet. Een discussie over meerkosten vertraagt de oplossing precies op het moment dat de blootstelling actief is.
In het beschreven scenario resulteert die vertraging in acuut compliance-verzuim onder NIS2 en AVG. De kern van het probleem is dus niet dat één partij per definitie alle IAM-taken moet bezitten. Het is dat de opdracht zonder expliciete grenzen geen antwoord biedt op twee operationele vragen: wie start en uitvoert de remedie, en wie draagt de consequentie wanneer een beveiligingscomponent na go-live aandacht vraagt? Zolang die vragen openstaan, kunnen goedkeuringen en herstelbesluiten uiteenlopen, ook wanneer beide partijen menen binnen hun oorspronkelijke scope te handelen.
Wanneer is het cruciaal om IAM-verantwoordelijkheden te definiëren?
De verdeling van IAM-verantwoordelijkheden vraagt vroegtijdige explicitering zodra de opdrachtgever geen gestandaardiseerde centrale IdP met formele governance heeft. De interne IAM-volwassenheid bepaalt in deze situatie het risiconiveau van de opdracht. Zonder centrale basis kan een ontwikkelpartner in de praktijk maatwerkautorisatielogica gaan bouwen om de app vooruit te helpen. Volgens de beschikbare aanwijzing kan dat later leiden tot falende ISO 27001-audits. De vraag is daarom niet alleen of een app gebruikers moet herkennen, maar of de organisatie een bestuurlijk uitgangspunt heeft voor rollen, autorisatie en beheer.
Een tweede situatie ontstaat wanneer de app cryptografische tokens veilig moet opslaan. De beschikbare aanbeveling koppelt dit aan hardware-backed beveiliging via iOS Keychain en Android Keystore, met biometrische authenticatieattestatie. In die verdeling ligt de technische abstractie bij de softwarepartner, terwijl de opdrachtgever de compliancedefinitie volgens OWASP MASVS-AUTH bezit. De verantwoordelijkheden moeten dus worden gedefinieerd voordat technische keuzes als impliciete beleidsbesluiten gaan functioneren.
Dat moment is vooral relevant wanneer beide partijen een ander beeld hebben van wat ‘veilig opslaan’ inhoudt. De opdrachtgever kan de gewenste normatieve uitkomst moeten vastleggen; de partner vertaalt die vervolgens naar de technische abstractie in de mobiele app. Zonder die scheiding kan de partner onbedoeld bepalen welke mate van bescherming voldoende is, terwijl de opdrachtgever later moet verklaren waarom die keuze passend was. Andersom kan de opdrachtgever een eis noemen zonder vast te leggen welke technische oplevering daarbij hoort.
Deze situaties laten zien dat IAM-verantwoordelijkheden niet pas bij acceptatie van een release aan bod komen. Zij horen op tafel zodra de beschikbare centrale identiteit, de beoogde autorisatiegovernance of de vereiste bescherming van tokens onzeker is. Dan blijft zichtbaar welke besluiten bij de organisatie blijven en welke concrete realisatie de ontwikkelpartner op zich neemt.
Belangrijkste criteria voor het evalueren van IAM-verantwoordelijkheden
Gebruik onderstaande criteria om te beoordelen of de taakverdeling meer omvat dan een koppeling met een centrale IdP. De tabel richt zich op de controleerbare grens tussen wat de opdrachtgever moet vastleggen en wat de ontwikkelpartner aantoonbaar moet realiseren of toetsen. De AAL2/AAL3-verwijzing geldt hierbij voor enterprise-applicaties met verhoogd risico; het is geen algemeen niveau voor iedere mobiele app.
| Evaluatiecriterium | Vraag voor de opdrachtgever | Verwachting richting ontwikkelpartner | Gevolg als het criterium ontbreekt |
|---|---|---|---|
| Betekenis van de IdP-koppeling | Is vastgelegd welke autorisaties de centrale IdP levert en welke controle de appomgeving zelf moet ondersteunen? | Maak zichtbaar dat de IdP niet alleen als inlogwidget wordt gebruikt, maar dat inkomende tokens op permissies en geldigheid op API-niveau worden gecontroleerd. | De organisatie kan aannemen dat koppeling automatisch alle autorisatie afdekt, terwijl die controle feitelijk ontbreekt. |
| Risiconiveau van authenticatie | Is vastgesteld of de applicatie een verhoogd risico heeft en welk authenticatieniveau daaruit volgt? | Vertaal het overeengekomen niveau naar de technische eisen voor authenticators en sleutelopslag. | Een beoordeling kan stranden omdat de gekozen authenticatie niet bij het vastgestelde risiconiveau aansluit. |
| Toetsbare authenticatiemethode | Is duidelijk welke methoden binnen de gekozen risicoklasse zijn toegestaan? | Onderbouw dat de gerealiseerde methode past bij de overeengekomen eis. | Voor AAL2/AAL3 bij enterprise-applicaties met verhoogd risico sluit de beschikbare richtlijn onveilige methoden zoals SMS-OTP uit. |
| Cryptografische binding | Is benoemd wie beslist dat cryptografisch gebonden authenticators vereist zijn? | Toon aan hoe de technische realisatie die binding en hardwarematige sleutelopslag ondersteunt. | De verdeling vervaagt wanneer een beveiligingseis alleen als algemene wens is geformuleerd, zonder eigenaar voor besluit en realisatie. |
| Bewijs van API-autorisatie | Is expliciet gevraagd om aantoonbaarheid van permissie- en geldigheidscontrole buiten de gebruikersinterface? | Lever de onderbouwing voor de uitgevoerde controles op API-niveau. | Een visueel afgeschermde app kan ten onrechte als volledig geautoriseerd worden beschouwd. |
Bronnen bij deze sectie: nist.gov
Een gestructureerde aanpak voor IAM-verantwoordelijkheden
Een bruikbare IAM-matrix verdeelt niet alleen activiteiten, maar koppelt elk onderwerp aan een formele eigenaar, technische uitvoerder, op te leveren bewijs en beslisser voor productie. Daarmee voorkomt u dat een beleidsbesluit als technische taak wordt gelezen, of dat een technische oplevering wordt aangezien voor formele risicoacceptatie.
- Leg de beleidsgrens contractueel vast. De opdrachtgever bezit de beleidsmatige architectuurbesluiten: IdP-configuratie, autorisatiematrices en risicoacceptatie. De ontwikkelpartner bezit de technische implementatie, waaronder OAuth 2.0 met PKCE en veilige tokenopslag. Beschrijf deze grens formeel in de overeenkomst, niet uitsluitend in een backlog of mondeling overleg. Hierdoor blijft zichtbaar dat een keuze voor rollen of een productieacceptatie niet automatisch verschuift naar de partij die de mobiele app bouwt. Leg naast de eigenaar ook vast wie een besluit voorbereidt en welke concrete oplevering het besluit ondersteunt.
- Maak kwetsbaarhedenbeheer tot een eigen matrixregel. Voor kwetsbaarheden in de softwareleveringsketen voert de ontwikkelpartner continu dependency-scans uit en genereert deze een SBOM conform NIST SP 800-218. De opdrachtgever fiatteert vervolgens de formele risicoacceptatie en de autorisatie voor productie-uitrol. Deze verdeling onderscheidt technische signalering van bestuurlijke toestemming. Een scan of SBOM is daarmee geen automatisch akkoord om uit te rollen, terwijl productieautorisatie evenmin de technische verplichting vervangt om afhankelijkheden doorlopend te onderzoeken.
- Koppel hersteltermijnen aan de productieautorisatie. De formele fiattering door de opdrachtgever vindt plaats binnen overeengekomen hersteltermijnen. Neem daarom in dezelfde matrixregel op welke hersteltermijnen gelden, wie de voortgang vastlegt en welk besluit volgt wanneer een bevinding niet binnen die termijn is opgelost. Zo krijgt de partner een afgebakende uitvoeringsverantwoordelijkheid en houdt de opdrachtgever het expliciete besluit over aanvaarding en uitrol. Zonder deze verbinding kan een technische bevinding wel worden geregistreerd, maar blijft onduidelijk of deze productie blokkeert of onder risicoacceptatie valt.
- Behandel bewijs als onderdeel van de oplevering. Bij zowel de beleidsgrens als kwetsbaarhedenbeheer hoort bewijs bij de toegewezen taak: de SBOM en resultaten van dependency-scans komen van de ontwikkelpartner; het formele fiatteringsbesluit komt van de opdrachtgever. Neem per matrixregel op waar dit bewijs wordt bewaard en aan welke productie-uitrol het is gekoppeld. Daardoor is achteraf te herleiden welke technische informatie beschikbaar was en welk besluit daarop volgde, zonder eigenaarschap tussen partijen te vermengen.
Bronnen bij deze sectie: nist.gov
Veelgestelde vragen over IAM-verantwoordelijkheden
Deze vragen gaan over twee terugkerende grensgevallen: de plaats waar autorisatie wordt afgedwongen en de gevolgen van wijzigingen in centraal toegangsbeleid. Beide onderwerpen vragen om expliciet eigenaarschap, omdat een technisch werkende koppeling geen garantie biedt voor blijvende toegang of effectieve toegangsbeperking.
- “Kan de mobiele app autorisatie zelf afhandelen door onderdelen van de interface te verbergen?” Nee, niet als enige maatregel. Een mobiele client draait in een onbetrouwbare runtime-omgeving. Daarom moet autorisatiehandhaving plaatsvinden aan de serverzijde, in de backend of API-gateway. Alleen client-side onderdelen afschermen op basis van niet-gevalideerde token-claims creëert directe omzeilingsrisico’s en BOLA-kwetsbaarheden. In de verantwoordelijkheidsverdeling betekent dit dat de afspraak niet mag eindigen bij wie de rol in de interface zichtbaar maakt. Er moet ook een toegewezen partij zijn die de server-side autorisatie realiseert en onderbouwt. De opdrachtgever kan daarbij bepalen welke toegang bij welke rol past; de technische uitvoering moet voorkomen dat een client die beperking zelfstandig kan omzeilen. Dit bezwaar gaat dus niet over een voorkeur voor een bepaalde gebruikerservaring, maar over het onderscheid tussen presentatie in de app en daadwerkelijke toegangscontrole.
- “Wie is verantwoordelijk als een wijziging in Conditional Access gebruikers plotseling buitensluit?” De wijziging kan in de centrale IdP plaatsvinden, maar daarmee is de werking van de mobiele app niet automatisch gewaarborgd. In het beschreven patroon verandert de opdrachtgever het Conditional Access-beleid, breekt vervolgens de redirect-flow door gewijzigde authenticatieparameters en ontbreekt eigenaarschap voor compatibiliteitsmonitoring. Dan ontstaat wederzijdse verwijzing naar de andere partij, terwijl operationele buitendienstmedewerkers urenlang niet kunnen inloggen. Leg daarom afzonderlijk vast wie wijzigingen in het centrale beleid beoordeelt, wie de compatibiliteit van de mobiele redirect-flow bewaakt, welke signalen als storing gelden en wie de eerste herstelactie coördineert. Die toewijzing laat eigendom van het centrale beleid bij de opdrachtgever, zonder de partner onduidelijkheid te laten over de appcompatibiliteit waarvoor deze verantwoordelijk is.
Belangrijke overwegingen voor IAM-verantwoordelijkheden
De laatste toets voor een IAM-verdeling ligt in het beheer ná oplevering. Een matrix is pas bruikbaar wanneer zij ook beschrijft wat er gebeurt als een account wordt ingetrokken of een rol later verandert. Juist daar komen centrale identiteitsprocessen, mobiele sessies en het dagelijks beheer van rechten bij elkaar.
- Leg eigenaarschap voor sessiebeëindiging vast. Enterprise sessiebeheer vereist continue synchronisatie tussen de centrale IdP, waar de-provisioning en SCIM-events plaatsvinden, en de mobiele app. Benoem daarom wie de gebeurtenissen aan de identiteitskant beheert, wie de verwerking in de appomgeving onderhoudt en wie controleert dat de keten blijft werken. Zonder expliciete API-contracten voor token revocation en refresh token rotatie kunnen ingetrokken accounts volgens de beschikbare aanwijzing dagenlang ongeautoriseerde toegang behouden via actieve offline tokens. Dat is een concreet operationeel risico: een beheerdershandeling in de IdP heeft dan niet tijdig het beoogde effect in de mobiele app.
- Voorkom een verweesd RBAC-model. Rollen en rechten die onder tijdsdruk hardcoded in de mobiele backend worden vastgelegd, kunnen na oplevering losraken van centraal beheer. Als centrale beheerinterfaces ontbreken, verlopen rechtenmutaties handmatig in databases en zonder audittrail. De opdrachtgever heeft dan geen normaal beheerpunt voor autorisaties, terwijl de ontwikkelpartner mogelijk geen doorlopende opdracht heeft om deze mutaties uit te voeren. Neem daarom in de taakverdeling op wie het autorisatiemodel na oplevering beheert, hoe wijzigingen worden aangevraagd en welke partij de aanwezigheid van een beheerinterface en audittrail verifieert.
- Verbind leverancierswerk aan aantoonbaar beheer. In een leveranciersrelatie is de technische oplevering onvoldoende wanneer de beheergrens voor sessies en rollen onduidelijk blijft. De opdrachtgever houdt de bestuurlijke verantwoordelijkheid voor de eigen identiteits- en rechtenbesluiten. De ontwikkelpartner houdt een afgebakende verantwoordelijkheid voor de overeengekomen verwerking en beheerbaarheid in de mobiele oplossing. Die grens maakt het mogelijk om wijzigingen te beoordelen op hun effect op ingetrokken accounts en bestaande rollen, in plaats van alleen op de oorspronkelijke release. Handmatige rechtenmutaties zonder audittrail blijven anders een operationele beperking met directe gevolgen voor controleerbaarheid.
Dit artikel biedt geen juridisch advies. De toepasselijke verplichtingen hangen af van het doel, de functionaliteit, de gebruikerscontext en de risicoclassificatie van het systeem. Laat de concrete toepassing juridisch beoordelen vóór productiegebruik.
