Non-human identity (NHI)

Wat is een non-human identity?

Een non-human identity is een login die aan een stuk software toebehoort in plaats van aan een persoon. Het serviceaccount dat je ERP met de webshop verbindt, de API-sleutel in een nachtelijke refresh, het certificaat op een machine in het atelier, het token waarmee een deploymentpipeline aanmeldt, de RPA-bot die facturen in het boekhoudpakket intikt: elk daarvan meldt zich aan, draagt rechten en komt onder eigen naam in een log terecht.

De Cloud Security Alliance trekt de lijn bij wat het ding kan, niet bij hoe het eruitziet. Iets telt als non-human identity zodra het zich kan authenticeren, kan bewijzen wie het is, en rechten kan krijgen op een bron. Hun indeling van juli 2026 splitst dat in service- en integratieaccounts, workload- en microservice-identiteiten, infrastructuuridentiteiten voor virtuele machines en cloudinstanties, apparaatidentiteiten voor sensoren en hardware, en agentidentiteiten voor zelfstandige AI-systemen.

Microsoft deelt dezelfde groep anders in. In Entra zijn workload identities de applicaties, service principals en managed identities, daarnaast staan de apparaatidentiteiten, en samen heten die twee bij Microsoft machine- of non-human identities.

De werkbare test is korter dan beide indelingen. Heeft het een wachtwoord, een sleutel of een certificaat, en is het geen collega, dan is het een non-human identity.

Waarom er veel meer van zijn dan personeelslogins

In een paper van mei 2026 over identiteitsbeheer en AI-agents zet de Cloud Security Alliance het gemiddelde op ongeveer vijfenveertig non-human identities per menselijke gebruiker, en boven de honderd op één in cloud-native omgevingen. De precieze factor doet er minder toe dan de richting. Je hebt er vrijwel zeker een veelvoud van het aantal mensen dat bij je werkt.

Dat komt door de manier waarop ze ontstaan. Een mens komt binnen via HR, tekent iets, krijgt een mailbox en verschijnt op een lijst. Een non-human identity wordt gemaakt door wie de koppeling bouwt, halverwege een project, op het moment dat het nodig is. Ze heeft geen contract, geen leidinggevende en geen startdatum die iemand genoteerd heeft. Elke SaaS-tool die je aanhangt en elke splitsing tussen test en productie levert er weer een op, en geen enkele neemt ooit ontslag.

Waarom ze de zwakste schakel zijn

OWASP publiceerde in 2025 een Non-Human Identities Top 10. Lees je die tien punten samen, dan valt vooral op dat zowat niets waar je voor personeelsaccounts op rekent hier van toepassing is.

• Het geheim is de hele identiteit. Achter een API-sleutel zit geen tweede factor. Wie de tekenreeks heeft, is de identiteit, en daarom staan gelekte geheimen zo hoog in de OWASP-lijst.

• Het geheim verandert nooit. Langlevende geheimen krijgen een eigen plaats in die top tien, met cijfers die tonen dat de meeste cloudsleutels ouder zijn dan een jaar en dat ongeveer de helft van de bedrijven geen enkele vaste procedure heeft om er een in te trekken.

• Eén identiteit doet vijf jobs. Deel je dezelfde login over meerdere diensten, dan reikt één lek meteen tot alles waar dat aanmeldgegeven bij kan. Je verliest er ook de mogelijkheid mee om ze te vervangen, want je weet niet meer wat er dan stilvalt.

• Niemand is eigenaar. OWASP noemt het resultaat improper offboarding: slapende koppelingen waarvan het account actief blijft, en identiteiten die wees worden zodra de persoon die ze aanmaakte vertrekt. Geen enkel uitdiensttredingsproces vangt ze op.

• Mensen melden ermee aan. Een ontwikkelaar die via het serviceaccount zit te debuggen, staat in de log als het serviceaccount. De handeling is echt, de verantwoordelijkheid is weg, en elke beperking op zijn eigen login wordt overgeslagen.

Twee alledaagse situaties tonen wat die vijf punten op een gewone dinsdag betekenen.

Een webshopkoppeling werd gebouwd in 2021. De integratiegebruiker in het ERP kreeg brede rechten zodat het project niet zou stilvallen, het wachtwoord ging in een configuratiebestand, en het project werd afgesloten. Vijf jaar later draait de webshop op een ander platform en staat de oude koppeling uit, maar het account staat nog altijd open met hetzelfde wachtwoord en dezelfde rechten op bestellingen en klanten.

Eén API-sleutel voedt vijf geplande refreshes en een nachtelijke export. Die sleutel belandt in een publieke repository. Uit de logs haal je niet welke van de zes misbruikt is, want alle zes zijn dezelfde identiteit. En je vervangt die sleutel niet op vrijdag zonder maandag te ontdekken welke rapporten gestopt zijn.

Non-human identity versus een menselijk account

Allebei hebben ze andere controles nodig, en het verschil wordt zichtbaar op drie punten.

Tweede factor. Een mens keurt een melding op zijn gsm goed. Een serviceaccount kan dat niet, dus multifactor-authenticatie bestaat er niet voor en het bewaarde geheim is de volledige verdediging. De bescherming moet ergens anders vandaan komen: een aanmeldgegeven dat minuten leeft in plaats van jaren, een regel over waarvandaan de identiteit mag aanmelden, of een platformidentiteit zonder opgeslagen geheim.

In dienst, van functie, uit dienst. Een menselijk account hangt aan een HR-proces. Iemand start, iemand verandert van rol, iemand vertrekt, en de toegang volgt. Non-human identities hebben zo'n aanleiding niet, en daarom zet OWASP het nakijken van de bijhorende identiteiten mee in de uitdiensttredingsprocedure: ga na welke de vertrekker aanmaakte, draag het eigenaarschap over, vervang de aanmeldgegevens.

Vervallen sessies. De sessie van een mens loopt af en die meldt zich opnieuw aan zonder erbij stil te staan. Een machineaanmelding is net gebouwd om zonder toezicht te blijven werken, dus een einde bouw je er bewust in: een token van enkele minuten, een certificaat met een echte vervaldatum, een sleutel met een vervangingsopdracht erachter.

Hoe het er wel hoort uit te zien

1. Eén identiteit per toepassing. Elke koppeling, pipeline en bot krijgt zijn eigen. Dat is wat het mogelijk maakt om een log te lezen, een recht af te nemen of een sleutel te vervangen zonder je adem in te houden.

2. Kortlevende aanmeldgegevens, of geen. Managed identities en workload identity federation bestaan net zodat een pipeline of container zich kan aanmelden zonder sleutel in een configuratiebestand. Heb je toch een sleutel nodig, geef ze dan een vervaldatum.

3. Een eigenaar en een einddatum. De eigenaar is een persoon met een naam, want een team is niemand. De einddatum is het antwoord op een vraag die anders nooit gesteld wordt.

4. Minimale rechten vanaf dag één. Brede rechten die uitgedeeld worden om een project vooruit te helpen, komen nooit terug, want tegen dan weet niemand nog wat ervan afhangt.

5. Een lijst die je kan openen, en vervanging die niemand moet onthouden. Welke identiteiten er zijn, waar elk voor dient, wie de eigenaar is, en wanneer ze laatst gebruikt werd. Een rotatieschema dat van iemands geheugen afhangt, stopt na de tweede keer.

Wat AI-agents daaraan veranderen

Een AI-agent is een non-human identity, dus alles hierboven geldt er al voor. Drie dingen maken hem lastiger dan een serviceaccount.

Ze worden gemaakt door mensen die geen software bouwen. Een collega van de boekhouding zet op een namiddag een agent in elkaar zonder het aan iemand te vragen, langs dezelfde weg waarlangs shadow AI binnenkomt. De identiteit erachter komt wel in je tenant terecht.

Je kan de schade vooraf niet inschatten. De Cloud Security Alliance beschrijft agents die tijdens het draaien rechten verwerven, subagents opstarten, externe API's aanroepen, code schrijven en uitvoeren, en handelingen aan elkaar knopen. Hun conclusie is het stuk om te onthouden: hoe ver een agentaanmelding kan reiken, valt niet vast te stellen op het moment dat je ze uitreikt.

Het eigenaarschap ontbreekt hier vaker dan elders. In datzelfde paper zegt ongeveer de helft van de bedrijven geen duidelijke eigenaar te hebben voor hun AI-identiteiten, en een kleiner deel houdt niet eens bij wanneer er nieuwe bijkomen.

Een agent een eigen login geven is waar het lemma agentidentiteit over gaat, en het gereedschap dat een hele vloot ervan afschermt is de agent control plane. De vraag naar de categorie komt wel eerst. Heeft de integratiegebruiker in je ERP naast die agent evenmin een eigenaar, dan is de agent niet je grootste probleem.

Waar je begint in een KMO

Hier is geen platform voor nodig. Je hebt wel een lijst nodig, en een namiddag.

1. Open de gebruikerslijst van de systemen waar echt geld of echte data in zit. ERP, boekhoudpakket, webshop, bankkoppeling, CRM. Duid elk account aan dat geen mens is. De namen verraden zichzelf: api, integratie, admin2, de naam van een leverancier, de naam van iemand die vertrokken is.

2. Zet er een persoon naast. Een team is geen eigenaar en IT evenmin. Schrijf op wat de identiteit doet, en weet niemand dat, zet ze dan uit op een rustig moment en kijk wie er belt. Dat is goedkoper dan het uit een inbraakrapport te moeten leren.

3. Geef elk een controledatum, en splits wat gedeeld is. Begin bij het aanmeldgegeven waar de meeste systemen van afhangen, want dat is net het aanmeldgegeven dat je vandaag niet durft te vervangen.

4. Vraag elke leverancier of de bewaarde sleutel weg kan. Een verrassend aantal koppelingen ondersteunt intussen een platformidentiteit of een token met vervaldatum, en niemand schakelt over omdat de oude sleutel het nog doet.