Meervoudige verificatie, vaak MFA genoemd, is een tweede controle bovenop een wachtwoord: een code uit een app, een sms of een fysieke sleutel. De vraag of dit verplicht is voor een softwarebedrijf valt niet met één ja of nee te beantwoorden, want de NIS2-richtlijn schrijft geen specifieke techniek voor. Artikel 21 verplicht organisaties die onder de zorgplicht vallen wel tot passende maatregelen voor toegangsbeveiling en meervoudige authenticatie, en toezichthouders kijken daarbij naar waar het risico het grootst is.
Voor een softwarebedrijf zijn dat in de praktijk twee heel verschillende plekken: de ontwikkelstraat waarmee u zelf werkt, en de software die u aan klanten oplevert. Beide vragen om een eigen afweging, en die afweging is niet overal even streng.
Twee plekken waar meervoudige verificatie een rol speelt
De eerste plek is intern: de omgeving waarin uw ontwikkelaars werken. Broncode, de ontwikkelstraat, cloudconsoles en de systemen waarmee u naar productie uitrolt. De tweede plek zit in het product zelf: als de software die u bouwt of levert een inlogscherm heeft, is meervoudige verificatie ook daar een onderwerp, zowel voor uw eigen gebruikers als voor de eindgebruikers van uw klant. Een securityvragenlijst van een opdrachtgever vraagt bijna altijd naar allebei, vaak in aparte vragen die net anders geformuleerd zijn dan u zou verwachten.
Bij de toegang tot uw ontwikkelstraat
Hier ligt de sterkste verwachting. Wie bij de broncode kan, wie kan deployen naar productie, en wie beheerdersrechten heeft op de cloudomgeving, vormt het grootste risico als een wachtwoord alleen wordt gestolen of hergebruikt. Voor deze accounts geldt meervoudige verificatie in vrijwel elk beveiligingskader als een basismaatregel, en het is ook wat toezichthouders en klanten als eerste verwachten. Versiebeheer, de ontwikkelstraat zelf, en met name elk account met rechten om code naar productie te brengen, horen in de praktijk zonder uitzondering achter een tweede stap.
Daarbij hoort ook een blik op wie die toegang eigenlijk nog nodig heeft. Een dossier waarin per systeem staat wie er bij mag en waarom, maakt het makkelijker om deze vraag in een vragenlijst met een concreet antwoord te beantwoorden in plaats van met een aanname. hoe toegangsbeheer en meervoudige verificatie per onderwerp worden uitgelegd geeft daar een startpunt voor.
Bij de software die u oplevert
Het tweede vlak is de software zelf. Als uw product een inlogfunctie heeft, komt de vraag of u meervoudige verificatie aanbiedt bijna altijd terug in een securityvragenlijst, en soms zelfs als contracteis. Dat is een andere afweging dan bij uw eigen ontwikkelstraat: hier gaat het niet om wat u zelf gebruikt, maar om wat u aan uw klant levert. Een opdrachtgever die zelf onder de zorgplicht valt, moet volgens artikel 21 ook zijn keten beoordelen, en de vraag of uw product sterke authenticatie ondersteunt hoort daarbij.
Het antwoord hoeft niet te zijn dat het overal verplicht staat aangezet. Vaak volstaat het om te laten zien dat de mogelijkheid bestaat, dat gebruikers ertoe worden aangespoord, en dat u een plan heeft om het uit te breiden waar het risico dat rechtvaardigt.
Waar het minder vanzelfsprekend is
Niet elk account of elke omgeving vraagt om dezelfde zwaarte. Een testomgeving zonder echte klantgegevens, een intern documentatiesysteem met alleen leesrechten, of een los hulpmiddel dat één ontwikkelaar incidenteel gebruikt, wegen anders dan een account met productietoegang. De zorgplicht vraagt om maatregelen die passen bij de risico's, niet om overal dezelfde zware laag toe te voegen. Toezichthouders beoordelen dit op basis van proportionaliteit, en dat betekent dat een onderbouwde keuze om ergens geen meervoudige verificatie toe te passen net zo goed onderdeel van een dossier kan zijn als de plekken waar het wel staat.
De onderbouwing is hier het belangrijkste woord. Een keuze zonder toelichting oogt in een vragenlijst al snel als een omissie, terwijl dezelfde keuze mét een korte reden vaak precies het antwoord is waar een opdrachtgever naar zoekt.
Wat dit betekent voor het gesprek met een opdrachtgever
Een opdrachtgever die een vragenlijst stuurt, wil meestal niet weten of u aan elke letter voldoet, maar of u weet waar uw risico's zitten en daar bewust mee omgaat. Voor meervoudige verificatie betekent dat: kunnen laten zien wat er staat op de ontwikkelstraat, wat er staat in het product, en waarom de rest anders is ingericht. Wie dat per systeem heeft vastgelegd met een status en een eigenaar, hoeft de vraag niet opnieuw uit te zoeken zodra de volgende vragenlijst binnenkomt.
Of en hoe dit voor uw eigen organisatie precies uitpakt, hangt af van uw rol in de keten en van wat uw klanten specifiek vragen; raadpleeg bij twijfel de tekst van de richtlijn zelf of een adviseur. Wilt u eerst weten waar u staat, dan geeft de gratis check in een paar vragen een eerste indicatie, en een toelichting op waar de informatie vandaan komt laat zien hoe die indicatie tot stand komt.
Wilt u breder lezen hoe dit onderwerp samenhangt met de andere maatregelen uit de zorgplicht, dan vindt u dat terug in het overzicht van onderwerpen per situatie. De quick-scan en de kennisbank zijn vrij toegankelijk, zonder dat u daarvoor een account hoeft aan te maken.