Password History

Een robuust wachtwoordgeschiedenisbeleid is cruciaal voor Nederlandse overheidsorganisaties omdat wachtwoorden nog altijd de poortwachters zijn van talloze legacy-applicaties, beheerportalen en keteninterfaces. Wanneer gebruikers ongehinderd oude wachtwoorden kunnen recyclen, werkt elke investering in meervoudige authenticatie, voorwaardelijke toegang of detectie slechts gedeeltelijk: een aanvaller hoeft dan enkel een oud wachtwoord uit een datalek te testen om toegang te krijgen. Bovendien eisen de BIO, AVG en NIS2 dat organisaties aantoonbaar passende maatregelen nemen tegen identiteitsmisbruik. Het afdwingen van wachtwoordgeschiedenis beperkt niet alleen de kans op succesvolle aanvallen, maar vermindert ook de tijd die SOC en servicedesk kwijt zijn aan het onderzoeken van verdachte aanmeldpogingen én het herstellen van misbruikte accounts.

Implementatie

Deze richtlijn beschrijft hoe wachtwoordgeschiedenis via Microsoft Intune, Graph-automatisering en ondersteunende processen wordt ingericht, bewaakt en hersteld. We behandelen de beleidsmatige vereisten, de praktische implementatiestappen met het script password-history.ps1, het monitoringscenario via Log Analytics en de remediatie-aanpak voor apparaten die afwijken. Door techniek, governance en auditvereisten te combineren ontstaat een herhaalbaar patroon waarmee elke overheidsorganisatie de maatregel kan implementeren zonder het JSON-schema te wijzigen.

Vereisten

Het afdwingen van een consequente wachtwoordgeschiedenis vereist meer dan het inschakelen van een enkele instelling; het begint bij helder beleid dat verankerd is in de Nederlandse Baseline voor Veilige Cloud en dat aantoonbaar aansluit op de BIO, AVG en NIS2. Bestuurders moeten expliciet vastleggen hoeveel historische wachtwoorden worden onthouden, welke uitzonderingen voor dienst- of break-glass-accounts zijn toegestaan en wie toeziet op naleving. Zonder deze bestuurlijke borging ontbreekt een solide grondslag om maatregelen verplicht te stellen en afwijkingen te corrigeren, waardoor credential stuffing en brute-force scenario's vrij spel krijgen. Een formele risicobeoordeling, inclusief dreigingsmodellen voor identiteitsmisbruik en insider threats, vormt daarom de eerste vereiste voordat technische implementaties worden gestart. Vanuit toolingperspectief is een volledig ingerichte Microsoft Intune tenant noodzakelijk, inclusief koppeling met Entra ID, configuratieprofielen in de Settings Catalog en het Graph-API serviceaccount met de module Microsoft.Graph.DeviceManagement. Alleen dan kunnen wachtwoordbeleid, compliance policies en rapportages geautomatiseerd worden uitgerold naar alle Windows 10/11 endpoints. Daarnaast moeten beheerdersrollen binnen Intune en Entra ID duidelijk gesegmenteerd zijn, zodat wijzigingen in wachtwoordbeleid alleen door geautoriseerde identity- of endpointbeheerders mogen worden doorgevoerd. Het Change Advisory Board proces dient deze wijzigingen vooraf te toetsen op impact voor ketenapplicaties, serviceaccounts en specifieke doelgroepen zoals externe consultants of OT-apparatuur. Endpoints zelf moeten voldoen aan concrete technische voorwaarden. Apparaten moeten zijn ingeschreven via Azure AD Join of Hybrid Join, beschikken over TPM 2.0, BitLocker-geïnitialiseerde volumes en actuele Windows buildversies waarop security baselines toepasbaar zijn. In het netwerk moeten poorten voor Intune, Windows Update en Microsoft Defender for Endpoint openstaan, zodat policy synchronisatie en compliance feedback binnen de ingestelde intervallen plaatsvinden. Organisaties die nog afhankelijk zijn van on-premises GPO's moeten bovendien aantonen hoe conflicterende instellingen worden uitgefaseerd, zodat wachtwoordgeschiedenis niet wordt overschreven door verouderde lokale policies of scripts. Operationeel vraagt deze maatregel om voldoende capaciteit en competenties. Er moet een multidisciplinair team beschikbaar zijn met vertegenwoordigers van identity & access management, endpointbeheer, SOC en service management. Zij stellen gezamenlijk de configuratie op, beschrijven procedures voor uitzonderingsaanvragen en borgen dat documentatie in het centrale kennisportaal steeds wordt bijgewerkt. Eindgebruikerscommunicatie, onboardingmateriaal voor nieuwe medewerkers en instructies voor lokale beheerders horen daarbij, zodat iedereen begrijpt waarom het systeem het opnieuw kiezen van een oud wachtwoord weigert. Trainingen voor servicedeskmedewerkers zijn verplicht, omdat zij het eerste aanspreekpunt zijn bij lockouts of foutmeldingen. Tot slot moeten logging, audit trails en bewijslast vooraf worden geregeld. Dit betekent dat Intune rapportages, Azure Monitor logs en Microsoft Defender for Endpoint signalen naar een centrale Log Analytics workspace of SIEM worden doorgestuurd, inclusief tagging van beleidsversies. Alleen dan kan de organisatie aantonen welke apparaten compliant zijn, hoe snel afwijkingen worden opgelost en welke managementbesluiten aanpassingen legitimeren. Bewijsopslag moet voldoen aan de retentie-eisen van ten minste één jaar voor operationele controles en zeven jaar voor formele audits. Zonder deze vereiste infrastructuur is het onmogelijk om de naleving van wachtwoordgeschiedenis duurzaam te garanderen. Daarnaast moeten leverancierscontracten en sourcingafspraken expliciet opnemen dat externe beheerders en leveranciers zich houden aan hetzelfde wachtwoordgeschiedenisbeleid. Wanneer third-party engineers tijdelijk lokale adminrechten nodig hebben, dient hun toegang te verlopen via just-in-time mechanismen en moeten hun accounts automatisch terugvallen op de standaardpolicy zodra de klus is afgerond. Door deze afspraken contractueel vast te leggen, wordt voorkomen dat externe partijen een zwakker beleid afdwingen of beheerscripts achterlaten die het beveiligingsniveau aantasten.

Implementatie

Gebruik PowerShell-script password-history.ps1 (functie Invoke-Implementation) – De functie Invoke-Implementation in password-history.ps1 realiseert de volledige uitrol van de wachtwoordgeschiedenisinstelling door het Intune Settings Catalog-profiel te genereren, parameters op basis van de Nederlandse Baseline voor Veilige Cloud toe te passen en het profiel doelgericht toe te wijzen aan Azure AD-groepen. Het script opent standaard in een lokale debugmodus waarin alle Graph-aanroepen, request bodies en responsecodes worden gelogd, zodat beheerders exact kunnen zien welke configuraties worden aangemaakt voordat productie wordt geraakt. Deze aanpak voorkomt handmatige fouten in de Intune-portal, borgt herhaalbaarheid en faciliteert peer reviews volgens het changeproces. Voordat er ook maar één wijziging wordt aangebracht, voert het script een reeks controles uit: het valideert of de vereiste Microsoft.Graph.DeviceManagement module lokaal aanwezig is, controleert of de operator met een rol als Intune Administrator is aangemeld en leest bestaande configuraties uit om conflicten te voorkomen. De gewenste parameterwaarden, zoals het minimumaantal onthouden wachtwoorden en de beleidsnaamgeving, zijn vastgelegd in het manifest zodat wijzigingen traceerbaar zijn. Dankzij het idempotente ontwerp kan het script meerdere keren worden uitgevoerd zonder duplicaten te genereren; het herkent bestaande profielen op basis van tagvelden en werkt alleen gewijzigde instellingen bij. Tijdens de daadwerkelijke implementatiefase hanteert het script een gefaseerde uitrol naar een test-, pilot- en productiegroep. Iedere fase wordt afgesloten met een lokale validatiestap waarin de effectieve instellingen worden uitgelezen uit Intune en gelogd in een CSV-export voor de audittrail. Het script genereert tevens communicatie-artefacten: het schrijft een korte samenvatting naar Markdown die door het projectteam kan worden hergebruikt in change-notities en serviceberichten. Wie liever handmatig controleert, kan de parameter -WhatIf gebruiken om alleen de geplande acties te simuleren. Hierdoor sluit het script aan op de eis om elke wijziging eerst onder lokale debug-instellingen te testen voordat deze breed wordt uitgerold..

Gebruik PowerShell-script password-history.ps1 (functie Invoke-Monitoring) – Dezelfde password-history.ps1 bevat de functie Invoke-Monitoring, die direct aansluitend aan de implementatie kan worden uitgevoerd om te verifiëren of het nieuwe Intune-profiel daadwerkelijk is toegepast op de verwachte doelgroepen. De functie haalt het actuele assignment-overzicht op, vergelijkt dit met de beoogde Azure AD-groepen en controleert of de beleidsstatus overal als success wordt gerapporteerd. Wanneer een apparaat nog in pending staat, wordt het apparaat-id samen met de verantwoordelijke beheerafdeling in het logbestand opgenomen zodat vervolgacties gericht kunnen worden uitgezet. De functie produceert daarnaast een rijk validatierapport waarin per apparaat wordt vastgelegd welk wachtwoordbeleid actief is, welke laatste synchronisatietijd is geregistreerd en of er conflict policies zijn gedetecteerd. Dit rapport wordt zowel als JSON als CSV geëxporteerd, waardoor het eenvoudig is om het te koppelen aan rapportagetools of om het te uploaden in een change ticket. Dankzij de ingebouwde drempelwaarden kan het script een niet-succesratio boven de vijf procent direct markeren als implementatierisico, waarna het runbook automatisch wordt gestopt totdat het team de oorzaak heeft onderzocht. Door deze validatiestap vast in het change-runbook op te nemen, ontstaat er een aantoonbare keten van ontwerp, implementatie, verificatie en acceptatie. Het projectteam kan de output gebruiken om de CAB te informeren, terwijl het SOC dezelfde dataset kan inzetten om te controleren of gevoelige apparaten niet met een verouderd wachtwoordbeleid online blijven. Zo wordt de implementatie niet alleen technisch afgerond, maar ook bestuurlijk geborgd..

monitoring

Gebruik PowerShell-script password-history.ps1 (functie Invoke-Monitoring) – De monitoringfunctie in password-history.ps1 is ontworpen als een doorlopend controlemechanisme dat minimaal dagelijks kan draaien vanuit een beheerde taakplanner of een Azure Automation runbook. Zodra de functie wordt aangeroepen, maakt zij een beveiligde Graph-verbinding en haalt zij alle apparaten op die het wachtwoordgeschiedenisbeleid zouden moeten ontvangen, inclusief compliance-status, laatst gesynchroniseerde tijdstempel en aangemelde gebruiker. De functie correleert deze gegevens met Intune-devicecategorieën en gevoeligheidslabels, zodat kritieke systemen automatisch een zwaardere weging krijgen in de rapportage. Hierdoor ontstaat een actueel overzicht van waar wachtwoordgeschiedenis daadwerkelijk actief is en waar aanvullende maatregelen nodig zijn. Om configuratiedrift vroegtijdig te detecteren, vergelijkt de functie de effectieve device-instellingen met de definitie van de policy. Wanneer een apparaat via een lokale GPO een afwijkend wachtwoordbeleid toepast, markeert het script dit als conflict en berekent het de duur van de afwijking. Deze informatie wordt samen met het device-id, de primaire eigenaar en het netwerksegment opgeslagen in een Log Analytics workspace. Daarbovenop worden adaptieve drempelwaarden gebruikt: zodra meer dan twee procent van de apparaten in een hoogrisicogroep afwijkt, genereert de functie automatisch een waarschuwing richting het SOC. De monitoringuitvoer wordt verrijkt met trendinformatie. Het script bewaart per run de kernstatistieken, zoals het aantal compliant apparaten, het aantal conflicten en de gemiddelde synchronisatietijd, en schrijft deze weg naar een historische dataset. Daardoor kan via Power BI of Kusto Queries snel worden aangetoond of verbeteracties effect hebben gehad. Tegelijkertijd worden de ruwe gegevens beschikbaar gesteld aan het Identity & Access-team, dat ze kan gebruiken om uitzonderingsverzoeken te valideren en om patronen in gebruikersgedrag te herkennen. Naast technische data levert de monitoringfunctie ook communicatiesignalen. Wanneer specifieke gebruikers of afdelingen herhaaldelijk buiten compliant status vallen, wordt automatisch een notificatiebestand aangemaakt dat door de servicedesk kan worden gebruikt voor doelgerichte voorlichting. Het bestand bevat heldere instructies, verwijzingen naar interne documentatie en tips om caches te wissen of een herstart te plannen zodat Intune een nieuwe synchronisatie uitvoert. Daarmee wordt monitoring niet alleen een controlemiddel, maar ook een service-instrument dat eindgebruikers helpt om compliant te blijven. Tot slot is de functie hardening-proof: alle logbestanden worden geanonimiseerd waar mogelijk, gevoelige velden kunnen optioneel met AES-256 worden versleuteld voordat zij naar het SIEM worden gestuurd, en authenticatie richting Graph verloopt via managed identities of een certificaat dat in Azure Key Vault wordt opgeslagen. Hierdoor voldoet de monitoringoplossing aan de beveiligingseisen voor scripts binnen overheidsomgevingen. Het script rapporteert zijn eigen runtime, API-verbruik en foutcodes zodat technische teams binnen vijftien seconden kunnen zien of een run succesvol was. Dit maakt het mogelijk om de monitoring dagelijks te draaien zonder onnodige belasting op de omgeving en met volledige transparantie richting auditteams. Een bewezen werkwijze is om de monitoringfunctie te koppelen aan een Power Automate-flow die de samenvatting van iedere run naar het CISO-office mailt. Zo ontvangen besluitvormers binnen enkele minuten een overzicht met KPI's, topoorzaken voor non-compliance en aanbevolen acties. Wanneer de rapportage boven een ingestelde drempel uitkomt, voegt de flow automatisch een taak toe aan het SecOps-kanbanbord zodat opvolging traceerbaar is..

Remediatie

Gebruik PowerShell-script password-history.ps1 (functie Invoke-Remediation) – De functie Invoke-Remediation in password-history.ps1 vertaalt detecties rechtstreeks naar herstelacties. Zodra een apparaat als non-compliant wordt aangemerkt, verzamelt het script de context, zoals policyversie, apparaatrol en eigenaarschap, en bepaalt het automatisch welk herstelpad het meest passend is. Dit kan variëren van een geforceerde Intune-synchronisatie tot het opnieuw toewijzen van het configuratieprofiel of het plaatsen van het apparaat in een quarantainelijst voor handmatige opvolging. Door deze beslisboom te automatiseren wordt de hersteltijd drastisch verkort en ontstaat een consistent proces, ongeacht welke beheerder de run uitvoert. Voor standaardgevallen voert het script meteen technische acties uit. Het kan een opdracht naar het apparaat sturen om de policy opnieuw op te halen, een lokale registrycontrole uitvoeren via Intune remediation scripts en, wanneer nodig, de wachtwoordinstellingen resetten naar de voorgeschreven waarde. Alle acties worden gelogd met tijdstempel, operator-id en resultaatcode, zodat controle achteraf mogelijk blijft. Wanneer de oorzaak ligt in conflicterende GPO's of verouderde imaging, voegt het script automatisch een notitie toe aan het rapport met verwijzing naar de verantwoordelijke beheerafdeling. Complexere situaties, zoals accounts die opzettelijk een afwijkend beleid vereisen of apparaten die onderdeel zijn van een forensisch onderzoek, worden niet automatisch aangepast. In dat geval registreert het script de bevindingen als voorgestelde maatregel en verstuurt het een melding naar het Identity & Access-team en het SOC. De melding bevat naast technische details ook een risico-inschatting, een voorgestelde deadline en een verwijzing naar relevante beleidsartikelen. Zo behouden specialisten de regie over gevoelige afwijkingen zonder dat informatie versnipperd raakt. Invoke-Remediation besteedt eveneens aandacht aan gebruikerscommunicatie. Bij elke herstelactie kan optioneel een e-mail of Teams-bericht worden verstuurd naar de apparaateigenaar met duidelijke instructies, inclusief verwijzingen naar de interne kennisbank. Hiermee wordt voorkomen dat gebruikers onverwacht worden geconfronteerd met wachtwoordwijzigingen zonder context, wat de kans op shadow IT of onnodige servicedesktickets aanzienlijk verlaagt. Ook leidinggevenden kunnen automatisch worden geïnformeerd wanneer apparaten uit kritieke afdelingen structureel afwijken, zodat zij hun teams kunnen aansturen. Tot slot voorziet de functie in rapportage richting auditors. Elke run levert een overzicht op van hoeveel apparaten zijn hersteld, welke oorzaken het meest voorkwamen en welke acties nog openstaan. Dit overzicht kan direct als audit evidence worden opgeslagen, inclusief verwijzingen naar change-tickets en incidentnummers. Dankzij de ingestelde maximale uitvoeringstijd van vijftien seconden per apparaat wordt bovendien gewaarborgd dat remediatieprocessen snel worden afgebroken wanneer een actie te lang duurt; het script registreert dan automatisch een incident zodat beheerders alternatieve oplossingen kunnen inzetten. Daarmee voldoet de organisatie aan de eis dat scripts niet onbeheersbaar lang mogen draaien en dat er altijd een fallback bestaat. Elke maand evalueert het beheerteam de verzamelde remediatiestatistieken tijdens een gezamenlijke sessie met het SOC en de servicedesk. Ze analyseren welke grondoorzaken het vaakst voorkomen, welke instructies onduidelijk blijken voor eindgebruikers en welke processen moeten worden aangepast om herhaling te voorkomen. De uitkomsten worden gedocumenteerd in het verbeterregister en vormen input voor zowel training als beleid, waardoor remediatie telkens sneller en voorspelbaarder verloopt. Daarnaast levert elke run een dataset op die eenvoudig kan worden opgenomen in Power BI of Kusto-dashboards. Door de resultaten te correleren met incidenttickets ontstaat inzicht in de gemiddelde oplostijd, de meest getroffen afdelingen en de effectiviteit van communicatie-acties. Deze feedbackloop maakt het mogelijk om gerichte investeringen te doen in tooling, training of procesoptimalisatie en toont aan auditors dat remediatie daadwerkelijk wordt gemeten..

Compliance en Auditing

De naleving van wachtwoordgeschiedenisbeleid raakt meerdere compliancekaders tegelijk. Binnen de BIO valt deze maatregel onder het thema Toegangsbeveiliging, waar wordt geëist dat authenticatiemiddelen zodanig worden beheerd dat onbevoegde toegang wordt voorkomen. De Nederlandse Baseline voor Veilige Cloud vertaalt deze eis naar een concreet beleid waarin minimaal vierentwintig vorige wachtwoorden worden onthouden en waarin uitzonderingen expliciet door de CISO moeten worden goedgekeurd. Tegelijkertijd sluit de maatregel aan op ISO 27001 controle A.9.4.3 en op CIS Windows Benchmark 18.9.19.2, waardoor internationale auditteams de configuratie eenvoudig kunnen toetsen. Om compliance aantoonbaar te houden, moet elke wijziging aan het wachtwoordbeleid worden vastgelegd in een wijzigingsrecord met verwijzing naar het besluitvormingsdocument en de risicobeoordeling. De Intune-configuratie-export, het PowerShell logbestand en de Graph-responses worden samen opgeslagen in het centrale evidence-archief, zodat auditors kunnen herleiden welke instellingen actief waren op een bepaald moment. Daarnaast wordt aanbevolen om per kwartaal een snapshot te maken van de relevante Azure AD policy objects en deze te voorzien van een digitale handtekening, zodat de integriteit van het bewijs is gegarandeerd. De combinatie van technische logging en procesdocumentatie maakt het mogelijk om zowel preventieve als detectieve controles aan te tonen. Preventief wordt vastgelegd hoe het beleid is ontworpen, welke parameters zijn gekozen en wie de goedkeuring heeft verleend. Detectief wordt aangetoond dat monitoringrapporten consequent worden geanalyseerd, dat remediaties zijn uitgevoerd en dat lessons learned zijn vertaald naar verbeteracties. Deze cyclus past binnen het Plan-Do-Check-Act model waarop ISO 27001 en de BIO zijn gebaseerd. Auditors en toezichthouders verwachten bovendien dat organisaties inzicht hebben in uitzonderingen. Daarom bevat het compliance-dossier een register waarin staat welke accounts tijdelijk zijn vrijgesteld van wachtwoordgeschiedenis, waarom dat noodzakelijk is, welke compensaties gelden en wanneer de uitzondering verloopt. Het register wordt gekoppeld aan de output van Invoke-Monitoring, zodat automatisch wordt gecontroleerd of vrijstellingen niet stilzwijgend worden verlengd. Deze aanpak voorkomt dat noodmaatregelen permanent worden en ondersteunt het principe van minimale rechten. Tot slot moet de organisatie expliciet vastleggen hoe rapportages worden gedeeld met bestuur, CIO-office en ketenpartners. Een maandelijks executive dashboard toont kernindicatoren zoals het percentage compliant apparaten, de doorlooptijd van remediatie en het aantal openstaande uitzonderingen. Bij afwijkingen boven de afgesproken drempel worden escalaties binnen vijf werkdagen besproken in het security-overleg. Hiermee ontstaat een aantoonbare lijn van verantwoording waarin beleidsdoelen, technische uitrol, monitoring en compliance-rapportage onlosmakelijk met elkaar verbonden zijn. Wanneer externe auditors of toezichthouders aanvullende eisen stellen, kan dezelfde dataset eenvoudig worden uitgebreid met bewijs van ketenpartners. Denk aan printscreens uit applicaties die op het Windows-platform draaien, verklaringen van leveranciers dat zij het beleid respecteren of rapportages waaruit blijkt dat data-uitwisseling alleen plaatsvindt vanaf compliant systemen. Door deze documenten te bundelen met de Intune-export ontstaat een compleet dossier dat elke auditronde kan doorstaan zonder ad-hoc zoektochten naar ontbrekende informatie. Bewijsarchieven worden volgens de vastgestelde retentieperioden opgeslagen in een versleutelde SharePoint-site met beperkte toegang voor het CISO-office, internal audit en privacy officers. Elk document krijgt een metadata-profiel met datum, eigenaar en referentie naar het bijbehorende change-request, waardoor het terugzoeken tijdens audits binnen enkele seconden is geregeld.

Compliance & Frameworks

• CIS M365: Control 18.9.19.2 (L1) - CIS Security Benchmark aanbevelingen
• BIO: 16.01 - BIO Baseline Informatiebeveiliging Overheid - 16.01 - Gebeurtenissen logging en audittrails
• ISO 27001:2022: A.12.4.1 - ISO 27001:2022 - Gebeurtenissen logging en audittrails

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

Dwing via Intune en password-history.ps1 een beleid af dat minimaal vierentwintig vorige wachtwoorden onthoudt, valideer de uitrol met automatische monitoring en herstel afwijkingen direct vanuit hetzelfde script.

• Implementatietijd: 2 uur
• FTE required: 0.01 FTE