Every breach ends with someone using a right they should not have had. Four ways access rights go wrong, each with an example from practice, and the control that often helps most. Elke inbraak eindigt met iemand die een recht gebruikt dat hij niet had mogen hebben. Vier manieren waarop toegangsrechten misgaan, elk met een voorbeeld uit de praktijk, en de maatregel die vaak het meest helpt.
Most identities in a company are not people. Service accounts run the backups and the payroll, API keys connect systems, scripts log in on a schedule, and AI agents now join them. They were created by someone who has since left, their passwords never expire because expiring would break the job, and their rights were set generously once so nobody would be called at night. Nobody is paid to look at them, and they outnumber the staff. Microsoft now gives agents their own identity type (Entra Agent ID), so they can have an owner too.
Example: a service account called svc_payroll, created in 2016, password unchanged since, member of Domain Admins because the payroll software “needed it” for one installation step years ago. The password sits in a script on a shared drive. Whoever reads that script controls the company. Business impact: the account nobody owns is the account nobody notices being abused, and the first thing an attacker looks for.
De meeste identiteiten in een bedrijf zijn geen mensen. Serviceaccounts draaien de back-ups en de salarisrun, API-sleutels verbinden systemen, scripts loggen volgens schema in, en nu komen daar AI-agents bij. Ze zijn aangemaakt door iemand die inmiddels weg is, hun wachtwoorden verlopen nooit omdat verlopen de taak zou breken, en hun rechten zijn ooit ruim gezet zodat niemand ’s nachts gebeld zou worden. Niemand wordt betaald om ernaar te kijken, en het zijn er meer dan er medewerkers zijn. Microsoft geeft agents nu een eigen identiteitstype (Entra Agent ID), zodat ook zij een eigenaar kunnen krijgen.
Voorbeeld: een serviceaccount met de naam svc_payroll, aangemaakt in 2016, wachtwoord sindsdien ongewijzigd, lid van Domain Admins omdat de salarissoftware dat jaren geleden “nodig had” voor één installatiestap. Het wachtwoord staat in een script op een gedeelde schijf. Wie dat script leest, heeft het bedrijf in handen. Bedrijfsimpact: het account zonder eigenaar is het account waarvan niemand het misbruik opmerkt, en het eerste waar een aanvaller naar zoekt.
AI-powered code and file scanning finds hardcoded passwords, forgotten API keys and old service-account secrets across shared drives and repositories in minutes, work that used to take a determined attacker days of manual searching.AI-gestuurd scannen van code en bestanden vindt hardgecodeerde wachtwoorden, vergeten API-sleutels en oude serviceaccountgeheimen op gedeelde schijven en in repositories binnen minuten, werk dat een vastberaden aanvaller vroeger dagen handmatig zoeken kostte.
AI coding assistants often suggest or reuse hardcoded credentials from examples they were trained on, and automation pipelines built around an AI agent's own API key create one more non-human identity nobody is watching.AI-codeerassistenten stellen vaak hardgecodeerde inloggegevens voor uit voorbeelden waarop ze getraind zijn, en automatiseringspijplijnen rond de eigen API-sleutel van een AI-agent leveren weer een niet-menselijke identiteit op waar niemand naar omkijkt.
AI-driven identity and secret-scanning tools can list every hardcoded credential, dormant service account and unused API key across the estate in one pass, but someone still has to assign an owner and put it in a vault.AI-gestuurde identiteits- en secret-scanningtools kunnen elk hardgecodeerd wachtwoord, slapend serviceaccount en ongebruikte API-sleutel in één keer in kaart brengen, maar iemand moet nog steeds een eigenaar aanwijzen en het in een kluis zetten.
Cloud platforms and business systems come with a fine-grained rights model. Nobody uses it under time pressure. A role gets a wildcard because the precise list was long, and the role is copied to the next team because it “works”. Years later every developer can read every database, the helpdesk can reset the CEO’s password, and nobody remembers deciding any of it.
Example: an AWS IAM policy with "Action": "*", "Resource": "*" attached to the whole developer group; in Entra ID, Global Administrator handed to the service desk for password resets, where Helpdesk Administrator or Authentication Administrator would do. Business impact: one phished developer laptop equals the entire data estate. With narrow roles the same laptop equals one application.
Cloudplatforms en bedrijfssystemen hebben een fijnmazig rechtenmodel. Onder tijdsdruk gebruikt niemand het. Een rol krijgt een wildcard omdat de precieze lijst lang was, en de rol wordt gekopieerd naar het volgende team omdat hij “werkt”. Jaren later kan elke developer elke database lezen, kan de servicedesk het wachtwoord van de CEO resetten, en herinnert niemand zich dat ooit te hebben besloten.
Voorbeeld: een AWS IAM-policy met "Action": "*", "Resource": "*" gekoppeld aan de hele developergroep; in Entra ID de rol Global Administrator uitgedeeld aan de servicedesk voor wachtwoordresets, terwijl Helpdesk Administrator of Authentication Administrator volstaat. Bedrijfsimpact: één gephishte developerlaptop staat gelijk aan al uw data. Met smalle rollen staat dezelfde laptop gelijk aan één applicatie.
Once an attacker lands on any account, automated cloud-permission mapping tools instantly reveal every wildcard role and every database it reaches, turning one phished laptop into a map of the entire estate within minutes.Zodra een aanvaller op een willekeurig account landt, onthullen geautomatiseerde tools voor cloudrechten direct elke wildcard-rol en elke database die daarmee te bereiken is, waardoor één gephishte laptop binnen minuten een kaart van de hele omgeving oplevert.
AI coding assistants routinely suggest a broad wildcard policy as the quick working example, and a developer under deadline pressure accepts it, quietly adding one more overly wide role to the estate.AI-codeerassistenten stellen standaard een ruime wildcard-policy voor als het snelle werkende voorbeeld, en een developer onder tijdsdruk neemt dat over, waardoor er stilletjes weer een te ruime rol bijkomt.
AI can compare what a role actually uses against what it is allowed to do and propose a narrower policy automatically, but a person still has to approve the change before the wildcard is removed.AI kan vergelijken wat een rol daadwerkelijk gebruikt met wat hij mag doen en automatisch een smallere policy voorstellen, maar iemand moet de wijziging nog steeds goedkeuren voordat de wildcard verdwijnt.
Some rights are harmless alone and dangerous together. Creating a supplier is fine. Releasing a payment is fine. The same account doing both means one person, or one attacker holding that account, can invent a vendor and pay it. Every system allows this unless someone deliberately configures it to say no, and most systems were never asked.
Example: a finance employee moves teams and keeps the “vendor master” role from the old job while gaining “payment release” in the new one. Eighteen months later a phished password is used to create a supplier with a familiar name and a foreign IBAN, and to approve an invoice of €340,000. Both actions are logged, both look legitimate. Business impact: direct financial loss, plus an audit finding that the conflict had been visible in the rights table all along.
Sommige rechten zijn apart onschuldig en samen gevaarlijk. Een leverancier aanmaken is prima. Een betaling vrijgeven is prima. Hetzelfde account dat beide doet, betekent dat één persoon, of één aanvaller met dat account, een leverancier kan verzinnen en betalen. Elk systeem staat dit toe tenzij iemand het bewust instelt om nee te zeggen, en de meeste systemen is dat nooit gevraagd.
Voorbeeld: een medewerker van finance wisselt van team en houdt de rol “leveranciersstamgegevens” uit de oude functie, terwijl hij in de nieuwe “betaling vrijgeven” krijgt. Achttien maanden later wordt met een gephisht wachtwoord een leverancier met een vertrouwde naam en een buitenlands IBAN aangemaakt, en een factuur van € 340.000 goedgekeurd. Beide handelingen staan in het logboek, beide zien er legitiem uit. Bedrijfsimpact: direct financieel verlies, plus een auditbevinding dat het conflict al die tijd zichtbaar was in de rechtentabel.
AI does not create the segregation-of-duties gap itself; whoever holds the combined create-vendor and release-payment rights can already invent and pay a fake vendor by hand, exactly as before AI existed.AI creëert het functiescheidingsprobleem niet zelf; wie de gecombineerde rechten leverancier-aanmaken en betaling-vrijgeven al heeft, kon een nepleverancier al met de hand verzinnen en betalen, precies zoals vóór AI.
Once one account can both create a vendor and release payment, AI can write a convincing invoice, a plausible vendor name and matching bank details in minutes, turning a rights gap into finished fraud almost instantly.Zodra één account zowel een leverancier kan aanmaken als een betaling kan vrijgeven, schrijft AI in enkele minuten een overtuigende factuur, een geloofwaardige leveranciersnaam en bijpassende bankgegevens, en verandert een rechtenprobleem bijna meteen in afgeronde fraude.
AI scanning ERP transaction logs can flag the same user creating a vendor and releasing a payment far faster than a periodic manual audit would, but the SoD matrix still has to say that combination is forbidden.AI die ERP-transactielogs doorzoekt, kan sneller dan een periodieke handmatige audit signaleren dat dezelfde gebruiker een leverancier aanmaakt én een betaling vrijgeeft, maar de functiescheidingsmatrix moet nog steeds vastleggen dat die combinatie verboden is.
A team of four uses one administrator account. The password lives in a spreadsheet, a chat thread and a sticky note. When someone leaves, it is not changed, because everyone else would need the new one. When something breaks, or disappears, the log says “admin” did it. Nobody did it. And the intern from last summer can still log in.
Example: a shared admin@ account for the Microsoft 365 tenant, used by IT, an external consultant and a former intern. Multi-factor authentication is switched on, but the code goes to a shared phone in a drawer. When every mailbox is exported to an unknown address at 02:00, the investigation ends at the word “admin”. Business impact: no accountability, no forensic trail, no way to revoke one person, and an insurer asking why the basic rule was not followed.
Een team van vier gebruikt één beheerdersaccount. Het wachtwoord staat in een spreadsheet, een chatgesprek en op een geeltje. Als iemand vertrekt, wordt het niet gewijzigd, want dan moet iedereen het nieuwe hebben. Als er iets stukgaat, of verdwijnt, zegt het logboek dat “admin” het heeft gedaan. Niemand heeft het gedaan. En de stagiair van afgelopen zomer kan nog steeds inloggen.
Voorbeeld: een gedeeld admin@-account voor de Microsoft 365-tenant, gebruikt door IT, een externe consultant en een oud-stagiair. Multifactorauthenticatie staat aan, maar de code komt binnen op een gedeelde telefoon in een la. Als om 02:00 elke mailbox naar een onbekend adres wordt geëxporteerd, eindigt het onderzoek bij het woord “admin”. Bedrijfsimpact: geen verantwoording, geen forensisch spoor, geen manier om één persoon de toegang te ontnemen, en een verzekeraar die vraagt waarom de basisregel niet is gevolgd.
Whoever holds the shared password can use AI to write messages in a plausible house style from admin@, so nothing about the wording gives away that someone new is now behind the account.Wie het gedeelde wachtwoord heeft, kan AI gebruiken om berichten in een geloofwaardige huisstijl vanaf admin@ te schrijven, zodat niets aan de tekst verraadt dat er nu iemand anders achter het account zit.
Because nobody owns the account, there is no personal baseline of normal behaviour to compare against, so an AI-assisted impersonator calling the shared phone for the MFA code has an easier, less suspicious target.Omdat niemand eigenaar is van het account, is er geen persoonlijke gedragsbasislijn om mee te vergelijken, waardoor een met AI ondersteunde oplichter die naar de gedeelde telefoon belt voor de MFA-code een makkelijker, minder verdacht doelwit heeft.
User-behaviour analytics can flag an unusual action inside a shared account, such as an odd hour or a new pattern, even without knowing who is behind it, but named accounts with PAM remain the stronger control.Gedragsanalyse kan een ongebruikelijke handeling binnen een gedeeld account signaleren, zoals een vreemd tijdstip of een nieuw patroon, ook zonder te weten wie erachter zit, maar persoonlijke accounts met PAM blijven de sterkere maatregel.
| Control | Fixes | In one line |
|---|---|---|
| Identity inventory | Orphans (01) | Every account, human or not, listed with a named owner who is asked yearly whether it should still exist. We suggest switching off anything without an owner. |
| Secrets vault | Orphans (01) | Passwords and keys for service accounts live in a vault and rotate automatically. Where the platform allows, workload identity federation removes the key altogether. Nothing in scripts or spreadsheets. |
| Least-privilege roles | Wildcards (02) | Roles built from what the job actually does, no wildcards, and every widening reviewed by a second person. CIEM or policy checks on IaC can flag wildcards before they go live. |
| SoD matrix | Two hats (03) | A written list of right combinations no single account may hold, enforced by the ERP itself, with finance signing off on any exception. |
| Named accounts + PAM | Shared (04) | Only personal accounts. With PAM, administrator rights are checked out for a task and time, with sessions recorded and the shared admin@ account retired. |
| Access certification | All four | Business owners, not IT, confirm quarterly who may reach their data and their processes. Consider removing anything not confirmed. |
| Joiner-mover-leaver | 01 · 03 · 04 | HR events drive access automatically: a move removes the old role before adding the new one; a leaver is gone the same day, service accounts included. |
| Privilege alerts | 02 · 04 | Any new administrator, any widened role, any new wildcard raises an alert to someone who checks it against a ticket. |
| Maatregel | Lost op | In één zin |
|---|---|---|
| Identiteitenregister | Wezen (01) | Elk account, mens of niet, staat op een lijst met een eigenaar die jaarlijks wordt gevraagd of het nog moet bestaan. Wij raden aan alles zonder eigenaar uit te zetten. |
| Secrets vault | Wezen (01) | Wachtwoorden en sleutels van serviceaccounts staan in een kluis en roteren automatisch. Waar het platform het toelaat, maakt workload identity federation de sleutel overbodig. Niets in scripts of spreadsheets. |
| Least-privilege-rollen | Wildcards (02) | Rollen opgebouwd uit wat de functie echt doet, zonder wildcards, en elke verruiming beoordeeld door een tweede persoon. CIEM of policycontroles op IaC kunnen wildcards signaleren vóór ze live gaan. |
| Functiescheidingsmatrix | Twee petten (03) | Een vastgelegde lijst van rechtencombinaties die geen enkel account mag hebben, afgedwongen door het ERP zelf, met finance die elke uitzondering tekent. |
| Persoonlijke accounts + PAM | Gedeeld (04) | Alleen persoonlijke accounts. Met PAM worden beheerdersrechten per taak en tijd uitgecheckt, sessies opgenomen en wordt het gedeelde admin@-account opgeheven. |
| Toegangscertificering | Alle vier | Proceseigenaren, niet IT, bevestigen elk kwartaal wie bij hun data en processen mag. Overweeg te verwijderen wat niet bevestigd wordt. |
| Joiner-mover-leaver | 01 · 03 · 04 | HR-gebeurtenissen sturen de toegang automatisch: bij een overstap verdwijnt de oude rol vóór de nieuwe erbij komt; een vertrekker is dezelfde dag weg, serviceaccounts inbegrepen. |
| Rechtenalarm | 02 · 04 | Elke nieuwe beheerder, elke verruimde rol, elke nieuwe wildcard stuurt een melding naar iemand die het naast een ticket legt. |
Rights accumulate by default. Any organisation older than a few years has orphaned accounts, wide roles and at least one shared login.Rechten stapelen zich vanzelf op. Elke organisatie van meer dan een paar jaar oud heeft verweesde accounts, ruime rollen en minstens één gedeelde inlog.
From payment fraud to full compromise, because rights decide what a stolen account can do. Plus audit findings that were avoidable.Van betaalfraude tot volledige overname, omdat rechten bepalen wat een gestolen account kan. Plus auditbevindingen die te vermijden waren.
Accounts will still be stolen. Least privilege and segregation limit what the thief gains to one application or one half of a transaction.Accounts worden nog steeds gestolen. Least privilege en functiescheiding beperken de buit tot één applicatie of één helft van een transactie.
CIO and CFO: IT runs the tooling. The business owns who needs what, and finance owns segregation of duties in the systems that move money.CIO en CFO: IT beheert de tooling. De business is eigenaar van wie wat nodig heeft, en finance van de functiescheiding in de systemen die geld verplaatsen.
number of non-human identities without a named owner · % of privileged roles containing a wildcard · open segregation-of-duties conflicts in the ERP · days since the last completed access certification.aantal niet-menselijke identiteiten zonder eigenaar · % bevoorrechte rollen met een wildcard · openstaande functiescheidingsconflicten in het ERP · dagen sinds de laatste afgeronde toegangscertificering.
“Excessive, orphaned or shared access rights allow a single compromised or dishonest account to reach data and move money far beyond its job.”“Overmatige, verweesde of gedeelde toegangsrechten stellen één gecompromitteerd of oneerlijk account in staat data te bereiken en geld te verplaatsen ver buiten zijn functie.”
| Framework | What it requires of you | When a supplier hands you their report | When this incident happens |
|---|---|---|---|
| NIS2 | NIS2 requires access control policies (Art. 21(2)(i)) and MFA where appropriate (Art. 21(2)(j)). Management approves the measures and is accountable for them (Art. 20). | Ask how the supplier’s staff reach your environment: named accounts, MFA, and revocation when their people leave. A shared vendor login is your finding too. | Misuse of a privileged account can count as a significant incident if it meets the thresholds: early warning within 24 hours of becoming aware, incident notification within 72 hours, final report within one month. The first question will be who owned that account. |
| DORA | DORA requires financial entities to limit access to what approved functions need and to use strong authentication (Art. 9(4)(c)–(d)). The register of ICT third parties lists what each provider may reach. | A report rarely shows which of the provider’s engineers hold rights in your tenant. Ask for the list, and put access limits and revocation in the contract DORA requires. | Fraud or data loss through excessive rights can be a major ICT-related incident: initial notification within 4 hours of classifying it as major (at most 24 hours after becoming aware), intermediate report within 72 hours of the initial notification, final report within one month. |
| SOC 2 | Logical access (criteria CC6) is the largest set: provisioning, removal, privileged access and periodic reviews are all tested over the period, and service accounts are in scope. | Look for exceptions on access reviews and terminations; they are the most common ones. Then read the complementary user entity controls: you administer your own users in their platform. | An access review that should have caught the account becomes a noted exception or a qualified opinion, and customers will ask for evidence of the review and the remediation. |
| ISAE 3402 | Where an outsourced process touches financial reporting, the auditor tests who could change the numbers: segregation of duties and privileged access at the service organisation. | Check whether segregation of duties and access control objectives are in scope and whether the exceptions concern them. The report says nothing about wildcard roles in the cloud. | ISAE 3402 creates no duty to notify user auditors. Expect a deviation in the next report, and ask for interim disclosure in the contract. Payment fraud can also reach your own financial statement audit. |
| Kader | Wat het van u vraagt | Als een leverancier u zijn rapport geeft | Als dit incident u treft |
|---|---|---|---|
| NIS2 | NIS2 vereist beleid voor toegangsbeheer (art. 21(2)(i)) en waar passend MFA (art. 21(2)(j)). Het bestuur keurt de maatregelen goed en is ervoor verantwoordelijk (art. 20). | Vraag hoe de medewerkers van de leverancier uw omgeving bereiken: persoonlijke accounts, MFA, en intrekking als hun mensen vertrekken. Een gedeelde inlog van de leverancier komt ook op uw conto. | Misbruik van een bevoorrecht account kan gelden als significant incident als het de drempels haalt: vroegtijdige waarschuwing binnen 24 uur na kennisname, incidentmelding binnen 72 uur, eindrapport binnen een maand. De eerste vraag zal zijn wie eigenaar van dat account was. |
| DORA | DORA vereist dat financiële entiteiten toegang beperken tot wat goedgekeurde functies nodig hebben en sterke authenticatie gebruiken (art. 9(4)(c)–(d)). Het register van ICT-derden vermeldt wat elke leverancier mag bereiken. | Een rapport laat zelden zien welke engineers van de leverancier rechten in uw tenant hebben. Vraag de lijst op, en leg toegangsgrenzen en intrekking vast in het contract dat DORA vereist. | Fraude of dataverlies door overmatige rechten kan een ernstig ICT-gerelateerd incident zijn: eerste melding binnen 4 uur na classificatie als ernstig (uiterlijk 24 uur na kennisname), tussenrapport binnen 72 uur na de eerste melding, eindrapport binnen een maand. |
| SOC 2 | Logische toegang (criteria CC6) is de grootste set: toekennen, intrekken, bevoorrechte toegang en periodieke reviews worden over de periode getest, en serviceaccounts vallen binnen de scope. | Let op afwijkingen bij toegangsreviews en uitdiensttredingen; dat zijn de meest voorkomende. Lees daarna de complementary user entity controls: u beheert zelf uw gebruikers in hun platform. | Een toegangsreview die het account had moeten vangen, wordt een genoteerde afwijking of een oordeel met beperking, en klanten vragen om bewijs van de review en het herstel. |
| ISAE 3402 | Waar een uitbesteed proces de financiële verslaggeving raakt, toetst de auditor wie de cijfers zou kunnen wijzigen: functiescheiding en bevoorrechte toegang bij de serviceorganisatie. | Controleer of functiescheiding en toegangsbeheer als beheersdoelstellingen in scope zijn en of de afwijkingen daarover gaan. Het rapport zegt niets over wildcard-rollen in de cloud. | ISAE 3402 schept geen meldplicht richting de auditors van gebruikers. Verwacht een afwijking in het volgende rapport, en leg tussentijdse melding vast in het contract. Betaalfraude kan ook uw eigen jaarrekeningcontrole raken. |
Checked against: NIS2 Directive (EU) 2022/2555 Art. 20, 21, 23; DORA Regulation (EU) 2022/2554 Art. 9, 19; AICPA Trust Services Criteria CC6; Microsoft Learn on Entra Agent ID (Apr 2026), workload identity federation and built-in roles (Aug 2026) · September 2026.
Gecontroleerd tegen: NIS2-richtlijn (EU) 2022/2555 art. 20, 21, 23; DORA-verordening (EU) 2022/2554 art. 9, 19; AICPA Trust Services Criteria CC6; Microsoft Learn over Entra Agent ID (apr 2026), workload identity federation en ingebouwde rollen (aug 2026) · september 2026.