Koppel device compliance aan Microsoft 365-toegang met één vastgelegde keten waarin per apparaatcategorie duidelijk is wie de compliancestatus beoordeelt, wie de toegangsvoorwaarde beheert, wie de eerste diagnose uitvoert en waar escalatie plaatsvindt. Stem wijzigingen in endpointbeheer, toegangsbeleid en patchbeheer vooraf af, en beheer uitzonderingen met autorisatie, einddatum en herbeoordeling.
Kernpunten: device compliance en Microsoft 365-toegang
Een niet-compliant apparaat kan de toegang tot Exchange Online, SharePoint en Teams direct blokkeren. Bij meerdere IT-leveranciers voorkomt alleen expliciet eigenaarschap dat incidenten tussen endpointbeheer en Microsoft 365-beheer blijven liggen.
- Behandel apparaatstatus als een directe voorwaarde voor toegang, niet als een afzonderlijk endpointvraagstuk.
- Leg voor beheerde apparaten, BYOD en apparaten van externe medewerkers afzonderlijke verantwoordelijkheden en toegangsvarianten vast.
- Richt de eerste supportroute zo in dat direct duidelijk is of de oorzaak in apparaatbeheer, statusoverdracht of toegangsbeleid ligt.
- Beperk tijdelijke uitzonderingen met een formele aanvraag, autorisatie, einddatum en periodieke controle.
- Test beleidswijzigingen vooraf op hun gevolgen voor gebruikers en bespreek wijzigingen en uitzonderingen periodiek met alle betrokken beheerpartijen.
- Maak toegangsvoorwaarden, rechten en apparaatvalidaties controleerbaar bij onboarding, functiewijzigingen en offboarding.
Van apparaatstatus naar Microsoft 365-toegang: waar de verantwoordelijkheid begint
Device compliance is geen los endpointonderwerp zodra het als voorwaarde voor Microsoft 365-toegang wordt gebruikt. Entra ID kan een apparaat met een niet-compliant status afwijzen met AADSTS53000. Die autorisatiefout blokkeert de uitgifte van een geldig access token. De aanleiding kan lokaal op het apparaat liggen, samenhangen met de verbinding of voortkomen uit beheer; voor de toegangsbeslissing leidt datzelfde resultaat tot één uitkomst: geen geldig token.
Daardoor is de impact direct zichtbaar in de werkomgeving. Zonder token kan een medewerker geen toegang krijgen tot Exchange Online, SharePoint en Teams. Een wijziging in de beoordeling van apparaatstatus is dus niet uitsluitend een technische aanpassing in endpointbeheer. Wanneer die wijziging ongecoördineerd plaatsvindt, kan een groep medewerkers op hetzelfde moment de toegang tot deze diensten verliezen. De partij die de toegangsregel beheert, kan die blokkade zien, terwijl de partij die het apparaat beheert mogelijk eerst moet vaststellen waarom de status niet voldoet. Precies op dat raakvlak begint gedeeld eigenaarschap.
De samenstelling van het apparatenpark bepaalt hoeveel partijen en uitzonderingen in dat eigenaarschap passen. Een homogene vloot beheerde Windows-laptops laat zich anders organiseren dan een gemengde omgeving met persoonlijke mobiele apparaten en laptops van externe contractors. In de eerste situatie kan de relatie tussen apparaatbeheer en toegang worden ingericht rond één herkenbare categorie apparaten. In de tweede situatie moet de verantwoordelijke structuur rekening houden met verschillende typen apparaten en verschillende manieren waarop die apparaten tot toegang worden toegelaten.
Dat onderscheid hoort vooraf in de verantwoordelijkheidsmatrix te staan, niet pas bij de eerste blokkade. Leg daarom per apparaatcategorie vast wie de status beoordeelt, wie de toegangseis beheert en wie het eerste aanspreekpunt is wanneer AADSTS53000 optreedt. Zo wordt voorkomen dat een toegangsblokkade als uitsluitend Microsoft 365-probleem of uitsluitend laptopprobleem wordt behandeld. De technische keten is kort; de bestuurlijke keten moet vooral eenduidig zijn.
Bronnen bij deze sectie: microsoft.com, systunation.com, oneuptime.com, ncsc.nl
Een geblokkeerde aanmelding wordt traag opgelost als niemand de keten bezit
Na een apparaatvervanging kan de toegang tot Microsoft 365 vastlopen voordat duidelijk is welk team moet handelen. Lokale IT zet een defecte laptop om, maar rondt de MDM-enrollment van het vervangende apparaat niet af of verwijdert het oude Entra ID-object niet. De status van het nieuwe apparaat blijft dan op ‘Not Evaluated’ staan. Als een toepasselijke Conditional Access-policy vereist dat het apparaat als compliant is gemarkeerd, kan de gebruiker daardoor niet aanmelden.
De blokkade is dan het zichtbare symptoom van een onvolledige overdracht. Endpointbeheer ziet een onvoltooide enrollment; de Microsoft 365-beheerder ziet een afgewezen toegangsvoorwaarde. De eerste diagnose moet daarom vastleggen of de enrollment, het Entra ID-object of de toegepaste toegangsbeslissing als eerste wordt onderzocht. Ontbreekt die route, dan kan de melding als netwerkprobleem worden opgepakt of tussen beide teams worden teruggelegd. Herstel duurt daardoor onnodig lang, terwijl de gebruiker geen toegang heeft.
Deze situatie maakt ook de keuze voor het apparaatmodel concreet. Volledig beheerde bedrijfslaptops beperken contractrisico’s, maar verminderen de operationele wendbaarheid en verhogen de hardwarekosten. Een gedifferentieerd beleid met MAM en browser-only restricties biedt meer ruimte voor uiteenlopende gebruikerssituaties, maar laat meer toegangsvarianten naast elkaar bestaan.
Bij gescheiden endpoint- en Microsoft 365-beheer wordt een vervangende laptop daarmee een praktische toets voor de samenwerking tussen partijen. De afgesproken diagnoseroute moet direct duidelijk maken wie de volgende stap zet.
Bronnen bij deze sectie: microsoft.com, microsoft.com
Gesplitst beheer werkt alleen met beheerde uitzonderingen en voorspelbare wijzigingen
Intune beoordeelt lokale endpointtelemetrie, zoals BitLocker, OS-versie en Defender-status, en kent daaruit een binaire compliance-status toe. Die status wordt asynchroon naar Entra ID gerepliceerd. Pas wanneer een toepasselijke Conditional Access-policy die apparaatcompliance als grant control gebruikt, bepaalt die status of de policy toegang kan afdwingen. Endpointbeheer en het beheer van toegangsbeleid raken elkaar dus niet alleen bij een incident, maar ook bij iedere aanpassing die deze keten beïnvloedt.
Juist uitzonderingen maken gesplitst beheer kwetsbaar. Een servicedesk kan een complianceblokkade snel omzeilen door een gebruiker in een statische uitzonderingsgroep te plaatsen. Zonder automatische vervaldatum en periodieke hercertificering via access reviews blijft die tijdelijke afwijking bestaan, terwijl niemand opnieuw hoeft te beoordelen of zij nog gerechtvaardigd is. De uitzondering heeft daarom een eigen levenscyclus nodig: aanvraag, autorisatie, einddatum en herbeoordeling moeten als samenhangende stappen worden behandeld, niet als een losse servicedeskhandeling.
Ook een wijziging in Conditional Access vraagt een voorspelbare route. Een Report-Only-evaluatieperiode maakt zichtbaar wat de beoogde policy zou raken voordat deze wordt afgedwongen. De uitkomsten kunnen vervolgens in periodiek kwartaaloverleg worden beoordeeld naast openstaande uitzonderingen en voorgenomen beleidswijzigingen. Daarmee kunnen beide beheerpartijen tijdig vaststellen welke wijziging aan de endpointstatus of toegangskant gevolgen heeft voor de rest van de keten.
Bronnen bij deze sectie: systunation.com, ncsc.nl
Toegang en auditspoor zijn de twee criteria voor het verantwoordelijkheidsmodel
Een gedeeld beheermodel is alleen toetsbaar als twee afzonderlijke vragen met bewijs kunnen worden beantwoord: onder welke apparaatvoorwaarden is Microsoft 365-bedrijfsdata bereikbaar, en kan bij een personeelswijziging worden herleid welke rechten en apparaatvalidaties moeten worden gecontroleerd? De tabel houdt die vragen bewust apart. Daarmee blijft zichtbaar of de toegangseis en de controle daarop bij dezelfde of verschillende beheerpartijen liggen.
| Beoordelingslijn | Vast te leggen uitgangspunt | Benodigd bewijs |
|---|---|---|
| Toegangsbaseline | Cloudtoegang tot bedrijfsdata verloopt via beheerde of compliant endpoints, of via een goedgekeurde app-protection baseline. Beheerrechten zijn strikt gescheiden van de toegang tot de gegevens die worden beschermd. | Per toegangsvariant is vastgelegd welke endpointstatus of app-protection baseline toegang ondersteunt en welke beheerrechten daarbij horen. Zo is controleerbaar of een partij de toegangsvoorwaarde beheert zonder tegelijk onbeperkte toegang tot bedrijfsdata te krijgen. |
| Auditspoor | Toegangsrechten en apparaatvalidaties staan in een formele rechtenmatrix en zijn bij functiewijziging of uitdiensttreding direct controleerbaar. | De rechtenmatrix koppelt rechten en apparaatvalidaties aan de betreffende gebruiker en maakt die koppeling traceerbaar op het moment dat de functie of het dienstverband verandert. Daardoor is niet alleen de rolverdeling vastgelegd, maar ook wat op dat moment aantoonbaar moet worden nagegaan. |
De eerste lijn toetst de toegang zelf: een gebruikersaccount is niet het enige criterium wanneer bedrijfsdata alleen via een beheerd of compliant apparaat, of via goedgekeurde app protection, bereikbaar mag zijn. De tweede lijn toetst of de vastgelegde rechten en apparaatvalidaties bij een verandering in de arbeidsrelatie daadwerkelijk kunnen worden gecontroleerd. Ontbreekt een van beide, dan is óf de toegangsroute óf de onderbouwing ervan niet volledig te beoordelen.
Bronnen bij deze sectie: ncsc.nl, ncsc.nl, ncsc.nl, cisecurity.org
Leg overdrachten vast bij beleidswijzigingen, onboarding en offboarding
Gebruik de matrix niet als een algemene lijst met teams, maar als een werkblad voor overdrachtsmomenten. Per regel vult de organisatie een beslissingsbevoegde partij, een uitvoerende partij en een escalatiepunt in. De rollen kunnen bij interne IT, een endpointleverancier of een werkplekpartner liggen; de matrix schrijft die keuze niet voor. Zij maakt wel zichtbaar waar een handeling van de ene partij gevolgen heeft voor de volgende partij. Voor de bredere inrichting van een moderne werkplek is juist die zichtbaarheid bepalend voor een beheersbare overgang.
- Wijziging in Intune-compliancebaselines: leg vast wie de wijziging besluit, wie haar uitvoert en wie beoordeelt of de aangepaste status gevolgen heeft voor toegang. Een compliancebaseline staat niet op zichzelf: zij vormt input voor de status die later in de toegangsketen wordt gebruikt. Het escalatiepunt hoort daarom expliciet te zijn wanneer de verwachte apparaatstatus afwijkt van de uitkomst.
- Wijziging in Conditional Access-toewijzingen: benoem afzonderlijk wie de toewijzing aanpast en wie vooraf controleert welke apparaatpopulatie daardoor geraakt kan worden. Wanneer deze wijziging niet synchroon loopt met de compliancebaseline, ontstaat een operationele interfacekloof. Een apparaat kan dan volgens de ene beheerhandeling anders worden behandeld dan volgens de toegangsvoorwaarde.
- Lokaal patchbeheer: neem patchbeheer op als eigen matrixregel, ook wanneer het door een endpointleverancier wordt uitgevoerd. Een wijziging in lokale onderhoudsactiviteiten kan raken aan de endpointstatus, terwijl de partij voor Microsoft 365-toegang niet de uitvoerder is. De matrix maakt zichtbaar wie die afhankelijkheid registreert en bij een afwijking naar de eigenaar van de toegang opschaalt.
- Onboarding: behandel de start van een nieuwe medewerker als overdracht tussen HR, endpointbeheer en Microsoft 365. Zonder synchronisatie kunnen account, apparaat en toegangsstatus uiteenlopen. Dat kan leiden tot inlogstoringen voor nieuwe medewerkers. Leg daarom per stap vast welke gebeurtenis de volgende partij activeert en wie vaststelt dat de overdracht compleet is.
- Offboarding: leg eveneens vast wie de beëindiging van de arbeidsrelatie vertaalt naar de opvolgende acties rond endpointbeheer en Microsoft 365. Wanneer deze processen niet synchroon verlopen, kunnen verweesde apparaten met toegang achterblijven. De matrixregel moet daarom naast uitvoering ook het punt bevatten waarop een ontbrekende of afwijkende overdracht wordt geëscaleerd.
Bronnen bij deze sectie: systunation.com, ncsc.nl
Hard-block handhaving of gesplitst beheer: waar ligt de operationele grens?
De overdrachtsmatrix maakt ook zichtbaar wat de keuze voor hard-block handhaving of een beheermodel in de praktijk vraagt. De keuze gaat niet uitsluitend over de strengheid van toegang, maar ook over hoe vaak gebruikers, interne IT en leveranciers een overdracht moeten maken wanneer een apparaatstatus verandert.
- Wat betekent hard-block handhaving voor een medewerker?
Een strikte hard-block op device compliance verhoogt de endpointbeveiliging tegen kwetsbaarheden doordat toegang niet wordt verleend wanneer een apparaat niet aan de voorwaarde voldoet. De keerzijde is het risico dat een legitieme gebruiker onverwacht wordt buitengesloten wanneer software-updates vertraagd zijn. In dat geval is de blokkade een directe toegangsuitkomst, ook als de gebruiker zelf geen bewuste wijziging heeft gedaan. Operationeel verschuift de vraag dan naar de vastgelegde route: wie beoordeelt de status, wie behandelt de toegangsblokkade en wie beslist of een uitzondering passend is. - Wat onderscheidt integraal werkplekbeheer van gesplitst beheer?
Integraal werkplekbeheer onder één IT-partner vermindert overdrachten en escalatielussen tussen leveranciers. Dat vereenvoudigt de route van apparaatstatus naar toegang, omdat minder grenzen tussen partijen hoeven te worden overbrugd. Het model zegt echter niet dat iedere organisatie alle beheeronderdelen buiten de deur moet leggen. De relevante vergelijking is hoeveel overdrachtsmomenten de organisatie accepteert tegenover de mate van eigen regie die zij wil behouden. - Waarom vraagt gesplitst beheer om formelere afspraken?
Gesplitst beheer behoudt interne regie op hardware. Daar staat tegenover dat de interfaces tussen partijen zwaarder moeten worden vastgelegd. De afspraken moeten duidelijk maken wat een partij overdraagt, welke informatie de volgende partij nodig heeft en waar opschaling begint als endpointstatus en toegangsbeslissing niet op elkaar aansluiten. Zonder die formele grens blijft interne hardwareregie bestaan, maar wordt de oplossing van een blokkade afhankelijk van informele afstemming. - Is één model altijd beter?
Nee. Hard-block handhaving en integraal beheer verkleinen bepaalde overdrachten, terwijl zij andere gevolgen hebben voor gebruikers, hardwaresturing en organisatie-inrichting. Gesplitst beheer kan passend zijn wanneer interne regie op hardware gewenst is, mits de afspraken over interfaces het extra coördinatiewerk daadwerkelijk dragen. De operationele grens wordt bereikt wanneer een blokkade niet volgens de vastgelegde route kan worden opgepakt en doorgegeven.
Bronnen bij deze sectie: microsoft.com, systunation.com
Een werkbaar model verbindt rolverdeling met de eerste diagnose
Een RACI en een operationeel interfacemodel krijgen pas praktische betekenis op het eerste supportmoment. Daarin staan expliciete rollen voor eerste- en tweedelijnssupport, beleidswijzigingen en escalaties tussen klant en leverancier. Die vastlegging maakt zichtbaar wie een incident ontvangt, wie aanvullende analyse uitvoert en wie de bevoegdheid heeft om een beleids- of beheeractie in gang te zetten. Zonder deze verdeling is een matrix vooral een overzicht van betrokkenen, terwijl een geblokkeerde aanmelding juist een opvolgende route nodig heeft.
Die route begint met een onderscheid dat de eerste lijn direct kan maken. Gestandaardiseerde diagnostische beslisbomen en flowcharts helpen vaststellen of er sprake is van een lokale Intune-syncfout of van een Entra Conditional Access-beleidsblokkade. Het zijn verschillende uitkomsten die naar verschillende vervolgacties leiden. Een syncfout vraagt onderzoek naar de statusoverdracht vanuit het endpointdomein. Een beleidsblokkade vraagt onderzoek naar de toegepaste toegangsvoorwaarde. Als beide situaties onder één algemene melding ‘kan niet inloggen’ vallen, belandt het incident gemakkelijk bij de verkeerde partij.
De diagnoseroute hoort daarom dezelfde grenzen te volgen als de verantwoordelijkheidsmatrix. Per uitkomst moet de eerste lijn weten welke partij eigenaar is van de volgende analyse, welke informatie wordt overgedragen en wanneer de tweede lijn wordt betrokken. Beleidswijzigingen krijgen daarbij een eigen escalatiepad, omdat een supportactie niet automatisch een wijziging in toegangsbeleid rechtvaardigt. Zo blijft onderscheid bestaan tussen het herstellen van een fout en het besluit om de toegangseis te veranderen.
Een samenhangend gedeeld model bevat dus meer dan een taakverdeling: het beschrijft de handoff van melding naar diagnose, van diagnose naar eigenaar en van eigenaar naar escalatie. Daardoor kunnen teams een toegangsincident gericht opvolgen in plaats van eerst de onderlinge verantwoordelijkheden te moeten uitzoeken.
Bronnen bij deze sectie: microsoft.com, oneuptime.com