Le questionnaire Cyber Essentials a changé le 27 avril 2026. La version Danzell a introduit quelque chose que le référentiel n'avait jamais eu : des questions dont une mauvaise réponse fait échouer l'évaluation d'emblée, au lieu de réduire un score. Plusieurs d'entre elles portent directement sur Microsoft 365, et deux attrapent des choses que la plupart des tenants traînent discrètement depuis des années.
Nous détenons nous-mêmes Cyber Essentials, ce texte est donc écrit à partir de notre passage par l'exercice et non de la lecture de la spécification.
C'est une checklist à dérouler avant de soumettre, pas un substitut au questionnaire officiel d'IASME.
Le changement qui prend les équipes au dépourvu
Deux points comptent plus que les autres.
Les questions sur l'authentification multifacteur peuvent désormais vous recaler d'emblée. Auparavant, une position MFA imparfaite s'expliquait. Désormais, pour les comptes dans le périmètre, c'est réussite ou échec.
Il existe une définition formelle des services cloud dans le périmètre. Cela referme la brèche qui permettait aux organisations de soutenir que Microsoft 365 se situait hors des limites de l'évaluation. Si vos utilisateurs s'y connectent et qu'il contient des données de l'organisation, il est dans le périmètre. Le débat est clos.
Ensemble, ils font que l'évaluation atteint désormais des recoins que l'on laissait autrefois tranquilles.
Cela change la nature du travail. Une question à échec automatique n'est pas une question à laquelle on rédige une réponse soignée ; soit vous pouvez y répondre honnêtement par l'affirmative, soit vous ne le pouvez pas. L'exercice devient une découverte plutôt qu'une rédaction : une liste de chaque identité capable de s'authentifier, de ce qui l'authentifie, et de ce qui casserait si vous y touchiez. Produire cette liste représente l'essentiel de l'effort. La remédiation est généralement rapide.
L'ordre qui rend une réussite Cyber Essentials reproductible : découvrir d'abord, décider ensuite, changer en troisième, et conserver les preuves.
Les deux qui prennent vraiment les équipes au dépourvu
Les comptes de service
Chaque tenant en possède. Le compte qui exécute un export planifié. Celui avec lequel une application métier s'authentifie. Celui créé pour une migration en 2021 que personne n'a désactivé.
Ils n'ont généralement pas de MFA, car la MFA casserait ce qu'ils automatisent. C'était tolérable quand la question était notée. Ce ne l'est plus.
Trouvez-les avant d'en débattre. Deux vues vous donnent la liste des candidats en une dizaine de minutes :
- Microsoft Entra admin centre, Protection, Authentication methods, User registration details. Affiche chaque compte et indique s'il est capable de MFA et enregistré. Filtrez sur les comptes sans rien d'enregistré et vous avez votre exposition sous les yeux.
- Entra ID, Monitoring, Sign-in logs, filtré sur les connexions utilisateur non interactives. L'automatisation apparaît là, pas dans le journal interactif. Un compte avec des milliers de connexions non interactives et aucune méthode enregistrée est un compte de service, quel que soit le nom qu'on lui a donné.
La même liste sort de Microsoft Graph PowerShell au format 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
Ce qu'il faut faire, par ordre de préférence :
- Remplacez entièrement le compte. Une identité de charge de travail ou une identité managée est la bonne réponse pour tout ce qui s'exécute sans surveillance. Pas de connexion interactive, pas de question MFA, pas de secret partagé dans un fichier de configuration.
- S'il doit rester un compte, retirez les droits de connexion interactive, cadrez-le étroitement avec l'accès conditionnel, et soyez en mesure de montrer ce qu'il peut et ne peut pas faire.
- Documentez la raison de son existence. Un évaluateur acceptera bien plus volontiers une exception maîtrisée qu'un compte que personne ne sait expliquer.
Un exemple concret rend le choix palpable. Un export financier s'exécute chaque nuit sous un compte sous licence, avec un mot de passe dans une tâche planifiée. La bonne réponse le déplace vers une inscription d'application avec des identifiants par certificat et uniquement les permissions Graph dont l'export a besoin, ce qui supprime le compte et le mot de passe d'un même geste. Si l'application ne le permet pas encore, gardez le compte, bloquez la connexion interactive, restreignez-le par accès conditionnel à ce seul service, et consignez le contrôle compensatoire.
Le mode de défaillance ici, c'est de les découvrir la semaine de la soumission. Ils sont toujours plus nombreux que prévu.
Les boîtes aux lettres partagées
C'est celle qui surprend. Une boîte aux lettres partagée n'est pas censée avoir de connexion activée du tout. L'accès est censé être délégué à des utilisateurs nommés qui disposent de leur propre MFA.
En pratique, de nombreux tenants ont des boîtes aux lettres partagées dont le compte sous-jacent est activé avec un mot de passe que quelqu'un connaît, créé il y a des années pour qu'un téléphone ou un scanner puisse envoyer du courrier. C'est un compte doté d'un mot de passe et sans MFA, qui contient des données de l'organisation, et le nouveau questionnaire a un avis à ce sujet.
Vérifiez chaque boîte aux lettres partagée à la recherche d'une connexion activée :
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
Tout ce qui remonte doit voir sa connexion bloquée, dans le centre d'administration Entra sous Users ou avec Update-MgUser -UserId <upn> -AccountEnabled:$false. Déléguez l'accès à des personnes nommées avec Add-MailboxPermission pour l'accès complet et Add-RecipientPermission pour l'envoi en tant que, afin que chaque action sur cette boîte appartienne à une identité porteuse de sa propre MFA.
Si quelque chose doit réellement envoyer du courrier sans surveillance, c'est un problème de permission applicative, pas un problème de mot de passe de boîte aux lettres. Déplacez-le vers une inscription d'application avec des permissions de messagerie étroitement cadrées, ou vers un connecteur de réception restreint à une adresse statique connue. Là où l'authentification SMTP de base est encore activée, Set-CASMailbox -Identity <mailbox> -SmtpClientAuthenticationDisabled $true la ferme boîte par boîte et le paramètre équivalent sur Set-TransportConfig la ferme à l'échelle de l'organisation. Vérifiez d'abord ce que prend en charge chaque appareil : un multifonction qui cesse silencieusement de numériser vers la messagerie génère une file de tickets dont personne ne vous remerciera.
Le reste de la checklist
Chaque compte utilisateur sous licence dispose de la MFA. Pas « nous avons une politique ». Vérifiez l'application effective, y compris pour les comptes créés depuis la rédaction de la politique, les invités, et toute personne exclue de l'accès conditionnel. Lisez spécifiquement les exclusions de chaque politique, car c'est là que réside la dérive : un groupe de projet ajouté pour quinze jours en 2024, un compte fournisseur, un rôle d'annuaire qui contourne discrètement la règle.
Les comptes invités sont pris en compte. Les invités s'authentifient dans leur tenant d'origine, leur MFA peut donc être satisfaite ailleurs, et les paramètres d'accès inter-tenants décident si votre tenant fait confiance à cette revendication. Vous n'êtes pas obligé de faire un choix particulier ici, mais vous devez savoir lequel vous avez fait.
Les comptes de secours constituent une exception documentée. Les comptes d'accès d'urgence sont autorisés. Il est attendu que vous les contrôliez et les surveilliez : deux comptes exclusivement cloud, exclus des politiques susceptibles de verrouiller tout le monde dehors, des identifiants scindés et conservés physiquement, et une alerte qui se déclenche dès que l'un des deux se connecte. Les recommandations actuelles privilégient une méthode résistante au hameçonnage plutôt qu'un simple mot de passe, revoyez donc ce point si la paire a quelques années.
Les comptes d'administration sont distincts des comptes du quotidien. Un administrateur qui consulte sa messagerie depuis la même identité est un constat d'audit en attente. Là où la licence le permet, l'élévation juste-à-temps via Privileged Identity Management vous donne la séparation et un journal tout prêt de qui a détenu quel rôle et quand.
L'authentification héritée est désactivée. Si l'authentification de base peut encore atteindre quoi que ce soit, la réponse sur la MFA n'est pas vraie en pratique. Filtrez les journaux de connexion sur une application cliente « Other clients » et regardez ce qui apparaît. La plupart des protocoles hérités d'Exchange Online sont retirés depuis longtemps ; l'authentification SMTP est celle qui survit, parce que quelque chose d'opérationnel en dépend.
Vos preuves de correctifs sur les appareils sont exportables. Le référentiel s'intéresse à l'état des appareils, et la réponse doit venir de quelque chose que vous pouvez montrer plutôt qu'affirmer. Intune sait la produire, et le prouver depuis Intune est un exercice distinct qu'il vaut mieux mener avant d'en avoir besoin. Ce que vous voulez, c'est un export daté de la conformité de build et de mises à jour par appareil, pas la capture d'écran d'un tableau de bord qui aura changé la semaine prochaine.
Votre déclaration de périmètre correspond à la réalité. Les services cloud étant formellement définis, une frontière inexacte est désormais un échec net plutôt qu'une discussion. Parcourez la liste des services auxquels vos collaborateurs se connectent avec une identité professionnelle, y compris ceux qu'un service a adoptés sans le dire à personne.
Faites-le dans le bon ordre
Menez la découverte avant de toucher à quoi que ce soit. La tentation est de commencer à bloquer les connexions au fur et à mesure que vous les trouvez, et c'est ainsi qu'une exécution de facturation planifiée s'arrête silencieusement un vendredi après-midi.
L'ordre qui fonctionne :
- Recensez chaque compte : utilisateurs, comptes de service, boîtes aux lettres partagées, invités.
- Pour chacun, établissez à quoi il sert et si quelque chose en dépend.
- Décidez l'état cible de chacun.
- Modifiez-les de façon contrôlée, en surveillant ce qui casse.
- Collectez les preuves au fil de l'eau, car vous en aurez de nouveau besoin l'an prochain.
Accordez-vous environ six semaines. Retrouver à quoi sert réellement un compte mystère prend le plus de temps, et tout ce qui nécessite une modification applicative exige une fenêtre de changement. Utilisez des politiques d'accès conditionnel en mode rapport seul durant cette période, afin de mesurer un durcissement avant qu'il ne retombe sur quiconque.
Soyez précis sur les preuves que vous conservez : un export daté par contrôle plutôt qu'un dossier de captures d'écran. Le rapport de détails d'enregistrement, les politiques d'accès conditionnel avec les exclusions visibles, l'état de connexion des boîtes aux lettres partagées, la procédure de compte de secours, l'export de conformité des appareils, et une note par exception.
Cyber Essentials se renouvelle chaque année, tout ce que vous construisez comme un coup unique sera donc à reconstruire dans douze mois. Le construire comme quelque chose de reproductible fait la différence entre quinze jours et un après-midi la prochaine fois.
Les liens avec le reste
Le problème de preuve et le problème de sécurité sont le même problème vu de deux côtés. Notre parcours sécurité et conformité Microsoft 365 couvre la posture, et conformité ISO et préparation à l'audit couvre la piste de preuves. Nous avions écrit sur la correspondance entre les paramètres Microsoft 365, Cyber Essentials et ISO 27001, et cette correspondance tient toujours ; ce qui a changé, c'est la conséquence d'une erreur.
L'hygiène des comptes recoupe presque entièrement le travail d'arrivées, de mobilités et de départs, dérouler correctement la checklist d'offboarding Microsoft 365 en fait donc une partie pour vous.
La place d'EtherInsights
Rassembler ces preuves à la main, chaque année, sur un tenant est exactement le genre de travail que l'on repousse jusqu'à ce qu'il devienne urgent. EtherInsights existe en partie pour cette raison. Il rend compte de la couverture d'identité et de MFA, de l'état des appareils et d'Intune, et de la configuration du tenant depuis un seul endroit, de sorte que la passe de découverte qui prend des jours à la main devient un rapport que vous pourrez relancer l'an prochain et comparer à celui de cette année.
Pour les fournisseurs de services managés, la multiplication est le sujet : la même checklist sur vingt tenants représente vingt exercices de découverte, et les comptes qui échouent chez l'un ressemblent en général trait pour trait à ceux du suivant. La dérouler comme un rapport reproductible est ce qui rend le renouvellement annuel supportable, et sécurité et conformité Microsoft 365 est l'endroit où posture et preuves se rejoignent.
Découvrez la sécurité et la conformité Microsoft 365 pour voir comment posture, preuves et réévaluation annuelle se rejoignent en un seul endroit.