applatenmaken.com/kennisbank/inloggen
Inloggen in uw software: DigiD, eHerkenning en de nieuwe eisen
De Rijksoverheid heeft deze week de soevereiniteitseisen voor inlogmiddelen aangescherpt. Voor wie software laat bouwen is dat een goed moment om de vraag te stellen die vaak pas aan het eind opkomt: hoe logt iemand straks in, welk zekerheidsniveau is daarvoor nodig, en wie kan er meekijken bij dat inlogproces.
Waarom dit vooraan in uw project hoort
Inloggen wordt in veel projecten als een technisch detail behandeld: er komt een schermpje met een gebruikersnaam en een wachtwoord, en daar is het mee klaar. Dat werkt zolang uw gebruikers medewerkers zijn. Zodra burgers, cliënten, patiënten of bedrijven moeten inloggen, verandert het van een detail in een ontwerpbeslissing met gevolgen voor uw hele planning.
De reden is dat aansluiting op een erkend inlogmiddel geen instelling is maar een traject. Er zit een aanvraag in, een beoordeling, een aansluittest en meestal een verplichte periodieke controle. Dat kunt u niet in de laatste weken van een project regelen, en het is de meest voorkomende oorzaak van uitstel bij software die met persoonsgegevens werkt.
Daar komt bij dat de eisen bewegen. De Rijksoverheid scherpt de soevereiniteitseisen voor inlogmiddelen aan, en die beweging past in een breder patroon waarin overheden vastleggen dat kritieke voorzieningen niet onder buitenlandse zeggenschap mogen vallen. Wat daarvan geldt voor uw situatie is een vraag om vroeg te stellen.
- DigiD
- Voor burgers die inloggen bij overheid, zorg en aangewezen andere organisaties.
- eHerkenning
- Voor bedrijven en organisaties die namens de rechtspersoon handelen, met een machtigingsstructuur.
- eIDAS
- Voor Europese burgers en bedrijven die met een middel uit een andere lidstaat inloggen.
- Eigen accountbeheer
- Voor medewerkers en voor situaties waarin geen erkend middel is voorgeschreven.
- Wat verandert
- De eisen aan onder wiens zeggenschap zo'n voorziening staat, worden aangescherpt.
Welk niveau van zekerheid heeft u nodig
Niet elke handeling vraagt dezelfde zekerheid over wie er inlogt. Het niveau bepaalt welk middel u nodig heeft en wat de aansluiting kost aan tijd en geld, dus het is de eerste vraag die u beantwoordt.
| Wat de gebruiker doet | Welk niveau past daarbij | Waar u op let |
|---|---|---|
| Openbare informatie bekijken | !Geen inlog nodig | !Dat u niet uit gewoonte een drempel opwerpt die niets toevoegt |
| Eigen gegevens inzien | ✓Een middel met tweestapsverificatie | !Dat het niveau past bij hoe gevoelig die gegevens zijn |
| Medische of financiële gegevens inzien | ✓Een hoger zekerheidsniveau | !Dat het niveau is vastgesteld door wie daarover gaat, niet door de bouwer |
| Namens een bedrijf handelen | ✓eHerkenning met de juiste machtiging | !Dat de machtigingsstructuur klopt: wie mag wat namens wie |
| Namens iemand anders handelen | ✓Een machtigingsvoorziening | !Dat vertegenwoordiging expliciet is geregeld en niet via gedeelde accounts loopt |
De laatste regel is in de praktijk het lastigst. Vertegenwoordiging komt overal voor: een mantelzorger, een boekhouder, een ouder, een bewindvoerder. Wordt dat niet ontworpen, dan lossen gebruikers het op door hun inloggegevens te delen, en dan klopt uw hele registratie niet meer.
Wat u vastlegt in de opdracht
Aansluiten op een erkend middel raakt de planning, de architectuur en het budget. Deze punten horen daarom in het programma van eisen en niet in een gesprek halverwege de bouw.
De laatste vraag wordt vrijwel nooit gesteld. Ligt een landelijke voorziening eruit, dan ligt uw dienst eruit, tenzij u daar iets voor heeft bedacht.
Neem hierin ook toegankelijkheid mee. Een inlogproces dat alleen werkt met een smartphone en een goed werkende camera, sluit een deel van uw gebruikers uit. Sinds 28 juni 2025 is toegankelijkheid voor veel digitale diensten bovendien een wettelijke eis; zie toegankelijkheid is al verplicht voor uw software.
De soevereiniteitskant
De aanscherping van deze week gaat over de vraag onder wiens zeggenschap een inlogvoorziening staat. Voor u als afnemer van maatwerksoftware is dat zelden een directe eis, maar het werkt wel door: als uw opdrachtgever of uw toezichthouder die eis stelt, komt hij bij u terecht.
Praktisch betekent het dat u moet weten welke partijen er in uw inlogketen zitten. Dat is meestal meer dan één: de aanbieder van het middel, een tussenpartij die de aansluiting verzorgt, en soms nog een dienst die de sessie beheert. Bij elk van die schakels is de vraag onder welke rechtsmacht die partij valt, en dat is een andere vraag dan waar de servers staan; zie soevereiniteit is geen locatie maar rechtsmacht.
Wat u in elk geval kunt doen, is voorkomen dat u vastzit. Bouw de koppeling met het inlogmiddel achter één laag in uw software, zodat u er later een ander middel naast of voor in de plaats kunt zetten. Dat is een ontwerpkeuze die niets extra kost tijdens de bouw en die u de vrijheid geeft om mee te bewegen als de eisen weer veranderen. Voor uw specifieke verplichtingen legt u de vraag voor aan een jurist; deze pagina is uitleg en geen juridisch advies.
Veelgestelde vragen
Wanneer heb ik DigiD nodig?
Wanneer burgers bij uw dienst inloggen en uw organisatie tot de aangewezen groep behoort, zoals overheid, zorg en pensioenuitvoering. Of u in aanmerking komt en welk zekerheidsniveau nodig is, wordt niet door uw bouwer bepaald maar volgt uit uw sector en uit wat gebruikers in uw dienst kunnen doen.
Wat is het verschil tussen DigiD en eHerkenning?
DigiD is voor burgers die als persoon inloggen. eHerkenning is voor mensen die namens een bedrijf of organisatie handelen, met een machtigingsstructuur die vastlegt wie wat namens wie mag doen. Levert uw dienst aan beide groepen, dan heeft u ze allebei nodig en dus twee trajecten.
Hoe lang duurt zo'n aansluiting?
Langer dan een technische koppeling doet vermoeden, want er zit een aanvraag, een beoordeling en een aansluittest in, plus meestal een periodieke controle daarna. Dat is precies waarom dit vooraan in uw project hoort: het is de meest voorkomende oorzaak van uitstel bij software die met persoonsgegevens werkt.
Wie bepaalt welk zekerheidsniveau ik nodig heb?
Niet uw softwareleverancier. Het niveau volgt uit wat gebruikers in uw dienst kunnen doen en hoe gevoelig die gegevens zijn, en dat is een beoordeling die bij uw organisatie ligt, vaak samen met uw functionaris gegevensbescherming of een jurist. Uw bouwer voert het uit en adviseert over de gevolgen.
Hoe regel ik dat iemand namens een ander kan handelen?
Met een expliciete machtigingsstructuur, en dat is een ontwerpvraag die vroeg gesteld moet worden. Doet u het niet, dan lossen gebruikers het zelf op door inloggegevens te delen: een mantelzorger die inlogt met de gegevens van een cliënt, een boekhouder met die van een ondernemer. Vanaf dat moment klopt uw registratie van wie wat deed niet meer.
Wat als de landelijke inlogvoorziening uitvalt?
Dan ligt uw dienst eruit, tenzij u daar iets voor heeft bedacht. Deze vraag wordt vrijwel nooit gesteld en is toch reëel. Bespreek vooraf of er een noodroute nodig is, bijvoorbeeld een alternatieve identificatie voor kritieke handelingen, of dat een tijdelijke onderbreking acceptabel is.
Wat betekenen de aangescherpte soevereiniteitseisen voor mij?
Als afnemer van maatwerksoftware zelden een directe eis, maar hij werkt door via uw opdrachtgevers en toezichthouders. Praktisch betekent het dat u moet weten welke partijen er in uw inlogketen zitten en onder welke rechtsmacht die vallen. Dat is een andere vraag dan waar de servers staan.
Hoe voorkom ik dat ik vastzit aan één inlogmiddel?
Door de koppeling achter één laag in uw software te bouwen in plaats van hem overal in te weven. Dan is er een ander middel naast of in plaats van zetten een beheerhandeling in plaats van een verbouwing. Dat kost tijdens de bouw niets extra en geeft u ruimte als de eisen opnieuw veranderen.