Toegang intrekken bij vertrek, overname of leverancierswissel: het draaiboek per kanaal

Offboarding leeft in de meeste bedrijven op één datum: de laatste werkdag van iemand die vertrekt. Diezelfde klus komt er nog twee keer aan, en die twee keer voert bijna niemand hem uit. Bij een overname verandert er aan niemands account iets, maar wel alles aan wie er nog binnen mag. Bij een leverancierswissel loopt de oude partij door op een beheerrelatie die niemand opzegt.

Dit is het draaiboek voor die drie overgangen. Het is nadrukkelijk geen complete offboardingchecklist, want het moment waarop toegang ophoudt hoort te worden vastgelegd op het moment dat je die toegang uitgeeft, niet op iemands laatste werkdag. Deed je dat destijds niet en ligt er nu een overgang op je bureau, dan loop je hem hieronder na. Per kanaal, in een volgorde die je legitieme koppelingen heel laat.

Een uitgiftekanaal is elke plek waar in jouw bedrijf toegang wordt weggegeven: je identiteitsbeheer, een OAuth-toestemming aan een externe app, een API-token, een gedeelde kluis, een cloudsleutel, of een beheerrelatie met een IT-partner. Elk kanaal heeft een eigen intrekknop, een eigen vertraging en een eigen eigenaar. Een overgang loop je daarom per kanaal af, niet per persoon.

Waarom de handleiding van je leverancier hier ophoudt

Microsoft beschrijft het verwijderen van een oud-medewerker als een oplossing van zeven stappen: inloggen blokkeren, de postbus bewaren, het mobiele apparaat wissen, de mail doorsturen of omzetten naar een gedeelde postbus, iemand anders toegang geven tot OneDrive en Outlook, de licentie weghalen en het account verwijderen. Voor mail en licenties is dat een prima handleiding. Geen van die zeven stappen raakt een OAuth-toestemming, een API-token, een service-account of een gedeeld leveranciersaccount.

Google doet het op zijn eigen offboardingpagina beter. Daar staat wel dat je de OAuth-tokens van externe apps, de app-specifieke wachtwoorden en de geregistreerde beveiligingssleutels moet intrekken, naast het weghalen van het herstel-e-mailadres en het herstelnummer en het resetten van de aanmeldcookie (versie juli 2026). Het verschil zit dus niet in de techniek, maar in welke handleiding je toevallig volgt.

Allebei stoppen ze bij de rand van je eigen omgeving. Een gedelegeerde beheerrelatie met je IT-partner, een toegangssleutel in AWS, een agent die onder de inlog van een medewerker draait: die staan in geen van beide lijsten. Juist daar zit het werk bij een overname of een leverancierswissel.

Drie overgangen, dezelfde kanalen, een andere startplek

De zeven kanalen hieronder zijn bij elke overgang dezelfde. Wat verschilt is wie zijn recht verliest, wie de toegang ooit uitgaf, en waar je dus begint. Start je op de verkeerde plek, dan sloop je iets dat nog draait of laat je maandenlang een deur openstaan.

Medewerker vertrekt. Eén persoon verliest zijn recht om in te loggen. Alles wat hij zelf heeft uitgegeven verliest niets. Begin bij zijn identiteit, want dat is het enige kanaal met een harde deadline, en werk daarna naar buiten toe.

Overname, afsplitsing of een nieuwe eigenaar. Hier draait het niet om intrekken maar om een kring die verschuift, en meestal komt er eerst toegang bíj: due diligence, mensen van de koper die tijdelijk moeten meekijken, een transitieperiode waarin de oude eigenaar nog beheerder is. Die toegang krijgt bijna nooit een einddatum mee, en dat is precies waarom deze overgang zo lang naijlt. Begin bij je gastaccounts en bij de systemen waarvan een privépersoon nog eigenaar is.

Leverancierswissel. Niet één account verliest zijn recht maar een hele organisatie, en de uitgever was die organisatie zelf. Begin bij de beheerrelatie en de gedeelde beheerinlogs, want daar zit een IT-partner in de praktijk. Wat je bij zo'n wissel controleert is niet het certificaat van de leverancier maar de toegang die hij op dit moment nog heeft.

Wat je nodig hebt

Deze klus kost geen nieuw abonnement. Hij kost je de juiste rollen, een half uur voorbereiding, en één beslissing die de meeste bedrijven overslaan: wie mag bepalen dat een koppeling weg mag. Zonder die naam is elke intrekking een gok tussen twee slechte uitkomsten.

Twee vereisten worden structureel onderschat. De eerste is die eigen beheerder. Wie de gedelegeerde beheerrechten van zijn oude IT-partner intrekt zonder zelf een werkende globale beheerder te hebben, sluit zichzelf buiten en mag daarna de supportafdeling van Microsoft gaan bellen. Test die inlog in een privévenster voordat je iets opzegt.

De tweede is de licentie voor activiteitsdata. Zonder Entra ID P1 of P2 zie je niet wanneer een app of een gastaccount voor het laatst is gebruikt, en dan verschuift het meten naar handwerk: de eigenaar bellen. Dat werkt ook. Het duurt alleen langer.

Het draaiboek: zeven kanalen, in deze volgorde

1. Bevries de identiteit, verwijder hem nog niet. In het Entra-beheercentrum ga je naar Users, All users, de gebruiker, Account status, Edit, en haal je het vinkje bij Account enabled weg. Draai je hybride met een lokale Active Directory, doe het dan daar met Disable-ADAccount en reset het wachtwoord twee keer, om pass-the-hash te ondervangen als de replicatie achterloopt. In Google Workspace verander je het wachtwoord en haal je het herstel-e-mailadres en het herstelnummer weg, want anders is de resetknop nog een open route naar binnen.

Verwijderen doe je later. Haal je de licentie weg, dan bewaart Microsoft mail, contacten en agenda nog 30 dagen en daarna zijn ze definitief weg; verwijder je het account, dan heb je 30 dagen om het te herstellen. Er is ook een onderzoeksreden: een verwijderd account is een gat in je logboek op precies het moment dat je wilt kunnen terugkijken. Let op als het account uit een lokale Active Directory komt, want dan kun je het in Microsoft 365 niet verwijderen of herstellen; dat moet on-premises.

2. Trek de sessies in en reken op vertraging. Blokkeren is niet hetzelfde als eruit zetten. Op de overzichtspagina van de gebruiker in Entra staat de knop Revoke sessions. Via PowerShell doe je het blokkeren en het intrekken achter elkaar:

$User = Get-MgUser -Search UserPrincipalName:'jan@voorbeeld.nl' -ConsistencyLevel eventual
Update-MgUser -UserId $User.Id -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $User.Id

Zet daarna zijn geregistreerde apparaten uit met Get-MgUserRegisteredDevice. In Google Workspace reset je de aanmeldcookie via Devices, Sign a user out of a managed Google account. Verwacht geen knop met een direct effect: een access token van Entra ID blijft standaard een uur geldig, automatische deprovisioning naar SaaS-apps draait doorgaans elke 20 tot 40 minuten, en een sessietoken dat een applicatie zélf heeft uitgegeven kan Entra ID helemaal niet intrekken; dat moet die applicatie doen. Wie om 16:59 op vrijdag begint, heeft dus niet om 17:00 iedereen buiten.

3. Loop de OAuth-toestemmingen na, in golven. Dit is het kanaal waar het maandagochtend misgaat. Een goedgekeurde app werkt op eigen tokens, los van het wachtwoord en de tweede factor van de gebruiker, en het intrekken van de toestemming maakt de al afgegeven tokens niet ongeldig. Het klikpad verschilt per platform: in Microsoft 365 loopt het via Entra ID, Enterprise apps, All applications, Permissions, met een tabblad Admin consent en een tabblad User consent; in Google Workspace via Security, Access and data control, API controls, Manage Third-Party App Access.

De volgorde is hier belangrijker dan de knop. Meet eerst per app de laatste activiteit, trek dan in golven van vijf tot tien apps in met een week ertussen, en zet de herconsent dicht voordat je breed doorpakt, anders staat dezelfde app twee weken later gewoon terug.

4. Roteer de gedeelde geheimen; toegang weghalen is niet genoeg. Bij een gedeeld wachtwoord is intrekken een illusie, want hij kent het nog. Wat je hier intrekt is niet de toegang maar het geheim zelf. Loop je kluis langs op alles wat de vertrekkende partij kon zien en verander het: het leveranciersaccount waar drie mensen op inloggen, de wifi-sleutel van kantoor, het beheerderswachtwoord van de firewall, het portaal van je energieleverancier, de sociale kanalen, de code van de alarminstallatie.

Bij een leverancierswissel is dit meestal de langste lijst, want een IT-partner werkt per definitie met gedeelde beheerinlogs. Het probleem eronder is dat een kluis geen einddatum per item kent. De CIS Controls schrijven voor een accountinventaris expliciet de naam van de persoon, de gebruikersnaam en een start- en stopdatum voor, en dat werkt net zo goed op een kluisitem: eigenaar, doel, hercontroledatum.

5. Trek de persoonlijke API-tokens en sleutels in. Dit is het kanaal dat een uitgezet account overleeft. Atlassian schrijft in zijn eigen kennisbank dat het deactiveren of via SCIM ontkoppelen van een gebruiker zijn site- en producttoegang niet automatisch weghaalt, zodat zijn API-tokens blijven werken tot je die toegang expliciet weghaalt of het account opschort. Er zit nog een addertje onder: tokens die een gebruiker zelf in zijn profiel maakte vervallen bij het verwijderen van dat account, maar API-sleutels die vanuit het beheerportaal zijn aangemaakt blijven actief, ook als de beheerder die ze aanmaakte allang weg is.

In AWS vind je ze via het credential report of via aws iam get-access-key-last-used, dat per sleutel de laatste gebruiksdatum, de regio en de laatst aangeroepen dienst teruggeeft; in de console zet je daarvoor de kolom Access key last used aan. Een sleutel die je niet kunt thuisbrengen deactiveer je eerst, en verwijder je pas als er een week niets is omgevallen.

In GitHub verliest een verwijderd organisatielid zijn toegang tot private repository's en tot private forks daarvan, maar lokale kopieën blijven gewoon op zijn laptop staan en GitHub legt de verantwoordelijkheid daarvoor expliciet bij jou. Wat er aan sleutels in die repository's lag is dus meegekopieerd, en de enige echte fix daarvoor is roteren, niet verwijderen.

6. Geef de service-accounts en agents een eigen naam. Hier zit de schade die je pas maanden later ziet. Een nachtelijke export op het token van de vertrokken ontwikkelaar. Een rapportagescript op zijn persoonlijke sleutel. Een AI-agent die is uitgerold onder zijn inlog. Trek je die identiteit in, dan valt de automatisering om; laat je hem staan, dan bestaat de toegang van iemand die weg is. Beide antwoorden zijn fout, omdat bij de uitgifte nooit is vastgelegd wie hier eigenlijk handelt.

De CIS Controls vragen niet voor niets om een aparte inventaris van service-accounts, met per account een eigenaar, een doel en een controledatum, minimaal per kwartaal nagelopen. Praktisch betekent dat: elk proces een eigen identiteit, met een eigen einddatum, en een naam die naar de taak verwijst in plaats van naar een mens.

Dat is ook waar de markt heen beweegt. 1Password bracht op 28 juli 2026 een dienst uit die permanente rechten op cloudinfrastructuur, databases en Kubernetes vervangt door toegang die per taak ontstaat en verdwijnt zodra het werk klaar is, en Cyera tekende diezelfde dag een intentieovereenkomst van ongeveer 1 miljard dollar voor Oasis Security, dat bijhoudt welke service-accounts, sleutels en agents in bedrijfssystemen inloggen. Wil je een handeling van een agent hard aan een mens koppelen, dan kun je sinds 22 juli 2026 een betaling of een configuratiewijziging met een tik op een YubiKey laten aftekenen.

Voor een bedrijf van dertig man is dat gereedschap te zwaar. De goedkope versie levert hetzelfde op: een eigen account per agent met eigen rechten en een einddatum, en daaromheen een logboek, een budgetplafond en een menselijke goedkeuring vooraf.

7. Sluit de kanalen buiten je eigen omgeving. Dit weegt bij een overname en een leverancierswissel het zwaarst, en het staat in geen enkele standaardhandleiding.

De beheerrelatie met je IT-partner staat in Microsoft 365 op de pagina Partner relationships. Daar zie je met welke partners je een relatie hebt en wie gedelegeerde beheerrechten heeft, en beëindig je die door de partner te selecteren en Remove roles te kiezen, waarna de leden van de gekoppelde beveiligingsgroep de diensten niet meer kunnen beheren. Zowel jij als de partner krijgt daarvan een bevestiging per mail.

Gastaccounts zijn de tweede groep. Entra ID heeft een rapport over inactieve gasten dat standaard uitgaat van 90 dagen zonder aanmelding, en met een access review kun je gasten die niet meer inloggen automatisch 30 dagen blokkeren en daarna uit de directory verwijderen. Dat rapport zit achter Entra ID Governance of de Entra Suite. Na een overname of een afgerond project is dit de snelste opruiming die je hebt.

De derde groep zijn de registers waar je bedrijf zelf aan hangt: je domeinnaamregistrar, je DNS-beheerder, je betaalprovider, je app-store-accounts, je certificaten, je telefoniecontract. Staat daar nog een privémailadres of de oude eigenaar als contactpersoon, dan heb je een kanaal dat geen enkel identiteitsbeheer ziet en dat bij een overname stilletjes buiten de deal valt.

Waar dit in de praktijk stukloopt

Alles op één dag intrekken. De verleiding is groot bij een leverancierswissel: contract afgelopen, alles dicht. Maandagochtend blijkt dat de urenkoppeling en de mailarchivering aan dezelfde toestemmingen hingen. Mitigatie: intrekken in golven met een week ertussen, en per golf een uur waarin je bereikbaar bent. Alleen bij een verdenking van misbruik trek je alles tegelijk in, en dan accepteer je de schade bewust.

Het account meteen verwijderen. Dat voelt grondig en kost je drie dingen: de mail en agenda die na 30 dagen definitief weg zijn, het spoor in je logboek, en bij een hybride omgeving de mogelijkheid om het in Microsoft 365 terug te draaien. Mitigatie: blokkeren en sessies intrekken op dag één, verwijderen na 30 tot 60 dagen, met die datum in de agenda.

Jezelf buitensluiten. Wie de gedelegeerde beheerrechten van zijn IT-partner intrekt zonder werkende eigen beheerder, staat buiten zijn eigen tenant. Mitigatie: maak eerst je eigen globale beheerder, log ermee in via een privévenster, zet er een phishing-bestendige tweede factor op, en zeg pas daarna de relatie op. Een gefaseerde overstap van sms-MFA naar passkeys in Entra ID is precies het moment om dat goed te doen.

Denken dat SCIM dit al regelt. SCIM ontkoppelt de gebruiker en laat staan wat die gebruiker heeft uitgegeven; Atlassian documenteert dat letterlijk voor zijn eigen API-tokens. Mitigatie: behandel automatische deprovisioning als kanaal 1 en 2 van de zeven, niet als het geheel.

De tijdelijke toegang die nooit tijdelijk was. Bij een overname of een transitieperiode krijgt de andere partij toegang "voor even". Zes maanden later staat die er nog, want er is geen gebeurtenis die hem weghaalt. Mitigatie: leg de einddatum vast op het moment dat je de toegang geeft, zet hem in dezelfde agenda als de closingdatum, en laat een access review op inactieve gasten de rest doen.

Beslis-kader: één keer opruimen, of het intrekmoment inbouwen

Vier assen bepalen wat hier verstandig is. Hoeveel uitgiftekanalen heb je echt, alleen Microsoft 365 of ook AWS, GitHub en een stapel losse SaaS? Hoe vaak heb je een overgang, twee keer per jaar of twee keer per maand? Wie beheert het straks, jijzelf, een interne beheerder, of de partij die je net wisselde? En wat kost een fout hier, een lastig gesprek of een meldplichtig datalek?

De drempels die ik aanhoud:

• Minder dan drie overgangen per jaar en alles achter één identiteitsbeheer. Doe het met de hand, met dit draaiboek en een vast moment. Automatiseren kost hier meer dan het oplevert.
• Veel mensen, veel apps, het meeste achter single sign-on. Zet automatische deprovisioning aan en laat access reviews de gasten en groepslidmaatschappen opruimen. Dat dekt kanaal 1, 2 en een deel van 7.
• Weinig single sign-on, veel gedeelde inlogs en leveranciersaccounts. Investeer eerst in kluisbeheer met een eigenaar en een hercontroledatum per item. Zonder dat blijft kanaal 4 je grootste gat, en daar helpt geen identiteitsbeheer tegen.
• Engineers en agents op productie-infrastructuur. Dan is permanente toegang de kern van het probleem en niet het opruimen ervan. Toegang die per taak ontstaat en vanzelf vervalt lost hier meer op dan welke checklist ook.

Eerlijk over kant-en-klaar tegenover maatwerk: kant-en-klaar wint voor alles wat in je identiteitsbeheer of je kluis past. Microsoft, Google en 1Password hebben dat beter opgelost dan jij het gaat bouwen, en een licentie is goedkoper dan onderhoud. Maatwerk is alleen op zijn plek bij de kanalen die je zelf hebt gemaakt: de koppeling die je liet bouwen, het script dat op een persoonlijke sleutel draait, de agent die je zelf uitrolde. Daar bestaat geen knop voor, want die identiteit heeft nooit iemand als identiteit ontworpen. Dat werk is klein en eenmalig, en het is het enige stuk dat je niet kunt kopen.

Wat de opties kosten en wat ze niet dekken

De prijzen hieronder zijn de openbare lijstprijzen van 30 juli 2026, per gebruiker per maand bij jaarbetaling.

De rijen sluiten elkaar niet uit. De meeste bedrijven hebben rij 2 al en denken daarmee klaar te zijn, terwijl hun echte gat in rij 4 en rij 6 zit.

Uitgewerkt: een leverancierswissel bij een installatiebedrijf van 45 mensen

Neem een installatiebedrijf met 45 medewerkers dat na zeven jaar van IT-partner wisselt. De oude partij beheerde Microsoft 365, de firewall, de back-up en de telefonie. Het contract loopt af op 30 september; de nieuwe partij begint op 1 oktober. Het bedrijf is een voorbeeld, de menupaden en de volgorde zijn echt.

Twee weken vooraf: inventaris. Op de pagina Partner relationships blijken twee partners te staan: de huidige beheerder met gedelegeerde beheerrechten, en een leverancier van de urenregistratie die al vier jaar niet meer in beeld is. In de gedeelde kluis staan een kleine zestig items, waarvan ongeveer een derde een beheerinlog is die de oude partij kent. Onder Enterprise apps staan achttien toestemmingen, waarvan er vier geen eigenaar hebben. Alles gaat in één spreadsheet met vier kolommen: kanaal, wie het uitgaf, wie het nu nodig heeft, wanneer het weg mag.

Week min één: de eigen beheerder. Er komt een nieuw beheeraccount op de eigen domeinnaam, met een hardwaresleutel als tweede factor, getest in een privévenster. Dit is de stap waar de rest op rust.

30 september, 09:00. De vier toestemmingen zonder eigenaar gaan eruit; de veertien met eigenaar blijven staan. Om 09:30 volgt de allang vergeten tweede partnerrelatie, via Remove roles. De relatie met de vertrekkende partij blijft bewust nog even bestaan, want zij draaien vandaag de overdracht van de firewallconfiguratie.

30 september, 17:00. De partnerrelatie met de oude beheerder gaat eruit. Daarna beginnen de rotaties: firewall, back-upconsole, telefonieportaal, de beheerinlog van de switches, het abonnement bij de leverancier van de installatiesoftware. Elk gewijzigd wachtwoord krijgt in de kluis een eigenaar en een hercontroledatum over twaalf maanden.

1 oktober. De nieuwe partij krijgt een eigen gedelegeerde beheerrelatie, geen gedeeld beheeraccount. De monteursapp bleek te draaien op een API-sleutel die ooit door een medewerker van de oude partij was aangemaakt. Die sleutel wordt vervangen door een nieuwe op naam van een service-account dat het proces heet, niet een persoon.

Half oktober. De access review op inactieve gasten levert elf accounts op van afgeronde projecten, waaronder drie van de oude partij. Ze worden geblokkeerd en dertig dagen later verwijderd. De spreadsheet met vier kolommen verhuist naar een vaste kwartaalafspraak van een half uur.

Doorlooptijd: ongeveer zes uur werk, verspreid over drie weken. Wat het bedrijf overhield is niet de opgeruimde lijst, maar dat er nu per regel een naam en een datum staat.

Het intrekmoment hoort bij de uitgifte

Kijk je naar de zeven kanalen hierboven, dan valt vooral op hoeveel werk het is om iets ongedaan te maken dat in tien seconden werd uitgegeven. Een toestemming klikken kost één scherm. Hem verantwoord intrekken kost een export, een activiteitsmeting, een eigenaar en drie golven.

Die scheefheid is geen pech en geen slordigheid van je beheerder. Ze zit erin omdat het uitgeven van toegang overal een ontworpen moment heeft en het intrekken ervan nergens. De CIS Controls schrijven daarom voor om slapende accounts na 45 dagen inactiviteit uit te zetten of te verwijderen, en dat is precies wat het is: een noodrem voor uitgiftes die nooit een einde meekregen.

Het draaiboek hierboven maakt een overgang beheersbaar. Het maakt hem niet goedkoop. Goedkoop wordt het pas als de volgende koppeling, het volgende token en de volgende agent een einddatum krijgen op de dag dat ze ontstaan. Een ruime datum mag. Een verlengde datum mag. Geen datum, dat is hoe je hier terechtkomt.