De vragenset van Cyber Essentials wijzigde op 27 april 2026. De Danzell-versie introduceerde iets dat het schema nog niet had: vragen waarbij een verkeerd antwoord de beoordeling direct afkeurt in plaats van een score te verlagen. Verschillende daarvan landen recht op Microsoft 365, en twee ervan betrappen dingen die de meeste tenants stilletjes al jaren meedragen.
We hebben zelf Cyber Essentials, dus dit is geschreven vanuit het doorlopen ervan en niet vanuit het lezen van de specificatie.
Dit is een checklist om te doorlopen voordat u indient, geen vervanging van de officiële vragenset van IASME.
De wijziging die mensen verrast
Twee dingen tellen zwaarder dan de rest.
Vragen over multifactorauthenticatie kunnen u nu direct afkeuren. Eerder was een onvolmaakte MFA-positie iets dat u toelichtte. Nu is het, voor de accounts binnen scope, geslaagd of gezakt.
Er is een formele definitie van clouddiensten binnen scope. Dit sluit het gat waarmee organisaties konden beweren dat Microsoft 365 buiten de beoordelingsgrens viel. Als uw gebruikers erop inloggen en er organisatiegegevens in staan, valt het binnen scope. Die discussie is voorbij.
Samen betekenen ze dat de beoordeling nu reikt tot plekken die vroeger met rust werden gelaten.
Dat verandert de aard van het werk. Een vraag die direct afkeurt is niet iets waarop u een zorgvuldig antwoord schrijft; u kunt hem eerlijk bevestigend beantwoorden of niet. De oefening wordt inventarisatie in plaats van formuleren: een lijst van elke identiteit die kan authenticeren, wat die authenticeert, en wat er zou breken als u het wijzigde. Die lijst opstellen is het meeste werk. Het herstel is meestal snel.
De volgorde die een geslaagde Cyber Essentials herhaalbaar houdt: eerst inventariseren, dan beslissen, dan wijzigen, en het bewijs bewaren.
De twee die mensen echt betrappen
Serviceaccounts
Elke tenant heeft ze. Het account dat een geplande export draait. Het account waarmee een line-of-business-applicatie authenticeert. Het account dat in 2021 voor een migratie werd aangemaakt en dat niemand heeft uitgezet.
Ze hebben meestal geen MFA, omdat MFA zou breken wat ze automatiseren. Dat was te verdragen toen de vraag werd gescoord. Nu niet meer.
Vind ze voordat u erover discussieert. Twee weergaven geven u de kandidatenlijst in ongeveer tien minuten:
- Microsoft Entra-beheercentrum, Beveiliging, Verificatiemethoden, Registratiegegevens van gebruikers. Dit rapport toont elk account en of het MFA-geschikt en geregistreerd is. Filter op de accounts zonder registratie en u kijkt naar uw blootstelling.
- Entra ID, Bewaking, Aanmeldingslogboeken, gefilterd op niet-interactieve gebruikersaanmeldingen. Automatisering verschijnt hier en niet in het interactieve logboek. Een account met duizenden niet-interactieve aanmeldingen en geen geregistreerde methode is een serviceaccount, hoe iemand het ook noemde.
Dezelfde lijst komt uit Microsoft Graph PowerShell als CSV:
Connect-MgGraph -Scopes 'AuditLog.Read.All','Directory.Read.All'
Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
Where-Object { -not $_.IsMfaRegistered } |
Select-Object UserPrincipalName, IsAdmin, IsMfaCapable |
Export-Csv .\no-mfa.csv -NoTypeInformation
Wat u moet doen, in volgorde van voorkeur:
- Vervang het account volledig. Een workload-identiteit of beheerde identiteit is het juiste antwoord voor alles dat onbeheerd draait. Geen interactieve aanmelding, geen MFA-vraag, geen gedeeld geheim in een configuratiebestand.
- Als het een account moet blijven, verwijder dan de rechten voor interactief aanmelden, baken het strak af met voorwaardelijke toegang, en zorg dat u kunt aantonen wat het wel en niet kan.
- Leg vast waarom het bestaat. Een auditor accepteert een beheerste uitzondering veel makkelijker dan een account dat niemand kan verklaren.
Een uitgewerkt voorbeeld maakt de keuze concreet. Een financiële export draait 's nachts onder een gelicentieerd account met een wachtwoord in een geplande taak. Het juiste antwoord verplaatst hem naar een app-registratie met certificaatgegevens en alleen de Graph-machtigingen die de export nodig heeft, waarmee het account en het wachtwoord samen verdwijnen. Kan de applicatie dat nog niet, houd dan het account, blokkeer interactief aanmelden, beperk het met voorwaardelijke toegang tot die ene dienst, en leg de compenserende maatregel vast.
De faalmodus hier is dat u deze pas ontdekt in de week dat u indient. Ze zijn er altijd meer dan verwacht.
Gedeelde postvakken
Dit is degene die mensen verrast. Een gedeeld postvak hoort helemaal geen ingeschakelde aanmelding te hebben. Toegang hoort gedelegeerd te worden aan met naam genoemde gebruikers die hun eigen MFA hebben.
In de praktijk hebben veel tenants gedeelde postvakken met een ingeschakeld onderliggend account en een wachtwoord dat iemand kent, meestal jaren geleden aangemaakt zodat een telefoon of een scanner e-mail kon versturen. Dat is een account met een wachtwoord en zonder MFA, dat organisatiegegevens bevat, en de nieuwe vragenset heeft daar een mening over.
Controleer elk gedeeld postvak op een ingeschakelde aanmelding:
Connect-ExchangeOnline
Connect-MgGraph -Scopes 'User.Read.All'
Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited |
ForEach-Object { Get-MgUser -UserId $_.ExternalDirectoryObjectId -Property UserPrincipalName,AccountEnabled } |
Where-Object { $_.AccountEnabled } |
Select-Object UserPrincipalName
Alles dat terugkomt heeft geblokkeerde aanmelding nodig, in het Entra-beheercentrum onder Gebruikers of met Update-MgUser -UserId <upn> -AccountEnabled:$false. Delegeer toegang aan met naam genoemde mensen met Add-MailboxPermission voor volledige toegang en Add-RecipientPermission voor verzenden-als, zodat elke actie tegen dat postvak toebehoort aan een identiteit met eigen MFA.
Als iets echt onbeheerd e-mail moet versturen, is dat een probleem van applicatiemachtigingen en niet van een postvakwachtwoord. Verplaats het naar een app-registratie met strak afgebakende e-mailmachtigingen, of naar een ontvangstconnector die beperkt is tot een bekend statisch adres. Waar basis-SMTP-authenticatie nog is ingeschakeld, sluit Set-CASMailbox -Identity <mailbox> -SmtpClientAuthenticationDisabled $true het per postvak en sluit de equivalente instelling op Set-TransportConfig het organisatiebreed. Controleer eerst wat elk apparaat ondersteunt: een multifunctioneel apparaat dat stilletjes stopt met scannen naar e-mail is een supportwachtrij waarvoor niemand u bedankt.
De rest van de checklist
Elk gebruikersaccount met een licentie heeft MFA. Niet "we hebben beleid". Verifieer de handhaving, inclusief accounts die zijn aangemaakt sinds het beleid werd geschreven, gasten, en iedereen die is uitgesloten van voorwaardelijke toegang. Lees specifiek de uitsluitingen op elk beleid, want daar zit de afwijking: een projectgroep die in 2024 voor veertien dagen is toegevoegd, een leveranciersaccount, een directoryrol die de regel stilletjes omzeilt.
Gastaccounts zijn in kaart gebracht. Gasten authenticeren in hun eigen tenant, dus hun MFA kan elders zijn voldaan, en instellingen voor toegang tussen tenants bepalen of uw tenant die claim vertrouwt. U hoeft hier geen bepaalde keuze te maken, maar u moet wel weten welke keuze u hebt gemaakt.
Noodtoegangsaccounts zijn een gedocumenteerde uitzondering. Accounts voor noodtoegang zijn toegestaan. Van u wordt verwacht dat u ze beheerst en bewaakt: twee accounts die alleen in de cloud bestaan, uitgesloten van het beleid dat iedereen zou kunnen buitensluiten, met gesplitste en fysiek bewaarde inloggegevens, en een waarschuwing die afgaat zodra een van beide inlogt. De huidige richtlijn geeft de voorkeur aan een phishingbestendige methode boven alleen een wachtwoord, dus beoordeel dat als het tweetal enkele jaren oud is.
Beheerdersaccounts staan los van dagelijkse accounts. Een beheerder die vanuit dezelfde identiteit e-mail doorneemt is een bevinding die staat te wachten. Waar de licentie het ondersteunt, geeft just-in-time-verhoging via Privileged Identity Management u de scheiding en een kant-en-klaar overzicht van wie welke rol had en wanneer.
Legacy authenticatie staat uit. Als basisauthenticatie nog ergens bij kan, is het MFA-antwoord in de praktijk niet waar. Filter de aanmeldingslogboeken op een clienttoepassing van "Andere clients" en kijk wat er verschijnt. De meeste legacy protocollen in Exchange Online zijn allang uitgefaseerd, maar SMTP-authenticatie is degene die vaak overleeft omdat iets operationeels ervan afhangt.
Uw bewijs van apparaatpatching is exporteerbaar. Het schema geeft om de staat van apparaten, en het antwoord moet komen uit iets dat u kunt tonen in plaats van beweren. Intune kan het produceren, en dat aantonen vanuit Intune is een aparte oefening die het waard is te doen voordat u hem nodig hebt. Wat u wilt is een gedateerde export van build- en updatecompliance per apparaat, geen schermafbeelding van een dashboard dat er volgende week anders uitziet.
Uw scopeverklaring komt overeen met de werkelijkheid. Nu clouddiensten formeel zijn gedefinieerd, is een onnauwkeurige grens een regelrechte afkeuring in plaats van een discussie. Loop de lijst langs van diensten waarop uw mensen met een werkidentiteit inloggen, inclusief de diensten die een afdeling in gebruik nam zonder het iemand te vertellen.
Doe dit in de juiste volgorde
Doe de inventarisatie voordat u iets aanraakt. De verleiding is om aanmeldingen te blokkeren zodra u ze vindt, en zo stopt een geplande factuurverwerking stilletjes op een vrijdagmiddag.
De volgorde die werkt:
- Som elk account op: gebruikers, serviceaccounts, gedeelde postvakken, gasten.
- Stel per account vast waarvoor het dient en of er iets van afhangt.
- Bepaal de doeltoestand voor elk account.
- Wijzig ze op een gecontroleerde manier en let op wat er breekt.
- Leg het bewijs onderweg vast, want volgend jaar hebt u het opnieuw nodig.
Gun uzelf ongeveer zes weken tussen beginnen en indienen. Uitzoeken waarvoor een mysterieus account eigenlijk wordt gebruikt duurt het langst, en alles dat een applicatiewijziging vraagt heeft een wijzigingsvenster en een terugvalplan nodig. Gebruik in die periode beleid voor voorwaardelijke toegang in alleen-rapportmodus, zodat u een aanscherping kunt meten voordat hij bij iemand landt.
Wees specifiek over het bewijs dat u bewaart. Een bruikbaar pakket is een gedateerde export per maatregel en niet een map met schermafbeeldingen: het rapport met registratiegegevens, het beleid voor voorwaardelijke toegang met zichtbare uitsluitingen, de aanmeldstatus van gedeelde postvakken, de noodtoegangsprocedure, de export van apparaatcompliance, en een notitie per gedocumenteerde uitzondering die uitlegt wat ervoor compenseert.
Cyber Essentials wordt jaarlijks verlengd, dus alles wat u eenmalig bouwt, bouwt u over twaalf maanden opnieuw. Het bouwen als iets herhaalbaars is het verschil tussen veertien dagen en een middag de volgende keer.
Waar dit op aansluit
Het bewijsprobleem en het beveiligingsprobleem zijn hetzelfde probleem van twee kanten bekeken. Onze route Microsoft 365-beveiliging en conformiteit behandelt de posture, en ISO-compliance en auditgereedheid behandelt het bewijsspoor. We schreven eerder over Microsoft 365-instellingen koppelen aan Cyber Essentials en ISO 27001, en die koppeling geldt nog steeds; wat veranderde is het gevolg van het fout doen.
De accounthygiëne die hierbij komt kijken overlapt bijna volledig met werk rond instroom, doorstroom en uitstroom, dus als u de Microsoft 365-offboardingchecklist goed uitvoert, hebt u hier al een deel van gedaan.
Waar EtherInsights past
Dit bewijs jaarlijks met de hand verzamelen over een hele tenant is precies het soort werk dat wordt uitgesteld tot het dringend is. EtherInsights bestaat deels om die reden. Het rapporteert over identiteits- en MFA-dekking, apparaat- en Intune-status, en tenantconfiguratie vanaf één plek, zodat de inventarisatieronde die met de hand dagen kost een rapport wordt dat u volgend jaar opnieuw kunt draaien en met dit jaar kunt vergelijken.
Voor managed serviceproviders is de vermenigvuldiging het punt: dezelfde checklist over twintig tenants zijn twintig inventarisatieoefeningen, en de accounts die in de ene tenant afkeuren zien er in de volgende meestal identiek uit. Het draaien als herhaalbaar rapport is wat de jaarlijkse verlenging doenlijk maakt, en Microsoft 365-beveiliging en conformiteit is waar het postureoverzicht en het bewijsoverzicht samenkomen.
Ontdek Microsoft 365-beveiliging en conformiteit om te zien hoe posture, bewijs en jaarlijkse herbeoordeling op één plek samenkomen.