Een PAM-programma faalt zelden op de installatie. De vault staat, de wachtwoorden zitten erin, de eerste beheeraccounts zijn onboarded, en op de roadmap staat een vinkje. Dan lijkt het gedaan.
Het begint dan pas.
In vrijwel elk Privileged Access Management-traject dat ik begeleid, zit het echte werk niet in de techniek maar in alles wat na het vaulten komt. Service accounts die niemand beheert, leveranciers met beheerrechten, noodtoegang die nooit is getest, en een beheerorganisatie die het geheel moet overnemen zonder dat iemand heeft nagedacht over hoe. Dat is waar PAM-programma’s stranden. Niet op de vault.
Vaulten is stap één, en het makkelijkst
Laten we eerlijk zijn over wat vaulten is: het onderbrengen van privileged credentials in een kluis, met check-out, rotatie en logging. Dat is waardevol en het is een noodzakelijke eerste stap. Het is ook de best gedocumenteerde, best ondersteunde en minst omstreden stap van het hele traject. Elke PAM-leverancier — CyberArk, BeyondTrust, Delinea, of Entra PIM voor het Microsoft-landschap — kan je hierbij helpen.
Precies daarom is het verraderlijk. Het voelt als vooruitgang, en dat is het ook, maar het dekt maar een fractie van het probleem af. NIST SP 800-53 vraagt niet alleen om een kluis, maar om least privilege, gescheiden accounts, sterke authenticatie en continue logging over je hele privileged landschap. De vault is het fundament, niet het gebouw.
Service accounts en non-human identities: het echte probleem
Vraag in een willekeurige organisatie hoeveel service accounts er zijn, en je krijgt zelden een precies antwoord. Het zijn er vaak honderden. Ze draaien processen, koppelingen en batchjobs, ze hebben brede rechten, en een flink deel heeft een wachtwoord dat al jaren niet is gewijzigd omdat niemand durft aan te raken wat “het gewoon doet”.
Dit is de moeilijkste categorie in elk PAM-traject, en de gevaarlijkste. Een service account laat zich niet zomaar in een kluis stoppen en roteren; als je het wachtwoord wijzigt zonder te weten welke systemen erop leunen, ligt er een keten plat. Dus wordt het uitgesteld. En zo blijft de grootste privileged risicocategorie het langst onaangeraakt.
Het wordt alleen maar urgenter. Naast de klassieke service accounts komen er in hoog tempo nieuwe niet-menselijke identiteiten bij: workload identities, tokens, en de identiteiten van AI-agents die zelfstandig handelen. Wie de identiteit van zijn AI-agents nog niet beheert, krijgt er een privileged probleem bij op een fundament dat de oude versie ervan nog niet heeft opgelost. Eigenaarschap is hier de kern: elk service account, elke agent, hoort een eigenaar te hebben die weet wat het doet en verantwoordelijk is voor de rechten.
Third-party toegang: de audit-magneet
De tweede plek waar het misgaat, is privileged toegang voor externen. Leveranciers, implementatiepartners en beheerpartijen hebben vaak verregaande rechten in je omgeving, soms met gedeelde accounts, soms zonder duidelijke einddatum, bijna altijd slecht gemonitord.
Voor een auditor is dit laaghangend fruit, en onder de nieuwe Cyberbeveiligingswet wordt het een direct bestuursrisico: je bent medeverantwoordelijk voor de toegang die je aan je leveranciers geeft. Third-party privileged access hoort daarom in een eigen regime: tijdelijke, herleidbare toegang, per persoon en niet per gedeeld account, met sessie-opname en een harde einddatum. Het is precies het soort control dat op papier makkelijk is en in de praktijk zelden strak staat.
Break-glass: de noodtoegang die niemand test
Elk volwassen PAM-ontwerp heeft break-glass: noodtoegang voor als de reguliere route faalt. En in vrijwel elke organisatie is die noodprocedure óf te streng, óf te los.
Te streng betekent dat je PAM-oplossing bij een incident de organisatie verlamt: de vault is onbereikbaar, en niemand komt er meer bij op het moment dat het moet. Te los betekent dat break-glass een permanente achterdeur is, met een gedeeld noodwachtwoord dat iedereen kent. Het venijn zit hem erin dat je het pas merkt als het misgaat. Een break-glass-procedure die nooit is getest, is geen noodplan maar een aanname. Test hem, periodiek, en leg vast wie hem wanneer gebruikte.
Session management: technisch simpel, organisatorisch lastig
Sessie-opname en -monitoring zijn technisch een kwestie van aanzetten. De echte lastigheid is organisatorisch. Wie mag meekijken? Hoe verhoudt het zich tot privacy en tot de ondernemingsraad? En wie kijkt er daadwerkelijk naar de opnames, want een opname die niemand bekijkt is bewijsmateriaal achteraf, geen controle vooraf. Realtime meekijken betekent dat je de sessie waarin een beheerder om twee uur ‘s nachts een database begint te exporteren op dát moment ziet, en niet drie weken later bij een forensisch onderzoek. Dat verschil is de hele waarde van monitoring.
Joiner-Mover-Leaver, maar dan voor privileged
De lifecycle van gewone accounts is al lastig; voor privileged accounts is hij zwaarder en wordt hij vaker overgeslagen. De mover is het klassieke lek: iemand wisselt van rol en stapelt beheerrechten op, want de oude rechten worden zelden ingetrokken. En de leaver met een actief beheeraccount is het scenario waar elke auditrapportage over struikelt.
Privileged accounts horen daarom een strakkere cadans te hebben dan reguliere toegang. Frequentere recertificering, met een aparte workflow, want ze op één hoop gooien met gewone rechten maakt van recertificering een afvinkoefening. NIST scheidt privileged accounts niet voor niets expliciet uit in zijn least-privilege-controls.
De overdracht naar beheer: waar het programma pas klaar is
Hier zit misschien wel de grootste blinde vlek. Een PAM-programma is niet af als de techniek staat. Het is af als de beheerorganisatie het kan dragen: de vault beheren, service accounts onboarden, uitzonderingen afhandelen, break-glass testen, recertificeringen draaien. En dat vraagt kennis, capaciteit en eigenaarschap die bij de overdracht vaak niet zijn geregeld.
Wat je overhoudt als je die overdracht overslaat, is een dure oplossing die langzaam verwatert omdat niemand hem onderhoudt. Nieuwe service accounts belanden buiten de vault, uitzonderingen stapelen zich op, en over twee jaar sta je waar je begon, maar dan met een licentie erbij. Dat dit op governance stukloopt en niet op techniek, is precies waarom een PAM-traject een programmavraagstuk is en geen installatie.
Tot slot
Vaulten is het makkelijke deel. Het is zichtbaar, het is af te vinken, en het geeft het gevoel dat je er bent. Maar het echte werk begint erna: de service accounts die niemand durft aan te raken, de leveranciers met te veel rechten, de noodtoegang die nooit is getest, en de beheerorganisatie die het moet overnemen.
Een PAM-programma slaagt of faalt op die tweede helft. Wie na de vault stopt, heeft een kluis gebouwd om een deur die nog wagenwijd openstaat.
Veelgestelde vragen
Wat is Privileged Access Management precies?
Privileged Access Management (PAM) is het beheersen, beveiligen en monitoren van accounts met verhoogde rechten: beheeraccounts, service accounts en andere identiteiten die kritieke systemen kunnen wijzigen. Het omvat het opslaan van credentials in een kluis (vaulten), rotatie, sterke authenticatie, sessie-monitoring en least privilege. De kluis is de eerste stap, niet het hele verhaal.
Waarom is vaulten niet genoeg?
Omdat vaulten alleen de credentials afdekt die je al kent en beheert. De grootste risico’s zitten elders: service accounts die niet in de kluis zitten, leveranciers met brede rechten, ongeteste break-glass-procedures en een gebrekkige lifecycle voor privileged accounts. NIST SP 800-53 vraagt dan ook om least privilege, gescheiden accounts en continue logging over je hele privileged landschap, niet alleen om een kluis.
Waarom zijn service accounts zo lastig in PAM?
Omdat ze vaak talrijk, slecht gedocumenteerd en zonder duidelijke eigenaar zijn, en omdat andere systemen erop leunen. Het wachtwoord roteren zonder te weten welke koppelingen afhankelijk zijn, kan een keten platleggen. Daardoor worden ze uitgesteld, terwijl ze juist de grootste privileged risicocategorie vormen. Eigenaarschap toewijzen is de eerste stap.
Wat is break-glass en waarom is het riskant?
Break-glass is noodtoegang voor situaties waarin de reguliere privileged route faalt. Het risico is tweezijdig: te streng ingericht verlamt het de organisatie tijdens een incident, te los ingericht is het een permanente achterdeur met een gedeeld noodwachtwoord. Een break-glass-procedure die nooit is getest, is een aanname en geen noodplan.
Hoe raakt PAM aan de Cyberbeveiligingswet en NIS2?
Privileged en third-party toegang zijn precies de controls waar een toezichthouder als eerste naar kijkt. Onder de Cyberbeveiligingswet ben je medeverantwoordelijk voor de toegang die je aan leveranciers geeft, en bestuurders zijn persoonlijk aanspreekbaar op adequate maatregelen. Aantoonbaar beheer van privileged accounts is daarmee niet alleen goede hygiëne, maar een compliance-vereiste.
