Skip to main content

BCKN

Identity Dark Matter

Table of Contents

Een nieuw buzzword - Identity Dark Matter

Orchid Security publiceerde vorige week hun Identity Gap: 2026 Snapshot. Het rapport geeft een volledig overzicht over de status van Identity Security. Het belicht de meest voorkomende en hardnekkigste control gaps, account exposure, risk behaviors en meer.

The Invisible Elements of Identity Now Overshadow The Visible Ones

Een paar belangrijke cijfers

57% van de enterprise-applicaties gebruiken geen centrale, beveiligde identity provider (IdP). De meerderheid van deze applicaties regelen hun toegang buiten het zicht van een IAM stack. Twee derde van de non-human identities authentificeren en autoriseren zich locaal, binnen de applicatie, zonder directory, IdP, of centraal overzicht. 40% van alle accounts zijn orphan accounts en hebben geen owner binnen het bedrijf. En als laatste cijfer; Eén op drie enterprise-applicaties slaan credentials op in plain text.

Deze gaps bestaan uiteraard al langer en het rapport geeft dit ook weer. Het vooruitzicht van de groei van AI agents tegen eind 2026 maakt dit pas echt een probleem. De blinde vlek binnen je IAM stack is net diegene dat de efficiency-driven agents gaan gebruiken zodat de snelste route gekozen kan worden.

Ondanks de snelheid van de agentic adoption hebben minder dan 1 in vijf bedrijven een volwassen governance model in plaats voor AI agents.

Identity Dark Matter

Identity dark matter. Het klinkt als het nieuwste buzzword, al is de achterliggende gedachte heel concreet.

Je IAM-platform, je IdP, je IGA-tool, je PAM-oplossing; je IAM stack gaat ervan uit dat alle nieuwe identiteiten door een governance workflow worden aangemaakt. Je komt in dienst, je account wordt aangemaakt, je lifecycle binnen het bedrijf gaat van start. Dit proces is bij de meeste bedrijven ondertussen goed ingericht. Waar het begint te wringen is bij service accounts en die accounts mag je in de breedste vorm van het woord zien. Traditionele Windows service accounts maar ook API keys, oAuth clients, certificates, machine identities, bots, CI/CD identities. Een betere term is dan ook Non-human Identities.

Hier bestaat in de meeste bedrijven geen governance model voor. Er is geen structuur. Geen eigenaar, geen lifecycle, geen review of recertifications,…

Orchid’s data toont dat 67% van alle Non-human identities op die manier wordt aangemaakt, volledig buiten je IAM stack om. Zoals eerder aangegeven beheren 57% van de enterprise-applicaties hun eigen authenticatie, zonder centrale IdP. Op zich hoeft dit geen probleem te zijn zolang de identiteiten wel centraal beheerd worden in een IGA-tool en de nodige security controls voor handen zijn tijdens authenticatie. Denk aan MFA of Passwordless authentication.

Is dit niet het geval en worden identiteiten aangemaakt buiten het zicht en de controle van je IAM stack dan spreken we van Identity Dark Matter.

Hoe zijn we hier beland?

Een IAM-project wordt te vaak als een technisch project aangevat. Hierdoor vergeet men alle processen te bekijken die onder de IAM-invloedsfeer vallen. De eerste stap die genomen wordt is het JML-proces (Joiner, Mover, Leaver) van human identities en daar stopt het vaak.

De focus ligt op human identities. Een nieuwe medewerker heeft een account en toegangen nodig. Een huidige medewerker heeft een nieuwe rol en dus nieuwe toegangen nodig. Een medewerker verlaat het bedrijf dus de toegangen moeten weggenomen worden. Wat er met de non-human identities gebeurt, wordt niet bekeken.

Hierdoor komen de volgende twee bevindingen dan ook tot stand. Zoals het rapport aangeeft zijn 40% van de accounts actief nadat de eigenaar of het bijhorende proces weg is. Bij deze orphaned accounts komt ook nog dat 30% van alle applicaties in productie credentials hard-coded én in plain text in de code of configuratie bewaren.

40% of all accounts were found to be orphaned.

Voeg hier ook nog de privilege creep bij, waarbij in meer dan 70% van de geanalyseerde applicaties het aantal geprivilegieerde accounts groter is dan operationeel nodig, dan krijg je een gevaarlijke cocktail. Toegang wordt zelden ingetrokken. Least privilege is meestal wel van toepassing maar zelden een operationele realiteit.

Waarom AI-agents dit gevaarlijk maken

Identity Dark Matter is als term misschien nieuw maar de problemen die het verduidelijkt zijn dat zeker niet. Die bestonden al langer, buiten het zicht van je IAM stack. Deze problemen werden toegestaan door policy exceptions, het bestaan van legacy applicaties en er werd uiteindelijk, vaak stilzwijgend, geaccepteerd dat de centrale IAM stack niet alles onder controle had. Wat tot nu toe een behapbaar en beheersbaar iets was wordt door AI-agents een acuut probleem.

Een AI-agent is ontworpen om taken te voltooien. Als hij de juiste toegang niet heeft, zoekt hij naar wat er wel beschikbaar is. Hardcoded credentials in een config-file? Die werken. Een orphaned service account met brede rechten die al vijf jaar niemand heeft gereviewd? Die werkt ook. Een over-geprivilegieerd integratieaccount dat ooit voor iets anders werd aangemaakt? Prima.

En dit gaat niet traag. AI-agents doen het op machine-snelheid, over meerdere systemen tegelijk, zonder menselijke review.

The gap between deployment speed and identity readiness is where breaches happen.

Het probleem schaalt nu mee met je AI-adoptie. Elke nieuwe agent die je deployt vergroot je aanvalsoppervlak.

Waar je realistisch begint

Waar er een nieuw buzzword is om problemen aan te duiden, is er vaak ook één om het probleem aan te pakken: Identity Visibility and Intelligence Platforms (IVIP). Wie heeft toegang tot wat? Traditionele identity models hebben het moeilijk om hierop te antwoorden. IVIP kan deze antwoorden wel tevoorschijn toveren. Het zorgt voor vertrouwen in een toekomst waar identity behavior dynamischer, gedistribueerder en geautomatiseerder is dan voorheen.

Als we eerst het governance model helemaal op punt willen hebben, dan lopen we achter de feiten aan.

De eerste stap is visibility. Welke non-human identities bestaan er in mijn omgeving? Waar zijn ze aangemaakt? Tot welke systemen hebben ze toegang? Zijn er hard-coded credentials in applicaties die momenteel in productie draaien?

Een gerichte discovery-oefening die een werkelijk beeld geeft van je Identity Surface en niet het ideaalbeeld dat je IAM-dashboard je toont.

Eens je dit volledig beeld hebt, kun je prioriteren: welke accounts zijn het meest risicovol? Welke hebben brede toegang en geen eigenaar? Welke credentials kunnen worden geroteerd?

Governance volgt op visibility. Niet andersom.