BIO 11.02.07 ISO A.6.2.1

Intune Device Compliance Policies Design

đź“… 2025-10-30
•
⏱️ 12 minuten lezen
•
đź”´ Must-Have

đź’Ľ Management Samenvatting

Het ontwerp van Intune Device Compliance Policies beschrijft de minimale beveiligingseisen voor Windows-, iOS-, Android- en macOS-apparaten voordat zij toegang mogen krijgen tot bedrijfsgegevens en -diensten. Deze inrichting vormt een kernonderdeel van een Zero Trust‑architectuur: een apparaat wordt pas vertrouwd als het aantoonbaar aan vooraf gedefinieerde beveiligingscriteria voldoet. Door compliancebeleid centraal te beheren in Intune en dit te koppelen aan voorwaardelijke toegang in Entra ID, ontstaat een uniforme, controleerbare en aantoonbare manier om de endpoint‑beveiliging in de gehele organisatie te borgen.

Aanbeveling
IMPLEMENTEER DEVICE COMPLIANCE
Risico zonder
High
Risk Score
8/10
Implementatie
16u (tech: 8u)
Van toepassing op:
âś“ Intune
âś“ Endpoint Management

Zonder goed ingerichte compliance policies kunnen onbeveiligde, verouderde of gecompromitteerde apparaten toch verbinding maken met Microsoft 365, bedrijfsapplicaties en gevoelige data. Dit leidt tot duidelijke beveiligingsrisico’s: een verouderd besturingssysteem bevat bekende kwetsbaarheden die door aanvallers kunnen worden misbruikt, apparaten zonder versleuteling vergroten het risico op datalekken bij verlies of diefstal, en endpoints zonder actuele antivirus- en firewallconfiguratie zijn gevoeliger voor malware, ransomware en gerichte aanvallen. Door een minimale besturingssysteemversie, verplichte schijfversleuteling (zoals BitLocker of FileVault), actieve antivirusbeveiliging, een ingeschakelde firewall, een sterk wachtwoord of pincode en detectie van jailbreak of root‑toegang af te dwingen, wordt de drempel voor aanvallers aanzienlijk verhoogd. Tegelijkertijd helpt dit organisaties om te voldoen aan de BIO, ISO 27001 en NIS2, waarin een passende beveiliging van eindpunten en mobiele apparaten expliciet wordt verlangd. Compliance policies vormen daarmee de concrete, technische uitwerking van het device‑gedeelte van het beveiligingsbeleid.

Implementatie

In dit ontwerp wordt per platform vastgelegd aan welke voorwaarden een apparaat minimaal moet voldoen, en hoe niet‑conforme apparaten worden gedetecteerd, beoordeeld en geblokkeerd. Voor Windows‑apparaten betekent dit onder meer een ondersteunde en gepatchte versie (bijvoorbeeld Windows 10 1909 of hoger), ingeschakelde BitLocker‑versleuteling van systeem- en gegevensschijven, een actief en up‑to‑date antimalwareproduct zoals Microsoft Defender Antivirus, een ingeschakelde Windows‑firewall, gebruik van een Trusted Platform Module (TPM) waar mogelijk en een beveiligde opstartketen. Voor iOS wordt een minimaal besturingssysteemniveau vastgesteld, is een toegangscode met voldoende lengte en complexiteit verplicht, wordt gecontroleerd op jailbreak en wordt verwacht dat de standaard versleuteling van het apparaat actief is. Voor Android wordt minimaal een recente Android‑versie vereist, volledige apparaat- of werkprofielversleuteling, integratie met Google Play Protect en detectie van root‑toegang of andere aanwijzingen voor compromittering. Voor macOS worden een ondersteunde versie van het besturingssysteem, FileVault‑schijfversleuteling, een ingeschakelde firewall en gebruik van Gatekeeper als basisvoorwaarden vastgelegd. De compliance‑status van een apparaat (compliant, niet‑compliant of in een tijdelijke gratieperiode) wordt vervolgens gebruikt in voorwaardelijke toegangsbeleidsregels om toegang tot cloudbronnen automatisch toe te staan of te blokkeren, waarbij gebruikers duidelijke meldingen en instructies ontvangen om hun apparaat in overeenstemming te brengen met het beleid.

Vereisten

  1. Voor een effectief ontwerp van device compliance policies is in de eerste plaats een juiste licentiebasis nodig. De organisatie beschikt minimaal over Microsoft Intune‑licenties (bijvoorbeeld via Microsoft 365 E3/E5, Business Premium of afzonderlijke Intune‑abonnementen) voor alle gebruikers of apparaten die centraal beheerd worden. Het is raadzaam om vooraf in kaart te brengen welke typen apparaten in scope zijn (corporate owned, bring‑your‑own‑device, gedeelde werkplekken) en welke gebruikerspopulaties worden bediend (kantoorwerkers, buitendienst, beheerders). Op basis daarvan wordt bepaald hoeveel Intune‑ en eventueel aanvullende beveiligingslicenties noodzakelijk zijn en hoe deze op een beheerbare manier toegewezen kunnen worden, bijvoorbeeld via dynamische groepen in Entra ID. Zonder een volledig en actueel licentieoverzicht kan het gebeuren dat bepaalde apparaten geen beleid ontvangen en daarmee buiten de beveiligingsafspraken vallen.
  2. Daarnaast moeten de inhoudelijke compliance‑eisen per platform duidelijk en gedetailleerd zijn vastgelegd, bij voorkeur in een formeel goedgekeurd beveiligingsbeleid. Voor elk besturingssysteem wordt beschreven welke minimale OS‑versie vereist is, welke versleutelingsstandaard wordt gebruikt, welke wachtwoord- of pincode‑regels gelden, en welke aanvullende beveiligingsmaatregelen zoals antivirus, firewall en beveiligde opstart moeten worden afgedwongen. Deze eisen worden idealiter afgestemd met de CISO, de functionaris gegevensbescherming en de eigenaren van bedrijfskritische applicaties, zodat technische instellingen en beleidsafspraken met elkaar in lijn zijn. Wanneer de uitgangspunten per platform vooraf helder zijn beschreven, wordt het configureren van Intune‑policies een vertaling van het beleid in plaats van een reeks losse technische keuzes.
  3. Een derde vereiste is de inrichting van voorwaardelijke toegangsbeleidsregels in Entra ID die de compliance‑status van apparaten daadwerkelijk gebruiken om toegang te sturen. Minimaal wordt een beleidsregel geconfigureerd die toegang tot gevoelige cloudbronnen, zoals Exchange Online, SharePoint, Teams en bedrijfskritische SaaS‑applicaties, alleen toestaat voor apparaten die door Intune als compliant zijn beoordeeld. Waar nodig kunnen uitzonderingen worden ingericht voor specifieke scenario’s, bijvoorbeeld noodtoegang of serviceaccounts, maar deze worden beperkt en zorgvuldig gedocumenteerd. De combinatie van Intune‑compliance en Conditional Access zorgt ervoor dat een niet‑conform apparaat niet alleen wordt gesignaleerd, maar ook daadwerkelijk wordt verhinderd om onbeveiligd toegang te krijgen tot gegevens.
  4. Verder moeten gratieperioden en uitzonderingsscenario’s expliciet worden gedefinieerd voordat het beleid breed wordt uitgerold. Een gratieperiode geeft gebruikers beperkte tijd om hun apparaat in overeenstemming te brengen met het beleid zonder direct volledig geblokkeerd te worden. Daarbij wordt per platform bepaald hoe lang deze periode duurt, welke meldingen gebruikers ontvangen en welke functionaliteit eventueel tijdelijk beschikbaar blijft. Voor devices die structureel niet aan alle eisen kunnen voldoen (bijvoorbeeld specifieke industriële apparaten of testomgevingen) wordt een apart risicobeeld opgesteld en wordt vastgelegd onder welke voorwaarden zij toch toegang krijgen, bijvoorbeeld via een geïsoleerde omgeving of alleen tot laag‑risico‑applicaties.
  5. Heldere en tijdige communicatie naar eindgebruikers is een andere cruciale voorwaarde voor succes. Gebruikers moeten begrijpen waarom er strengere eisen aan hun apparaten worden gesteld, wat er precies van hen wordt verwacht, en welke stappen zij moeten doorlopen om compliant te worden. Dit vraagt om duidelijke Nederlandstalige handleidingen, FAQ’s en eventueel korte instructievideo’s die laten zien hoe iemand bijvoorbeeld BitLocker inschakelt, een sterk wachtwoord instelt of zijn besturingssysteem bijwerkt. Deze communicatie wordt idealiter via meerdere kanalen aangeboden, zoals intranet, e‑mailcampagnes, meldingen vanuit Intune Company Portal en berichten via leidinggevenden, zodat de impact van de verandering voorspelbaar en beheersbaar is.
  6. Tot slot moet de ondersteuning zodanig zijn ingericht dat gebruikers bij problemen snel en deskundig worden geholpen. De servicedesk en tweede‑lijns beheerteams krijgen training in de werking van Intune‑compliance, de betekenis van veelvoorkomende foutcodes en de stappen die nodig zijn om apparaten weer compliant te maken. Zij beschikken over duidelijke runbooks en beslisbomen: welke logbestanden moeten worden bekeken, wanneer moet een apparaat opnieuw worden ingeschreven, en in welke gevallen is escalatie naar het Intune‑ of securityteam nodig. Door ondersteuning en processen goed te organiseren, wordt voorkomen dat strengere beveiligingsmaatregelen leiden tot frustratie of productiviteitsverlies, en blijft de balans tussen veiligheid en gebruiksvriendelijkheid behouden.

Implementatie

De implementatie van device compliance policies in Intune start met een grondige inventarisatie van alle apparaten en gebruiksscenario’s binnen de organisatie. Breng in kaart welke besturingssystemen worden gebruikt, of het gaat om organisatie‑eigendom of persoonlijke apparaten, en welke toepassingen en data via deze endpoints worden benaderd. Op basis hiervan worden per platform logische doelgroepen samengesteld, bijvoorbeeld via dynamische Entra ID‑groepen op basis van apparaatkenmerken of gebruikersrollen. Deze voorbereiding zorgt ervoor dat beleid later gericht kan worden toegepast zonder onnodige uitzonderingen of complexe handmatige toewijzingen. Vervolgens worden per platform afzonderlijke compliance policies aangemaakt in Intune. Voor Windows kunnen dit bijvoorbeeld verschillende beleidssets zijn voor werkstations, laptops en speciale beheerwerkplekken, waarin minimale OS‑versie, BitLocker‑versleuteling, firewallstatus, antivirus en aanvullende beveiligingsinstellingen zijn vastgelegd. Voor iOS en Android wordt onder meer vastgelegd dat een toegangscode verplicht is, dat het apparaat niet gejailbreakt of geroot mag zijn, en dat de ingebouwde versleuteling actief is. Voor macOS wordt onder andere het gebruik van FileVault, een ingeschakelde firewall en een ondersteunde macOS‑versie afgedwongen. Bij het opstellen van deze policies is het verstandig om te beginnen met een beperkte set kernvereisten en deze later gefaseerd aan te scherpen, zodat de impact beheersbaar blijft. Nadat de policies zijn vormgegeven, worden zij toegewezen aan de eerder gedefinieerde groepen. Het is aan te raden om te starten met een pilotgroep van technisch vaardige gebruikers en representatieve apparaten, zodat kinderziektes vroegtijdig worden opgespoord. Tijdens deze pilotfase wordt het Intune‑dashboard intensief gemonitord op compliance‑statistieken, foutmeldingen en veelvoorkomende oorzaken van niet‑conforme apparaten. De bevindingen uit de pilot worden teruggekoppeld naar het ontwerp: waar nodig worden drempelwaarden aangepast, uitzonderingen verduidelijkt of extra communicatiemateriaal ontwikkeld. Parallel hieraan worden in Entra ID voorwaardelijke toegangsbeleidsregels ingericht die de door Intune berekende compliance‑status gebruiken als voorwaarde voor toegang. In eerste instantie kan gekozen worden voor een rapportage‑ of alleen‑auditmodus, waarin zichtbaar wordt welke gebruikers zouden worden geblokkeerd zonder dat dit al gebeurt. Zodra het vertrouwen in de configuratie voldoende groot is, wordt het beleid omgezet naar afdwingende modus en worden niet‑compliant apparaten daadwerkelijk tegengehouden. Het is van belang dat gebruikers in zo’n situatie een duidelijke melding krijgen die uitlegt waarom toegang wordt geblokkeerd en welke herstelstappen zij moeten nemen. Tot slot wordt de implementatie geborgd in beheerprocessen en documentatie. De beheerorganisatie legt vast wie verantwoordelijk is voor het regelmatig beoordelen van compliance‑rapportages, het doorvoeren van aanpassingen bij nieuwe OS‑versies en het afhandelen van uitzonderingen. Ook wordt beschreven hoe onboarden en offboarden van apparaten verloopt, en op welke momenten de compliance‑eisen herzien worden op basis van nieuwe dreigingen of gewijzigde wet‑ en regelgeving. Door deze stappen zorgvuldig te doorlopen, ontstaat een robuuste, toekomstbestendige inrichting waarin device compliance een vast en aantoonbaar onderdeel van de beveiligingsketen vormt.

Compliance en Auditing

Device compliance policies spelen een belangrijke rol in het aantoonbaar voldoen aan Nederlandse en Europese normen voor informatiebeveiliging. Binnen de Baseline Informatiebeveiliging Overheid (BIO) verwijst maatregel 11.02.07 expliciet naar de noodzaak om eindpunten te voorzien van passende beveiligingsinstellingen, zoals versleuteling, malwarebescherming en het beperken van functionaliteit tot wat noodzakelijk is voor het werk. Door middel van Intune‑compliancebeleid kan de organisatie deze eisen concreet invullen: per apparaat wordt automatisch vastgesteld of aan de minimale configuratie‑eisen wordt voldaan, en rapportages tonen in één oogopslag welk percentage van het apparaatpark conform de baseline is. Dit maakt het voor CISO’s en auditors eenvoudiger om te beoordelen of de overeengekomen beveiligingsmaatregelen daadwerkelijk in de praktijk zijn gebracht. Ook in ISO 27001 komt het belang van goed beheerde mobiele apparaten en werkplekken nadrukkelijk terug, onder andere in controle A.6.2.1 over het mobiele‑apparatenbeleid. De norm verlangt dat organisaties beleidsregels formuleren voor het gebruik en beheer van laptops, tablets, smartphones en andere mobiele apparatuur, inclusief eisen op het gebied van versleuteling, wachtwoordgebruik en verlies- of diefstalprocedures. Intune‑compliance vormt de technische motor onder deze beleidsregels: waar het beleid beschrijft wat er moet gebeuren, zorgen de policies ervoor dat deze afspraken automatisch worden afgedwongen en bewaakt. Tijdens ISO‑audits kan met behulp van Intune‑rapportages, exportbestanden en schermprints inzichtelijk worden gemaakt welke beleidsregels gelden, hoe deze zijn geconfigureerd en wat de actuele nalevingsgraad is. De NIS2‑richtlijn en de daaruit voortvloeiende nationale wetgeving leggen bovendien een zwaardere nadruk op de beveiliging van netwerk- en informatiesystemen die essentieel zijn voor de continuïteit van vitale processen. Endpoint‑beveiliging, inclusief het afdwingen van minimale configuraties en het beperken van toegang vanaf onbeveiligde apparaten, is daarin een belangrijk aandachtspunt. Door device compliance te koppelen aan voorwaardelijke toegang kan een organisatie aantonen dat toegang tot bedrijfskritische cloud‑diensten alleen wordt verleend aan apparaten die voldoen aan vooraf gedefinieerde beveiligingscriteria. Logbestanden uit Intune en Entra ID laten zien wanneer apparaten niet‑compliant waren, welke acties zijn ondernomen en hoe snel afwijkingen zijn verholpen, wat van grote waarde is bij incidentonderzoek en rapportage aan toezichthouders. Naast formele wet‑ en regelgeving sluiten streng ingerichte compliance policies goed aan op gangbare best‑practice‑raamwerken zoals de CIS Benchmarks voor Windows, macOS, iOS en Android. Veel van de daarin beschreven beveiligingsinstellingen – bijvoorbeeld het verplicht inschakelen van schijfversleuteling, het uitschakelen van verouderde protocollen en het afdwingen van schermvergrendeling – kunnen via Intune‑policies worden afgedwongen en via compliance‑rapporten worden gemonitord. Door het eigen beleid te spiegelen aan deze benchmarks en afwijkingen bewust te motiveren, ontstaat een transparant en reproduceerbaar beveiligingsniveau dat goed te toetsen is door interne en externe auditors. Samengevat zorgt een volwassen inrichting van device compliance ervoor dat naleving niet alleen op papier maar ook in de dagelijkse praktijk aantoonbaar is, ondersteund door betrouwbare managementinformatie en audit‑evidence.

Monitoring

Gebruik PowerShell-script device-compliance-policies.ps1 (functie Invoke-Monitoring) – Controleren.

Remediatie

Gebruik PowerShell-script device-compliance-policies.ps1 (functie Invoke-Remediation) – Herstellen.

Compliance & Frameworks

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).

PowerShell
<# .SYNOPSIS Device Compliance Policies Design .DESCRIPTION Implementation for Device Compliance Policies Design .NOTES Filename: device-compliance-policies.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 Related JSON: content/design/platform/device-compliance-policies.json #> #Requires -Version 5.1 #Requires -Modules Microsoft.Graph [CmdletBinding()] param( [Parameter()][switch]$WhatIf, [Parameter()][switch]$Monitoring, [Parameter()][switch]$Remediation, [Parameter()][switch]$Revert ) $ErrorActionPreference = 'Stop' $VerbosePreference = 'Continue' $PolicyName = "Device Compliance Policies Design" $CISControl = "3.x" $BIOControl = "11.02" function Connect-RequiredServices { # Connection logic based on API } function Test-Compliance { Write-Verbose "Testing compliance for: $PolicyName..." $result = [PSCustomObject]@{ ScriptName = "device-compliance-policies" PolicyName = $PolicyName IsCompliant = $false TotalResources = 0 CompliantCount = 0 NonCompliantCount = 0 Details = @() Recommendations = @() } # Compliance check implementation # Based on: Design Document $result.Details += "Compliance check - implementation required based on control" $result.NonCompliantCount = 1 return $result } function Invoke-Remediation { Write-Host "`nApplying remediation for: $PolicyName..." -ForegroundColor Cyan # Remediation implementation Write-Host " Configuration applied" -ForegroundColor Green Write-Host "`n[OK] Remediation completed" -ForegroundColor Green } function Invoke-Monitoring { $result = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Total: $($result.TotalResources)" -ForegroundColor White Write-Host "Compliant: $($result.CompliantCount)" -ForegroundColor Green $color = if ($result.NonCompliantCount -gt 0) { "Red" } else { "Green" } Write-Host "Non-compliant: $($result.NonCompliantCount)" -ForegroundColor $color return $result } function Invoke-Revert { Write-Host "Revert: Configuration revert not yet implemented" -ForegroundColor Yellow } try { Connect-RequiredServices if ($Monitoring) { Invoke-Monitoring } elseif ($Remediation) { if ($WhatIf) { Write-Host "WhatIf: Would apply remediation" -ForegroundColor Yellow } else { Invoke-Remediation } } elseif ($Revert) { Invoke-Revert } else { $result = Test-Compliance if ($result.IsCompliant) { Write-Host "`n[OK] COMPLIANT" -ForegroundColor Green } else { Write-Host "`n[FAIL] NON-COMPLIANT" -ForegroundColor Red } } } catch { Write-Error $_ }

Risico zonder implementatie

Risico zonder implementatie
High: Non-compliant devices accessing corporate data = security gaps (unencrypted devices - data theft, outdated OS - vulnerabilities, no antivirus - malware). Conditional Access cannot enforce compliance. Het risico is HOOG - device security baseline.

Management Samenvatting

Device Compliance Policies: Minimum OS version (patch level), Encryption required (BitLocker/FileVault), Antivirus installed + updated, Firewall enabled, Jailbreak/root detection (block compromised), Password complexity, Device health attestation (TPM-based). Conditional Access BLOCKS non-compliant devices. Activatie: Intune → Compliance policies → CA enforcement. Gratis (Intune included M365). Verplicht BIO 11.02, ISO 27001, Zero Trust. Implementatie: 8-16 uur. CRITICAL Zero Trust foundation - device trust verification.