Managed Identities vs App Registrations in Azure: belangrijkste verschillen en best practices

By Mirko Peters · 2026-04-28

Automatically translated with AI from the original post. Read the English original

Als je tegenwoordig iets serieus bouwt of beveiligt in Azure, is begrijpen hoe managed identities en app-registraties werken geen optie meer. Het is het absolute minimum. Beide spelen een grote rol in identity- en toegangsbeheer voor je apps, automatiseringen en services. Maar als je door elkaar haalt welk model waar past, krijg je onnodige hoofdpijn, beveiligingslekken of veel te veel werk met geheimen.

Deze gids legt uit wat managed identities en app-registraties zijn, hoe ze aansluiten op Entra ID (voorheen Azure AD) en waarom het kiezen van de juiste aanpak belangrijk is voor je beveiliging en dagelijkse beheer. Je krijgt heldere definities, praktijkscenario's, migratietips om afscheid te nemen van geheimen, en concrete tips voor probleemoplossing en governance. Het doel: een strakkere, veiligere en efficiëntere Microsoft-cloud draaien, zeker nu aanvallen toenemen en best practices voor Entra ID zich ontwikkelen.

Managed identities en app-registraties begrijpen

Laten we beginnen met duidelijk krijgen wat managed identities en app-registraties in Azure en Entra ID precies doen. Beide zijn manieren waarop niet-menselijke actoren, zoals apps, scripts of automatiseringen, zichzelf kunnen authenticeren en toegang krijgen tot resources in de Microsoft-cloud. Hoe ze dat doen, en welke dagelijkse problemen ze oplossen (of veroorzaken), verschilt echter behoorlijk.

Managed identities zijn het antwoord van Azure op authenticatie zonder geheimen. In plaats van met app-wachtwoorden en certificaten te werken, kun je een Azure-resource (denk aan een virtuele machine, App Service of Logic App) een eigen identiteit in Entra ID geven. Azure beheert deze identiteit automatisch: die wordt aangemaakt zodra je resource er is, verdwijnt als je de resource verwijdert en, belangrijkst, je krijgt nooit te maken met geheimen die worden rondgestuurd. Er zijn twee soorten managed identities: system-assigned (één per resource, strikt afgeschermd) en user-assigned (herbruikbaar over meerdere resources).

App-registraties zijn de klassieke aanpak. Als je een app registreert in Entra ID, maak je een applicatieobject aan en krijg je een client-ID, eventueel met geheimen of certificaten voor authenticatie. Als je app moet inloggen bij Microsoft-diensten, toegang nodig heeft tot de Graph API, of buiten Azure werkt (of voor meer dan één resource), gebruik je waarschijnlijk een app-registratie. Maar dan ben jij verantwoordelijk voor het beheer van de geheimen, de beveiliging en de levenscyclus, en dat brengt compromissen met zich mee.

Welke aanpak je kiest, is niet alleen een technische beslissing. Het is een berekening van beveiligingsrisico's: geheimen zijn aantrekkelijke doelwitten voor aanvallers, terwijl managed identities zonder geheimen hele categorieën kwetsbaarheden uitsluiten. Wil je een idee krijgen waarom dit zo belangrijk is, bekijk dan deze diepgaande analyse over misbruik van OAuth-toestemming in Entra ID. Aanvallers weten hoe ze zich kunnen nestelen in omgevingen die de basis niet op orde hebben, dus goed omgaan met identiteit is stap één.

Kernverschillen: levenscyclus, beveiliging en Azure-integratie

Hier komt theorie samen met de praktijk. Managed identities en app-registraties geven beide apps of scripts hun digitale ‘naamlabel’ waarmee ze toegang krijgen tot resources. Maar hoe je dat label krijgt, onderhoudt en opruimt, verschilt flink.

Managed identities zijn zo dicht mogelijk bij ‘instellen en vergeten’ als het in de cloud kan. Maak een Azure-resource aan, vraag een managed identity aan, en klaar. Azure maakt de identiteit voor je aan, koppelt die aan Entra ID en houdt de achterliggende synchronisatie op orde. Verwijder je de resource, dan verdwijnt de identiteit ook. Er is nul beheer van geheimen, geen wachtwoordrotaties, en beveiligingsteams slapen er beter van.

App-registraties vragen veel meer werk. Je maakt de app-registratie handmatig aan in Entra ID, houdt de client-ID bij en genereert geheimen of certificaten voor authenticatie. Na verloop van tijd verlopen die geheimen (of kunnen ze uitlekken), en jij moet controleren welke apps ze gebruiken. Geheimen roteren, verlopende inloggegevens bijhouden en verweesde registraties opruimen is op zichzelf al een taak. Daarom vragen beveiligingsteams altijd naar automatisering van de levenscyclus.

Wat beveiliging betreft is het verschil duidelijk: managed identities gebruiken authenticatie zonder geheimen, gekoppeld aan Azure-resources, terwijl app-registraties leunen op statische geheimen of certificaten. Daarom geeft men de voorkeur aan managed identities waar geheimen een risico vormen of waar automatisering centraal staat.

Deze verschillen in levenscyclus en beveiliging hebben grote gevolgen voor automatisering, compliance en het strak houden van cloudomgevingen. Wil je zien hoe governancebeleid en controles meespelen bij identity sprawl en security drift? Bekijk dan deze gids over Azure-governancestrategie. Het is een must-read voor iedereen die verantwoordelijk is voor grote, groeiende Azure-omgevingen.

Service-principals, RBAC-rollen en Microsoft Graph-machtigingen

Laten we nu even achter het gordijn kijken. Onder de motorkap maken zowel managed identities als app-registraties gebruik van service-principals in Entra ID. Zie een service-principal als de echte, werkende identiteit die Entra ID kent. Of die nu afkomstig is van een managed identity of van een app-registratie: dit object krijgt machtigingen en toegang binnen je tenant.

Bij app-registraties maakt Entra, zodra je een nieuwe app toevoegt, voor elke tenant waaraan je hem toewijst een bijbehorende service-principal aan. Dit is de identiteit die je gebruikt om Azure RBAC-rollen toe te kennen, zoals Contributor of Reader, en om Graph API-machtigingen te verlenen, zowel gedelegeerde als op applicatieniveau.

Managed identities zijn iets anders, maar gebouwd op dezelfde basis. Wanneer je een managed identity voor een Azure-resource inschakelt, maakt Entra een speciale service-principal aan die meegaat met de levensduur van de resource. Daarna ken je RBAC-rollen (zoals Key Vault Reader) rechtstreeks aan deze identiteit toe. De resource krijgt op de achtergrond tokentoegang, zonder codewijzigingen en zonder geheimen die rondslingeren.

Machtigingen verlenen is waar het op het echte werk aankomt. Beide modellen gebruiken Azure RBAC voor toegang op resourceniveau, maar de manier waarop je Graph-machtigingen verleent verschilt. Met app-registraties keur je Graph API-toegang goed via expliciete toestemming of goedkeuring door een beheerder. Managed identities kunnen applicatiemachtigingen voor Graph krijgen zonder interactieve aanmelding, wat ze ideaal maakt voor automatisering die gebruikersgegevens ophaalt, beveiliging controleert of workflows start.

Toegang toekennen en de compliance van deze identiteiten bewaken is echter niet bepaald "instellen en vergeten". Strakke RBAC-roltoewijzing, regelmatige audits en tools zoals Microsoft Defender for Cloud helpen je om bij te houden wie wat doet, verkeerde configuraties op te sporen en drift tot een minimum te beperken. Wil je dieper ingaan op identity governance? Lees dan deze gids over Azure enterprise governance of deze uitleg over compliancebewaking in Microsoft Defender for Cloud voor praktische tips over continue beveiliging.

De juiste keuze maken: scenario's, migratie en governance

Al deze achtergrond is belangrijk, maar de meeste teams willen vooral weten: wanneer gebruik je managed identities en wanneer app-registraties? En hoe migreer of beheer je deze identiteiten, zodat het bij opschaling niet misgaat?

Managed identities komen het best tot hun recht bij workloads die rechtstreeks in Azure draaien en alleen toegang binnen dezelfde tenant nodig hebben. Denk aan vm's die scripts uitvoeren, App Services die met Key Vault praten of Logic Apps die de Microsoft Graph bevragen. De beveiliging is beter, de installatie gaat sneller en er is minder geheimenbeheer nodig. Draai je echter SaaS, multi-tenantoplossingen of hybride opstellingen (zoals on-premises apps die cloud-API's aanspreken), dan blijven app-registraties de standaardkeuze vanwege hun flexibiliteit en bredere compatibiliteit.

Migreren van app-registraties naar managed identities is een actueel onderwerp. Het proces begint met een beoordeling van de gereedheid: welke workloads kunnen daadwerkelijk overstappen en welke afhankelijkheden of beperkingen zijn er? Voor applicaties die al op app-registraties zijn gebouwd, is het verstandig de overstap gefaseerd door te voeren, grondig te testen en terugvalplannen klaar te hebben om downtime of verrassingen bij authenticatie te voorkomen.

Hybride en multi-cloud omgevingen vragen om een beetje creativiteit. Soms moet je beide modellen tegelijk gebruiken, een aanpak die hybride identiteit heet. De kunst is om geheimen tot een minimum te beperken, machtigingen te beperken en goed vast te leggen welke identiteit wat doet. En ja, regelmatige audits zijn een must om verouderde of verweesde identiteiten op te sporen, want die vormen verborgen risico's.

Sterke governancebeleidsregels brengen de hele strategie samen. Met Azure Policy, Privileged Identity Management en routinematige compliancecontroles zorg je ervoor dat je minimale rechten afdwingt, afwijkingen opvangt en aansluit op zero trust. Voor een realistische blik op serviceaccounts versus echte workload-identiteiten (en waarom oude benaderingen tekortschieten) kun je deze analyse over risico's van niet-menselijke identiteiten en Microsoft Entra Workload Identities lezen. Wil je een overzicht van alle governance-essentials? De bron over de governancestrategie voor ondernemingen staat vol met best practices.