Every protocol solves a different authentication problem. OAuth2 delegates access. SAML federates enterprise identity. OIDC adds login on top of OAuth2. mTLS binds machine trust to certificates. Passkeys make login phishing-proof. Kerberos, NTLM, LDAP and RADIUS keep the legacy estate running, and API keys fill the gaps. For each: its strength, its weakness, and how easily AI helps break it, abuse it or enforce it. AI agents now hold credentials too. Elk protocol lost een ander authenticatieprobleem op. OAuth2 delegeert toegang. SAML federeert bedrijfsidentiteit. OIDC voegt inloggen toe bovenop OAuth2. mTLS bindt machinevertrouwen aan certificaten. Passkeys maken inloggen phishingbestendig. Kerberos, NTLM, LDAP en RADIUS houden de oude omgeving draaiend, en API-sleutels vullen de gaten. Per protocol: de sterkte, de zwakte, en hoe makkelijk AI helpt het te breken, te misbruiken of af te dwingen. AI-agents hebben nu ook inloggegevens.
You use an app that wants to read your files from a cloud service. The app does not ask for your password; it sends you to the cloud service's login page. You log in with your own credentials. The cloud service asks: "Do you want to allow this app to read your files?" You click yes. The app receives an access token: permission to fetch your files on your behalf. The app never sees your password. The cloud service never trusts the app directly, only your consent.
Use when: An application needs to access resources on behalf of the user, but the user should control what data the app can access, and the app should never handle the user's password.
U gebruikt een app die uw bestanden bij een clouddienst wil lezen. De app vraagt niet om uw wachtwoord, maar stuurt u door naar de inlogpagina van de clouddienst. U meldt zich aan met uw eigen gegevens. De clouddienst vraagt: "Wilt u deze app toestaan uw bestanden te lezen?" U klikt op ja. De app krijgt een toegangstoken: toestemming om uw bestanden namens u op te halen. De app ziet uw wachtwoord nooit. De clouddienst vertrouwt de app niet rechtstreeks, alleen uw toestemming.
Gebruik wanneer: Een applicatie namens de gebruiker bij gegevens moet kunnen, de gebruiker zelf bepaalt wat de app mag zien, en de app het wachtwoord nooit mag verwerken.
The app gets a scoped, expiring token instead of your password. Revoke the token and the app is out, without a password reset.De app krijgt een beperkt, verlopend token in plaats van uw wachtwoord. Trek het token in en de app is eruit, zonder wachtwoordreset.
Consent phishing: a malicious app asks for broad scopes and the user clicks Allow. Device-code phishing has the victim type a code on the real login page, which signs in the attacker (Microsoft, 2025). Access tokens are bearer tokens: they work for whoever holds them, and a stolen refresh token keeps working for weeks.Consent-phishing: een kwaadaardige app vraagt brede rechten en de gebruiker klikt op Toestaan. Bij device-code-phishing typt het slachtoffer een code op de echte inlogpagina en logt zo de aanvaller in (Microsoft, 2025). Toegangstokens zijn bearer-tokens: ze werken voor wie ze heeft, en een gestolen refresh-token blijft wekenlang werken.
The protocol itself holds. AI-driven adversary-in-the-middle kits proxy the real login page and grab the tokens after MFA, so the weak point is the login in front of it.Het protocol zelf houdt stand. AI-gestuurde adversary-in-the-middle-kits zetten de echte inlogpagina ertussen en pakken de tokens na MFA. Het zwakke punt is de login ervoor.
AI writes a convincing consent lure in any language in seconds. And an AI agent with a valid token does what injected text tells it to: the token is legitimate, the intent is not. Its scopes are its blast radius.AI schrijft in seconden een overtuigend consent-verzoek in elke taal. En een AI-agent met een geldig token doet wat geïnjecteerde tekst hem opdraagt: het token is echt, de bedoeling niet. De rechten van het token bepalen de schade.
AI-assisted monitoring flags new apps asking for mail or file scopes, tokens used from new countries, and agents calling APIs they never used before. Worth pairing with admin approval for high-risk scopes, and with device-bound tokens (DPoP, Entra Token Protection) so a stolen token fails elsewhere.AI-ondersteunde monitoring signaleert nieuwe apps die om mail- of bestandsrechten vragen, tokens vanuit nieuwe landen en agents die API's aanroepen die ze nooit gebruikten. Combineer dat bij voorkeur met beheerdersgoedkeuring voor risicovolle rechten, en met apparaatgebonden tokens (DPoP, Entra Token Protection), zodat een gestolen token elders niet werkt.
An employee opens a SaaS application. The app redirects them to the corporate identity provider, often Okta, Microsoft Entra ID or Ping Identity. They log in with their corporate account. The identity provider creates a signed XML assertion: "This is Alice from Engineering, valid until 3pm." The browser posts it to the SaaS app, which checks the signature, trusts the assertion and starts a session. The identity provider decides who gets in; the SaaS app trusts the company.
Use when: Multiple SaaS or internal applications need to share user identity managed by the enterprise directory, and the enterprise needs to centrally control access.
Een medewerker opent een SaaS-applicatie. De app stuurt hem door naar de identity provider van het bedrijf, vaak Okta, Microsoft Entra ID of Ping Identity. Hij meldt zich aan met zijn bedrijfsaccount. De identity provider maakt een ondertekende XML-assertie: "Dit is Alice van Engineering, geldig tot 15:00 uur." De browser stuurt die door naar de SaaS-app, die de handtekening controleert, de assertie vertrouwt en een sessie start. De identity provider bepaalt wie binnenkomt; de SaaS-app vertrouwt het bedrijf.
Gebruik wanneer: Meerdere SaaS- of interne applicaties dezelfde gebruikersidentiteit uit de bedrijfsdirectory gebruiken, en het bedrijf de toegang centraal wil beheren.
Disable the account in the corporate directory and access to every federated app ends at the next login. Mature and supported by almost every enterprise SaaS product.Schakel het account uit in de bedrijfsdirectory en de toegang tot elke gefedereerde app stopt bij de volgende login. Volwassen en ondersteund door vrijwel elk zakelijk SaaS-product.
Signature-wrapping and parser bugs have repeatedly let attackers forge assertions. A stolen signing key at the identity provider (Golden SAML) lets an attacker mint a login for anyone, MFA included.Signature-wrapping en parserfouten lieten aanvallers herhaaldelijk asserties vervalsen. Met een gestolen ondertekeningssleutel van de identity provider (Golden SAML) maakt een aanvaller een login voor iedereen aan, MFA inbegrepen.
Session theft through AI phishing kits works as well as against OIDC. Finding signature bugs still takes skill, but AI-assisted fuzzing and code reading shorten the search.Sessiediefstal via AI-phishingkits werkt net zo goed als bij OIDC. Handtekeningfouten vinden vraagt nog vakmanschap, maar AI-ondersteund fuzzen en code lezen verkorten de zoektocht.
Golden SAML needs the identity provider compromised first. Once it is, AI does not matter: every app trusts the forged assertions.Golden SAML vereist eerst een gecompromitteerde identity provider. Is dat gebeurd, dan maakt AI niet meer uit: elke app vertrouwt de vervalste asserties.
AI-based identity threat detection matches identity-provider sign-ins with SaaS sessions and flags sessions with no matching login: the signature of a forged assertion or a replayed session.AI-gebaseerde identiteitsdetectie koppelt aanmeldingen bij de identity provider aan SaaS-sessies en signaleert sessies zonder bijbehorende login: het kenmerk van een vervalste assertie of een hergebruikte sessie.
You log in to a website. The site redirects you to an identity provider (Google, Auth0 or your company's). You authenticate. Besides an access token, you now also receive an ID token: a signed JWT that says "This is Alice, email alice@company.com, picture: ...". The website verifies the signature and knows exactly who you are, with no second query. OIDC is OAuth2 plus an identity layer: the authorization server now also authenticates you.
Use when: An application needs both authentication (proving who you are) and authorization (accessing resources). Modern web and mobile apps typically use OIDC for login and OAuth2 for API access.
U logt in op een website. De site stuurt u door naar een identity provider (Google, Auth0 of die van uw bedrijf). U meldt zich aan. Naast een toegangstoken krijgt u nu ook een ID-token: een ondertekende JWT met de tekst "Dit is Alice, e-mail alice@company.com, profielfoto: ...". De website controleert de handtekening en weet precies wie u bent, zonder tweede vraag. OIDC is OAuth2 plus een identiteitslaag: de autorisatieserver stelt nu ook vast wie u bent.
Gebruik wanneer: Een toepassing zowel authenticatie (bewijzen wie u bent) als autorisatie (resources benaderen) nodig heeft. Moderne web- en mobiele apps gebruiken doorgaans OIDC voor inloggen en OAuth2 voor API-toegang.
A signed ID token with standard claims, libraries in every language, and one flow for web, mobile and APIs together with OAuth2.Een ondertekend ID-token met standaardclaims, bibliotheken in elke taal en één stroom voor web, mobiel en API's, samen met OAuth2.
Apps that skip checking signature, audience, issuer or expiry accept forged or replayed tokens. Tokens kept in browser storage can be read by any cross-site scripting flaw.Apps die handtekening, audience, issuer of vervaldatum niet controleren, accepteren vervalste of hergebruikte tokens. Tokens in browseropslag zijn leesbaar voor elke cross-site-scriptingfout.
Same adversary-in-the-middle session theft as SAML. Easy if the app was written with AI help and nobody reviewed it: generated token checks often "work" while skipping the audience check.Dezelfde adversary-in-the-middle-sessiediefstal als bij SAML. Makkelijk als de app met AI-hulp is geschreven en niemand het controleerde: gegenereerde tokencontroles "werken" vaak terwijl de audiencecheck ontbreekt.
A stolen session or ID token is a full login until it expires. AI makes the phishing that steals it cheaper and better targeted.Een gestolen sessie of ID-token is een volledige login tot het verloopt. AI maakt de phishing die het steelt goedkoper en gerichter.
AI code review reliably catches missing issuer, audience and expiry checks. It works best as a second reader, not the only one, for anything that touches login.AI-codereview vindt ontbrekende issuer-, audience- en vervalcontroles betrouwbaar. Het werkt het best als tweede lezer, niet als enige, voor alles wat met inloggen te maken heeft.
Service A needs to call Service B. Both hold X.509 certificates signed by the same trusted certificate authority. In the TLS handshake each side sends its certificate and checks the other's: signed by the CA, and the name on it matches the service it expects. If all checks pass, the connection is set up. No user, token or password is involved: this is machine-to-machine authentication.
Use when: Services need to authenticate to each other without a user, such as microservices, API gateways, load balancers or service-to-service traffic in zero-trust architectures.
Service A moet Service B aanroepen. Beide hebben X.509-certificaten, ondertekend door dezelfde vertrouwde certificaatautoriteit. Tijdens de TLS-handshake stuurt elke kant zijn certificaat en controleert die van de ander: ondertekend door de CA, en de naam op het certificaat komt overeen met de verwachte service. Kloppen alle controles, dan staat de verbinding. Er komt geen gebruiker, token of wachtwoord aan te pas: dit is authenticatie van machine tot machine.
Gebruik wanneer: Services zich zonder gebruiker aan elkaar moeten bewijzen, zoals microservices, API-gateways, load balancers of verkeer tussen services in zero-trust-architecturen.
Both sides prove they hold a private key; nothing replayable crosses the network. A strong fit for zero-trust networks between services.Beide kanten bewijzen dat ze een privésleutel hebben; er gaat niets over het netwerk dat hergebruikt kan worden. Past sterk bij zero trust tussen services.
Expired certificates cause outages. Private keys copied into disk images, containers or repositories let an attacker impersonate the service. Revocation checking is often switched off.Verlopen certificaten veroorzaken storingen. Privésleutels die in images, containers of repositories belanden, laten een aanvaller de service nabootsen. Intrekkingscontrole staat vaak uit.
AI does not break the cryptography. The attacker has to steal a private key first.AI breekt de cryptografie niet. De aanvaller moet eerst een privésleutel stelen.
AI speeds up hunting for keys in leaked code, container images and backups. A found key is the service's identity until someone revokes it.AI versnelt het zoeken naar sleutels in gelekte code, containerimages en back-ups. Een gevonden sleutel is de identiteit van de service tot iemand hem intrekt.
AI-assisted tooling keeps the certificate inventory, predicts expiries and finds private keys where they should not be. Short-lived workload certificates give AI agents an identity without long-lived API keys.AI-ondersteunde tooling houdt de certificateninventaris bij, voorspelt verlopen en vindt privésleutels waar ze niet horen. Kortlevende workloadcertificaten geven AI-agents een identiteit zonder langlevende API-sleutels.
You open a website and choose "sign in with a passkey". The site sends a random challenge. Your phone or laptop asks for your face, fingerprint or PIN, which never leaves the device, and signs the challenge with a private key that was created for that one website. The site checks the signature with the public key it stored when you registered. No password is typed, sent or stored anywhere.
The key is tied to the website's real domain. A pixel-perfect fake site on a look-alike domain gets no signature it can use, because your device will not sign for the wrong domain. That is what "phishing-resistant" means, and why passkeys hold up against AI-generated phishing that fools people.
Use when: People log in: staff, admins, customers. Start with administrators and anyone who can move money.
U opent een website en kiest "inloggen met een passkey". De site stuurt een willekeurige uitdaging. Uw telefoon of laptop vraagt om uw gezicht, vingerafdruk of pincode, die het apparaat nooit verlaten, en ondertekent de uitdaging met een privésleutel die voor die ene website is aangemaakt. De site controleert de handtekening met de publieke sleutel die hij bij uw registratie heeft opgeslagen. Er wordt nergens een wachtwoord getypt, verstuurd of opgeslagen.
De sleutel is gekoppeld aan het echte domein van de website. Een perfecte nepsite op een domein dat erop lijkt, krijgt geen bruikbare handtekening, omdat uw apparaat niet ondertekent voor het verkeerde domein. Dat is wat "phishingbestendig" betekent, en waarom passkeys standhouden tegen AI-phishing die mensen wel voor de gek houdt.
Gebruik wanneer: Mensen inloggen: medewerkers, beheerders, klanten. Begin bij beheerders en iedereen die geld kan overmaken.
The key is bound to the real website's domain. A fake site gets nothing it can replay. No password to reuse, leak or spray.De sleutel is gebonden aan het domein van de echte website. Een nepsite krijgt niets wat hij kan hergebruiken. Geen wachtwoord om te hergebruiken, te lekken of te raden.
If lost-device recovery falls back to SMS, email or a helpdesk call, attackers use that path instead. Synced passkeys are only as safe as the Apple, Google or Microsoft account they sync through.Als herstel bij een verloren apparaat terugvalt op sms, e-mail of een telefoontje naar de helpdesk, nemen aanvallers die route. Gesynchroniseerde passkeys zijn zo veilig als het Apple-, Google- of Microsoft-account waarmee ze synchroniseren.
AI makes phishing emails and cloned login pages perfect, but it cannot make a fake domain match the real one. There is no secret to phish.AI maakt phishingmails en nagemaakte inlogpagina's perfect, maar kan een nepdomein niet laten overeenkomen met het echte. Er is geen geheim om te phishen.
Attackers skip the passkey and target recovery: a deepfaked voice on the helpdesk line asking to reset a lost phone.Aanvallers slaan de passkey over en richten zich op herstel: een deepfake-stem aan de helpdesk die vraagt een verloren telefoon te resetten.
Risk-based checks and AI anomaly detection on recovery requests flag bursts and odd timing. For admin resets, consider in-person or verified-video identity checks rather than a voice on the phone.Risicogebaseerde controles en AI-anomaliedetectie op herstelverzoeken signaleren pieken en vreemde tijdstippen. Overweeg voor resets van beheerders een identiteitscontrole in persoon of via geverifieerde video, in plaats van een stem aan de telefoon.
You log on to a Windows PC in the office. The PC proves your password to the domain controller once, and gets a ticket back. From then on, every file share, printer and intranet app asks for a ticket, not your password. That is Kerberos: single sign-on for everything in the Windows domain. NTLM is its older predecessor, still used as a fallback whenever Kerberos can't be.
The weakness is that any domain user can request a ticket for any service account, and part of that ticket is encrypted with the service account's password. Attackers take it offline and crack it (Kerberoasting). NTLM hashes can be replayed or relayed without ever cracking them. Whoever steals the domain's master key can forge tickets for anyone.
Use when: You run on-premises Active Directory. Worth hardening; we suggest not building new systems on it.
U meldt zich aan op een Windows-pc op kantoor. De pc bewijst uw wachtwoord één keer aan de domeincontroller en krijgt een ticket terug. Daarna vraagt elke netwerkschijf, printer en intranet-app om dat ticket, niet om uw wachtwoord. Dat is Kerberos: single sign-on voor alles in het Windows-domein. NTLM is de oudere voorganger, nog steeds in gebruik als terugvaloptie wanneer Kerberos niet kan.
De zwakte: elke domeingebruiker kan een ticket aanvragen voor elk serviceaccount, en een deel van dat ticket is versleuteld met het wachtwoord van dat account. Aanvallers nemen het mee en kraken het offline (Kerberoasting). NTLM-hashes kunnen worden hergebruikt of doorgestuurd zonder ze te kraken. Wie de hoofdsleutel van het domein steelt, kan tickets vervalsen voor iedereen.
Gebruik wanneer: U on-premises Active Directory draait. Het loont om het te versterken; bouw er bij voorkeur geen nieuwe systemen op.
Single sign-on across the domain with tickets instead of passwords on the wire, and mutual authentication between user and server.Single sign-on in het hele domein met tickets in plaats van wachtwoorden over de lijn, en wederzijdse authenticatie tussen gebruiker en server.
Kerberoasting cracks service-account passwords offline. Pass-the-hash and NTLM relay reuse credentials without knowing the password. A stolen KRBTGT key (golden ticket) forges access to everything. Microsoft plans to switch network NTLM off by default in the next major Windows Server release (announced January 2026); until then it stays on unless you switch it off.Kerberoasting kraakt wachtwoorden van serviceaccounts offline. Pass-the-hash en NTLM-relay hergebruiken inloggegevens zonder het wachtwoord te kennen. Een gestolen KRBTGT-sleutel (golden ticket) vervalst toegang tot alles. Microsoft wil netwerk-NTLM standaard uitzetten in de volgende grote Windows Server-release (aangekondigd januari 2026); tot dan staat het aan, tenzij u het zelf uitzet.
Weak service-account passwords fall quickly to GPU cracking with AI-generated guess lists, and automated tooling maps attack paths through Active Directory in minutes.Zwakke serviceaccountwachtwoorden vallen snel door GPU-kraken met door AI gegenereerde raadlijsten, en geautomatiseerde tooling brengt aanvalspaden door Active Directory in minuten in kaart.
Pass-the-hash and relay are fully scripted. An AI assistant can walk a less skilled attacker through every step.Pass-the-hash en relay zijn volledig gescript. Een AI-assistent loodst een minder ervaren aanvaller door elke stap.
Identity threat detection with machine learning spots Kerberoasting bursts, forged-ticket anomalies and relay attempts. The most effective fix is boring: managed service accounts with long random passwords, and NTLM switched off.Identiteitsdetectie met machine learning signaleert Kerberoasting-pieken, afwijkingen van vervalste tickets en relaypogingen. De effectiefste maatregel is saai: beheerde serviceaccounts met lange willekeurige wachtwoorden, en NTLM uit.
You connect to the company VPN or Wi-Fi and type your username and password. The VPN box doesn't know you; it asks a RADIUS server. RADIUS in turn checks your password against the directory, usually over LDAP, and answers "accept" or "reject". The same pattern sits behind firewalls, switches, printers and many older business applications.
It is the oldest layer on this page. LDAP without TLS sends passwords in cleartext across the network, RADIUS protects its messages with MD5 and a shared secret, and a password is all it takes unless MFA is bolted on. That makes internet-facing VPNs a top target.
Use when: Devices or legacy apps can't do SAML or OIDC. Consider MFA in front, and a plan to move the VPN to identity-aware access.
U maakt verbinding met de VPN of wifi van het bedrijf en typt uw gebruikersnaam en wachtwoord. Het VPN-apparaat kent u niet en vraagt het aan een RADIUS-server. Die controleert uw wachtwoord in de directory, meestal via LDAP, en antwoordt "accept" of "reject". Hetzelfde patroon zit achter firewalls, switches, printers en veel oudere bedrijfsapplicaties.
Dit is de oudste laag op deze pagina. LDAP zonder TLS stuurt wachtwoorden onversleuteld over het netwerk, RADIUS beschermt zijn berichten met MD5 en een gedeeld geheim, en een wachtwoord is genoeg tenzij er MFA bij is gezet. Daarom zijn VPN's aan het internet een topdoelwit.
Gebruik wanneer: Apparaten of oude applicaties geen SAML of OIDC kunnen. Overweeg MFA ervoor en een plan om de VPN te vervangen door identiteitsgebaseerde toegang.
Network gear, VPNs, Wi-Fi, printers and old applications all speak it, and it reuses the directory you already have.Netwerkapparatuur, VPN's, wifi, printers en oude applicaties spreken het allemaal, en het gebruikt de directory die u al hebt.
Plain LDAP binds send passwords unencrypted. RADIUS relies on MD5 and a shared secret: the Blast-RADIUS flaw (2024) showed an attacker on the network path can forge an "accept". Often there is no MFA.Gewone LDAP-binds sturen wachtwoorden onversleuteld. RADIUS leunt op MD5 en een gedeeld geheim: de Blast-RADIUS-kwetsbaarheid (2024) liet zien dat een aanvaller op het netwerkpad een "accept" kan vervalsen. Vaak is er geen MFA.
VPN and Wi-Fi logins backed by LDAP or RADIUS are a favourite target for password spraying with AI-generated, company-specific password lists.VPN- en wifi-logins op LDAP of RADIUS zijn een favoriet doelwit voor password spraying met door AI gegenereerde, bedrijfsspecifieke wachtwoordlijsten.
Passwords bought from infostealer logs open the VPN directly. Nothing in the protocol tells a real employee from someone with their password.Wachtwoorden uit infostealer-logs openen de VPN direct. Niets in het protocol onderscheidt een echte medewerker van iemand met zijn wachtwoord.
AI-based detection on VPN and directory logs spots spraying, impossible travel and logins at odd hours. Phishing-resistant MFA in front, LDAPS and RADIUS over TLS are the usual next steps.AI-gebaseerde detectie op VPN- en directorylogs signaleert raadpogingen, onmogelijke reizen en logins op vreemde tijden. Phishingbestendige MFA ervoor, LDAPS en RADIUS over TLS zijn de gebruikelijke volgende stappen.
An API key is a long random string that a script, integration or AI tool sends with every request. The API checks the string and answers. There is no login, no user and no MFA: the key is the identity. That makes it the easiest credential to set up and the most common one in practice.
It is also the one that leaks most. Keys get pasted into code, config files, tickets, chat and prompts, and they rarely expire. Whoever finds a key can do everything it allows, from anywhere, until someone notices and rotates it.
Use when: Low-risk, internal, read-only access where nothing better is available. Otherwise OAuth client credentials, mTLS or workload identity are the better choice.
Een API-sleutel is een lange willekeurige tekenreeks die een script, koppeling of AI-tool bij elk verzoek meestuurt. De API controleert de reeks en antwoordt. Er is geen login, geen gebruiker en geen MFA: de sleutel is de identiteit. Daardoor is het de makkelijkste vorm van inloggegevens om op te zetten, en in de praktijk de meest gebruikte.
Het is ook de vorm die het vaakst lekt. Sleutels worden in code, configbestanden, tickets, chat en prompts geplakt, en verlopen zelden. Wie een sleutel vindt, kan alles wat die toestaat, van overal, tot iemand het merkt en hem vervangt.
Gebruik wanneer: Interne toegang met weinig risico en alleen-lezen, waar niets beters beschikbaar is. Anders zijn OAuth client credentials, mTLS of workloadidentiteit de betere keuze.
One string that works from any tool or script. Acceptable for low-risk, read-only, internal use with regular rotation.Eén tekenreeks die vanuit elke tool of elk script werkt. Acceptabel voor intern gebruik met weinig risico, alleen-lezen en regelmatige rotatie.
No user, no MFA, rarely rotated, usually over-privileged. Keys end up in code, logs, tickets and chat, and whoever finds one becomes the service.Geen gebruiker, geen MFA, zelden geroteerd, meestal te veel rechten. Sleutels belanden in code, logs, tickets en chat, en wie er een vindt, wordt de service.
Attackers use automated and AI-assisted scanners on public repositories, leaked code and container images; a pushed key can be found within minutes. AI-generated code often hardcodes keys.Aanvallers scannen publieke repositories, gelekte code en containerimages geautomatiseerd en met AI-hulp; een gepushte sleutel kan binnen minuten gevonden zijn. Door AI gegenereerde code zet sleutels vaak hard in de code.
AI agents and local MCP servers usually read keys from environment variables or config files. Prompt injection can make an agent reveal or misuse the key it holds.AI-agents en lokale MCP-servers lezen sleutels meestal uit omgevingsvariabelen of configuratiebestanden. Promptinjectie kan een agent de sleutel laten prijsgeven of misbruiken.
AI-assisted secret scanning in commits, tickets and chat catches keys before or right after they leak, and can trigger automatic revocation. Where possible, consider replacing keys with OAuth or workload identity.AI-ondersteunde secret-scanning in commits, tickets en chat vangt sleutels voor of direct na een lek, en kan automatisch intrekken. Overweeg sleutels waar mogelijk te vervangen door OAuth of workloadidentiteit.
AI agents read mail, open tickets, query databases and call APIs on someone's behalf. That makes them a new kind of user: they log in, hold credentials and act, but they are not a person, they don't do MFA, and they follow instructions they find in the data they read.
The Model Context Protocol (MCP), the common way to connect agents to tools, builds its remote authorization on the OAuth 2.1 draft (MCP revision 2026-07-28): the tool answers "401", the agent sends you to the authorization server, you consent, and the agent receives a short-lived token valid for that one tool only. The spec requires tool servers to reject tokens issued for anyone else and not to pass tokens on. Tools that run locally on the laptop skip all of this and read credentials from the environment, in practice static API keys.
Two sides of AI. As a client, every agent is best given its own identity, narrow scopes, short token lifetimes, an owner and a kill switch, because prompt injection can turn its token against you. As an attacker's tool, AI makes phishing kits, deepfaked helpdesk calls and password cracking cheaper, which weakens every protocol that ends in a password or a reset call. Passkeys and certificates hold up; passwords, SMS codes and static keys don't.
AI-agents lezen mail, openen tickets, bevragen databases en roepen API's aan namens iemand. Daarmee zijn ze een nieuw soort gebruiker: ze loggen in, hebben inloggegevens en handelen, maar ze zijn geen persoon, doen geen MFA en volgen instructies die ze aantreffen in de gegevens die ze lezen.
Het Model Context Protocol (MCP), de gangbare manier om agents aan tools te koppelen, baseert zijn autorisatie op afstand op het OAuth 2.1-concept (MCP-revisie 2026-07-28): de tool antwoordt "401", de agent stuurt u naar de autorisatieserver, u geeft akkoord, en de agent krijgt een kortlevend token dat alleen voor die ene tool geldt. De specificatie verplicht toolservers om tokens voor anderen te weigeren en tokens niet door te geven. Tools die lokaal op de laptop draaien, slaan dit allemaal over en lezen inloggegevens uit de omgeving: in de praktijk statische API-sleutels.
Twee kanten van AI. Als client krijgt elke agent bij voorkeur een eigen identiteit, beperkte rechten, kortlevende tokens, een eigenaar en een noodstop, omdat promptinjectie zijn token tegen u kan keren. Als gereedschap van aanvallers maakt AI phishingkits, deepfake-telefoontjes naar de helpdesk en wachtwoordkraken goedkoper. Dat verzwakt elk protocol dat eindigt in een wachtwoord of een resetgesprek. Passkeys en certificaten houden stand; wachtwoorden, sms-codes en statische sleutels niet.
MCP authorization builds on the OAuth 2.1 draft with PKCE, tokens bound to a single tool server, no token passthrough, and step-up consent for extra rights.MCP-autorisatie bouwt op het OAuth 2.1-concept met PKCE, tokens gebonden aan één toolserver, geen doorgeven van tokens en extra toestemming voor extra rechten.
An agent cannot reliably tell your instructions from instructions hidden in an email, web page or ticket it reads. One shared key for all agents, full-mailbox scopes, keys in plain config files and agent accounts nobody owns after the pilot are the usual findings.Een agent kan uw instructies niet betrouwbaar onderscheiden van instructies die verstopt zitten in een e-mail, webpagina of ticket dat hij leest. Eén gedeelde sleutel voor alle agents, rechten op de hele mailbox, sleutels in platte configbestanden en agentaccounts zonder eigenaar na de pilot zijn de gebruikelijke bevindingen.
Prompt injection needs no exploit code: a line of text in a document the agent reads is enough to redirect it.Promptinjectie vraagt geen exploitcode: een regel tekst in een document dat de agent leest, is genoeg om hem om te leiden.
An injected agent uses its own valid token, so every log entry looks legitimate. It acts at machine speed across every system it can reach.Een geïnjecteerde agent gebruikt zijn eigen geldige token, dus elke logregel ziet er legitiem uit. Hij handelt op machinesnelheid in elk systeem dat hij kan bereiken.
We suggest one identity and owner per agent, narrow short-lived tokens, and a kill switch. Guardrail models and policy checks screen tool calls; payments, deletions and external sharing are worth routing to a human for approval.Wij raden één identiteit en eigenaar per agent aan, beperkte kortlevende tokens en een noodstop. Guardrailmodellen en beleidscontroles screenen toolaanroepen; betalingen, verwijderingen en extern delen legt u bij voorkeur ter goedkeuring voor aan een mens.
| Protocol | Solves | Phishing-resistant | Best for | Watch out for | Break with AI |
|---|---|---|---|---|---|
| OAuth2 | Delegated access for apps and agents | No, depends on the login | Apps and AI agents using your data | Broad consent, stolen refresh tokens | Medium |
| SAML | Enterprise single sign-on | No, depends on IdP MFA | Employees across SaaS apps | Signature bugs, stolen signing key, session theft | Medium |
| OIDC | Login and identity for apps | No, depends on the login | Modern web and mobile login | Skipped token checks, session theft | Medium |
| mTLS | Machine-to-machine trust | Yes | Service-to-service, zero trust | Expired certificates, leaked keys | Hard |
| Passkeys | Passwordless login for people | Yes | Staff, admin and customer login | Weak account recovery | Hard |
| Kerberos / NTLM | Windows domain sign-on | No | On-premises Active Directory | Kerberoasting, pass-the-hash, relay | Easy |
| LDAP / RADIUS | Directory and network login | No | VPN, Wi-Fi, legacy apps | Cleartext binds, spraying, no MFA | Easy |
| API keys | Simple app-to-API access | No | Low-risk scripts and tools | Leaks in code, never rotated | Easy |
| Protocol | Lost op | Phishingbestendig | Beste voor | Let op | Breken met AI |
|---|---|---|---|---|---|
| OAuth2 | Gedelegeerde toegang voor apps en agents | Nee, hangt af van de login | Apps en AI-agents die uw gegevens gebruiken | Brede toestemming, gestolen refresh-tokens | Gemiddeld |
| SAML | Zakelijke single sign-on | Nee, hangt af van MFA bij de IdP | Medewerkers in SaaS-apps | Handtekeningfouten, gestolen sleutel, sessiediefstal | Gemiddeld |
| OIDC | Inloggen en identiteit voor apps | Nee, hangt af van de login | Modern inloggen op web en mobiel | Overgeslagen tokencontroles, sessiediefstal | Gemiddeld |
| mTLS | Vertrouwen tussen machines | Ja | Service naar service, zero trust | Verlopen certificaten, gelekte sleutels | Moeilijk |
| Passkeys | Wachtwoordloos inloggen voor mensen | Ja | Inloggen door medewerkers, beheerders, klanten | Zwak accountherstel | Moeilijk |
| Kerberos / NTLM | Aanmelden in het Windows-domein | Nee | On-premises Active Directory | Kerberoasting, pass-the-hash, relay | Makkelijk |
| LDAP / RADIUS | Directory- en netwerklogin | Nee | VPN, wifi, oude applicaties | Onversleutelde binds, raden, geen MFA | Makkelijk |
| API-sleutels | Eenvoudige app-naar-API-toegang | Nee | Scripts en tools met weinig risico | Lekken in code, nooit geroteerd | Makkelijk |
Authentication and authorization are default targets. Weak protocol selection, token theft, and certificate mismanagement are common findings in both pentests and breach post-mortems.Authenticatie en autorisatie zijn vaste doelwitten. Een zwakke protocolkeuze, tokendiefstal en slecht certificaatbeheer zijn veelvoorkomende bevindingen in pentests en analyses na een inbraak.
Authentication failure means unauthorized access to systems, data, and resources. An attacker can impersonate users or services, bypass controls, and operate undetected inside trusted systems.Faalt de authenticatie, dan krijgt een aanvaller toegang tot systemen, gegevens en resources. Hij kan gebruikers of services nabootsen, controles omzeilen en onopgemerkt binnen vertrouwde systemen werken.
Correct protocol selection and implementation eliminate most basic attacks. Residual risk remains from zero-day flaws, compromised keys/certificates, phishing for credentials, and insider abuse. Defense in depth (MFA, rate limiting, anomaly detection) reduces it further.Juiste protocolselectie en implementatie elimineren de meeste basisaanvallen. Restrisico blijft bestaan door zero-day-fouten, gecompromitteerde sleutels/certificaten, phishing naar inloggegevens en misbruik door insiders. Gelaagde verdediging (MFA, rate limiting, anomaliedetectie) verkleint het verder.
CTO for engineering practices and protocol choices; Security for policy, token/certificate management, and incident response.CTO voor engineeringpraktijken en protocolkeuzes; security voor beleid, token- en certificaatbeheer en incidentrespons.
% of admins and finance staff on phishing-resistant login (passkeys) · number of static API keys older than 90 days · number of AI agents and service accounts without a named owner · NTLM still enabled: yes or no · average certificate rotation interval in days.% beheerders en financiële medewerkers met phishingbestendig inloggen (passkeys) · aantal statische API-sleutels ouder dan 90 dagen · aantal AI-agents en serviceaccounts zonder benoemde eigenaar · NTLM nog aan: ja of nee · gemiddeld rotatie-interval van certificaten in dagen.
"Phishable, replayable or leaked credentials, in legacy protocols, static API keys or tokens held by AI agents, enable unauthorized access to systems and data.""Phishbare, herbruikbare of gelekte inloggegevens, in oude protocollen, statische API-sleutels of tokens van AI-agents, maken ongeautoriseerde toegang tot systemen en gegevens mogelijk."
Attackers use AI for real-time phishing proxies that steal sessions after MFA, deepfaked helpdesk calls to reset accounts, and faster cracking of weak passwords. Inside, AI agents hold tokens and keys and can be steered by prompt injection. Phishing-resistant login and a per-agent identity with narrow, short-lived access are what hold up.Aanvallers gebruiken AI voor realtime phishingproxy's die sessies na MFA stelen, deepfake-telefoontjes naar de helpdesk om accounts te resetten, en sneller kraken van zwakke wachtwoorden. Binnen hebben AI-agents tokens en sleutels en zijn ze via promptinjectie te sturen. Phishingbestendig inloggen en een eigen identiteit per agent met beperkte, kortlevende toegang houden stand.
| Framework | What it requires of you | When a supplier hands you their report | When this incident happens |
|---|---|---|---|
| NIS2 | Art. 21(2)(i) asks for access-control policies and 21(2)(j) for multi-factor or continuous authentication where appropriate. Protocol choice and secure credential storage fall under the wider risk-management duty. In the Netherlands: the Cyberbeveiligingswet (Cbw), in force since 15 August 2026. | Ask why each protocol was chosen, and for evidence that tokens and keys are not stored in cleartext, that critical systems use MFA, and that token and certificate expiry is enforced. | Stolen tokens or certificates used to break in can count as a significant incident if it meets the thresholds. Then: early warning within 24 hours of becoming aware · incident notification within 72 hours · final report within one month. Revoking and reissuing the affected credentials is usually the first step. |
| DORA | For financial entities, Art. 9(4)(d) requires policies and protocols for strong authentication based on relevant standards, and protection of cryptographic keys. Keep them documented, with evidence they work. | Ask for the protocol implementation documents and evidence that tokens expire, certificates are rotated and authentication is logged. Worth including protocol attack scenarios in testing. | Account takeover through stolen tokens or certificates can count as a major ICT-related incident if it meets the classification criteria. Classify promptly · initial notification within 4 hours of classifying it as major (and at most 24 hours after becoming aware) · intermediate report within 72 hours of the initial notification · final report within one month. |
| SOC 2 | If you issue one: authentication, logical access and the lifecycle of credentials, tokens and certificates fall under CC6 (logical and physical access); monitoring for their misuse under CC7 (system operations). | Ask for test evidence on token and certificate storage, rotation and revocation, and whether the audit included penetration testing of login flows. | The deviation (weak token management, missing MFA, misconfigured protocol) appears in the next report. Customers will ask for evidence of remediation before renewing. |
| ISAE 3402 | If you provide a service to clients: authentication and access control are usually among your control objectives. A Type II report shows whether those controls worked throughout the period. | Check that the report covers MFA and key and certificate management for the systems that serve you, read the exceptions, and check which complementary controls are expected of you. | ISAE 3402 creates no duty to notify user auditors. Expect a deviation in the next report, and ask for interim disclosure in the contract. |
| ISO 27001 | ISO/IEC 27001:2022 Annex A: access control (5.15), identity management (5.16), authentication information (5.17), access rights (5.18), privileged access (8.2), secure authentication (8.5) and use of cryptography (8.24). The 2013 numbering no longer applies: the transition ended on 31 October 2025. | Check that authentication mechanisms are covered in the security policy. Ask for evidence of regular access reviews and for the key and certificate management procedures. | ISO 27001 sets no reporting clock of its own: follow your incident process (5.24–5.28) and the legal duties above. If personal data is involved, notify the Autoriteit Persoonsgegevens within 72 hours (GDPR Art. 33). |
| Kader | Wat het van u vraagt | Als een leverancier u zijn rapport geeft | Als dit incident u treft |
|---|---|---|---|
| NIS2 | Art. 21(2)(i) vraagt om beleid voor toegangsbeheer en 21(2)(j) om multifactor- of continue authenticatie waar passend. Protocolkeuze en veilige opslag van inloggegevens vallen onder de bredere zorgplicht voor risicobeheer. In Nederland: de Cyberbeveiligingswet (Cbw), van kracht sinds 15 augustus 2026. | Vraag waarom elk protocol is gekozen, en om bewijs dat tokens en sleutels niet leesbaar zijn opgeslagen, dat kritieke systemen MFA gebruiken en dat vervaldata van tokens en certificaten worden afgedwongen. | Gestolen tokens of certificaten waarmee is ingebroken, kunnen als significant incident gelden als de drempels worden gehaald. Dan geldt: vroegtijdige waarschuwing binnen 24 uur na kennisname · incidentmelding binnen 72 uur · eindrapport binnen een maand. De getroffen inloggegevens intrekken en opnieuw uitgeven is meestal de eerste stap. |
| DORA | Voor financiële entiteiten vereist art. 9(4)(d) beleid en protocollen voor sterke authenticatie op basis van relevante standaarden, en bescherming van cryptografische sleutels. Leg ze vast, met bewijs dat ze werken. | Vraag om de implementatiedocumentatie van de protocollen en om bewijs dat tokens verlopen, certificaten worden vernieuwd en aanmeldingen worden gelogd. Het loont om aanvalsscenario's op protocollen mee te nemen in tests. | Accountovername via gestolen tokens of certificaten kan als ernstig ICT-gerelateerd incident gelden als het aan de classificatiecriteria voldoet. Classificeer snel · eerste melding binnen 4 uur na classificatie als ernstig (en uiterlijk 24 uur na kennisname) · tussentijds rapport binnen 72 uur na de eerste melding · eindrapport binnen een maand. |
| SOC 2 | Als u er zelf een afgeeft: authenticatie, logische toegang en de levenscyclus van inloggegevens, tokens en certificaten vallen onder CC6 (logische en fysieke toegang); monitoring op misbruik daarvan onder CC7 (systeembeheer). | Vraag om testbewijs voor opslag, rotatie en intrekking van tokens en certificaten, en of de audit penetratietests van de inlogstromen omvatte. | De afwijking (zwak tokenbeheer, ontbrekende MFA, verkeerd geconfigureerd protocol) staat in het volgende rapport. Klanten vragen om bewijs van herstel voordat ze verlengen. |
| ISAE 3402 | Als u diensten aan klanten levert: authenticatie en toegangsbeheer horen meestal bij uw beheersdoelstellingen. Een Type II-rapport laat zien of die maatregelen de hele periode werkten. | Controleer of het rapport MFA en sleutel- en certificaatbeheer dekt voor de systemen die u bedienen, lees de uitzonderingen en kijk welke aanvullende maatregelen van u worden verwacht. | ISAE 3402 schept geen meldplicht richting de auditors van klanten. Verwacht een afwijking in het volgende rapport, en vraag in het contract om tussentijdse melding. |
| ISO 27001 | ISO/IEC 27001:2022 bijlage A: toegangsbeheer (5.15), identiteitsbeheer (5.16), authenticatie-informatie (5.17), toegangsrechten (5.18), speciale toegangsrechten (8.2), veilige authenticatie (8.5) en gebruik van cryptografie (8.24). De nummering van 2013 geldt niet meer: de overgangstermijn liep af op 31 oktober 2025. | Controleer of authenticatiemechanismen in het beveiligingsbeleid staan. Vraag om bewijs van regelmatige toegangsreviews en om de procedures voor sleutel- en certificaatbeheer. | ISO 27001 kent geen eigen meldtermijn: volg uw incidentproces (5.24–5.28) en de wettelijke plichten hierboven. Gaat het om persoonsgegevens, meld dan binnen 72 uur bij de Autoriteit Persoonsgegevens (AVG art. 33). |
Checked against: NIS2 Art. 21 and 23 and DORA Art. 9 and 19, OAuth 2.1 draft-16 (Sep 2026), MCP 2026-07-28, Microsoft on NTLM (Jan 2026), Microsoft on device-code phishing (Feb 2025), Entra Token Protection (Aug 2026), ISO/IEC 27001:2022 and IAF MD 26 · September 2026.
Gecontroleerd tegen: NIS2 art. 21 en 23 en DORA art. 9 en 19, OAuth 2.1-concept 16 (sep 2026), MCP 2026-07-28, Microsoft over NTLM (jan 2026), Microsoft over device-code-phishing (feb 2025), Entra Token Protection (aug 2026), ISO/IEC 27001:2022 en IAF MD 26 · september 2026.