Frågeuppsättningen för Cyber Essentials ändrades den 27 april 2026. Danzell-versionen införde något systemet inte haft tidigare: frågor där ett felaktigt svar underkänner bedömningen direkt i stället för att sänka ett poäng. Flera av dem landar rakt på Microsoft 365, och två av dem fångar saker de flesta tenanter tyst burit i åratal.
Vi har själva Cyber Essentials, så det här är skrivet utifrån att ha gått igenom det snarare än utifrån att ha läst specifikationen.
Detta är en checklista att köra innan du lämnar in, inte en ersättning för den officiella frågeuppsättningen från IASME.
Ändringen som fångar folk
Två saker betyder mer än resten.
Frågor om multifaktorautentisering kan nu underkänna dig direkt. Tidigare var en ofullkomlig MFA-position något du förklarade. Nu är det, för kontona inom omfattningen, godkänt eller underkänt.
Det finns en formell definition av molntjänster inom omfattningen. Detta stänger luckan som lät organisationer hävda att Microsoft 365 låg utanför bedömningens gräns. Om dina användare loggar in på det och det innehåller organisationsdata är det inom omfattningen. Den diskussionen är över.
Tillsammans betyder de att bedömningen nu når in på platser som förr lämnades i fred.
Det ändrar arbetets karaktär. En fråga som underkänner direkt är inte något du skriver ett noggrant svar på; du kan antingen besvara den ärligt jakande eller så kan du inte. Övningen blir inventering snarare än formulering: en lista över varje identitet som kan autentisera, vad som autentiserar den, och vad som skulle gå sönder om du ändrade den. Att ta fram den listan är merparten av arbetet. Åtgärdandet går vanligen snabbt.
Ordningen som håller ett godkänt Cyber Essentials upprepningsbart: inventera först, besluta sedan, ändra därefter, och behåll bevisen.
De två som faktiskt fångar folk
Tjänstekonton
Varje tenant har dem. Kontot som kör en schemalagd export. Kontot som en verksamhetsapplikation autentiserar med. Kontot som skapades för en migrering 2021 och som ingen stängde av.
De saknar vanligen MFA, eftersom MFA skulle bryta det de automatiserar. Det var uthärdligt när frågan poängsattes. Det är det inte nu.
Hitta dem innan du diskuterar dem. Två vyer ger dig kandidatlistan på ungefär tio minuter:
- Administrationscentret för Microsoft Entra, Skydd, Autentiseringsmetoder, Registreringsinformation för användare. Rapporten visar varje konto och om det är MFA-kapabelt och registrerat. Filtrera till kontona utan något registrerat så tittar du på din exponering.
- Entra ID, Övervakning, Inloggningsloggar, filtrerat på icke-interaktiva användarinloggningar. Automatisering syns här snarare än i den interaktiva loggen. Ett konto med tusentals icke-interaktiva inloggningar och ingen registrerad metod är ett tjänstekonto, vad någon än kallade det.
Samma lista kommer ut ur Microsoft Graph PowerShell som en 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
Vad du bör göra, i preferensordning:
- Ersätt kontot helt. En arbetsbelastningsidentitet eller hanterad identitet är rätt svar för allt som körs obevakat. Ingen interaktiv inloggning, ingen MFA-fråga, ingen delad hemlighet i en konfigurationsfil.
- Om det måste förbli ett konto, ta bort rättigheterna för interaktiv inloggning, avgränsa det snävt med villkorsstyrd åtkomst, och kunna visa vad det kan och inte kan göra.
- Dokumentera varför det finns. En revisor accepterar ett kontrollerat undantag betydligt lättare än ett konto ingen kan förklara.
Ett genomarbetat exempel gör valet konkret. En ekonomiexport körs nattetid under ett licensierat konto med ett lösenord i en schemalagd uppgift. Rätt svar flyttar den till en appregistrering med certifikatuppgifter och bara de Graph-behörigheter exporten behöver, vilket tar bort kontot och lösenordet på en gång. Om applikationen inte klarar det än, behåll kontot, blockera interaktiv inloggning, begränsa det med villkorsstyrd åtkomst till den enda tjänsten, och notera den kompenserande kontrollen.
Felläget här är att upptäcka dessa veckan du lämnar in. De är alltid fler än väntat.
Delade postlådor
Det här är den som överraskar folk. En delad postlåda ska inte ha någon aktiverad inloggning alls. Åtkomst ska delegeras till namngivna användare som har sin egen MFA.
I praktiken har många tenanter delade postlådor med ett aktiverat underliggande konto och ett lösenord någon känner till, oftast skapat för flera år sedan så att en telefon eller en skanner kunde skicka post. Det är ett konto med ett lösenord och utan MFA, som innehåller organisationsdata, och den nya frågeuppsättningen har en åsikt om det.
Kontrollera varje delad postlåda för en aktiverad inloggning:
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
Allt som kommer tillbaka behöver blockerad inloggning, i administrationscentret för Entra under Användare eller med Update-MgUser -UserId <upn> -AccountEnabled:$false. Delegera åtkomst till namngivna personer med Add-MailboxPermission för fullständig åtkomst och Add-RecipientPermission för skicka-som, så att varje åtgärd mot den postlådan tillhör en identitet som bär sin egen MFA.
Om något verkligen behöver skicka post obevakat är det ett problem med applikationsbehörigheter, inte ett problem med ett postlådelösenord. Flytta det till en appregistrering med snävt avgränsade postbehörigheter, eller till en mottagningsanslutning begränsad till en känd statisk adress. Där grundläggande SMTP-autentisering fortfarande är aktiverad stänger Set-CASMailbox -Identity <mailbox> -SmtpClientAuthenticationDisabled $true den per postlåda och motsvarande inställning på Set-TransportConfig stänger den för hela organisationen. Kontrollera först vad varje enhet stöder: en multifunktionsenhet som tyst slutar skanna till e-post är en supportkö ingen tackar dig för.
Resten av checklistan
Varje användarkonto med en licens har MFA. Inte "vi har en policy". Verifiera efterlevnaden, inklusive konton skapade sedan policyn skrevs, gäster, och alla som undantagits från villkorsstyrd åtkomst. Läs undantagen på varje policy specifikt, för det är där avdriften bor: en projektgrupp som lades till i två veckor 2024, ett leverantörskonto, en katalogroll som tyst kringgår regeln.
Gästkonton är redovisade. Gäster autentiserar i sin hemtenant, så deras MFA kan vara uppfylld någon annanstans, och inställningar för åtkomst mellan tenanter avgör om din tenant litar på det påståendet. Du behöver inte göra ett visst val här, men du måste veta vilket val du gjorde.
Nödåtkomstkonton är ett dokumenterat undantag. Konton för nödåtkomst är tillåtna. Du förväntas kontrollera och övervaka dem: två konton som bara finns i molnet, undantagna från de policyer som kan låsa ute alla, med uppdelade och fysiskt förvarade inloggningsuppgifter, och en avisering som går i samma stund som något av dem loggar in. Nuvarande vägledning föredrar en nätfiskeresistent metod framför enbart ett lösenord, så se över det om paret är några år gammalt.
Administrativa konton är åtskilda från vardagskonton. En administratör som läser e-post från samma identitet är en anmärkning som väntar på att inträffa. Där licensieringen stöder det ger just-in-time-höjning genom Privileged Identity Management dig åtskillnaden och ett färdigt underlag över vem som hade vilken roll och när.
Äldre autentisering är avstängd. Om grundläggande autentisering fortfarande når något är MFA-svaret inte sant i praktiken. Filtrera inloggningsloggarna på en klientapp som "Andra klienter" och se vad som dyker upp. De flesta äldre protokoll i Exchange Online är sedan länge avvecklade, men SMTP-autentisering är den som tenderar att överleva eftersom något operativt beror på den.
Dina bevis för enhetsuppdatering går att exportera. Systemet bryr sig om enheternas tillstånd, och svaret måste komma från något du kan visa snarare än påstå. Intune kan ta fram det, och att bevisa det från Intune är en separat övning värd att göra innan du behöver den. Det du vill ha är en daterad export av build- och uppdateringsefterlevnad per enhet, inte en skärmbild av en instrumentpanel som ser annorlunda ut nästa vecka.
Din omfattningsbeskrivning stämmer med verkligheten. Med molntjänster formellt definierade är en felaktig gräns nu ett rakt underkännande snarare än en diskussion. Gå igenom listan över tjänster ditt folk loggar in på med en arbetsidentitet, inklusive de en avdelning tog i bruk utan att berätta för någon.
Gör detta i rätt ordning
Kör inventeringen innan du rör något. Frestelsen är att börja blockera inloggningar allteftersom du hittar dem, och det är så en schemalagd fakturakörning tyst stannar en fredagseftermiddag.
Ordningen som fungerar:
- Räkna upp varje konto: användare, tjänstekonton, delade postlådor, gäster.
- Fastställ för varje konto vad det är till för och om något beror på det.
- Bestäm mållägen för vart och ett.
- Ändra dem på ett kontrollerat sätt och håll utkik efter det som går sönder.
- Samla bevisen efter hand, för du kommer att behöva dem igen nästa år.
Ge dig själv ungefär sex veckor mellan start och inlämning. Att spåra vad ett mystiskt konto faktiskt används till tar längst tid, och allt som kräver en applikationsändring behöver ett ändringsfönster och en återställningsplan. Använd policyer för villkorsstyrd åtkomst i endast rapportläge under den perioden så att du kan mäta en åtstramning innan den landar på någon.
Var specifik med de bevis du sparar. Ett användbart paket är en daterad export per kontroll snarare än en mapp med skärmbilder: rapporten med registreringsinformation, policyerna för villkorsstyrd åtkomst med undantagen synliga, inloggningsläget för delade postlådor, nödåtkomstrutinen, exporten av enhetsefterlevnad, och en notering per dokumenterat undantag som förklarar vad som kompenserar för det.
Cyber Essentials förnyas årligen, så allt du bygger som en engångsinsats bygger du om inom tolv månader. Att bygga det som något upprepningsbart är skillnaden mellan två veckor och en eftermiddag nästa gång.
Var detta hänger ihop
Bevisproblemet och säkerhetsproblemet är samma problem sett från två håll. Vår rutt Microsoft 365-säkerhet och konformitet täcker läget, och ISO-efterlevnad och revisionsberedskap täcker bevisspåret. Vi skrev tidigare om att koppla Microsoft 365-inställningar till Cyber Essentials och ISO 27001, och den kopplingen håller fortfarande; det som ändrades är konsekvensen av att göra fel.
Kontohygienen det handlar om överlappar nästan helt med arbete kring nyanställda, förflyttningar och avslut, så om du kör checklistan för offboarding i Microsoft 365 ordentligt har du redan gjort en del av detta.
Var EtherInsights passar in
Att samla dessa bevis för hand, årligen, över en tenant är precis den sorts arbete som skjuts upp tills det är brådskande. EtherInsights finns delvis av det skälet. Det rapporterar om identitets- och MFA-täckning, enhets- och Intune-läge, och tenantkonfiguration från ett ställe, så att inventeringsrundan som tar dagar för hand blir en rapport du kan köra om nästa år och jämföra med i år.
För leverantörer av hanterade tjänster är multiplikationen hela poängen: samma checklista över tjugo tenanter är tjugo inventeringsövningar, och kontona som underkänns i en tenant brukar se identiska ut i nästa. Att köra den som en upprepningsbar rapport är vad som gör den årliga förnyelsen uthärdlig, och Microsoft 365-säkerhet och konformitet är där lägesbilden och bevisbilden sitter tillsammans.
Utforska säkerhet och konformitet i Microsoft 365 för att se hur läge, bevis och årlig omprövning kommer samman på ett ställe.