Een wachtwoordbeleid moet accounts moeilijker te kraken maken zonder veilig gedrag onnodig lastig te maken.\nDe beste beleidsregels zijn duidelijk, praktisch en afgestemd op hoe mensen daadwerkelijk werken. Ze stimuleren het gebruik van lange, unieke wachtwoorden, ondersteunen wachtwoordmanagers, vereisen waar mogelijk multi-factor authenticatie (MFA), en vermijden verouderde regels die voorspelbaar gedrag veroorzaken.
\nDit artikel legt uit wat je wel en niet moet doen bij een modern wachtwoordbeleid, wat je moet vermijden, welke best practices er zijn, en bevat een sjabloon dat je direct kunt overnemen voor jouw organisatie.
\nEen wachtwoordbeleid is een reeks regels die bepalen hoe wachtwoorden worden aangemaakt, opgeslagen, gebruikt, gedeeld, gewijzigd en beschermd.\nHet is van toepassing op medewerkers, contractanten, beheerders, serviceaccounts en soms klanten, afhankelijk van de betrokken systemen.
\nEen goed wachtwoordbeleid moet praktische vragen beantwoorden:
\nHet doel is niet het meest ingewikkelde regelpakket maken, maar het echte risico verlagen.
\nLengte is een van de sterkste verdedigingen tegen gokken en brute-force aanvallen. Eén minimale vereiste voor de hele organisatie is vaak begrijpelijker voor mensen en makkelijker te handhaven dan verschillende regels voor normale gebruikers, beheerders en speciale gevallen. Een praktische standaard is minimaal 16 tekens voor alle accounts van menselijke gebruikers. Langer is beter wanneer men gebruikmaakt van een wachtwoordmanager of willekeurig gegenereerde wachtwoordzinnen.
\nGebruikers moeten wachtwoorden kunnen maken die veel langer zijn dan het minimum. Vermijd lage maximale limieten zoals 16 of 20 tekens. Een maximumlengte van minimaal 64 tekens is een redelijke basis, en veel systemen kunnen nog langere wachtwoorden veilig ondersteunen.
\nWachtwoordzinnen moeten zijn toegestaan mits ze lang zijn en niet gebaseerd op bekende citaten, songteksten, bedrijfsnamen of voorspelbare zinnen. Een wachtwoordzin die uit verschillende willekeurige woorden bestaat is meestal beter dan een kort wachtwoord met geforceerde substituties.
\nElke account moet een uniek wachtwoord hebben. Hergebruik is een van de belangrijkste redenen waardoor een inbreuk bij één dienst leidt tot overname van accounts bij andere diensten. Een wachtwoordmanager maakt het praktisch om unieke wachtwoorden te gebruiken, omdat gebruikers deze niet allemaal hoeven te onthouden.
\nJe beleid moet expliciet goedkeuren en stimuleren om een goedgekeurde wachtwoordmanager te gebruiken. Gebruikers moeten wachtwoorden mogen plakken in inlogformulieren, automatisch laten invullen en willekeurige wachtwoorden mogen genereren. Het blokkeren van plakken lijkt misschien beschermend, maar ontmoedigt vaak juist het gebruik van sterke wachtwoordmanagers.
\nWachtwoorden moeten worden geweigerd als ze voorkomen in bekende dataleklijsten, veelgebruikte wachtwoordenlijsten of organisatie-specifieke zwarte lijsten. Dit is effectiever dan gebruikers verplichten om één hoofdletter, een cijfer en een symbool op te nemen.
\nMulti-factor authenticatie moet worden ingeschakeld waar technisch mogelijk, vooral voor beheerders, externe toegang, clouddiensten, e-mail, wachtwoordmanagers, financiële systemen en andere waardevolle systemen. MFA vervangt geen sterke wachtwoorden, maar vermindert wel de impact van gestolen credentials.
\nGeef de voorkeur aan phishing-resistente MFA zoals passkeys, hardwarebeveiligingssleutels, of platform authenticators. App-gebaseerde authenticators zijn meestal beter dan SMS. SMS-MFA mag alleen worden gebruikt als er geen andere MFA-methode technisch mogelijk is, omdat telefoonnummers kunnen worden onderschept, overgezet (SIM-swapping of portering), of misbruikt via account recovery.
\nDit is geen theoretisch risico. In 2018 maakte Reddit bekend dat aanvallers sms-gebaseerde twee-factor-authenticatie onderschepten en toegang kregen tot interne systemen: https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/. In 2021 meldde Coinbase dat aanvallers cryptocurrency van minstens 6.000 klanten hebben gestolen na misbruik van inloggegevens en een zwakke plek in het SMS-recovery-proces: https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/.
\nWachtwoorden dienen gewijzigd te worden wanneer er aanwijzingen of een redelijk vermoeden is van compromittering. Voorbeelden zijn phishing, malware op het apparaat van de gebruiker, credentials uitgelekt bij een datalek, verdachte login-activiteit, of onbedoelde openbaarmaking.
\nGedeelde wachtwoorden moeten worden vermeden waar individuele accounts mogelijk zijn. Indien gedeelde credentials onvermijdelijk zijn, moeten deze worden opgeslagen in een goedgekeurde wachtwoordmanager, alleen toegankelijk zijn voor gemachtigde gebruikers, en moet het delen waar mogelijk worden gelogd.
\nWachtwoordreset is vaak het zwakste punt in accountbeveiliging. Herstelprocessen moeten identiteit verifiëren, resetlinks snel laten verlopen, single-use tokens gebruiken en gebruikers op de hoogte stellen wanneer hun wachtwoord is gewijzigd.
\nVerplichte wisselingen elke 30, 60 of 90 dagen leiden vaak tot zwakkere wachtwoorden. Gebruikers passen meestal kleine, voorspelbare aanpassingen toe zoals het toevoegen van een cijfer of een aanpassing aan het seizoen. De Digital Identity Guidelines van NIST hebben het routinematige periodieke vervangen afgeschaft en eisen wijziging alleen bij aanwijzingen van compromittering. Zie sectie 3.1.1.2: https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver. Eis een wijziging na vermoed compromis, functiewijzigingen, account recovery, of als een wachtwoord niet langer aan het beleid voldoet.
\nRegels als \"moet een hoofdletter, kleine letter, cijfer en symbool bevatten\" garanderen geen sterkte. Password1! voldoet aan veel complexiteitsregels maar is nog steeds zwak. Prioriteer lengte, uniciteit, willekeur en screening op datalekken.
Het blokkeren van plakken maakt het gebruik van wachtwoordmanagers lastiger. Dit dwingt gebruikers sneller om kortere, makkelijk te typen wachtwoorden te kiezen. Sta plakken en automatisch invullen toe, tenzij er een specifieke, gedocumenteerde beveiligingsreden is om het te blokkeren.
\nWachtwoordhints geven vaak teveel prijs. Als een gebruiker het antwoord uit de hint kan afleiden, kan een aanvaller dat vaak ook. Gebruik in plaats daarvan veilige herstelprocessen.
\nSystemen mogen wachtwoorden nooit als platte tekst of met omkeerbare encryptie opslaan. Wachtwoorden dienen gehasht te worden met een moderne, langzame en gesalte hashmethode zoals Argon2id, bcrypt, scrypt of PBKDF2, afhankelijk van de systeemeisen en regelgeving.
\nSnelle, generieke hash-algoritmen zoals MD5, SHA-1, SHA-256 of SHA-512 zijn niet geschikt als wachtwoordhashmethode. Ze zijn ontworpen om snel te zijn, wat brute-force aanvallen na een datalek makkelijker maakt. Voor meer achtergrond, zie ons artikel over de evolutie van wachtwoordhashing.
\nWachtwoorden mogen niet worden verzonden via e-mail, chat, tickets, documenten of screenshots. Gebruik een wachtwoordmanager met veilige deel- en toegangsbeheerfuncties.
\nWachtwoorden mogen geen namen, geboortedata, bedrijfsnamen, toetsenbordpatronen, herhaalde karakters of veel gebruikte substituties bevatten zoals @ voor a en 0 voor o. Aanvallers proberen deze patronen als eerste.
Gebruik vereisten die makkelijk te begrijpen zijn:
\nBeheerdersaccounts, serviceaccounts en productie-accounts verdienen strengere controles. Vereis sterkere wachtwoorden, MFA, beperkte toegang, monitoring, en onmiddellijke rotatie bij toegangsveranderingen.
\nSterke wachtwoorden kunnen overmatige rechten niet compenseren. Gebruikers mogen alleen toegang hebben tot systemen en geheimen die nodig zijn voor hun rol.
\nDetecteer ongebruikelijke loginpatronen, onmogelijk reizen, herhaalde mislukte pogingen, loginpogingen vanuit nieuwe landen, en toegang buiten werktijden. Wachtwoordbeleid dient te worden ondersteund door monitoring en incident response.
\nTraining moet zich richten op wachtwoordhergebruik, phishing, valse loginpagina's, MFA-moeheid, veilig delen, en melden van vermoed compromis. Geef gebruikers geen schuld. Maak veilig gedrag makkelijk.
\nEen wachtwoordbeleid moet begrijpelijk zijn. Is het beleid te lang, vaag of streng, dan zullen mensen het omzeilen. Het beste beleid is dat wat daadwerkelijk gehandhaafd en nageleefd wordt.
\nGebruik onderstaand sjabloon als uitgangspunt. Pas de onderdelen tussen haakjes aan voor jouw organisatie, systemen, risiconiveau en wettelijke vereisten.
\nWachtwoordbeleid\n\nVersie: [1.0]\nEigenaar: [Security / IT-afdeling]\nDatum van inwerkingtreding: [JJJJ-MM-DD]\nHerzieningscyclus: [Elke 12 maanden]\n\n1. Doel\n\nDit beleid definieert de eisen voor het aanmaken, gebruiken, opslaan, delen en wijzigen van wachtwoorden voor [Organisatienaam]. Het doel is het risico te verminderen van ongeautoriseerde toegang, credentialdiefstal, overname van accounts en dataverlies.\n\n2. Toepassingsgebied\n\nDit beleid geldt voor alle medewerkers, opdrachtnemers, tijdelijke krachten, dienstverleners, en andere gebruikers die toegang hebben tot systemen, applicaties, netwerken, cloudservices of gegevens van [Organisatienaam].\n\nDit beleid is van toepassing op standaardgebruikersaccounts, bevoorrechte accounts, serviceaccounts, gedeelde accounts en elk systeem waar wachtwoorden voor authenticatie worden gebruikt.\n\n3. Eisen voor wachtwoordcreatie\n\nAlle wachtwoorden moeten aan de volgende eisen voldoen:\n\n- Accounts van menselijke gebruikers moeten een wachtwoord van minstens 16 tekens hebben.\n- Wachtwoorden moeten uniek zijn en mogen niet worden hergebruikt voor werk- of privéaccounts.\n- Wachtwoorden mogen geen namen, gebruikersnamen, bedrijfsnamen, geboortedata, toetsenbordpatronen, herhaalde karakters of andere makkelijk te raden informatie bevatten.\n- Wachtwoorden mogen niet gebaseerd zijn op bekende zinnen, citaten, songteksten of voorspelbare substituties.\n- Wachtwoorden mogen niet voorkomen op bekende datalek- of veelgebruikte wachtwoordenlijsten.\n- Wachtwoorden mogen spaties, symbolen, cijfers, hoofdletters en kleine letters bevatten.\n- Wachtwoordzinnen zijn toegestaan mits ze lang, uniek en niet gebaseerd op voorspelbare of publieke zinnen zijn.\n\n4. Wachtwoordmanagers\n\n[Organisatienaam] vereist of stimuleert sterk het gebruik van een goedgekeurde wachtwoordmanager voor het aanmaken, opslaan en delen van wachtwoorden.\n\nGebruikers mogen een wachtwoordgenerator, automatisch invullen en kopieer-/plakfunctionaliteit van de goedgekeurde wachtwoordmanager gebruiken. Wachtwoorden mogen niet worden opgeslagen in browsers, spreadsheets, documenten, notitie-apps, e-mail, chat, screenshots of niet-goedgekeurde middelen.\n\n5. Multi-factor authenticatie\n\nMulti-factor authenticatie moet overal waar technisch mogelijk worden ingeschakeld, waaronder maar niet beperkt tot:\n\n- E-mailaccounts\n- Externe toegangssystemen\n- Accounts voor wachtwoordmanagers\n- Clouddiensten\n- Beheerdersaccounts\n- Financiële, HR- en andere kritieke systemen\n- Elk systeem geclassificeerd als [vertrouwelijk / kritiek]\n\nWaar beschikbaar gebruiken gebruikers phishing-resistente MFA zoals passkeys, hardwarebeveiligingssleutels of platform authenticators. Authenticator-apps hebben de voorkeur boven SMS. SMS-MFA is verboden tenzij geen enkele andere MFA-methode technisch mogelijk is en mag alleen worden gebruikt waar geen sterkere MFA-optie mogelijk is.\n\n6. Wijziging van wachtwoorden\n\nWachtwoorden moeten direct gewijzigd worden als:\n\n- Een wachtwoord bekend of vermoed gecompromitteerd is.\n- Een gebruiker een wachtwoord heeft ingevoerd op een vermoedelijk phishingplatform.\n- Een wachtwoord gedeeld is met een niet-geautoriseerde persoon.\n- Malware of ongeautoriseerde toegang is gedetecteerd op het apparaat van de gebruiker.\n- Een wachtwoord voorkomt in een bekend datalek.\n- De rol of het dienstverband van een bevoorrechte gebruiker verandert.\n- IT of Security de gebruiker instrueert het wachtwoord te wijzigen.\n\nRoutinematige wachtwoordvervaltermijnen zijn niet vereist, tenzij wettelijk, contractueel of door het systeem verplicht. Wachtwoorden mogen niet worden gewijzigd door kleine voorspelbare aanpassingen aan het vorige wachtwoord.\n\n7. Delen van wachtwoorden\n\nWachtwoorden mogen niet worden gedeeld via e-mail, chat, tickets, documenten, screenshots, telefoongesprekken of mondeling.\n\nGedeelde credentials zijn alleen toegestaan wanneer individuele accounts technisch niet mogelijk zijn, of met expliciete goedkeuring van [Security / IT]. Gedeelde wachtwoorden moeten opgeslagen en gedeeld worden via de goedgekeurde wachtwoordmanager en alleen toegankelijk zijn voor geautoriseerde gebruikers.\n\n8. Bevoorrechte accounts\n\nBevoorrechte accounts moeten unieke wachtwoorden gebruiken die niet worden gebruikt voor standaardgebruikersaccounts. Privileged accounts moeten waar mogelijk MFA gebruiken en regelmatig worden gecontroleerd.\n\nBevoorrechte wachtwoorden moeten worden geroteerd als een beheerder de organisatie verlaat, van rol verandert, geen toegang meer nodig heeft, of als er sprake is van vermoeden van compromis.\n\n9. Serviceaccounts en applicatiegeheimen\n\nWachtwoorden voor serviceaccounts, API-sleutels, tokens en applicatiegeheimen moeten worden opgeslagen in een goedgekeurd secrets management systeem of wachtwoordmanager.\n\nInloggegevens voor serviceaccounts mogen niet worden opgenomen in broncode, configuratiebestanden, afbeeldingen, documentatie of scripts, tenzij beschermd door een goedgekeurd secrets management proces.\n\n10. Wachtwoord resetten en recovery\n\nProcessen voor het resetten van wachtwoorden moeten de identiteit van de gebruiker verifiëren alvorens toegang te herstellen. Resetlinks en tijdelijke wachtwoorden moeten single-use zijn, snel verlopen en worden verzonden via goedgekeurde kanalen.\n\nGebruikers moeten worden geïnformeerd wanneer hun wachtwoord is gewijzigd of gereset. Tijdelijke wachtwoorden moeten bij de eerste login worden gewijzigd.\n\n11. Technische controles\n\nSystemen die wachtwoorden opslaan of verwerken moeten:\n\n- Wachtwoorden nooit in platte tekst opslaan.\n- Wachtwoorden hashen met een goedgekeurde moderne gesalte hashmethode: PBKDF2, scrypt, bcrypt of Argon2.\n- Geen MD5, SHA-1, SHA-256, SHA-512 of andere snelle generieke hash-algoritmen als enige wachtwoordhashmethode gebruiken.\n- Authenticatie-endpoints beschermen met rate limiting of gelijkwaardige maatregelen.\n- Veelgebruikte, zwakke en bekende gecompromitteerde wachtwoorden weigeren.\n- Gebruikers toestaan wachtwoorden te plakken uit wachtwoordmanagers.\n- Redelijke wachtwoordlengte ondersteunen, minimaal 64 tekens waar technisch mogelijk.\n- Beveiligingsrelevante authenticatiegebeurtenissen loggen.\n\n12. Vermoed compromis melden\n\nGebruikers moeten vermoed compromis, phishing, ongebruikelijke loginprompts, MFA-pushes die ze niet zelf hebben gestart, of onbedoelde openbaarmaking van een wachtwoord direct melden aan [Security / IT-contact].\n\n13. Uitzonderingen\n\nUitzonderingen op dit beleid moeten worden gedocumenteerd, risicogewogen, tijdsgebonden en goedgekeurd door [Security / IT-leiding]. Compensatiemaatregelen dienen waar mogelijk te worden toegepast.\n\n14. Handhaving\n\nNiet-naleving van het beleid kan leiden tot verwijdering van toegang, verplichte securitytraining, disciplinaire maatregelen of andere stappen conform [Organisatienaam] beleid en toepasselijke wetgeving.\n\n15. Evaluatie\n\nDit beleid moet minimaal jaarlijks worden herzien, of na significante veranderingen aan systemen, dreigingen, wetgeving of bedrijfsvoering.\nEen sterk wachtwoordbeleid is niet bedoeld om het leven van gebruikers lastig te maken, maar om zwakke gewoontes te doorbreken, wachtwoordmanagers te ondersteunen, MFA te benutten en snel te reageren op blootgestelde credentials. Houd het beleid praktisch, handhaafbaar en gericht op echte aanvallen zoals phishing, credential stuffing, wachtwoordhergebruik en gecompromitteerde accounts.
","frontmatter":{"date":"May 07, 2026","slug":"password-policy-dos-donts-best-practices","title":"Wachtwoordbeleid: Do's, Don'ts, Best Practices en een Copy-Paste Sjabloon","description":"Ontdek wat een modern wachtwoordbeleid moet eisen, welke verouderde regels je moet vermijden, en kopieer een praktisch sjabloon voor jouw organisatie.","author":"Sascha Pfeiffer","featuredImage":null}}},"pageContext":{"slug":"password-policy-dos-donts-best-practices","lang":"nl","langPathPrefix":"/nl"}},"staticQueryHashes":["2149092236","3128451518","3192060438"]}