Blog

Self-Service Password Reset veilig invoeren in Microsoft Entra ID

15 juli 2026

Laat medewerkers veilig zelf hun wachtwoord herstellen met SSPR, sterke verificatiemethoden, een pilot en een controleerbaar noodproces.

Een vergeten wachtwoord kost vaak meer tijd dan de reset zelf. De medewerker kan niet verder, de servicedesk moet de identiteit controleren en meerdere apps vragen daarna opnieuw om aanmelding. Self-Service Password Reset, meestal afgekort tot SSPR, laat medewerkers hun Microsoft 365-wachtwoord zelf herstellen zonder dat een beheerder het wachtwoord hoeft te zien of handmatig hoeft te wijzigen.

Dat verlaagt het aantal routinematige supportverzoeken, maar alleen als de herstelroute vooraf goed is ingericht. Een gebruiker zonder geregistreerde methode kan zichzelf niet herstellen. Een oude telefoon of een zwakke verificatiemethode maakt het proces onbetrouwbaar. En in een hybride omgeving moet een cloudreset ook teruggeschreven kunnen worden naar de lokale Active Directory.

Deze gids behandelt SSPR daarom als een beheerproces, niet als één schakelaar. Je leest hoe je de doelgroep, verificatiemethoden, registratie, meldingen, pilot, support en periodieke controle op elkaar laat aansluiten. Wil je weten of SSPR, MFA en Conditional Access samen een veilige herstelroute vormen? Laat je Microsoft 365-omgeving beoordelen met de IT-scan.

Wat SSPR wel en niet doet

SSPR geeft een gebruiker twee belangrijke mogelijkheden: een vergeten wachtwoord opnieuw instellen en, als de configuratie dit ondersteunt, een vergrendeld account zelf ontgrendelen. De gebruiker begint via de officiële Microsoft-herstelpagina, voert zijn account in en bewijst zijn identiteit met de geregistreerde methoden die het organisatiebeleid toestaat.

SSPR is niet hetzelfde als multifactorauthenticatie. MFA controleert een aanmelding met een extra factor. SSPR gebruikt beveiligingsinformatie om een wachtwoord te herstellen of een account te ontgrendelen. Microsoft combineert de registratie van beveiligingsinformatie voor MFA en SSPR, zodat een medewerker methoden centraal kan registreren en beheren. De gids MFA instellen voor je organisatie helpt om de normale aanmeldbeveiliging naast de herstelroute in te richten.

Een geslaagde SSPR-inrichting bestaat uit meer dan een werkende resetpagina:

  • de juiste gebruikers zijn ingeschakeld;
  • iedere gebruiker heeft voldoende toegestane methoden geregistreerd;
  • de organisatie gebruikt de centrale Authentication methods policy;
  • medewerkers herkennen normale en verdachte meldingen;
  • support heeft een betrouwbare noodroute voor mensen die geen methode meer kunnen gebruiken;
  • hybride accounts zijn getest met password writeback;
  • beheer controleert registratie, resetactiviteit en wijzigingen van methoden.

De belangrijkste wijziging: beheer methoden centraal

Microsoft heeft het beheer van authenticatiemethoden uit de oude, losse MFA- en SSPR-beleidsinstellingen uitgefaseerd. Sinds 30 september 2025 kunnen organisaties verificatiemethoden niet meer via die legacy policies beheren. De centrale Authentication methods policy in Microsoft Entra ID is de actuele beheerplek.

Dat onderscheid is belangrijk bij oudere handleidingen. SSPR zelf wordt nog steeds voor None, Selected of All users geactiveerd in het gedeelte Password reset. Welke authenticatiemethoden beschikbaar zijn, beheer je centraal in de Authentication methods policy. Controleer dus niet alleen of SSPR aanstaat, maar ook of de migratiestatus van authenticatiemethoden voltooid is en de juiste doelgroepen onder het centrale beleid vallen.

Maak vóór een wijziging een eenvoudige inventaris:

Onderdeel Controle
SSPR-doelgroep Staat SSPR op Selected voor een pilot of op All na een afgeronde uitrol?
Authentication methods policy Zijn methoden centraal ingeschakeld en aan de bedoelde groepen gekoppeld?
Registratie Hebben gebruikers genoeg methoden voor het vereiste aantal bewijzen?
Meldingen Krijgen gebruikers en beheerders de afgesproken resetmeldingen?
Supportlink Verwijst Contact your administrator naar een actueel supportkanaal?
Hybride identiteit Is password writeback ingericht en daadwerkelijk getest?
Noodtoegang Zijn beheerders- en noodaccounts apart beoordeeld?

Pas methoden niet onverwacht aan. Als je twee bewijzen verplicht en een gebruiker heeft maar één geschikte methode geregistreerd, kan die gebruiker SSPR niet uitvoeren. Hetzelfde probleem ontstaat wanneer je een bestaande methode uitschakelt zonder eerst te controleren hoeveel medewerkers daarvan afhankelijk zijn.

Kies verificatiemethoden op risico en uitval

Microsoft ondersteunt voor SSPR meerdere authenticatiemethoden, waaronder Microsoft Authenticator, software- en hardware-OATH-tokens, sms, telefonie en e-mail. De precieze inzet hangt af van tenantbeleid, accounttype en Microsoft-ondersteuning. Niet iedere methode is even sterk of voor iedere medewerker even bruikbaar.

Methode Sterkte Operationeel aandachtspunt
Microsoft Authenticator Sterke en bekende gebruikerservaring na registratie Maak een veilig proces voor toestelverlies en toestelwissel
Software- of hardware-OATH Bruikbaar als app of apart token nodig is Beheer uitgifte, verlies, vervanging en intrekking
Sms of telefoon Breed beschikbaar en eenvoudig uit te leggen Telefoonnummer kan verouderd of overgenomen zijn
Alternatieve e-mail Praktisch als reserve voor sommige gebruikers Gebruik alleen een persoonlijk, actueel en goed beveiligd adres

Beveiligingsvragen zijn geen goede standaard voor zakelijke accounts. Antwoorden kunnen bekend, hergebruikt of online te vinden zijn. Kies liever methoden die aantoonbaar bij de medewerker horen en die je bij verlies kunt intrekken.

Microsoft laat organisaties één of twee methoden vereisen voor een reset. Twee bewijzen geven meer zekerheid, maar verhogen ook de kans dat iemand bij verlies van een telefoon niet genoeg methoden overhoudt. Microsoft adviseert gebruikers meerdere methoden te laten registreren, zodat er een alternatief bestaat wanneer één methode niet beschikbaar is.

Voor veel MKB-organisaties is dit een werkbare aanpak:

  1. bied minimaal twee geschikte methoden aan;
  2. laat medewerkers meer methoden registreren dan strikt noodzakelijk;
  3. behandel beheerdersaccounts strenger dan gewone gebruikers;
  4. bied een vooraf vastgelegde route voor medewerkers zonder geschikte telefoon;
  5. wijzig het aantal vereiste bewijzen pas nadat de registratiegraad is gecontroleerd.

Begin met een representatieve pilot

Microsoft Entra ID kan SSPR activeren voor None, Selected of All users. Gebruik Selected voor een pilot. Volgens Microsoft kan in het Entra-beheercentrum één groep rechtstreeks als geselecteerde SSPR-groep worden aangewezen; geneste groepen worden voor een bredere uitrol ondersteund. Houd de pilotstructuur eenvoudig, zodat duidelijk blijft wie in scope is.

Een goede testgroep bevat niet alleen IT-medewerkers. Neem bijvoorbeeld op:

  • iemand met een zakelijke smartphone;
  • iemand zonder zakelijke smartphone;
  • een medewerker die veel op afstand werkt;
  • iemand op kantoor met een hybride Windows-account;
  • een medewerker van administratie of verkoop met bedrijfskritieke apps;
  • een beheerder die logs, meldingen en supportvragen beoordeelt.

Gebruik een normaal niet-beheerdersaccount voor de functionele test. Microsoft past voor accounts met beheerdersrollen een strengere resetpolicy toe. Daardoor kan een test met alleen een beheerder een andere ervaring geven dan de uitrol naar gewone medewerkers.

Leg vooraf vast wat een geslaagde pilot betekent. Alleen kunnen resetten is niet genoeg. Een bruikbaar acceptatiecriterium is bijvoorbeeld: alle pilotdeelnemers hebben voldoende methoden, voeren één gecontroleerde reset uit, ontvangen de verwachte melding, kunnen daarna weer bij hun werkapps en weten wat ze moeten doen bij een verloren telefoon.

Richt registratie in vóórdat iemand vastloopt

Een gebruiker kan SSPR pas gebruiken als er voldoende geschikte beveiligingsinformatie beschikbaar is. Laat medewerkers daarom tijdens de uitrol registreren, niet pas wanneer zij hun wachtwoord zijn vergeten.

Microsoft gebruikt gecombineerde registratie voor MFA en SSPR. Medewerkers kunnen hun beveiligingsinformatie beheren via de centrale registratie-ervaring. Organisaties kunnen gebruikers tijdens een interactieve aanmelding laten registreren en later laten bevestigen of de gegevens nog kloppen. Microsoft documenteert voor herbevestiging een bereik van 0 tot 730 dagen, waarbij 0 betekent dat gebruikers niet periodiek om bevestiging worden gevraagd.

Kies geen interval zonder beheerreden. Een halfjaarlijkse bevestiging kan voor veel organisaties een bruikbaar begin zijn, maar controleer ook bij gebeurtenissen die niet op dat interval wachten:

  • uitgifte of vervanging van een telefoon;
  • wijziging van een telefoonnummer;
  • langdurig verlof;
  • functiewijziging;
  • vertrek uit dienst;
  • melding van een onbekende authenticatiemethode;
  • beveiligingsincident rond het account.

Een registratiecampagne moet kort en concreet zijn. Vertel medewerkers waarom registratie nodig is, welke methoden zijn toegestaan, waar zij hun gegevens beheren, hoe zij een reset starten en waar zij hulp krijgen. Vermeld ook dat een onverwachte melding over een wachtwoordreset of gewijzigde methode direct gemeld moet worden.

Conditional Access kan de gecombineerde registratie aanvullend beveiligen. Microsoft ondersteunt daarvoor de user action Register security information. Een organisatie kan bijvoorbeeld aanvullende verificatie vereisen wanneer iemand buiten een vertrouwde context beveiligingsinformatie registreert. Ontwerp zo'n policy zorgvuldig, sluit noodaccounts correct uit en gebruik eerst report-only waar dat passend is. De gids Conditional Access: drie basisregels beschrijft de veilige pilotdiscipline voor toegangsbeleid.

Configureer meldingen en een echte supportuitgang

SSPR kan gebruikers per e-mail informeren wanneer hun wachtwoord via SSPR is hersteld. Beheer kan ook instellen dat beheerders een melding krijgen wanneer een ander beheerdersaccount SSPR gebruikt. Zet deze meldingen bewust aan en koppel ze aan een opvolgproces.

Een melding heeft pas waarde als de ontvanger weet wat hij moet doen. Gebruik bijvoorbeeld deze instructie:

  • heb je de reset zelf uitgevoerd, controleer dan of je weer kunt aanmelden;
  • heb je de reset niet uitgevoerd, neem direct contact op met support;
  • keur geen nieuwe Authenticator-melding goed om de resetmelding te onderzoeken;
  • wijzig bij vermoedelijk misbruik niet alleen het wachtwoord, maar laat ook sessies, methoden en aanmeldingen controleren.

Microsoft laat ook de link Contact your administrator aanpassen. Vul daar een actueel e-mailadres of een support-URL in. Een niet-bestaande mailbox of algemene homepage helpt een geblokkeerde medewerker niet. Test de link vanaf de werkelijke herstelervaring en controleer of support buiten kantooruren bereikbaar moet zijn.

Test de volledige gebruikersreis

Gebruik voor de pilot de officiële Microsoft-routes voor registratie en herstel. Open de test in een privévenster, zodat een bestaande sessie de uitkomst niet maskeert. Voer de test uit met een niet-beheerdersaccount dat in de geselecteerde groep zit.

Controleer tijdens de registratie en reset:

  1. verschijnt de juiste organisatie en gebruikerservaring;
  2. kan de gebruiker alleen methoden kiezen die het beleid toestaat;
  3. heeft de gebruiker genoeg methoden voor het vereiste aantal bewijzen;
  4. werkt herstel vanaf een beheerd en een extern netwerk;
  5. ontvangt de gebruiker de verwachte resetmelding;
  6. is de activiteit zichtbaar in de relevante rapportage;
  7. werken Outlook, Teams, OneDrive en andere bedrijfskritieke apps na de reset;
  8. weet de gebruiker waar hij hulp krijgt als één methode ontbreekt.

Verander tijdens de pilot doelbewust één veilige randvoorwaarde. Laat bijvoorbeeld een testgebruiker met toestemming één reservemethode verwijderen en controleer of support begrijpt waarom de reset daarna wel of niet werkt. Doe dit niet met productieaccounts die op dat moment bedrijfskritisch zijn.

Maak van de uitkomst een korte acceptatielijst met datum, accounttype, gebruikte methoden, resetresultaat, meldingsresultaat en eventuele heraanmelding per belangrijke app. Zo kan beheer aantonen dat de route echt is getest.

Hybride omgeving: controleer password writeback

Bij cloudaccounts verandert SSPR het wachtwoord in Microsoft Entra ID. Bij gebruikers van een lokale Active Directory kan password writeback nodig zijn om de wijziging terug te schrijven naar de on-premises directory. Zonder werkende writeback kan Microsoft vaststellen dat het wachtwoord lokaal wordt beheerd en de gebruiker alsnog naar de beheerder sturen.

Microsoft ondersteunt writeback via Microsoft Entra Connect Sync en via Cloud Sync, met eigen vereisten en ondersteunde scenario's. Voor Cloud Sync noemt Microsoft onder meer een Entra ID P1- of proeflicentie, een Hybrid Identity Administrator en een geschikte versie van de provisioning agent. De benodigde rechten in Active Directory moeten op de betrokken gebruikersobjecten doorwerken.

Test in een hybride omgeving minimaal:

  • een gewone SSPR-reset door een eindgebruiker;
  • aanmelden op een cloudapp met het nieuwe wachtwoord;
  • aanmelden op een on-premises voorziening met hetzelfde nieuwe wachtwoord;
  • een accountontgrendeling als die optie is ingeschakeld;
  • een gebruiker uit iedere relevante directoryscope;
  • een account waarop rechtenovererving afwijkend is ingericht.

Ga niet uit van een groene configuratiepagina als bewijs. De keten is pas geslaagd wanneer het nieuwe wachtwoord aantoonbaar in beide omgevingen werkt en de activiteit in de verwachte logs verschijnt.

Ontwerp het noodproces vóór de uitrol

Zelfservice dekt niet ieder scenario. Een telefoon kan verloren zijn, een nummer kan zijn gewijzigd en een medewerker kan alle geregistreerde methoden tegelijk kwijt zijn. Dan moet support helpen zonder de herstelroute tot beveiligingslek te maken.

Leg een beslisroute vast:

  1. registreer wie hulp vraagt en om welk account het gaat;
  2. verifieer de identiteit via vooraf goedgekeurde, onafhankelijke gegevens;
  3. gebruik niet alleen naam, functie, personeelsnummer of informatie uit sociale media;
  4. laat bij verhoogd risico een manager of proceseigenaar de zakelijke context bevestigen;
  5. verwijder of blokkeer de verloren methode waar nodig;
  6. herstel toegang met de minst ruime tijdelijke maatregel;
  7. laat de medewerker direct nieuwe methoden registreren en testen;
  8. controleer onbekende methoden, verdachte aanmeldingen, actieve sessies en mailboxregels;
  9. leg uitvoerder, tijdstip, bewijs en resultaat vast.

Bij een reguliere toestelwissel voegt de medewerker idealiter eerst de nieuwe methode toe en test die voordat de oude wordt verwijderd. Bij onverwacht verlies hoort de gids MFA-app kwijt: herstelprocedure bij het supportdraaiboek. Een onverwachte methode of resetmelding kan op accountmisbruik wijzen en vraagt dan om incidentrespons, niet alleen om een nieuwe reset.

Meet of SSPR echt supportwerk wegneemt

SSPR is bedoeld om uitval en routinematig servicedeskwerk te verminderen. Meet daarom niet alleen of de functie ingeschakeld is. Gebruik operationele indicatoren:

Indicator Waarom deze telt
Registratiegraad Zonder voldoende methoden is de gebruiker niet zelfredzaam
Geslaagde resets Laat zien of de herstelroute werkelijk werkt
Mislukte resets Kan wijzen op ontbrekende methoden, scope- of writebackproblemen
Handmatige wachtwoordresets Laat zien hoeveel werk nog bij support blijft
Gemiddelde hersteltijd Maakt de impact op productiviteit zichtbaar
Onverwachte resetmeldingen Kan een beveiligingssignaal zijn
Verouderde of verwijderde methoden Geeft inzicht in beheerkwaliteit
Herhaalde hulp per afdeling Wijst op gebrekkige communicatie of apparaatbeleid

Controleer de eerste weken na uitrol vaker en ga daarna over op een vast beheerinterval. Een praktische cyclus is maandelijks de registratie- en resettrends bekijken, per kwartaal de doelgroepen en methoden beoordelen en jaarlijks met meerdere gebruikers een volledige hersteltest uitvoeren. Herhaal een test ook na belangrijke wijzigingen in Conditional Access, authenticatiemethoden, directorysync of licenties.

Veelgemaakte fouten

De oude SSPR-methodenpagina als bron blijven gebruiken

Sinds 30 september 2025 worden methoden niet meer via de legacy MFA- en SSPR-policies beheerd. Controleer de centrale Authentication methods policy en de migratiestatus.

Iedereen tegelijk activeren

Zonder pilot, registratiecampagne en supportprocedure ontdekken medewerkers problemen pas wanneer zij al buitengesloten zijn.

Twee bewijzen eisen terwijl gebruikers er maar één hebben

Een strengere instelling helpt niet als medewerkers daardoor geen reset meer kunnen uitvoeren. Meet eerst de registratiegraad en communiceer de wijziging.

Alleen sms als praktisch antwoord kiezen

Sms is toegankelijk, maar een telefoonnummer kan veranderen of worden overgenomen. Bied meerdere geschikte methoden en een veilige reserveroute.

Beheerders en gewone gebruikers hetzelfde behandelen

Microsoft hanteert voor beheerdersaccounts strengere resetvoorwaarden. Beoordeel privileged accounts en noodaccounts apart en test met een normaal gebruikersaccount.

Password writeback aannemen zonder ketentest

Een ingeschakelde optie bewijst niet dat rechten, agent, scope en lokale wachtwoordpolicy goed samenwerken. Test een echte hybride gebruiker in cloud en on-premises apps.

Support laat identiteit op zwakke gegevens rusten

Naam, functie of personeelsnummer is vaak vindbaar. Gebruik een vooraf goedgekeurd verificatieproces en leg de beslissing vast.

Na herstel alleen het wachtwoord controleren

Controleer ook onbekende authenticatiemethoden, aanmeldingen en sessies. Bij vermoedelijk misbruik kan een aanvaller anders toegang houden.

Veelgestelde vragen

Is SSPR hetzelfde als MFA?

Nee. MFA beveiligt een aanmelding met extra verificatie. SSPR controleert de identiteit voordat een gebruiker een wachtwoord herstelt of een account ontgrendelt. De registratie van beveiligingsinformatie is wel gecombineerd.

Welke licentie is nodig?

Microsoft noemt voor password reset minimaal Microsoft Entra ID P1 in de actuele SSPR-tutorial. Licentievoorwaarden verschillen per scenario, waaronder cloud-only en hybride writeback. Controleer daarom de actuele Microsoft-licentiepagina voor de accounts en functies die je gebruikt.

Moet iedere medewerker twee methoden gebruiken?

De organisatie kan voor SSPR één of twee bewijzen vereisen. Microsoft adviseert meerdere methoden te registreren voor flexibiliteit. Kies de eis op basis van risico, gebruikersgroep en de kwaliteit van het noodproces.

Kan Microsoft Authenticator de enige beschikbare methode zijn?

Dat hangt af van het aantal vereiste bewijzen en de beleidsconfiguratie. Microsoft waarschuwt dat Authenticator in bepaalde SSPR-configuraties niet als enige beschikbare methode kan worden gekozen. Bied daarom aanvullende geschikte methoden en test de werkelijke gebruikerservaring.

Kan een gebruiker resetten zonder vooraf geregistreerde methoden?

Nee. Als de gebruiker niet genoeg gegevens heeft voor de vereiste methoden, verwijst SSPR hem naar de beheerder. Daarom hoort registratie vóór de brede activering plaats te vinden.

Werkt SSPR voor lokale Active Directory-accounts?

Ja, in een hybride ontwerp kan password writeback het nieuwe wachtwoord naar de lokale Active Directory terugschrijven. Dat vereist geschikte licenties, configuratie, agent, rechten en een succesvolle ketentest.

Wat gebeurt er als we van één naar twee bewijzen gaan?

Gebruikers met maar één geschikte geregistreerde methode kunnen daarna niet meer zelf resetten. Controleer eerst de registratiegegevens, laat medewerkers een extra methode toevoegen en wijzig het beleid pas daarna.

Waar start een medewerker de reset?

Microsoft verwijst gebruikers naar de officiële SSPR-herstelpagina. Deel bij voorkeur die Microsoft-link in interne instructies en test ook de aangepaste supportlink in de herstelervaring.

Hoe weten we of de uitrol geslaagd is?

SSPR is geslaagd als gebruikers voldoende methoden hebben, een echte reset werkt, meldingen en rapportage beschikbaar zijn, hybride writeback waar nodig functioneert en support veilig kan helpen bij verlies van alle methoden.

Gebruikte Microsoft-bronnen

De centrale methodenpolicy, licentievoorwaarde, doelgroepopties, registratie, resetflow, meldingen, beheerdersverschillen en password writeback zijn op 1 september 2026 gecontroleerd tegen de actuele bronbestanden van Microsoft Learn: