PAM-projecten lopen zelden vast op de techniek. Ze lopen vast op scope. Onze aanpak: een MVP binnen 10 tot 30 dagen, daarna iteratief uitbouwen op basis van wat de organisatie aankan.
Een CIO komt langs met een audit die over zes weken landt. De auditor wil weten wie root-toegang heeft op de productieservers, wie de service accounts draait achter de payment-koppeling, en wanneer iemand voor het laatst een bevoegdheid heeft ingetrokken. De antwoorden staan niet in een systeem. Ze staan in hoofden, in een Excel die iemand twee jaar geleden bijhield, en in een SSH-sleutel die nog op de laptop staat van een externe die in 2024 is vertrokken.
Dit is het werkelijke vertrekpunt voor de meeste PAM-trajecten waar wij bij betrokken raken. Niet een mooie greenfield-architectuur, maar een organisatie die weet dat het zo niet langer kan en die snel resultaat wil zien zonder een traject van anderhalf jaar.
PAM-projecten lopen zelden vast op de techniek. Ze lopen vast op scope. Een traditionele implementatie probeert in één beweging alles te dekken: vault voor wachtwoorden, sessie-opname, governance, just-in-time elevation, koppeling met SIEM, koppeling met IGA, koppeling met de service desk. De business case is mooi op papier. Na negen maanden draait er een vault waar nog niemand in werkt en is het projectteam halverwege de scope al uitgeput.
Wij zien drie patronen die dit veroorzaken.
Het eerste is dat de organisatie geen helder beeld heeft van wélke privileged accounts er bestaan. De inventarisatie wordt onderschat, blijkt halverwege groter dan gedacht, en het ontwerp wordt opnieuw gemaakt. Dat kost weken.
Het tweede patroon is dat het traject los wordt getrokken van de bestaande IAM-omgeving. Een PAM-product naast Okta of naast Active Directory levert twee policy engines op, twee plekken waar je toegang intrekt, en twee bronnen waar de auditor naar moet kijken. Operationele schuld in plaats van controle.
Het derde patroon is overdreven scope-ambitie. De wens om in fase één al sessie-opname, vault, JIT en governance live te hebben, terwijl de organisatie nog niet eens een betrouwbare lijst van admins heeft.
Onze aanpak voor PAM volgt dezelfde lijn die we hanteren bij Okta-implementaties en bij geautomatiseerde provisioning. We werken met een MVP die binnen 10 tot 30 dagen live staat en daarna iteratief uitbreidt. Dat is geen marketing-belofte, dat is hoe wij in 18 jaar hebben geleerd dat dit type traject wél landt.
Concreet betekent dat het volgende.
We beginnen niet met een tool, we beginnen met data. Welke serveromgevingen, welke SaaS-applicaties met admin-rollen, welke service accounts, welke shared accounts zijn er feitelijk in gebruik? Vaak ontdekken we hier al accounts die niemand meer kent en die toch nog actief zijn. Dat is geen leuke conversatie, maar het is de eerlijke conversatie die het traject hierna versnelt.
De meeste organisaties hebben de meeste pijn op één van deze drie plekken: Linux- en Windows-serverbeheer, SaaS service accounts, of secrets en wachtwoorden voor break-glass-scenario’s. Wij kiezen samen met je security- en operations-team de pijler waar de ROI het snelst zichtbaar wordt en de auditdruk het hoogst is. De andere pijlers volgen in latere iteraties.
Werkt de organisatie met Okta, dan sluiten we Okta’s PAM-oplossing (officiëel Okta Privileged Access) aan op dezelfde policy engine die SSO en MFA stuurt. Dat scheelt een tweede beheerinterface en zorgt dat een offboarding via HR direct ook de privileged toegang intrekt. Werk je niet met Okta, dan beoordelen we welke PAM-leverancier het beste aansluit op je IAM-fundament. We zijn Okta Apex Partner en Okta Partner of the Year 2025 in de Benelux, dus onze ervaring zit aan die kant het diepst, maar we adviseren wat past.
Na de eerste 30 dagen heb je iets dat werkt: een afgekaderde groep admins die via een gevaultte route inlogt, sessies die worden opgenomen, en een dashboard waar de CISO en de auditor in mee kunnen kijken. Vanaf dat punt breiden we uit. Just-in-time elevation, governance-workflows, integratie met access reviews, certification voor service accounts. Stuk voor stuk, met meetbare uitkomsten.
Eerlijk: PAM is geen quick fix. Wat wij niet doen, is in fase één al beloven dat alle 800 servers en alle 60 SaaS-apps in één klap onder beheer staan. Dat is technisch mogelijk maar organisatorisch onverstandig. Mensen moeten leren werken met een nieuwe inlogroute. Beheerders moeten wennen aan sessie-opname. Auditors moeten leren waar ze de logs moeten ophalen. Te snel uitrollen leidt tot workarounds, en workarounds leiden tot precies de schaduw-IT die je probeerde op te lossen.
We doen ook geen losse PAM-trajecten zonder context. Als je IAM-fundament wankel is, lossen we eerst dat op. PAM bovenop een onbetrouwbare bron is een dure manier om een verkeerd antwoord automatisch te geven.
Bij organisaties die deze aanpak doorlopen zie je in de praktijk een paar terugkerende patronen [VERIFY: bevestigen met concrete FuseLogic PAM-cases zodra die publiceerbaar zijn]:
Geen van deze uitkomsten is spectaculair op zichzelf. Bij elkaar zijn ze het verschil tussen “we hopen dat het goed zit” en “we weten dat het goed zit, en we kunnen het laten zien”.
Een PAM-traject begint bij ons altijd met een kort gesprek over wat je nu hebt en wat het meest urgent is. Geen vooraf-ingevulde scope, geen standaard-offerte. We willen weten waar de pijn zit, welke audit eraan komt, en welke besluiten al genomen zijn over je IAM-stack. Vanuit dat gesprek werken we toe naar een MVP die binnen 30 dagen meetbaar resultaat oplevert, at the speed of business.