De medewerker is weg, zijn koppelingen draaien door

Zet het account van een vertrokken collega uit in je identiteitsbeheer, en je hebt precies één ding ingetrokken: zijn vermogen om zelf in te loggen. Alles wat hij in de jaren daarvoor namens jouw bedrijf heeft uitgegeven, draait door. De koppeling tussen de webshop en de nieuwsbrieftool die hij ooit aanzette. Het API-token dat hij maakte zodat een rapportage zichzelf vulde. Het gedeelde leveranciersaccount waarvan drie mensen het wachtwoord kennen en niemand de eigenaar is.

Dat is geen slordigheid van je systeembeheerder. Zo zijn die systemen gebouwd.

Mijn stelling is daarom niet "vergeet niet in te trekken". Die zin staat al in elke offboardingchecklist en verandert al jaren niets. Mijn stelling is dit: wie toegang uitgeeft, is ook eigenaar van het moment waarop die toegang weer weggaat. Dat moment is een ontwerpkeuze op de dag van uitgifte, geen nazorgtaak op iemands laatste werkdag.

De schakelaar die je omzet, knipt één draad door

Het intrekmoment is het punt waarop verleende toegang echt ophoudt te werken. Bij een gebruikersaccount valt dat samen met de laatste werkdag. Bij alles wat die gebruiker zélf heeft uitgegeven, ligt het ergens anders: bij een apart token, bij een aparte toestemming, of bij niemand. Een offboarding die alleen het account uitzet, raakt dus maar één van die momenten.

Dat is geen theoretisch onderscheid. Atlassian schrijft in zijn eigen kennisbank dat de API-tokens van een gedeactiveerde of via SCIM ontkoppelde gebruiker gewoon bruikbaar blijven zolang dat account nog toegang tot de site heeft, en dat de REST-aanroepen dus blijven slagen. Deactiveren is niet verwijderen. Dat verschil kost je precies de toegang waarvan je dacht dat hij weg was.

Bij OAuth-koppelingen is het nog een slag scherper. Wie in Microsoft 365 en Google Workspace app-toestemmingen intrekt, maakt de al afgegeven tokens daarmee niet ongeldig: die blijven werken tot ze verlopen. De knop die je indrukt regelt de toekomst, niet het heden.

En de aanname eronder, dat er één schakelaar is die alles raakt, klopt sowieso niet voor je hele applicatielandschap. Uit het jaaronderzoek van 1Password onder ruim 5.000 kenniswerkers blijkt dat maar ongeveer twee derde van de zakelijke applicaties achter single sign-on staat, en dat zeven op de tien securityprofessionals SSO alleen niet als volledige oplossing zien. De rest hangt aan losse inlogs, losse tokens en losse toestemmingen, elk met een eigen intrekmoment.

De uitgever is bijna nooit je IT-afdeling

Hier valt de checklist om. Een checklist gaat ervan uit dat er één partij is die toegang verleent en dus ook kan wegnemen. In de praktijk gaf de marketeer de nieuwsbrieftool toegang tot je contacten, koppelde de ontwikkelaar een token aan je facturatie en deelde de administratie één leveranciersaccount met z'n drieën. Uit datzelfde onderzoek van 1Password komt dat ruim de helft van de medewerkers weleens een app installeert zonder goedkeuring van IT. Die mensen gaven toegang uit. Ze wisten alleen niet dat ze daarmee ook een intrekmoment aan het uitgeven waren.

Het gevolg zie je pas bij het opruimen. De moeilijkste voorwaarde om app-toestemmingen op te schonen is geen beheerdersrol en geen PowerShell-module, maar per koppeling één naam die weet of hij nog nodig is. Zonder die naam is elke intrekking een gok tussen twee slechte uitkomsten: je laat iets staan dat weg moest, of je sloopt op maandagochtend een koppeling die vrijdag nog werkte.

Ontbrekend eigenaarschap kost je ook je zicht als het misgaat. Een IT-contractor uit Ohio werd na zijn ontslag in mei 2021 niet buitengesloten door zijn eigen account, want hij deed zich voor als een andere contractor om inloggegevens te bemachtigen. Hij draaide een script dat ongeveer 2.500 wachtwoorden resette en duizenden collega's buitensloot, en de rechter legde hem 862.516,74 dollar aan schadevergoeding en 24 maanden cel op, zo maakte het Amerikaanse openbaar ministerie in mei 2026 bekend. Het detail dat mij bijblijft: het onderzoek richtte zich eerst op het account waarmee hij zich vermomde. Een account zonder duidelijke eigenaar is niet alleen een open deur, het is ook een verkeerde naam in je logboek.

Datzelfde patroon groeit nu mee met AI. Een agent erft doorgaans de rechten van de medewerker die hem uitrolde, en dan kun je de toegang van die agent niet intrekken zonder de medewerker zelf te raken. Vertrekt de medewerker, dan staat je automatisering op een identiteit die niet meer bestaat, of blijft die identiteit bestaan omdat de automatisering hem nodig heeft. Beide antwoorden zijn fout, en dat komt doordat niemand bij de uitgifte heeft vastgelegd wie hier eigenlijk handelt.

De schade zit in de staart, niet op de laatste werkdag

Offboarding wordt behandeld als een gebeurtenis van één dag, terwijl het risico zich juist ontvouwt in de maanden erna. Uit het onderzoek van 1Password komt dat ruim een derde van de werknemers, 38 procent, na vertrek nog succesvol bij een account, data of applicatie van een vorige werkgever binnenkwam. Dat is geen groep hackers. Dat zijn mensen die ontdekten dat hun oude inlog het nog deed.

De cijfers over de niet-menselijke kant zijn somberder. Sophos ondervroeg begin 2026 vijfduizend IT- en securityverantwoordelijken bij bedrijven van 100 tot 5.000 medewerkers en vond dat 71 procent in een jaar minstens één identiteitsgerelateerd incident had. Zwak beheer van niet-menselijke identiteiten werd genoemd bij 41 procent van die incidenten, en slechts een op de drie organisaties rouleert of controleert serviceaccounts en niet-menselijke identiteiten regelmatig, tegen 11 procent die dat doorlopend doet. Een token dat niemand controleert, verloopt niet uit zichzelf. Het wacht.

Hoe lang die staart is, laat het datalek bij wachtwoordmanager LastPass zien: aanvallers kwamen daar binnen via leverancier Klue, met een vergeten inloggegeven uit 2022 van een inmiddels stopgezet integratieproject. Aan die kant stond geen boze ex-medewerker. Er stond een inloggegeven dat zijn eigen aanleiding jarenlang overleefde, omdat het project een startmoment had en geen eindmoment.

Om eerlijk te zijn: een eigenarenlijst rot sneller dan de toegang

De sterkste tegenwerping komt van mensen die dit vak echt doen, en die luidt ongeveer zo. Eigenaarschap per koppeling klinkt netjes, maar het is een register, en registers verouderen. De eigenaar verandert van rol, verlaat het bedrijf of weet na acht maanden niet meer waar die koppeling voor was. Ondertussen bestaat er allang een gestandaardiseerd antwoord, joiner-mover-leaver met SCIM-provisioning, en een klein bedrijf van dertig man kan geen programma voor identiteitsbeheer dragen. Een checklist die daadwerkelijk elke maand wordt afgelopen is dan meer waard dan een eigenaarsmodel dat op papier bestaat.

Dat argument klopt, en het is precies de reden waarom ik mijn punt zo scherp stel. Eigenarenlijsten rotten omdat ze los worden bijgehouden van de handeling waar ze over gaan. Iemand geeft toegang uit op dinsdag en iemand anders schrijft dat ergens op, of niet. De oplossing is dus geen betere lijst, maar het intrekmoment verplaatsen naar binnen de uitgifte zelf: een einddatum die meekomt met het recht, niet een taak die erachteraan komt.

En de tweede helft van de tegenwerping, dat SCIM dit oplost, botst op wat Atlassian hierboven zelf documenteert. SCIM ontkoppelt de gebruiker en laat zijn tokens staan. De standaard dekt de identiteit, niet alles wat die identiteit ooit heeft uitgedeeld.

Toegang die zichzelf intrekt

Dat inzicht is geen niche-mening meer, het is de richting waarin de markt beweegt. 1Password bracht op 28 juli een dienst uit die permanente rechten op cloudinfrastructuur, databases en Kubernetes vervangt door toegang die per taak ontstaat en automatisch verdwijnt zodra het werk klaar is. Wat daar gebeurt, is niet dat het intrekken beter wordt georganiseerd. Het intrekmoment wordt onderdeel van het verlenen, waardoor de vraag of iets nog ingetrokken moet worden vervalt.

Een bedrijf van dertig man koopt daar geen platform voor, en dat hoeft ook niet. De goedkope versie van hetzelfde idee is een regel in plaats van een programma: geen koppeling, token of gedeeld account zonder een naam en een einddatum, ingevuld op het moment dat je het aanmaakt. Een einddatum mag ruim zijn. Hij mag verlengd worden. Hij mag er alleen niet ontbreken, want een recht zonder einddatum is een recht dat je nooit meer bewust weegt. Diezelfde beweging zie je terug in de wending van jaarlijkse leverancierscontroles naar een actuele lijst van wie op dit moment toegang heeft tot je systemen.

Dat is ook het eerlijke antwoord op de vraag waarom deze fout blijft terugkomen. Offboarding is ontworpen voor een wereld waarin mensen de enige sleutelhouders waren. In die wereld was de laatste werkdag een echt intrekmoment, want de sleutel lag op het bureau. Nu hangen de sleutels aan tokens, koppelingen en agents die iemand ooit in tien seconden heeft uitgegeven, meestal met de beste bedoelingen en zonder één gedachte aan het einde ervan.

Het moment waarop toegang stopt, wordt vastgelegd op het moment dat toegang begint. Doe je het daar niet, dan bestaat dat moment niet. Dan is er alleen een laatste werkdag, en de stille aanname dat het daarmee wel geregeld zal zijn.