Veel softwareteams hebben hun inlogstromen al lang “geregeld”. Totdat er iets verschuift in de standaard, en je ineens merkt hoeveel er eigenlijk op gewoonte draait.
De recente update in Microsoft Entra ID, waarin passkeys nadrukkelijker de default sign-in experience worden, is zo’n moment. Niet omdat iedereen morgen een crisis heeft. Wel omdat zo’n wijziging een oude vraag weer zichtbaar maakt: wat is bij ons echt de standaard, wat is uitzondering, en wie draagt daarvan het bewijs?
De frictie zit zelden in één methode
In de praktijk is authenticatie bijna nooit één nette keuze. Er is een default voor de meeste mensen, een uitzondering voor een bepaalde groep, een oude applicatie die nog via een omweg werkt, en ergens nog een SMS- of voicepad dat “voorlopig” blijft bestaan.
Dat voelt vaak prima tot iemand vraagt waarom het zo is. Dan blijkt dat het antwoord niet altijd in een document staat, maar in hoofden, Slack-threads of halfvergeten ticketnotities.
Voor leiders is dat geen technisch detail. Het is een eigenaarschapsvraag. Als het standaard inlogpad verandert, wie weet dan wat er nu echt gebeurt? Wie kan uitleggen waarom een uitzondering bestaat? En wie beslist wanneer die uitzondering weg mag?
Microsofts wijziging als aanleiding, niet als alarm
Microsoft maakt passkeys in Entra ID nadrukkelijker de voorkeursroute voor inloggen en werkt tegelijk aan een nieuw model voor SMS- en voice-authenticatie. Dat is op zichzelf geen grootse dramatische breuk. Het is vooral een signaal dat het landschap beweegt.
En dat is precies het soort signaal waar volwassen teams rustig op kunnen reageren. Niet door direct alles open te trekken. Wel door te kijken waar het eigen bewijs dun is.
Want zodra een leverancier de standaard verscherpt, komt de echte vraag boven tafel: hebben wij door wie van welke methode gebruikmaakt, of denken we dat vooral?
Die vraag klinkt klein. In een groeiend team is hij dat zelden.
Kies één stroom en maak zichtbaar wat default is
De meest bruikbare eerste stap is verrassend beperkt: neem één gebruikersgroep of één applicatiestroom en breng het in kaart.
Niet voor het hele domein. Niet voor alle identiteiten, alle tenants en alle legacy-varianten tegelijk.
Kies bijvoorbeeld je interne engineers, of juist je supportteam, of één kritieke SaaS-koppeling. Kijk dan heel concreet naar drie dingen:
Welke sign-in methode is daar werkelijk de default?
Welke uitzonderingen bestaan er nog?
Wie is eigenaar van de beslissing als de situatie moet veranderen?
Dat is geen uitgebreide audit. Het is een bewijsritueel. Klein genoeg om deze week te doen, scherp genoeg om iets bloot te leggen.
Vaak zie je dan dat het probleem niet zit in een tekort aan tooling. Het zit in het ontbreken van een duidelijk referentiepunt. Er zijn meerdere routes “mogelijk”, maar niemand kan meteen aanwijzen welke route bedoeld is voor de standaard gebruiker.
Waarom dit Blue Ocean is voor securityleiders
Veel securitydiscussies glijden snel naar breedte. Meer beleid, meer tooling, meer controlelagen, meer projectstructuur. Dat klinkt volwassen, maar het kost vaak vooral energie zonder het eigenaarschap helderder te maken.
De Blue Ocean-beweging hier is juist omgekeerd: eerst precisie, dan pas verbreding.
Als je één stroom kiest, krijg je sneller antwoord op vragen als:
Waar zit de frictie echt?
Welke uitzondering bestaat nog uit noodzaak, en welke uit gewoonte?
Wie moet er eigenlijk beslissen, en wie levert het bewijs?
Dat levert rust op, juist omdat je niet meteen alles hoeft op te lossen. Je maakt een proportionele beslissing in plaats van een reflex. En dat past beter bij softwareleiderschap dan een reflexmatige “laten we het hele toegangslandschap maar eens doornemen”.
Ook intern is dat gezonder. Teams voelen het verschil tussen een abstract security-initiatief en een concreet vraagstuk met eigenaar. Het eerste trekt iedereen een beetje in de mist. Het tweede geeft houvast: hier kijken we, dit weten we al, dit nog niet.
De vraag die vaak ontbreekt: wie draagt het bewijs?
In veel organisaties wordt de vraag nog gesteld als: “Is dit veilig genoeg?”
Maar dat is vaak te breed om iets mee te doen.
Een beter vertrekpunt is: wie draagt het bewijs dat dit ons standaard pad is? Wie houdt de uitzonderingen bij? Wie merkt het als een nieuwe methode de oude stilletjes vervangt?
Die formulering is nuchterder. En bruikbaarder. Ze voorkomt dat security een mening wordt. Je zoekt niet naar gelijk. Je zoekt naar eigenaarschap over een concrete stroom.
Dat is ook waarom passkeys als default zo interessant zijn als aanleiding. Niet omdat passkeys alleen het antwoord zijn, maar omdat de verandering je dwingt om opnieuw te kijken naar wat je organisatie als vanzelfsprekend beschouwt.
Soms blijkt dat de standaard prima is. Soms blijkt dat een uitzondering ongemerkt de norm is geworden. Beide uitkomsten zijn nuttig, zolang iemand ze kan onderbouwen.
Een kleine route naar rust en helderheid
Als je dit morgen wilt oppakken, houd het dan klein.
Pak één loginpad. Pak één groep. Pak één eigenaar.
Leg vast wat de default is, welke uitzondering blijft bestaan, en wat het signaal is dat je opnieuw moet kijken. Dat kan in een kort document, een diagram op één pagina of gewoon in een besluitnotitie die je later terug kunt vinden.
Daarna heb je genoeg om verder te praten. Niet vanuit aanname, maar vanuit bewijs.
Als je wilt zien waar in jouw organisatie bewijs, eigenaarschap en prioriteit als eerste uit elkaar lopen, is Pathfinder Signal daarvoor bedoeld: een korte route om één relevant signaal scherp te krijgen, zonder meteen een groot traject te openen.
En misschien is dat precies wat deze update van Entra ID vraagt: niet meer activiteit, maar een helderder antwoord op de vraag wie het inlogpad eigenlijk bewaakt.