Kennisbank · 8 augustus 2026

Helpdesk trainen op resetfraude

Door Sander Vermeer

Praktische gids voor teams

Supportdesk trainen op wachtwoordreset fraude is vooral nuttig wanneer aanvallers vriendelijkheid, irritatie of spoed gebruiken om verificatie over te slaan. De fout is om dit als los securityonderwerp te behandelen. In de praktijk gaat het om gedrag: ziet iemand twijfel, stopt die persoon op tijd en komt de melding snel bij de juiste plek terecht?

De kern van deze gids: supportmedewerkers moeten behulpzaam blijven zonder verificatie over te slaan. Je hoeft daarvoor geen groot programma te starten. Begin met één duidelijk scenario, één meldroute en één meetpunt dat je na afloop echt bespreekt. Zo blijft de oefening klein genoeg om uit te voeren en concreet genoeg om gedrag te veranderen.

Wanneer dit onderwerp speelt

Dit onderwerp komt meestal boven tafel na een incident, een auditvraag of een training die weinig heeft veranderd. Iemand heeft misschien niet geklikt, maar ook niets gemeld. Of de melding kwam wel binnen, maar pas nadat meerdere collega’s hetzelfde bericht hadden gezien. Dan is de conclusie niet dat medewerkers onoplettend zijn. De conclusie is dat de route en feedback nog te vaag zijn.

Een goede aanpak begint klein. Kies een herkenbare situatie, spreek vooraf af wat je wilt zien en leg uit welke actie gewenst is. Als de oefening alleen draait om fouten zoeken, krijg je defensieve reacties. Als je gewenst gedrag meet, ontstaat een bruikbaar gesprek.

Oefen een resetverzoek zonder een echt account te veranderen

Een medewerker krijgt een onverwachte resetmail en even later een telefoontje: “Ik ben van support. Kun je de code doorgeven? Dan lossen we het op.” Gebruik dit als mondeling rollenspel met fictieve gegevens. Stuur geen echte reset, vraag geen echte code en laat niemand op een nagemaakte inlogpagina inloggen.

1. De medewerker onderbreekt het verzoek. Het gewenste antwoord: “Ik geef geen code door. Ik neem via onze bekende servicedesk contact op.”
2. De servicedesk controleert langs de afgesproken route. Gebruik contactgegevens uit het eigen register, niet het nummer van de beller. Verander geen MFA-methode of hersteladres alleen omdat het gesprek overtuigend klinkt.
3. De medewerker opent de dienst zelf. Bij Google: Beveiliging en inloggen → Recente beveiligingsgebeurtenissen → Beveiligingsgebeurtenissen bekijken. Dit is een controle, geen opdracht om iets te resetten.
4. Bespreek de uitkomst. Werd het verzoek gestopt, de identiteit onafhankelijk gecontroleerd en de melding vastgelegd? Een onverwachte resetmail op zichzelf bewijst geen inbraak.

Google beschrijft deze route in zijn uitleg over verdachte accountactiviteit. Ontbrekende activiteit maakt de oorspronkelijke mail niet vanzelf betrouwbaar. Een medewerker hoeft ook geen privéaccount te openen tijdens de training; het voorbeeldscherm is genoeg om de gekozen route te bespreken.

Voeg daarna één lastigere variant toe: de beller zegt dat ook de hersteltelefoon kwijt is. Een passkey helpt tegen een valse loginpagina, maar neemt de beslissing van de servicedesk niet over. Het goede resultaat is een gecontroleerde herstelprocedure met vastgelegde verificatie, niet een snelle uitzondering. Combineer dit met oefenen met onverwachte MFA-verzoeken.

Een beller vraagt een reset voor een collega

Stel je dit scenario voor: een beller wil een wachtwoordreset voor een collega die zogenaamd in een meeting zit. De vraag is dan niet alleen of iemand de rode vlag ziet. Je wilt weten of die persoon de veilige route gebruikt, of de melding snel genoeg binnenkomt en of de melder terugkoppeling krijgt.

Daar zit vaak de echte winst. Teams die al redelijk goed herkennen, lopen alsnog vast wanneer niemand weet wie de melding oppakt. Andersom kan een team met weinig technische kennis toch veiliger worden als melden eenvoudig en positief voelt.

Beslisblok voor je team

Gebruik deze mini-tool

Veelgemaakte fout

Een tweede fout is dat de training te breed wordt. Eén sessie over phishing, ransomware, wachtwoorden, MFA, privacy en incidentrespons klinkt efficiënt, maar mensen onthouden vooral dat security ingewikkeld is. Kies liever één gedrag per ronde. Bijvoorbeeld: verdachte sms niet openen, maar melden. Of: MFA-push niet goedkeuren als je niet zelf inlogt.

Stappenplan

1. Kies één doelgroep. Finance, HR, support en directie krijgen andere berichten. Gebruik geen algemeen voorbeeld als de rolcontext belangrijk is.
2. Maak de gewenste actie concreet. Niet “wees alert”, maar “open de bekende portal zelf” of “stuur dit naar de meldmailbox”.
3. Meet naast fouten ook goed gedrag. Noteer meldratio, tijd tot melding en hoeveel melders feedback kregen.
4. Bespreek patronen, geen schuld. Deel wat goed ging en welke stap eenvoudiger moet worden.
5. Plan de volgende kleine oefening. Herhaal liever kort en vaak dan één grote jaarlijkse training.

Hoe dit past in je phishingaanpak

Gebruik dit onderwerp als steunpagina, niet als los eindpunt. Wie nog geen basis heeft, start met de supportscenario maken. Wie al met scenario’s werkt, kan de aanpak aanscherpen met meldreflex-scan. Zo bouw je geen verzameling losse tips, maar een trainingsritme waarin elk artikel naar een volgende actie leidt.

Maak het ook zichtbaar in managementtaal. “We hadden 12 klikken” is een beperkt verhaal. “We hadden 28 meldingen binnen 20 minuten en twee procesgaten gevonden” is veel bruikbaarder. Dat tweede verhaal helpt om budget, tijd en aandacht te krijgen zonder angst te verkopen.

FAQ

Hoe vaak moet je hiermee oefenen?

Voor de meeste teams werkt maandelijks of per kwartaal beter dan één jaarlijkse training. Houd de oefening kort en bespreek één duidelijk gedrag.

Moet je namen rapporteren?

Gebruik namen alleen als dat intern echt nodig en zorgvuldig geregeld is. Voor leren en verbeteren zijn teamniveau, meldratio en procesgaten meestal nuttiger.

Wanneer is een tool nodig?

Een simpele checklist is genoeg voor een eerste ronde. Een platform wordt nuttig zodra je campagnes, meldknoppen, rapportage en herhaling centraal wilt beheren.