Microsoft Intune kan apparaten configureren, applicaties installeren en securityinstellingen afdwingen.
Maar vervolgens ontstaat een belangrijke vraag:
Hoe weet u of een apparaat daadwerkelijk voldoet aan uw beveiligingseisen?
Daarvoor gebruikt Microsoft Intune Compliance Policies.
Een Compliance Policy kan bijvoorbeeld beoordelen of een apparaat aan bepaalde voorwaarden voldoet. Het resultaat daarvan is een compliance status die vervolgens kan worden gebruikt voor monitoring, rapportage en — in combinatie met Microsoft Entra Conditional Access — toegangsbeslissingen.
Dat maakt compliance tot een belangrijke schakel tussen endpointbeheer en identity security.
Conceptueel:
Intune Configuration
↓
Endpoint Security
↓
Compliance Evaluation
↓
Compliant / Non-compliant
↓
Conditional Access
↓
Toegang tot bedrijfsresources
Een verkeerde compliancearchitectuur kan echter grote gevolgen hebben.
Wanneer requirements te streng, technisch onhaalbaar of onvoldoende getest zijn, kunnen grote aantallen apparaten plotseling non-compliant worden.
Daarom moet een Compliance Policy net zo zorgvuldig worden ontworpen als een securitypolicy.
Wat is een Compliance Policy in Microsoft Intune?
Een Compliance Policy definieert voorwaarden waaraan een beheerd apparaat moet voldoen om volgens uw organisatie als compliant te worden beschouwd.
Het gaat dus om evaluatie.
Een eenvoudige vergelijking:
| Functie | Vraag |
|---|---|
| Configuration Profile | Hoe moet het apparaat worden ingesteld? |
| Endpoint Security | Welke securitycontrols configureren we? |
| Compliance Policy | Voldoet het apparaat aan onze eisen? |
| Conditional Access | Mag deze gebruiker/devicecontext toegang krijgen? |
Deze vier onderdelen werken samen, maar hebben verschillende verantwoordelijkheden.
Configuration is niet hetzelfde als compliance
Dit onderscheid is een van de belangrijkste concepten binnen Intune.
Stel dat u BitLocker wilt gebruiken.
Een security- of configurationpolicy kan ervoor zorgen dat BitLocker op het apparaat wordt geconfigureerd.
Conceptueel:
Policy
→ BitLocker inschakelen.
Een Compliance Policy kan vervolgens beoordelen of het apparaat aan relevante beveiligingsvoorwaarden voldoet.
Conceptueel:
Compliance
→ voldoet dit apparaat aan de gestelde eis?
Daarna kan Conditional Access bijvoorbeeld eisen stellen aan de compliance status voordat toegang tot bepaalde cloudresources wordt toegestaan.
Dus:
Configure
↓
Evaluate
↓
Control Access
Gebruik compliance niet als vervanging voor configuration.
Begin met de vraag: wat betekent compliant?
Voordat u een policy maakt, moet de organisatie bepalen:
Wanneer vertrouwen wij een beheerd apparaat voldoende om het voor onze bedrijfsprocessen te gebruiken?
Dat is in eerste instantie een governance- en securityvraag.
Niet alleen een technische Intune-vraag.
Een mogelijke definitie kan zijn:
Een corporate Windows-apparaat is compliant wanneer het door de organisatie wordt beheerd en voldoet aan de vastgestelde minimale technische beveiligingseisen.
Daaruit kunnen concrete controls volgen.
Maak compliance meetbaar
Een requirement zoals:
Apparaten moeten veilig zijn.
is niet bruikbaar.
Een Compliance Policy heeft concrete, technisch toetsbare voorwaarden nodig.
Bijvoorbeeld:
| Businessrequirement | Technische vertaling |
|---|---|
| Data op laptops moet beschermd zijn | Encryptie vereist |
| Device moet vertrouwde boot ondersteunen | Secure Boot vereist |
| Endpoint moet malwarebescherming hebben | Antivirus vereist |
| Netwerkverkeer moet lokaal beschermd zijn | Firewall vereist |
| Oude systemen mogen niet gebruikt worden | Minimale OS-versie |
| Device mag niet eenvoudig gecompromitteerd zijn | Relevante integrity/security checks |
De exacte technische controls hangen af van platform, licenties, architectuur en securityrequirements.
Gebruik een minimale compliancebaseline
Begin niet direct met iedere mogelijke compliancevoorwaarde.
Een baseline moet vooral de belangrijkste voorwaarden controleren.
Voor een corporate Windows-omgeving kan het ontwerp bijvoorbeeld kijken naar:
encryptie
antivirus
antispyware
firewall
Secure Boot
relevante device security-status
minimale ondersteunde OS-versie
De exacte instellingen moeten worden afgestemd op de eigen omgeving.
Het ontwerpprincipe is:
Controleer alleen zaken waarvan u begrijpt waarom ze belangrijk zijn én wat er gebeurt wanneer een apparaat niet voldoet.
Waarom een te complexe Compliance Policy riskant is
Iedere extra compliancevoorwaarde creëert een extra reden waarom een apparaat non-compliant kan worden.
Stel dat uw policy vijftien voorwaarden controleert.
Dan hoeft slechts één voorwaarde te falen om gevolgen te veroorzaken.
Wanneer compliance vervolgens aan Conditional Access wordt gekoppeld, kan een kleine technische afwijking uiteindelijk leiden tot verlies van toegang tot bedrijfsresources.
Daarom moet iedere compliancevoorwaarde deze test doorstaan:
Is de requirement noodzakelijk?
Kan Intune deze betrouwbaar beoordelen?
Kunnen onze apparaten eraan voldoen?
Kan de gebruiker het probleem herstellen?
Kan de servicedesk het probleem ondersteunen?
Is de impact van failure acceptabel?
Zo niet, heroverweeg de control.
Compliance moet aansluiten op configuration
Een belangrijk ontwerpprincipe is dat compliance geen eisen stelt die de organisatie zelf niet ondersteunt.
Bijvoorbeeld:
Compliance vereist encryptie
maar:
Intune configureert encryptie nergens
Dan verwacht u van endpoints een toestand die u zelf niet structureel beheert.
Een sterkere architectuur is:
Requirement
↓
Configuration/Security Policy
↓
Device ontvangt configuratie
↓
Compliance controleert resultaat
↓
Remediation indien nodig
↓
Access control
Configuration en compliance moeten dus als één keten worden ontworpen.
Maak een compliance control matrix
Een praktische methode is een matrix waarin iedere compliance-eis wordt gekoppeld aan de manier waarop de gewenste toestand wordt gerealiseerd.
Bijvoorbeeld:
| Compliance-eis | Configuratiebron | Owner | Remediation |
|---|---|---|---|
| Encryption | BitLocker Policy | Endpoint | Recovery/troubleshooting |
| Antivirus | Defender Policy | Security | Defender remediation |
| Firewall | Firewall Policy | Security | Policy/device check |
| Secure Boot | Hardware/OS | Endpoint | Hardware/firmware analyse |
| Minimum OS | Update Management | Endpoint | Windows Update |
| Device integrity | Security platform | Security | Incidentproces |
Hiermee voorkomt u losse compliancevoorwaarden zonder operationele eigenaar.
Maak onderscheid tussen corporate en BYOD
Niet ieder apparaat kan of moet aan dezelfde voorwaarden voldoen.
Een zakelijke Windows-laptop die volledig door IT wordt beheerd is fundamenteel anders dan een persoonlijke smartphone waarop alleen bedrijfsapplicaties worden beschermd.
Daarom kan de architectuur verschillende modellen gebruiken.
Bijvoorbeeld:
Corporate Windows
→ MDM
→ volledige configuration
→ endpoint security
→ device compliance
→ Conditional Access
Personal Mobile
→ beperkte of geen volledige device management, afhankelijk van strategie
→ App Protection
→ application-level data protection
→ passende Conditional Access-strategie
Probeer niet één complianceconcept op ieder scenario te forceren.
Maak platform-specifieke compliance policies
Windows, macOS, iOS/iPadOS en Android hebben verschillende beveiligingsmodellen.
Daarom is een platformgerichte architectuur logischer dan één abstracte universele baseline.
Bijvoorbeeld:
WIN-CMP-Corporate
IOS-CMP-Corporate
AND-CMP-Corporate
MAC-CMP-Corporate
Iedere policy kan aansluiten op de relevante mogelijkheden van het platform.
Gebruik duidelijke naming
Net als bij Configuration Profiles en Endpoint Security policies moet een Compliance Policy herkenbaar zijn.
Een mogelijke conventie:
[Platform] – CMP – [Scope] – [Variant]
Bijvoorbeeld:
WIN – CMP – Corporate – Standard
IOS – CMP – Corporate – Standard
AND – CMP – Corporate – Standard
MAC – CMP – Corporate – Standard
Of compacter:
WIN-CMP-Corporate
Consistentie is belangrijker dan de exacte syntax.
Denk na over de minimale OS-versie
Een Compliance Policy kan worden gebruikt om voorwaarden te stellen aan de ondersteunde OS-versie.
Dat kan securityvoordelen bieden.
Maar er is een belangrijk risico.
Stel dat u op maandagochtend een minimale versie instelt die veel apparaten nog niet hebben.
Die apparaten kunnen vervolgens non-compliant worden.
Wanneer compliance gekoppeld is aan Conditional Access, kan dat gebruikersimpact veroorzaken.
Daarom moet OS-compliance aansluiten op update management.
Conceptueel:
Update beschikbaar
↓
Pilot
↓
Productie-uitrol
↓
Adoption monitoren
↓
Pas daarna minimum requirement verhogen
Zo werken updatebeheer en compliance samen.
Gebruik geen onrealistische OS-requirements
Een policy die altijd de nieuwste versie eist, klinkt veilig.
Maar wanneer apparaten onvoldoende tijd krijgen om updates te installeren, creëert u operationele problemen.
Gebruik een gecontroleerde security window.
Bijvoorbeeld:
Update release
↓
Test
↓
Deployment
↓
Grace period
↓
Compliance requirement
De exacte tijdslijnen zijn afhankelijk van de risico’s en processen van uw organisatie.
Wat betekent non-compliant?
Een apparaat kan om verschillende redenen niet aan de gestelde eisen voldoen.
Denk bijvoorbeeld aan:
- encryptie ontbreekt;
- securitycontrol is uitgeschakeld;
- OS-versie is te oud;
- apparaat rapporteert onvoldoende status;
- een vereiste instelling ontbreekt;
- evaluatie is nog niet voltooid;
- device heeft langere tijd niet correct gesynchroniseerd.
Daarom is:
Non-compliant = gehackt
geen correcte conclusie.
Non-compliance betekent in de eerste plaats:
Het apparaat voldoet op dat moment niet aan één of meer gedefinieerde compliancevoorwaarden.
De oorzaak moet vervolgens worden onderzocht.
Maak onderscheid tussen securityincident en beheerprobleem
Een non-compliant apparaat kan een securityrisico aangeven.
Maar het kan ook een operationeel probleem zijn.
Bijvoorbeeld:
Securityincident
Malwarebescherming bewust uitgeschakeld.
Beheerprobleem
Device heeft policy nog niet ontvangen.
Updateprobleem
OS-versie loopt achter.
Hardwareprobleem
Vereiste functionaliteit wordt niet ondersteund.
Rapportageprobleem
Device heeft langere tijd niet correct ingecheckt.
Daarom moet de servicedesk niet iedere non-compliancemelding hetzelfde behandelen.
Actions for noncompliance
Een essentieel onderdeel van complianceontwerp is bepalen wat er gebeurt wanneer een apparaat niet voldoet.
Conceptueel kan het proces zijn:
Device voldoet niet
↓
Non-compliant status
↓
Gebruiker informeren
↓
Grace/remediationperiode
↓
Probleem herstellen
↓
Device opnieuw evalueren
↓
Compliant
of:
↓
Blijvend non-compliant
↓
Escalatie / access impact
De exacte mogelijkheden en acties moeten aansluiten op het platform en uw Intune-configuratie.
Geef gebruikers tijd om problemen op te lossen waar passend
Niet iedere afwijking hoeft onmiddellijk tot blokkering te leiden.
Stel dat een laptop één update achterloopt.
Wanneer de gebruiker direct geen toegang meer krijgt tot Microsoft 365, kan dat disproportioneel zijn.
Een mogelijke aanpak is:
Detect
↓
Inform
↓
Remediate
↓
Re-evaluate
↓
Enforce indien noodzakelijk
Voor kritieke risico’s kan een kortere reactietijd nodig zijn.
Gebruik dus een risicogebaseerde aanpak.
Ontwerp de gebruikerservaring
Compliance is niet alleen een technische status in een portal.
Voor een eindgebruiker kan non-compliance betekenen:
Mijn e-mail werkt niet.
Teams opent niet.
Ik krijg geen toegang tot SharePoint.
Mijn laptop zegt dat er iets moet worden aangepast.
Daarom moet de organisatie bepalen:
Welke melding ziet de gebruiker?
Begrijpt de gebruiker wat er mis is?
Kan de gebruiker het zelf oplossen?
Waar vindt de gebruiker instructies?
Wanneer moet de servicedesk worden gebeld?
Welke informatie ziet de servicedesk?
Een technisch perfecte policy met een slechte gebruikerservaring veroorzaakt supporttickets.
Maak remediation-instructies concreet
Een melding zoals:
Your device is non-compliant.
helpt weinig.
Beter is dat het ondersteuningsproces kan uitleggen:
Uw apparaat voldoet niet aan de vereiste Windows-versie. Open Windows Update, installeer de beschikbare updates, start het apparaat opnieuw op en synchroniseer daarna opnieuw.
Of:
De beveiligingsstatus van uw apparaat kan niet worden bevestigd. Neem contact op met de servicedesk en vermeld foutcode of status X.
De precieze communicatie hangt af van de oorzaak.
Test non-compliance bewust
Veel organisaties testen alleen een compliant apparaat.
Maar u moet juist ook gecontroleerd testen wat er gebeurt wanneer iets fout gaat.
Bijvoorbeeld:
Testcase 1
Compliant apparaat → toegang werkt.
Testcase 2
Relevante securityvoorwaarde ontbreekt → device wordt non-compliant.
Testcase 3
Probleem wordt hersteld → device wordt weer compliant.
Testcase 4
Device blijft non-compliant → afgesproken vervolgactie treedt op.
Testcase 5
Gebruiker krijgt begrijpelijke instructies.
Testcase 6
Servicedesk kan oorzaak vinden.
Dit is veel waardevoller dan alleen controleren of een groene status verschijnt.
Gebruik een pilot voordat compliance gevolgen krijgt
Een nieuwe Compliance Policy moet eerst worden gevalideerd.
Bijvoorbeeld:
| Ring | Doel |
|---|---|
| Ring 0 | Endpoint/Security |
| Ring 1 | IT Pilot |
| Ring 2 | Business Pilot |
| Ring 3 | Early Production |
| Ring 4 | Broad Production |
Monitor tijdens de pilot:
- hoeveel devices compliant zijn;
- waarom devices non-compliant zijn;
- onverwachte hardwareverschillen;
- gebruikersimpact;
- remediation;
- supporttickets;
- false positives of onverwachte evaluaties.
Pas daarna breidt u de scope uit.
Conditional Access komt pas daarna
Een veelgemaakte fout is tegelijkertijd:
een nieuwe Compliance Policy maken
en:
Conditional Access direct afdwingen
Daarmee combineert u twee veranderingen.
Als gebruikers vervolgens worden geblokkeerd, weet u minder snel waar het probleem zit.
Een betere volgorde:
1. Compliance Policy ontwerpen
↓
2. Policy testen
↓
3. Compliance data analyseren
↓
4. Problemen oplossen
↓
5. Businesspilot
↓
6. Compliance stabiel maken
↓
7. Conditional Access apart testen
↓
8. Gefaseerd enforce
Dit maakt troubleshooting aanzienlijk eenvoudiger.
Gebruik compliance niet als enige securitymaatregel
Een groene compliance status betekent niet dat een apparaat gegarandeerd veilig is.
Compliance beoordeelt specifieke gedefinieerde voorwaarden.
Een apparaat kan aan die voorwaarden voldoen en toch andere risico’s hebben.
Daarom is compliance één onderdeel van een bredere securityarchitectuur:
Identity Security
Endpoint Configuration
Endpoint Security
Threat Detection
Compliance
Conditional Access
Monitoring
Incident Response
Compliance is een control, geen volledige securitystrategie.
Compliance en Zero Trust
Binnen een Zero Trust-benadering wordt toegang niet uitsluitend vertrouwd omdat een gebruiker zich op een intern netwerk bevindt.
Identity, device state en andere signalen kunnen onderdeel zijn van toegangsbeslissingen.
Compliance kan daarbij een relevant devicesignaal vormen.
Conceptueel:
Wie bent u?
Identity
Welk apparaat gebruikt u?
Device
Voldoet het apparaat aan de voorwaarden?
Compliance
Wat probeert u te openen?
Resource
Onder welke omstandigheden?
Context
↓
Access decision
Dit maakt endpointbeheer onderdeel van access security.
Pas op voor één gigantische Compliance Policy
Net als bij Configuration Profiles kan één enorme policy moeilijk te beheren worden.
Maar ook hier moet u niet doorslaan naar één policy per instelling.
De juiste granulariteit wordt bepaald door:
- platform;
- doelgroep;
- securityniveau;
- ownership;
- lifecycle;
- uitzonderingen.
Voor veel organisaties kan één duidelijke standaardpolicy per platform of beheerscenario voldoende zijn, eventueel aangevuld met specifieke policies voor afwijkende risicoprofielen.
Standaardbaseline plus verhoogde eisen
Een bruikbaar model is:
Standard Corporate Baseline
voor het grootste deel van de organisatie.
Daarboven eventueel:
Enhanced Security Requirements
voor specifieke hoog-risico scenario’s.
Bijvoorbeeld privileged endpoints.
Hiermee voorkomt u dat iedere afdeling een eigen compliancebeleid krijgt.
HR en Finance hebben verschillende applicaties, maar hoeven niet automatisch verschillende fundamentele endpoint security-eisen te hebben.
Uitzonderingen op compliance
Soms kan een apparaat tijdelijk niet aan een bepaalde requirement voldoen.
Bijvoorbeeld vanwege:
- legacy hardware;
- gespecialiseerde software;
- migratie;
- tijdelijke technische beperkingen.
Maak hiervan geen ongedocumenteerde permanente uitzondering.
Registreer:
| Veld | Inhoud |
|---|---|
| Device/populatie | Welke endpoints |
| Requirement | Welke control |
| Reden | Waarom uitzondering |
| Risico | Securityimpact |
| Compensating control | Alternatieve maatregel |
| Owner | Verantwoordelijke |
| Approval | Security/Risk |
| Reviewdatum | Herbeoordeling |
| Einddatum | Waar mogelijk |
Zo blijft uitzondering governance beheersbaar.
Vermijd VIP-exceptions
Een executive laptop is niet automatisch een goede kandidaat voor minder security.
Integendeel: accounts van senior medewerkers kunnen toegang hebben tot zeer waardevolle informatie.
Wanneer een compliance-uitzondering nodig is, moet de reden technisch of risicogebaseerd zijn.
Niet:
Deze gebruiker is belangrijk.
Maar bijvoorbeeld:
Deze gespecialiseerde applicatie ondersteunt control X tijdelijk niet; risico is beoordeeld en compensating control Y is actief.
Monitor compliance trends
Kijk niet alleen naar de huidige compliancepercentage.
Bekijk trends.
Bijvoorbeeld:
| Metric | Week 1 | Week 2 | Week 3 |
|---|---|---|---|
| Compliant | 98,4% | 97,9% | 94,2% |
| Non-compliant | 1,1% | 1,6% | 5,1% |
| Unknown/overig | 0,5% | 0,5% | 0,7% |
De daling in week 3 is belangrijker dan het losse percentage.
Vraag:
Wat is veranderd?
Nieuwe update?
Nieuwe compliancevoorwaarde?
Policyprobleem?
Nieuwe devices?
Rapportageprobleem?
Trendanalyse helpt structurele problemen te ontdekken.
Definieer compliance-KPI’s
Voorbeelden van operationele KPI’s:
| KPI | Voorbeeld |
|---|---|
| Corporate devices compliant | ≥ 98% |
| Kritieke non-compliance | 0 onbeheerde gevallen |
| Devices zonder recente status | Onder afgesproken grens |
| Non-compliance zonder owner | 0 |
| Gemiddelde remediationtijd | Volgens SLA |
| Exceptions voorbij reviewdatum | 0 |
| Compliance-related incidents | Trend monitoren |
Gebruik percentages niet blind.
Een organisatie met 10.000 apparaten en 98% compliance heeft nog steeds 200 apparaten buiten de norm.
Maak een non-compliance workflow
Een volwassen omgeving heeft een proces.
Bijvoorbeeld:
Intune detecteert non-compliance
↓
Classificatie
Security / Update / Configuration / Hardware / Unknown
↓
Gebruikersremediation
waar mogelijk
↓
Service Desk
indien nodig
↓
Endpoint Team
voor technisch beheerprobleem
↓
Security Team
bij securityincident of risico
↓
Herstel
↓
Re-evaluation
↓
Closure
Hiermee wordt compliance onderdeel van IT operations.
Geef de servicedesk voldoende informatie
De servicedesk moet minimaal kunnen bepalen:
welk device betroffen is;
welke compliancevoorwaarde faalt;
wanneer het probleem begon;
of het device recent heeft ingecheckt;
welke standaardremediation bestaat;
wanneer escalatie noodzakelijk is.
Maak hiervoor runbooks.
Bijvoorbeeld:
Runbook: Windows device non-compliant door OS-version
Runbook: Encryption status
Runbook: Firewall status
Runbook: Device niet recent gesynchroniseerd
Hierdoor worden problemen sneller en consistenter opgelost.
Voorbeeld: compliancearchitectuur voor 500 Windows-laptops
Stel dat een organisatie 500 Windows 11-laptops beheert.
Een conceptuele keten kan zijn:
Configuration
Windows Configuration Profiles
↓
Security
BitLocker + Defender + Firewall + ASR
↓
Updates
Windows Update management
↓
Compliance
WIN-CMP-Corporate
↓
Conditional Access
Compliant device vereist voor geselecteerde resources
↓
Monitoring
Endpoint + Security + Service Desk
De compliancebaseline kan een beperkte set kritieke voorwaarden bevatten.
Afwijkingen worden eerst gemonitord en hersteld voordat bredere access enforcement plaatsvindt.
Voorbeeld van gefaseerde invoering
Fase 1 — Baseline ontwerpen
Requirements en controls bepalen.
Fase 2 — Configuration valideren
Kunnen endpoints daadwerkelijk voldoen?
Fase 3 — Compliance monitoren
Policy implementeren zonder direct zware accessgevolgen.
Fase 4 — Pilot remediation
Test non-compliance en herstelprocessen.
Fase 5 — Businesspilot
Representatieve gebruikers.
Fase 6 — Conditional Access pilot
Compliance gebruiken als access signal.
Fase 7 — Gefaseerde productie
Steeds grotere populaties.
Fase 8 — Operations
Monitoring, remediation, reporting en review.
Dit scheidt technische implementatie van access enforcement.
Veelgemaakte fouten met Intune Compliance Policies
Te veel voorwaarden
Iedere extra control creëert een nieuwe failure condition.
Compliance eisen zonder configuration
De organisatie eist iets dat zij niet centraal realiseert.
Nieuwe compliance en Conditional Access tegelijk activeren
Troubleshooting wordt moeilijker.
Geen grace/remediationstrategie
Een klein probleem veroorzaakt direct grote gebruikersimpact.
Geen negatieve tests
Alleen compliant devices worden getest.
Geen servicedeskproces
Gebruikers worden geblokkeerd maar niemand weet waarom.
Te strenge OS-versie
Update management loopt achter op compliance.
BYOD hetzelfde behandelen als corporate
Verschillende beheermodellen worden genegeerd.
Te veel exceptions
De baseline verliest betekenis.
Compliance gelijkstellen aan security
Een groen vinkje wordt ten onrechte als bewijs van volledige veiligheid beschouwd.
Compliance Policy checklist
Controleer vóór productie:
✓ de definitie van compliant is vastgelegd;
✓ requirements zijn meetbaar;
✓ iedere requirement heeft een business- of securityreden;
✓ configuration en compliance zijn op elkaar afgestemd;
✓ iedere control heeft een owner;
✓ remediation is mogelijk of bewust afgehandeld;
✓ platform-specifieke policies zijn ontworpen;
✓ corporate en BYOD zijn onderscheiden;
✓ naming convention is toegepast;
✓ minimum OS-requirements sluiten aan op update management;
✓ non-compliance is bewust getest;
✓ recovery naar compliant is getest;
✓ gebruikerscommunicatie is voorbereid;
✓ servicedesk-runbooks zijn beschikbaar;
✓ deployment rings worden gebruikt;
✓ businesspilot is uitgevoerd;
✓ compliance is stabiel vóór Conditional Access enforcement;
✓ exceptions zijn gedocumenteerd;
✓ KPI’s zijn vastgesteld;
✓ monitoring is ingericht;
✓ periodieke review is gepland.
Wanneer is een apparaat werkelijk compliant?
Technisch gezien bepaalt Intune de compliance status op basis van de policies en voorwaarden die u configureert.
Maar architectonisch is de belangrijkere vraag:
Hebben we de juiste voorwaarden gekozen om voldoende vertrouwen in het apparaat te ondersteunen?
Dat vereist meer dan een portalconfiguratie.
Het vereist samenwerking tussen:
Endpoint Management
Security
Identity
Risk/Compliance
Service Desk
Business
Een goede Compliance Policy is daardoor niet alleen een technische policy.
Het is een vertaling van organisatiebeleid naar meetbare endpointvoorwaarden.
Van compliance naar toegangscontrole
Zodra compliance betrouwbaar functioneert, ontstaat de volgende stap.
U weet nu:
wie de gebruiker is;
welk apparaat wordt gebruikt;
of het apparaat wordt beheerd;
of het apparaat aan uw compliancevoorwaarden voldoet.
Nu kunt u bepalen:
Mag deze combinatie toegang krijgen tot Microsoft 365 en andere bedrijfsresources?
Daarvoor komt Microsoft Entra Conditional Access in beeld.
De belangrijke uitdaging wordt dan:
Hoe koppelt u Intune-compliance aan Conditional Access zonder gebruikers onbedoeld buiten te sluiten?
Dat is de volgende stap in de architectuur.
Verder lezen over Microsoft Intune
Lees ook:
Microsoft Intune: complete gids voor modern endpointbeheer
Microsoft Intune implementeren: stappenplan van voorbereiding tot productie
Microsoft Intune basisconfiguratie: welke instellingen moet u als eerste configureren?
Hulp nodig met uw Intune Compliance Policies?
Worden apparaten onverwacht non-compliant?
Wilt u compliance koppelen aan Conditional Access, maar wilt u voorkomen dat gebruikers onbedoeld worden geblokkeerd?
Of wilt u eerst een betrouwbare compliancebaseline ontwerpen voor Windows, macOS, iOS of Android?
Stel uw Intune-vraag — uw eerste vraag is gratis.
Beschrijf kort uw omgeving, het gebruikte platform en het complianceprobleem waar u tegenaan loopt. Wij geven u een eerste praktisch advies over de mogelijke oorzaak, oplossing of vervolgstappen.