À compter de fin septembre 2026, Microsoft modifie la manière dont certaines actions d'administration des communautés et des adhésions (memberships) sont autorisées dans Microsoft Viva Engage. L'objectif est d'aligner l'administration des communautés sur le modèle de sécurité et d'administration de Microsoft Entra.

Aujourd'hui, les utilisateurs disposant du rôle Verified Admin ou Network Admin au sein de Viva Engage peuvent réaliser un ensemble limité de tâches d'administration des communautés et des adhésions, même s'ils ne disposent pas des permissions correspondantes dans Microsoft Entra. Après ce déploiement, ces actions nécessiteront les permissions administratives Microsoft Entra appropriées.

Pour continuer à réaliser ces actions, les utilisateurs devront soit :

• Disposer du rôle Yammer Administrator dans Microsoft Entra ;
• Soit être désignés comme Community Admin de la communauté spécifique qu'ils gèrent.

Ce changement renforce la cohérence entre l'administration de Viva Engage et les contrôles d'accès de Microsoft Entra.

Ce qui va changer

Après ce déploiement, les utilisateurs disposant uniquement du rôle Verified Admin ou Network Admin au sein de Viva Engage ne pourront plus modifier les paramètres de communauté suivants, sauf s'ils disposent également du rôle Yammer Administrator dans Microsoft Entra ou s'ils sont désignés comme Community Admin de la communauté concernée :

• Nom de la communauté (Community name)
• Description de la communauté (Community description)
• Avatar de la communauté (Community avatar)
• Paramètres de confidentialité de la communauté (public ou privé)
• Gestion des adhésions (Membership management)
• Suppression de la communauté (Community deletion)

À noter : aucune modification n'est apportée aux capacités du rôle Community Admin.

Les administrateurs doivent passer en revue les attributions administratives Viva Engage avant le déploiement. Voici les étapes à prendre en compte :

• Passer en revue les utilisateurs actuellement titulaires des rôles Verified Admin et Network Admin dans Viva Engage.
• Identifier les utilisateurs qui doivent continuer à gérer les paramètres de communauté ou les adhésions.
• Déterminer si ces utilisateurs doivent se voir attribuer le rôle Yammer Administrator dans Microsoft Entra.
• Ou, alternativement, leur attribuer des permissions Community Admin pour les communautés spécifiques concernées, lorsque cela est approprié.

Dans un précédent article, je vous annonçais le passage de Microsoft Edge à un rythme de publication majeure toutes les deux semaines. Microsoft aligne désormais le runtime WebView2 sur cette même cadence : à partir de la version 152, le runtime WebView2 suivra le nouveau cycle bihebdomadaire d'Edge, contre un cycle de quatre semaines jusqu'à présent. L'objectif est d'accélérer la diffusion des correctifs de sécurité, des améliorations de la plateforme et des nouvelles fonctionnalités.  

La bascule s'opère de façon progressive :

• Depuis la semaine du 27 août 2026 : la version 152 du runtime WebView2 était la dernière version majeure publiée 4 semaines après la précédente.
• Dès la semaine du 10 septembre 2026 : la version 153 sera la toute première version publiée seulement 2 semaines après la précédente.
• Ensuite : une nouvelle version majeure sera publiée environ toutes les deux semaines, en alignement avec la cadence d'Edge.

La cadence de publication du SDK WebView2 évolue également. Au lieu des publications mensuelles, les versions du SDK seront désormais publiées lorsqu'il y a de nouvelles fonctionnalités, corrections de bugs, mises à jour de sécurité ou autres améliorations à partager. Lorsqu'un SDK est publié, il le sera à la même date que la version du runtime correspondante.

L'impact sur vos applications dépend du mode de distribution du runtime que vous utilisez :  

• Mode Evergreen Runtime (mode par défaut) : aucune action n'est requise. Les machines de vos utilisateurs commenceront simplement à recevoir les correctifs de sécurité et de plateforme à un rythme plus fréquent.
• Mode Fixed Version Runtime : vous gardez le contrôle du moment de la mise à jour, mais les nouvelles versions majeures arrivent plus souvent. Prévoyez de valider et d'adopter les nouvelles versions plus fréquemment afin de ne pas prendre de retard sur les correctifs de sécurité.

Voici les bonnes pratiques mises en avant par Microsoft :

• Tester votre application WebView2 via le canal de préversion Beta de Microsoft Edge, afin de détecter les éventuels bugs avant leur diffusion à vos utilisateurs. Le test anticipé reste le meilleur moyen d'identifier les problèmes spécifiques à votre application avant qu'ils n'atteignent le canal Stable.
• Automatiser la validation des workflows critiques de votre application avec les canaux de préversion WebView2, notamment via Microsoft Edge WebDriver.
• Signaler les régressions au plus tôt (via le dépôt GitHub WebView2Feedback) afin qu'elles puissent être corrigées avant la publication Stable.

S'aligner sur Edge signifie que vos utilisateurs bénéficient plus rapidement d'une plateforme web plus sûre et plus riche, tout en vous offrant un train de publication unique et prévisible autour duquel planifier vos activités.

Depuis la version de plateforme 4.18.26060 (publiée en juin 2026), le comportement par défaut du mode Warn des règles ASR (Attack Surface Reduction) de Microsoft Defender for Endpoint a changé. Pour lever un blocage via l'option Unblock, l'utilisateur doit désormais disposer de droits d'administrateur local. Ce changement est intentionnel et s'inscrit dans une démarche de renforcement de la sécurité de la solution.

Pour rappel, les règles ASR (réduction de la surface d'attaque) de Microsoft Defender Antivirus ciblent les comportements logiciels à risque sur les postes Windows, comportements couramment exploités par les attaquants via des malwares. Par exemple : Le lancement d'exécutables et de scripts qui tentent de télécharger ou d'exécuter des fichiers, l'exécution de scripts obfusqués ou non approuvés, etc.

Bien que des applications légitimes puissent aussi présenter ces comportements, les malwares les utilisent très fréquemment de la même manière. Les règles ASR permettent de contraindre ces comportements et d'améliorer la posture défensive de l'organisation.

Chaque règle ASR peut être configurée dans l'un des modes suivants :

• Not configured / Disabled : la règle est désactivée.
• Audit : la règle n'applique aucun blocage mais journalise l'événement (idéal pour tester l'impact avant l'application). C'est l'événement 1122 dans le journal Microsoft-Windows-Windows Defender/Operational.
• Block : la règle bloque le comportement à risque (événement 1121). [
• Warn : la règle bloque le comportement mais présente à l'utilisateur une notification lui permettant de débloquer temporairement l'action (option Unblock), sur le principe de SmartScreen. L'action est alors autorisée pendant une durée de 24 heures.

Le mode Warn constitue ainsi un compromis entre Audit et Block : il protège tout en laissant à l'utilisateur la possibilité de poursuivre une action légitime.  

Jusqu'à présent, un utilisateur standard confronté à un blocage en mode Warn pouvait cliquer sur Unblock pour outrepasser temporairement la règle. Depuis la plateforme 4.18.26060 :

• L'option Unblock en mode Warn nécessite désormais une approbation administrateur : seul un compte disposant de droits d'administrateur local peut lever le blocage.
• Ce changement empêche un utilisateur standard (ou un malware s'exécutant dans son contexte) de contourner trivialement une règle ASR, ce qui renforce la robustesse du dispositif.

Important : l'option Unblock n'est destinée qu'à une suppression temporaire du blocage. Ce n'est pas un mécanisme d'exclusion durable.

Recommandations

Voici les points à prendre en compte :

• Pour une exclusion persistante, ne vous appuyez pas sur l'option Unblock. Configurez plutôt une exclusion par règle ASR (per-ASR rule exclusion), qui est le mécanisme adapté et durable.
• Distinguez bien les trois mécanismes d'exclusion : exclusion par règle ASR, exclusion globale ASR, et exclusion antivirus. Plusieurs règles ignorent totalement l'exclusion antivirus.
• Vérifiez la version de plateforme déployée sur votre parc via Get-MpComputerStatus (champ AMProductVersion) afin d'identifier les postes déjà en 4.18.26060 ou ultérieure.
• Informez votre support (help desk) et adaptez vos procédures internes : les utilisateurs standards ne pourront plus lever eux-mêmes un blocage en mode Warn.
• Mettez à jour votre documentation de dépannage pour intégrer ce nouveau comportement lors de l'analyse des événements ASR (ID 1121/1122).

Pour plus d'informations, consultez Attack surface reduction (ASR) rules overview sur Microsoft Learn.

Dans un précédent article, je vous annonçais le changement à venir pour Endpoint DLP sur macOS 27 (Golden Gate). Pour rappel, et comme le confirme le message MC1448378, macOS 27 (Golden Gate) désactive par défaut les autorisations Accessibility et autorise les utilisateurs à les désactiver, y compris lorsque le paramètre est imposé via une solution MDM. [microsofttouch.fr]

Pourquoi est-ce important : Microsoft Purview Endpoint DLP s'appuie sur les autorisations Accessibility pour appliquer certains contrôles liés aux navigateurs. Il convient de réaliser les actions décrites ci-dessous pour maintenir la protection sur les postes concernés.

Je vous recommande d'agir dès que possible afin de disposer d'une protection dès le jour 0 sur macOS 27 (Golden Gate). Gardez à l'esprit que ces changements ne fonctionneront que pour la version Stable de macOS 27 (Golden Gate), dont la sortie est prévue par Apple en septembre.

Contrôles Endpoint DLP concernés

• Upload vers un domaine de service cloud restreint (Upload to a restricted cloud service domain)
• Coller (paste) vers les navigateurs pris en charge (Paste to supported browsers)

Si Accessibility est désactivé, ces contrôles ne peuvent pas être appliqués sans le client Endpoint DLP et la configuration décrits ci-dessous.

Aucun impact : les postes qui n'exécutent pas macOS 27, les postes macOS 27 sur lesquels Accessibility reste activé, ainsi que le navigateur Edge, ne sont pas concernés.

Action requise : mettre à niveau le client Endpoint DLP, [Optionnel] configurer Accessibility via votre solution MDM, puis vérifier le statut de l'autorisation dans le portail Microsoft Purview.

Étape 1 – Mettre à niveau le client Endpoint DLP

Installez le client Endpoint DLP version 101.26072 ou ultérieure sur tous les postes macOS 27 concernés. Pour cela, vous pouvez configurer Microsoft AutoUpdate sur les postes ou récupérer les binaires dans le portail Purview que vous pouvez ensuite packager/déployer avec Microsoft Intune : 

Cette version assure la protection des scénarios d'upload et de paste concernés lorsque Accessibility est indisponible. Les versions antérieures ne peuvent pas appliquer ces contrôles lorsque Accessibility est désactivé.

Étape 2 – Configurer Accessibility via MDM

• Activer Accessibility pour Endpoint DLP. macOS 27 désactivant Accessibility par défaut, vous devez activer ce paramètre via votre solution MDM.
  • Si vous utilisez le client Endpoint DLP version 101.26072 ou ultérieure et que l'activation d'Accessibility est déjà en place (accessibility.mobileconfig sur GitHub – microsoft/mdatp-xplat) déployée dans votre organisation lors de l'onboarding macOS, alors vous êtes déjà couvert sur ce point.
  • Si ce n'est pas le cas, vous devez utiliser le fichier mobileconfig et le déployer avec Microsoft Intune sous la forme d'une stratégie de configuration (Custom)

• [Optionnel] Personnaliser l'application (enforcement) pour les uploads vers les domaines de service cloud restreints et les actions de paste dans les navigateurs pris en charge. Si vous ne personnalisez pas ces paramètres, le client Endpoint DLP version 101.26072 ou ultérieure bloque par défaut les actions concernées lorsque Accessibility est indisponible.

Configurez les paramètres suivants dans le preference domain Microsoft Defender for Endpoint. Vous pouvez récupérer le fichier mobileconfig mis à jour avec cette section sur : mdatp-xplat/macos/settings/data_loss_prevention/accessibility/com.microsoft.wdav.mobileconfig at master · microsoft/mdatp-xplat · GitHub. Chargez le avec Microsoft Intune sous la forme d'une stratégie de configuration (Custom)

 

<key> features</key> <dict>     <key>dataLossPrevention</key>     <string>enabled</string> </dict> <key>dlp</key> <dict>     <key>accessibility</key>     <dict>         <key>enforcement</key>         <dict>             <key>unallowedBrowserMode</key>             <string>enforce</string>             <key>pasteToBrowserMode</key>             <string>enforce</string>         </dict>         <key>notification</key>         <dict>             <key>customMessage</key>             <string>Please enable Accessibility permissions to comply with IT Policy</string>         </dict>     </dict> </dict>

Étape 3 – Vérifier le statut de l'appareil

Pour consulter le statut des autorisations Endpoint DLP d'un poste dans le portail Microsoft Purview :

• Accédez à Settings > Device Onboarding > Devices.
• Sélectionnez le poste concerné.
• Dans le volet de détails de l'appareil, examinez Accessibility sous Configuration status.

Vérification : confirmez que Accessibility remonte bien le statut de configuration attendu pour chaque poste macOS 27 concerné.

Informations complémentaires

Pour plus d'informations, consultez Microsoft Purview Endpoint DLP on macOS 27 (Preview) sur Microsoft Learn.

Note sur la documentation : l'exemple XML actuel de Microsoft Learn contient un problème connu lié à l'élément <key>notification</key>. L'exemple présenté dans cet article reflète la configuration attendue ; l'article Learn sera mis à jour.

iOS 28 est attendu pour la fin de l’année. A partir de cette publication, iOS 18/iPadOS 18 sera un prérequis à l’installation du portail d’entreprise Intune, les stratégies de protection applicative (APP/MAM). Si vous gérez des périphériques iOS/iPadOS, il se peut que vous ayez des périphériques qui ne pourront pas être mis à niveau vers la version minimale prise en charge (iOS 18/iPadOS 18). Consultez la documentation Apple suivante afin de vérifier quels périphériques prennent en charge iOS 18 ou iPadOS 18 (le cas échéant).

• Modèles d’iPhone supportés
• Modèles d’iPad supportés

Microsoft précise également un traitement spécifique pour les appareils enrôlés via :

• Automated Device Enrollment (ADE) sans utilisateur
• Scénarios de terminaux partagés

Vérifiez vos rapports Intune pour voir quels périphériques ou utilisateurs peuvent être affectés. Pour les périphériques gérés en MDM, allez dans Devices > All devices et filtrez par OS. Pour les périphériques avec des stratégies de protection des applications, allez dans Apps > Monitor > App protection status > App Protection report: iOS, Android.

Avec l’arrivée de macOS 27 (Golden Gate) à l’automne 2026, Microsoft annonce la fin de support par Microsoft Intune des versions autre que macOS 15 (Sequoia) et les versions ultérieures peu après la publication.

Il se peut que cela n'ait pas d'impact sur vous car les utilisateurs ont probablement déjà mis à niveau leurs périphériques macOS. Pour connaître la liste des matériels compatibles, vous pouvez consulter : macOS Sequoia is compatible with these computers – Apple Support 

Les périphériques actuellement enregistrés sous macOS 14 ou antérieure resteront inscrits même si ces versions ne sont plus prises en charge. Les nouveaux périphériques ne pourront pas s'inscrire s'ils utilisent macOS 14 ou une version inférieure.

Vous pouvez utiliser les rapports Intune pour voir quels périphériques ou utilisateurs peuvent être impactés. Accédez à Devices > All devices et filtrez par macOS. Demandez aux utilisateurs de mettre à niveau vers une version d'OS prise en charge avant la sortie de macOS 27.

Microsoft annonce la fin du support de Microsoft Defender for Endpoint (MDE) sur Amazon Linux 2 exécuté sur une architecture ARM64 à compter du 31 octobre 2026.

À partir de cette date :

• Les nouvelles versions de Defender for Endpoint ne pourront plus être installées sur Amazon Linux 2 (ARM64).
• La version 101.25122.0004 sera la dernière version supportée.
• Aucun correctif de sécurité, correctif de bugs ou support technique ne sera fourni après le 31 octobre 2026.

Cette évolution concerne uniquement Amazon Linux 2 sur ARM64.

Vous êtes concerné si vous exécutez Microsoft Defender for Endpoint sur :Amazon Linux 2 (ARM64). En revanche, les serveurs utilisant : Amazon Linux 2 (AMD64/x86_64) ne sont pas impactés par cette annonce.

Après la fin du support, les équipements concernés ne bénéficieront plus :

• Des nouvelles fonctionnalités MDE
• Des améliorations de détection
• Des évolutions de protection
• Des mises à jour de sécurité

Cette annonce concerne un scénario relativement spécifique, mais potentiellement fréquent dans les environnements AWS reposant sur des instances ARM. Les organisations utilisant Amazon Linux 2 (ARM64) avec Microsoft Defender for Endpoint devront anticiper une migration avant le 31 octobre 2026 afin de continuer à bénéficier des mises à jour de sécurité et du support Microsoft.

Microsoft a annoncé la fin prochaine du support du paramètre historique "Target to apps on all device types" (Cibler les applications sur tous les types d'appareils) au sein des stratégies de protection d'application Intune (App Protection Policies - APP). Ce paramètre historique sera remplacé par les filtres d'attribution (assignment filters). Cette fin de support prendra effet à partir du 11 janvier 2027, ou peu après.

L'utilisation du paramètre de ciblage historique peut prendre le pas sur les filtres d'attribution, ce qui peut entraîner un comportement de ciblage des stratégies ne correspondant pas aux attentes des administrateurs.

Important : pour éviter tout écart dans l'application des stratégies, il ne faut pas supprimer ou désactiver la configuration de ciblage historique avant que le nouveau filtre d'attribution n'ait été assigné à la stratégie.

Impact sur votre organisation

Les télémétries de Microsoft indiquent que le paramètre historique "Target to apps on all device types" est actuellement configuré dans certains tenants. Une fois le support de ce paramètre historique terminé, celui-ci ne s'appliquera plus. Les stratégies qui n'auront pas été migrées exclusivement vers des filtres d'attribution peuvent alors présenter des écarts de ciblage ou d'application.

À noter : si l'appareil est géré en MDM par un service tiers ou partenaire, les filtres d'attribution d'applications gérées ne pourront pas être mis en correspondance avec les types de gestion les plus granulaires.

Ce que vous devez faire pour vous préparer

Avant ce changement, afin d'éviter toute interruption dans le ciblage des stratégies, il convient de suivre les étapes suivantes, dans l'ordre, pour basculer vers les filtres d'attribution :

1. Passer en revue les stratégies APP existantes. Les stratégies pour lesquelles "Target to apps on all device types" est défini sur "No" utilisent la configuration de ciblage historique et doivent être migrées vers des filtres d'attribution :
   • Accédez au centre d'administration Intune > Apps > Protection pour éditer les stratégies APP existantes.
   • Sélectionnez une stratégie existante afin de vérifier si elle utilise un paramètre historique.
   • Dans le volet Intune App Protection, sélectionnez Properties.
   • Dans la section Apps, si "Target to apps on all device types" est défini sur "No", passez à l'étape 2. Si le paramètre est défini sur "Yes", aucune action n'est requise pour cette stratégie : revenez à Apps > Protection pour examiner les autres stratégies.
     
2. Créer un filtre d'attribution "Managed apps" en utilisant la propriété app.deviceManagementType reflétant le comportement de ciblage souhaité. Par exemple : (app.deviceManagementType -eq "Automated Device Enrollment user-associated devices"). Microsoft recommande également de créer et d'utiliser un filtre incluant (app.deviceManagementType -ne "Unmanaged") afin de garantir que le filtre ne s'applique qu'aux appareils gérés.
   • Si votre stratégie historique était configurée pour cibler les appareils iOS/iPadOS "Managed", votre nouveau filtre d'attribution doit inclure :
     • Managed
     • Automated Device Enrollment user-associated devices
     • Automated Device Enrollment userless devices
     • Account Driven User Enrollment
     • Device Enrollment with Company Portal and Web Enrollment
   • Si votre stratégie historique était configurée pour cibler les appareils Android "Android Enterprise", votre nouveau filtre d'attribution doit inclure tous les types d'appareils Android pertinents ci-dessous :
     • Corporate-owned dedicated devices with Entra ID Shared mode
     • Corporate-owned dedicated devices without Entra ID Shared mode
     • Corporate-owned with work profile
     • Corporate-owned fully managed
     • Personally-owned work profile
       
       
       Le filtre doit être adapté à votre stratégie
3. Assigner le filtre à la stratégie existante tout en conservant la configuration de ciblage historique active. Cela permet d'éviter tout changement involontaire dans le ciblage de groupes et les assignations de stratégies :
   • Dans le volet de la stratégie Intune App Protection, sélectionnez Properties.
   • Dans la section Assignments, sélectionnez "Edit".
   • Dans la section Included group, sélectionnez "Edit Filter" > "Include filtered devices in assignment" et choisissez le filtre Managed apps précédemment créé.
   • Vérifiez et enregistrez vos modifications.
     
     
     
4. Supprimer la configuration de ciblage historique. Une fois la bonne configuration du filtre d'attribution confirmée, mettez à jour le paramètre historique de la stratégie pour cibler All device types. Les filtres d'attribution deviendront alors le mécanisme de ciblage principal, et le paramètre historique ne sera plus visible ni modifiable dans le centre d'administration.
   Dans les propriétés, éditez la section Apps puis changer Target to app on all devices types à Yes.
   
5. Répéter les étapes 1 à 4 pour chaque stratégie APP Intune de votre tenant.
6. Surveiller le déploiement des stratégies afin de valider leur bonne application et leur conformité après le changement.

Plus d'informations sur la création d'un filtre dans la documentation Microsoft Intune.

Dans la continuité de l'annonce de l'équipe Windows sur la Public Preview des conteneurs WSL, Microsoft étend le plug-in Microsoft Defender for Endpoint (MDE) à la prise en charge des conteneurs WSL (WSLc), en Public Preview.  Pour rappel, WSL 2 fournit un environnement Linux intégré à Windows tout en restant isolé via la virtualisation. Sans plug-in, cet environnement reste opaque pour Defender. Le plug-in MDE vient précisément se greffer sur ce sous-système isolé pour y apporter de la visibilité — et il couvre désormais à la fois les distributions WSL 2 classiques et les nouveaux conteneurs WSLc.  Le plug-in étend la protection Defender aux charges de travail WSL et remonte les signaux dans les expériences que vous connaissez déjà :

• Device Inventory (inventaire des appareils)
• Alerts et Incidents
• Device Timeline (chronologie de l'appareil)
• Advanced Hunting

Concrètement, une instance WSL n'est plus un angle mort : vous pouvez enquêter sur les activités qui s'y déroulent depuis le portail Microsoft Defender, au même titre que sur l'hôte Windows.

Prérequis

• WSL version 2.0.7.0 ou ultérieure avec au moins une distribution active (wsl --update pour vous mettre à jour).
• Pour les conteneurs WSLc : WSL 2.9.5 ou ultérieure, ainsi qu'une version en préversion du plug-in compatible WSLc.
• Le poste Windows doit être onboardé à Defender for Endpoint (Plan 2).
• Systèmes d'exploitation supportés : Windows 10 version 2004+ (build 19044+) et Windows 11.

Configuration étape par étape

1. Vérifier la version de WSL. Assurez-vous d'exécuter une version compatible (et mettez à jour si besoin) :

wsl --version

wsl --update

2. Installer le plug-in MDE pour WSL Téléchargez le package DefenderPlugin-x64.msi (depuis le portail Microsoft Defender, dans

msiexec /i DefenderPlugin-x64.msi /qn

Par défaut, le plug-in s'installe sous C:\Program Files\Microsoft Defender for Endpoint plug-in for WSL.

3. Valider l'installation. Contrôlez l'état de santé du plug-in :

"C:\Program Files\Microsoft Defender for Endpoint plug-in for WSL\healthcheck.exe"

La commande retourne les versions de WSL, du plug-in, de l'agent Defender ainsi que son état de santé. Laissez quelques minutes à l'instanciation du plug-in, et jusqu'à 30 minutes pour l'onboarding complet d'une instance WSL.

4. (Si nécessaire) Configurer le proxy

Si vos machines passent par un proxy, le plug-in peut hériter de la configuration proxy de l'hôte Windows (via winhttp) ou être paramétré explicitement en créant un fichier wsl-proxy.conf dans le dossier d'installation. Pensez à autoriser les https://learn.microsoft.com/en-us/defender-endpoint/configure-environment requises.

5. Vérifier la remontée dans le portail

Ouvrez une distribution WSL, générez un peu d'activité, puis confirmez l'apparition de l'instance dans Device Inventory du portail Microsoft Defender, ainsi que la remontée des événements dans Device Timeline et Advanced Hunting.

Quelques points relevés dans la documentation, utiles avant de tester :

• Comptez quelques minutes pour l'instanciation du plug-in, et jusqu'à 30 minutes pour l'onboarding d'une instance WSL 2. Des conteneurs à durée de vie très courte peuvent ne jamais apparaître dans le portail.
• Les mises à jour automatiques via Windows Update sont prises en charge à partir de la version 1.24.522.2 du plug-in (tous les rings). Via WSUS, SCCM ou le Microsoft Update Catalog, elles sont limitées au ring Production pour garantir la stabilité du package.
• L'usage d'un kernel personnalisé n'est pas pris en charge.

La prise en charge WSLc étant en préversion publique, il faut s'inscrire pour obtenir la version compatible du plug-in :

• Inscription à la Public Preview via le formulaire dédié.
• Documentation MDE : MDE Plug-in for WSL.
• Documentation WSLc : WSL containers.

Microsoft annonce le retrait du support de Windows Information Protection (WIP) et de Microsoft Defender Application Guard (MDAG) dans Microsoft Edge. Ces deux fonctionnalités étaient déjà dépréciées côté Windows et ne sont plus disponibles depuis Windows 11, version 24H2.

Microsoft recommande de basculer vers les alternatives suivantes :

• Pour les scénarios WIP : Microsoft Purview Information Protection, Microsoft Purview Data Loss Prevention (DLP), Endpoint DLP, ainsi que les stratégies de protection d'application Intune.
• Pour les scénarios MDAG : les capacités de sécurité intégrées à Microsoft Edge et les autres solutions d'isolation supportées adaptées à votre environnement.

Calendrier de déploiement

Le retrait sera déployé au niveau mondial à partir de fin septembre 2026, avec une fin de déploiement également prévue fin septembre 2026.

Qui est concerné

Sont concernées les organisations ayant configuré WIP ou MDAG pour Microsoft Edge sur des postes Windows 10. Ces fonctionnalités sont désactivées par défaut et nécessitent une activation explicite par un administrateur : les organisations ne les ayant jamais activées ne sont pas impactées. Dans les faits, cela ne concerne qu'une population restreinte de postes Windows 10, ces deux fonctionnalités ayant été conçues pour Windows 10 et étant déjà indisponibles sous Windows 11, version 24H2.

Ce qui va changer

• Le support de WIP et de MDAG sera retiré de Microsoft Edge.
• Une fois le déploiement terminé, ces fonctionnalités ne fonctionneront plus à partir de Microsoft Edge 154 et versions ultérieures.
• Les organisations utilisant WIP ou MDAG doivent basculer vers les alternatives supportées.
• Les postes sous Windows 11, version 24H2 ne sont pas censés être impactés, ces fonctionnalités ayant déjà été retirées de la plateforme Windows.

Actions recommandées

Vérifiez vos configurations actuelles de sécurité Microsoft Edge et Windows afin de déterminer si WIP ou MDAG sont encore utilisés dans votre environnement.

Si vous utilisez WIP, planifiez la migration vers :

• Microsoft Purview Information Protection.
• Microsoft Purview Data Loss Prevention et Endpoint DLP.
• Les stratégies de protection d'application Intune, le cas échéant.

Si vous utilisez MDAG, évaluez les capacités de sécurité supportées de Microsoft Edge ainsi que les technologies d'isolation alternatives répondant aux besoins de votre organisation.

Planifiez vos actions de migration avant la fin du déploiement, prévue fin septembre 2026. Si vous avez besoin de délai supplémentaire, contactez le support Microsoft ou votre équipe de compte Microsoft pour évaluer les options disponibles.

Microsoft annonce une évolution majeure de Microsoft Purview DLP en étendant la protection des données au niveau réseau grâce à son intégration avec Microsoft Entra Internet Access et Global Secure Access.La Public Preview a démarré en juillet 2026 et la Disponibilité générale (GA) entre septembre et octobre 2026.

Cette nouvelle capacité permet d'inspecter et contrôler les données sensibles lorsqu'elles transitent vers des applications SaaS, des services cloud ou des plateformes d'IA générative. Grâce à cette intégration, les organisations pourront :

• Inspecter le trafic réseau à l'aide d'Entra Internet Access.
• Appliquer les classifications et stratégies DLP de Microsoft Purview aux flux réseau.
• Détecter et bloquer l'envoi d'informations sensibles vers des applications cloud ou d'IA.
• Contrôler les prompts envoyés aux outils d'IA générative.
• Générer des alertes et incidents dans Microsoft Purview et Microsoft Defender.

Jusqu'à présent, les contrôles DLP reposaient principalement sur :Microsoft 365, Les terminaux, et les applications intégrées.  Avec cette évolution, Microsoft apporte une approche proche du Secure Web Gateway (SWG) ou du CASB inline, permettant de contrôler les données directement au niveau du trafic réseau.

Les organisations pourront ainsi protéger les informations sensibles même lorsqu'elles sont envoyées vers :

• Des outils d'IA générative non approuvés
• Des services de stockage cloud tiers
• Des webmails
• Des réseaux sociaux
• Des formulaires web
• Des applications SaaS non managées

Quelques exemples :

• Bloquer l'envoi de numéros de cartes bancaires vers ChatGPT ou d'autres IA publiques.
• Empêcher le partage de documents confidentiels vers Dropbox ou Google Drive.
• Détecter la copie de données sensibles dans un formulaire web.
• Contrôler l'utilisation d'outils Shadow IT non approuvés.

Une fois disponible, les administrateurs devront créer et déployer des politiques pour :

• Auditer les échanges
• Générer des alertes
• Bloquer certaines transmissions
• Appliquer des règles basées sur :
  • les Sensitive Information Types
  • les Sensitivity Labels
  • le niveau de risque utilisateur

Microsoft renforce la protection des documents sensibles dans Microsoft 365. Désormais, Microsoft Edge appliquera la permission "Do Not Allow Screen Capture" aux PDF protégés par Microsoft Purview Information Protection lorsqu'ils sont ouverts dans les visionneuses web de SharePoint Online et OneDrive. Jusqu'à présent, une limitation existait dans l'affichage PDF via navigateur : certaines restrictions MIP n'étaient pas appliquées dans le lecteur PDF web.

Avec cette mise à jour :

• Les captures d'écran seront bloquées pour les PDF protégés par une étiquette contenant la permission Do Not Allow Screen Capture.
• La protection sera appliquée automatiquement dans Microsoft Edge.
• Les étiquettes de confidentialité et stratégies existantes continueront à fonctionner sans modification.
• Les PDF non étiquetés ou ne contenant pas cette restriction ne sont pas concernés.

Cette évolution aligne le comportement du lecteur PDF web avec celui déjà disponible dans les applications de bureau. Vous êtes concerné si vous utilisez :

• Microsoft Purview Information Protection
• Des étiquettes de confidentialité avec restrictions de capture d'écran
• SharePoint Online ou OneDrive for Business
• Microsoft Edge comme navigateur d'entreprise

Les utilisateurs ouvrant un PDF protégé dans Edge ne pourront plus réaliser de capture d'écran du contenu. Lors de la disponibilité générale :

• Seul Microsoft Edge est pris en charge.
• Les autres navigateurs ne bénéficieront pas nécessairement de la même protection.
• Les scénarios web mobiles ne sont pas couverts.

Les organisations souhaitant garantir cette protection devraient donc privilégier Edge pour l'accès aux documents sensibles.

Microsoft recommande de :

1. Vérifier les étiquettes de confidentialité utilisant Do Not Allow Screen Capture.
2. Informer les utilisateurs que certaines captures d'écran pourront désormais être bloquées.
3. Mettre à jour la documentation du support et du helpdesk.
4. Évaluer l'utilisation de stratégies de navigateur ou d'accès conditionnel afin de favoriser l'utilisation de Microsoft Edge pour les documents protégés.

La mise à jour de sécurité Windows de septembre 2026 nécessitera un redémarrage, y compris pour les appareils inscrits au hotpatching, car elle sera publiée sous la forme d'une mise à jour standard et non d'une mise à jour hotpatch. Certaines des améliorations de sécurité de cette mise à jour modifient des composants qui ne peuvent pas être mis à jour sans redémarrage. Les appareils inscrits au hotpatching devront donc redémarrer pour finaliser l'installation.

Pour mémoire, le hotpatching permet d'appliquer les mises à jour de sécurité Windows sans redémarrage, en corrigeant le code en mémoire des processus en cours d'exécution. L'objectif est d'assurer une protection immédiate tout en réduisant les interruptions pour les utilisateurs.

Le cycle repose sur une alternance :

• Des mois de baseline (planifiés trimestriellement : janvier, avril, juillet, octobre), qui incluent une mise à jour cumulative complète avec redémarrage.
• Des mois de hotpatch (les deux mois suivant chaque baseline), qui appliquent les correctifs de sécurité sans redémarrage.

La mise à jour de septembre 2026 constitue une exception à ce cycle : bien que ce soit normalement un mois de hotpatch, la nature des correctifs impose exceptionnellement un redémarrage.

Calendrier de déploiement

• Septembre 2026 : mise à jour standard avec redémarrage requis pour tous les appareils, y compris ceux inscrits au hotpatching.
• Octobre 2026 : mois de mise à jour baseline planifié, avec redémarrage requis.
• Novembre 2026 : prochaine mise à jour hotpatch attendue (sans redémarrage).

Recommandations

Voici les points à prendre en compte :

• Informer les utilisateurs que la mise à jour de septembre 2026 nécessitera un redémarrage, contrairement à ce qui est habituel pour un mois de hotpatch.
• Vérifier les stratégies de redémarrage (deadlines, délais de grâce, notifications) afin d'assurer une installation complète dans les délais.
• Suivre le déploiement des mises à jour via vos outils habituels (Windows Update for Business, Intune) pour confirmer la bonne application.
• Aucune modification d'inscription ni de conformité n'est nécessaire : les appareils demeurent inscrits au hotpatching et reprendront le cycle normal dès novembre 2026.

Microsoft enrichit Microsoft Purview Data Loss Prevention (DLP) avec une nouvelle capacité permettant de bloquer l'accès à des fichiers SharePoint Online et OneDrive pour des domaines externes spécifiques ou des adresses e-mail individuelles.

Les administrateurs pourront désormais configurer une règle DLP pour :

• Bloquer un ou plusieurs domaines externes (ex. : partner.com).
• Bloquer des utilisateurs externes spécifiques (ex. : user@partner.com).
• Définir des listes d'autorisation pour certains partenaires de confiance.
• Contrôler plus finement l'accès aux données sensibles partagées à l'extérieur.

En cas de conflit entre une liste d'autorisation et une liste de blocage, la règle de blocage est prioritaire.

Lorsqu'une règle est appliquée :

• Les utilisateurs externes concernés recevront un message "Access Denied".
• Ils ne pourront ni ouvrir ni télécharger le document protégé.

Cette nouveauté permet notamment :

• D'interdire le partage de données sensibles avec certains partenaires.
• De bloquer l'accès à des domaines jugés à risque.
• D'autoriser uniquement certains partenaires externes approuvés.
• De renforcer la protection des données réglementées ou confidentielles.

Avec cette évolution, Microsoft Purview DLP apporte un niveau de contrôle supplémentaire sur le partage externe dans Microsoft 365. Les administrateurs peuvent désormais restreindre l'accès à des documents sensibles en fonction de l'identité ou du domaine du destinataire externe, renforçant ainsi la gouvernance et la protection des données dans SharePoint Online et OneDrive.

Microsoft a annoncé le retrait des stratégies de fichiers (file policies) : la protection des données basée sur les fichiers quitte Microsoft Defender for Cloud Apps pour rejoindre Microsoft Purview. Les stratégies de fichiers cesseront de fonctionner le 6 janvier 2027. D'ici cette échéance, il vous faut passer en revue vos stratégies existantes et les recréer sous forme de stratégies DLP (Data Loss Prevention) ou d'étiquetage automatique (auto-labeling) dans Microsoft Purview. Je vous propose un tour d'horizon de ce qui change, des équivalences à connaître et de la démarche de migration à engager.

Ce qui change

Le périmètre du retrait concerne uniquement les stratégies de type « File policy » visibles dans le portail Microsoft Defender. Microsoft recommande de commencer par catégoriser chaque stratégie selon son intention, car la cible de migration diffère selon les cas.

• Les stratégies de détection et de réponse (détection de contenu sensible assortie d'une action de protection) doivent être recréées en tant que stratégies DLP Microsoft Purview.
• Les stratégies qui appliquent une étiquette de confidentialité en fonction du contenu doivent être recréées en tant que stratégies d'étiquetage automatique dans Information Protection.
• Attention, les stratégies Defender for Cloud Apps et Purview ne peuvent pas coexister : exécuter des stratégies équivalentes dans les deux produits en même temps génère des conflits d'application. Désactivez les stratégies Defender for Cloud Apps seulement après avoir validé et activé les stratégies Purview.

Ce que Defender for Cloud Apps continue d'assurer

Il ne s'agit pas d'un retrait du service : Microsoft Defender for Cloud Apps continue de fournir la découverte des applications SaaS (Shadow IT), la gestion de la posture (SSPM) et la détection des menaces. Seule la protection des données basée sur les fichiers est transférée vers Microsoft Purview.

À compter de début octobre 2026, Windows App commencera à utiliser trois nouveaux noms de domaine complets (FQDN) génériques (wildcard) pour le trafic de service côté client à destination de Windows 365. Ces domaines sont déjà inclus dans les exigences de connectivité côté cloud (cloud-side). Si votre organisation applique des contrôles réseau sur les appareils exécutant Windows App, vous devez autoriser ces endpoints dans votre configuration réseau côté client. Si ces endpoints ne sont pas joignables, les utilisateurs pourront rencontrer des échecs d'authentification et de connexion.

Les organisations qui ont déjà réalisé la mise à jour côté cloud doivent tout de même passer en revue leurs politiques de proxy, pare-feu, VPN, filtrage DNS et Secure Web Gateway (SWG) appliquées aux postes utilisateurs, afin de s'assurer que ces endpoints sont bien autorisés. Ce travail s'inscrit dans la démarche d'unification des exigences de domaines menée par Microsoft, consolidant le trafic de service sous le domaine unifié cloud.microsoft.

Nouveaux endpoints à autoriser

Windows App commencera à utiliser ces endpoints début octobre 2026. Les trois FQDN génériques sont les suivants :

Qui est concerné

Sont concernées les organisations qui :

• Utilisent Windows App pour se connecter à des Cloud PC Windows 365.
• Appliquent des contrôles réseau (pare-feu, proxy, VPN, filtrage DNS, Secure Web Gateway ou équivalent) sur les postes utilisateurs.

Les utilisateurs sur des appareils non gérés ou sur des réseaux domestiques n'ont généralement aucune action à mener, sauf si des contrôles réseau bloquent les endpoints requis.

Actions recommandées

Voici les étapes à prendre en compte :

• Autoriser le trafic HTTPS sortant sur le port 443/TCP vers les trois FQDN dans les règles de pare-feu, listes d'autorisation de proxy, configurations VPN, filtres DNS et politiques Secure Web Gateway applicables.
• Vérifier l'inspection TLS ou tout autre mécanisme d'interception susceptible d'empêcher Windows App d'atteindre les services Microsoft. Lorsque la politique de l'organisation le permet, routez ce trafic directement vers Microsoft.
• Anticiper les délais de validation : si les postes clients se trouvent derrière une frontière réseau gérée, sollicitez au plus tôt l'équipe qui administre ces contrôles, car les processus d'approbation et de gestion du changement peuvent nécessiter un délai supplémentaire.
• Informer votre support (help desk) et mettre à jour vos guides internes de configuration réseau et de dépannage.

Informations complémentaires

Pour plus d'informations, consultez Le domaine unifié cloud.microsoft de Microsoft sur Microsoft Learn.

Microsoft simplifie le fonctionnement de Microsoft Defender for Endpoint en intégrant totalement les capacités d’Automated Investigation and Response (AIR) dans le moteur antivirus. À compter du 1er septembre 2026, AIR ne sera plus disponible comme fonctionnalité distincte et ne pourra plus être déclenché manuellement.

Aujourd'hui, les équipes de sécurité peuvent lancer des investigations AIR manuellement ou via des automatisations.

À partir du 1er septembre 2026 :

• AIR ne sera plus proposé comme expérience d’investigation séparée.
• Le déclenchement manuel d’une investigation AIR sera supprimé.
• Les capacités de détection et de remédiation continueront à fonctionner automatiquement via la protection antivirus toujours active de Microsoft Defender.
• Les analyses antivirus complètes deviendront l'approche recommandée pour les investigations à la demande.

La protection reste activée par défaut et aucun niveau de sécurité n'est supprimé.

Vous êtes concerné si vous utilisez :Microsoft Defender for Endpoint, Microsoft Defender XDR, des playbooks, scripts ou intégrations lançant automatiquement AIR. Après la mise à jour :

• Les workflows déclenchant AIR ne fonctionneront plus.
• Les capacités automatiques de détection et de réponse continueront d'opérer en arrière-plan.
• Les investigations ponctuelles devront s'appuyer sur des analyses antivirus complètes.

Microsoft poursuit sa stratégie de "Shift Left Security", visant à automatiser davantage la protection afin de réduire les actions manuelles nécessaires de la part des équipes de sécurité. L'objectif est de :

• Simplifier l'expérience d'exploitation.
• Offrir une protection plus homogène.
• Réduire la dépendance aux investigations manuelles.
• Garantir des réponses automatiques cohérentes sur l'ensemble du parc.

Si vous n'utilisez pas AIR manuellement ou via des automatisations, aucune action n'est nécessaire. En revanche, si AIR est utilisé dans votre organisation, Microsoft recommande de :

1. Identifier les playbooks, scripts ou intégrations utilisant AIR.
2. Mettre à jour ces automatisations avant le 1er septembre 2026.
3. Remplacer les workflows AIR par des mécanismes reposant sur des analyses antivirus complètes.
4. Mettre à jour la documentation opérationnelle et les procédures SOC.
5. Informer les équipes sécurité et support de cette évolution.

Microsoft simplifie la gestion des mises à jour de Microsoft 365 Apps en fusionnant les canaux Semi-Annual Enterprise Channel (SAEC) et Monthly Enterprise Channel (MEC) au sein d'un canal unique orienté entreprise. Cette évolution a pris effet le 14 juillet 2026.

Depuis cette date :

• Les appareils configurés sur Semi-Annual Enterprise Channel recevront les mêmes mises à jour que le Monthly Enterprise Channel.
• Les politiques et configurations existantes continueront à fonctionner normalement.
• Aucun changement n'est prévu pour les appareils déjà configurés sur MEC, Current Channel ou les canaux Preview.
• Les utilisateurs ne devraient constater aucun impact sur leurs usages quotidiens.

Microsoft souhaite réduire la complexité liée à la coexistence de plusieurs canaux d'entreprise tout en :

• Accélérant l'accès aux nouvelles fonctionnalités.
• Améliorant la diffusion des correctifs de sécurité.
• Simplifiant la gestion des mises à jour pour les administrateurs.
• Offrant une expérience de maintenance plus cohérente au sein des organisations.

Impact pour votre organisation

Vous êtes principalement concerné si vous utilisez actuellement : Semi-Annual Enterprise Channel (SAEC). Microsoft indique qu'aucune action n'est nécessaire.

Il peut néanmoins être utile de :

• Vérifier les canaux actuellement utilisés dans votre organisation.
• Informer les équipes de support de cette évolution.
• Mettre à jour la documentation interne mentionnant encore le canal SAEC.

Microsoft annonce une évolution majeure du rythme de publication de Microsoft Edge. À partir de Microsoft Edge 152, dont la sortie est prévue le 27 août 2026, le canal Stable passera d'un cycle de mise à jour de 4 semaines à 2 semaines.

Avec cette nouvelle cadence :

• Le canal Stable sera mis à jour toutes les 2 semaines.
• Les correctifs de sécurité et améliorations de la plateforme seront déployés plus rapidement.
• Chaque mise à jour embarquera moins de changements, facilitant leur validation.
• Les mécanismes d'administration et de gestion d'Edge restent inchangés.

Aucun changement n'est prévu pour les organisations souhaitant un rythme plus conservateur :

• Extended Stable continuera à être mis à jour toutes les 8 semaines.
• Les versions Extended Stable seront publiées tous les quatre cycles Stable (par exemple : versions 156, 160, 164...).

Vous êtes concerné si vous utilisez le canal Microsoft Edge Stable sur : Windows, macOS, Linux, Mobile

Microsoft recommande de :

• Adapter les processus de validation aux mises à jour toutes les deux semaines.
• Maintenir un groupe pilote utilisant le canal Beta pour anticiper les changements.
• Mettre à jour la documentation interne et les procédures du support.
• Envisager le canal Extended Stable si votre organisation nécessite davantage de temps de qualification.

Merill Fernando (ex-Principal Product Manager – Microsoft Entra) revient sur un point important concernant les nouveaux "agent users" de Microsoft Entra Agent ID et leur interaction avec les groupes à appartenance dynamique.   Microsoft a clarifié la façon dont les comptes "agent user" sont traités par les règles de groupes dynamiques dans Entra ID. Un compte agent user est évalué comme n'importe quel autre utilisateur par les règles de membership dynamique basées sur les propriétés utilisateur. Si le compte satisfait une règle, il peut être ajouté au groupe dynamique au même titre qu'un utilisateur classique. Cela signifie qu'un agent peut hériter de tout ce qui est rattaché au groupe : licences basées sur le groupe, accès aux applications, ressources de groupes Microsoft 365, ou d'autres permissions.  

À noter : les agent users ne sont pas ajoutés automatiquement à tous les groupes dynamiques. Ils sont évalués par les mêmes règles que les utilisateurs classiques et ne sont ajoutés que s'ils satisfont ces règles. Le vrai problème réside dans les règles trop larges, qu'un agent user peut satisfaire sans que le propriétaire du groupe s'en rende compte.

Pourquoi les agent users ressemblent à des utilisateurs pour les règles dynamiques

Il faut distinguer deux identités dans Microsoft Entra Agent ID :

• L'identité principale de l'agent est un service principal. Elle n'est pas prise en charge comme membre d'un groupe dynamique.
• L'agent peut également disposer d'un compte "agent user" optionnel, destiné aux systèmes nécessitant une identité de type utilisateur. Microsoft le décrit comme un sous-type de la ressource user. Ce compte reçoit des tokens avec idtyp=user, peut être ajouté à des groupes et des unités d'administration, et peut se voir attribuer des licences. Microsoft Graph expose ce compte via la ressource agentUser.

Ce compte hérite de nombreuses propriétés utilisateur classiques, notamment : userPrincipalName, userType, department, companyName, employeeId, assignedLicenses, assignedPlans

Parce que la ressource agentUser hérite de ces propriétés, une règle écrite avant l'arrivée des agent users dans le tenant peut malgré tout matcher un agent. Prenons l'exemple d'une règle courante « tous les utilisateurs membres » :

(user.objectId -ne null) -and (user.userType -eq "Member")

La propriété userType permet de distinguer Member de Guest, mais un agent user peut également avoir userType défini sur Member : cette propriété ne dit donc rien sur le fait que l'identité corresponde ou non à une personne physique. Le même problème peut apparaître avec des règles basées sur le pays, le département, le nom de société, l'UPN, ou toute autre propriété utilisateur supportée.

Microsoft documente explicitement qu'un agent user peut se voir attribuer des licences, et que sa collection assignedLicenses inclut les licences héritées via le group-based licensing. Si un groupe dynamique est utilisé pour l'attribution de licences, un agent user qui rejoint ce groupe peut consommer l'une des licences disponibles. Si le pool de licences est épuisé, les nouveaux utilisateurs ajoutés ne recevront pas cette licence tant qu'une autre ne se libère pas.

Deux vérifications s'imposent côté licences :

• Le produit attribué au groupe pourrait être assigné à un agent qui n'en a pas l'usage.
• Le group-based licensing dynamique nécessite suffisamment de licences Entra ID P1 pour couvrir chaque utilisateur unique présent dans un ou plusieurs groupes dynamiques. Un agent user étant un sous-type d'utilisateur, il convient de vérifier avec votre contact licensing Microsoft l'impact de votre population d'agents sur ce besoin.

Les licences ne sont qu'une des conséquences possibles. Il faut également vérifier si chaque groupe concerné est utilisé pour :

• Les assignations d'applications d'entreprise (Enterprise applications)
• Les groupes Microsoft 365 et Teams
• Les permissions SharePoint
• Le ciblage de stratégies Conditional Access
• Les Access Packages et autres workflows de gouvernance des accès
• Les attributions de rôles Azure ou spécifiques à une application qui s'appuient sur ce groupe  

À noter également : un agent user ne peut pas être ajouté à un groupe assignable à un rôle (role-assignable group), ce qui limite son impact potentiel sur les rôles Entra ID les plus sensibles.

Voici ce qui est recommander :

• Auditez vos règles de membership dynamique existantes (utilisateurs et licences) afin d'identifier celles qui pourraient matcher un agent user sans distinction explicite.
• Ajoutez si besoin une condition d'exclusion explicite des agent users dans vos règles dynamiques les plus sensibles (licences, accès applicatifs, Conditional Access).
• Vérifiez le dimensionnement de vos licences Entra ID P1 utilisées pour le group-based licensing dynamique en tenant compte de votre population d'agents.
• Passez en revue les groupes dynamiques utilisés pour les accès SharePoint, les Access Packages, la Conditional Access et les rôles Azure afin de vérifier qu'aucun agent user n'y a été intégré involontairement.

Plus d'informations sur l'article original de Merill Fernando : Microsoft Entra agent users can join your dynamic groups. Here is what to check - merill.net

Microsoft a introduit un ensemble de nouveautés dans Microsoft Defender for Cloud (anciennement Azure Defender ou Azure Security Center). Comme pour les autres services, je vous propose un résumé des changements et fonctionnalités que Microsoft a pu introduire dans le mois.

• De nouvelles capacités de sécurité des conteneurs sont désormais en disponibilité générale (GA) : les recommandations de mauvaise configuration au niveau des conteneurs pour Kubernetes (KSPM sans agent dans Defender CSPM, évaluant chaque conteneur plutôt que le cluster entier), la recommandation actionnable « Upgrade Azure Kubernetes Service Version » qui identifie la version AKS minimale requise pour corriger les vulnérabilités des pods système gérés par AKS, l’évaluation des vulnérabilités des images de conteneurs découvertes à l’exécution sur Amazon EKS et Google GKE (couverture unifiée Azure, AWS et GCP), l’évaluation des vulnérabilités des nœuds Kubernetes (hôtes) sur EKS et GKE (parité avec AKS), et la prise en charge de l’analyse des images de conteneurs Docker Hardened. Les recommandations au niveau du cluster sont désormais dépréciées (montage de volume HostPath, ports autorisés, réseau et ports hôte, CAP_SYS_ADMIN, profils AppArmor).
• L’application (enforcement) des mauvaises configurations Kubernetes dans Defender for Containers est désormais en disponibilité générale (GA). Cette fonctionnalité évalue les configurations des ressources Kubernetes au moment de l’admission et peut auditer ou bloquer les déploiements qui ne respectent pas les règles de bonnes pratiques de sécurité Microsoft. Elle est disponible via l’approvisionnement automatique : pour AKS et Kubernetes avec Azure Arc, en activant Defender for Containers avec l’accès à l’API Kubernetes ; pour AWS et GCP, avec la protection contre les menaces sans agent. Le déploiement manuel avec Helm reste pris en charge.
• La découverte et la posture pour les charges de travail conteneurisées serverless sont désormais en disponibilité générale (GA). Cette capacité offre la visibilité de l’inventaire, des recommandations de sécurité pour les mauvaises configurations, les résultats d’évaluation des vulnérabilités et l’analyse des chemins d’attaque pour Azure Container Apps, Azure Container Instances et Amazon Elastic Container Service (ECS) sur AWS Fargate.
• L’API d’activation des plans bloque désormais l’intégration à cinq plans Defender dépréciés : Microsoft Defender for Azure Kubernetes Service et Defender for Azure Container Registry (à migrer vers Defender for Containers), Defender for DNS (vers Defender for Servers), ainsi que Defender for Key Vault et Defender for Azure Resource Manager (vers le modèle de tarification fixe). Ce blocage s’aligne sur la politique de dépréciation de Microsoft et sur le comportement déjà en place dans le portail. Il ne concerne que les nouvelles activations : les abonnements existants conservent l’accès au produit et la facturation sans changement. Pensez à mettre à jour les scripts ou automatisations qui appellent l’API pour ces plans, car ces appels échoueront une fois le blocage appliqué. Aucune date de retrait officielle n’a été annoncée pour ces plans.
• Des recommandations au niveau base de données pour SQL Vulnerability Assessment sont désormais en disponibilité générale (GA). Dans le cadre du passage des recommandations groupées aux recommandations individuelles, chaque règle d’évaluation des vulnérabilités SQL est exposée comme une recommandation distincte, rapportée directement sur la base de données SQL concernée. Ces recommandations influent sur le Cloud Score basé sur les risques, mais n’ont pas d’incidence sur le Secure Score classique. Trois options de remédiation sont possibles : corriger la mauvaise configuration (étapes ou script de remédiation fournis), approuver le résultat comme référence (baseline, définie par règle et par ressource) ou créer une exemption au niveau de l’abonnement ou du groupe d’administration.
• À venir : le CSPM fondamental (Foundational CSPM) passe à un modèle d’adhésion volontaire (opt-in) pour les nouveaux abonnements Azure. À compter du 27 octobre 2026, il ne sera plus activé par défaut sur les nouveaux abonnements Azure. Ce changement, qui s’inscrit dans la transition de la gestion de la posture de sécurité cloud vers le portail Microsoft Defender, vous donne davantage de contrôle sur sa configuration. Le CSPM fondamental reste gratuit et peut être activé à tout moment. Seuls les nouveaux abonnements Azure sont concernés : les abonnements existants conservent leur configuration actuelle et les environnements AWS et GCP ne sont pas affectés.
• La dépréciation des anciennes recommandations groupées est achevée : leur retrait du portail Azure a commencé et les données dépréciées (sous-évaluations) ne sont plus accessibles via l’API. Le portail Azure et Azure Resource Graph peuvent nécessiter quelques jours pour refléter ce changement. Les recommandations individuelles, annoncées en mai 2026, les remplacent. Si vous utilisiez les recommandations groupées, validez vos automatisations, rapports, flux de gouvernance et requêtes existants, et migrez les règles de désactivation restantes vers des exemptions.

Plus d’informations sur : Release notes for Microsoft Defender for Cloud | Microsoft Docs

Comme pour les autres services, je vous propose un résumé des changements et fonctionnalités que Microsoft a pu introduire dans le mois concernant son service Microsoft Defender for Office.

• Modèles localisés par défaut pour « Marquer comme » et les notifications : lorsque les notifications automatiques utilisent le modèle par défaut, les utilisateurs reçoivent les e-mails de notification dans leur langue préférée, en fonction des paramètres de langue de leur client Outlook. Les modèles de notification personnalisés configurés par les administrateurs ne sont pas concernés.
• Le RBAC unifié devient le modèle d’autorisation par défaut des nouvelles organisations Defender for Office 365 Plan 2 : depuis juillet 2026, les nouvelles organisations Microsoft Defender for Office 365 Plan 2 utilisent par défaut le modèle de contrôle d’accès en fonction du rôle unifié (RBAC unifié) de Microsoft Defender.
• Microsoft Defender for Office 365 Plan 1 inclus dans Microsoft 365 E3 : Microsoft 365 E3 inclut désormais Microsoft Defender for Office 365 Plan 1.
• Protection contre l’injection de prompt : Microsoft Defender for Office 365 détecte désormais les attaques par injection de prompt dissimulées dans les e-mails entrants.

Plus d’informations sur : What's new in Microsoft Defender for Office 365 - Office 365 | Microsoft Docs

Le 6 août 2026, Microsoft a confirmé la fin de la préversion publique de l'opérateur de règle memberOf pour les groupes dynamiques dans Entra. Cet opérateur, disponible en préversion depuis longtemps, permettait de construire un groupe dynamique (utilisateurs ou appareils) à partir des membres directs d'autres groupes (jusqu'à 50 groupes sources). Il était particulièrement utile lorsqu'une application ne savait pas interpréter l'imbrication de groupes (nested groups), ou lorsque l'on souhaitait disposer d'un groupe unique pour l'attribution de licences ou d'accès.

Microsoft indique que les règles memberOf peuvent ralentir le traitement de l'appartenance dynamique pour l'ensemble des groupes d'un locataire, ce qui explique la fin de cette préversion pour des raisons de scalabilité et de fiabilité.

Attention : il ne s'agit pas d'un retrait anodin d'une option inutilisée. Un groupe concerné conservera sa dernière appartenance calculée, ce qui peut laisser des accès en place alors qu'ils auraient dû évoluer (appartenance obsolète). Microsoft n'ajoutera ni ne supprimera plus de membres tant que vous n'aurez pas remplacé la règle.

Les dates à retenir méritent une attention immédiate :

• À partir du 27 octobre 2026, les stratégies d'attribution automatique (auto-assignment policies) utilisant memberOf seront mises en quarantaine. Le traitement s'arrête alors, même si la stratégie subsiste. [
• Après le 3 novembre 2026, les groupes dynamiques, les unités administratives dynamiques et les stratégies d'attribution automatique de la gestion des droits d'utilisation (entitlement management) cessent de se mettre à jour.

Il est recommandé de considérer le 27 octobre 2026 comme échéance principale pour toutes les configurations concernées, plutôt que de compter sur la semaine supplémentaire.

Les conséquences dépendent de l'usage du groupe : une appartenance obsolète peut préserver un accès Teams ou SharePoint, maintenir une licence basée sur le groupe, affecter le ciblage d'un accès conditionnel (Conditional Access), ou laisser une attribution de package d'accès désynchronisée.

Voici les étapes à prendre en compte :

1. Identifiez les groupes concernés. Vous pouvez inspecter chaque groupe dynamique depuis le centre d'administration Entra (Entra ID > Groupes > Tous les groupes), mais PowerShell est bien plus rapide pour réaliser cet audit. Installez le SDK Microsoft Graph PowerShell si nécessaire, connectez-vous avec l'autorisation en lecture seule Group.Read.All, puis exécutez les commandes suivantes :

Connect-MgGraph -Scopes 'Group.Read.All'

$filter = "startsWith(membershipRule,'user.memberOf') or startsWith(membershipRule,'device.memberOf')"

$memberOfGroups = Get-MgGroup -filter $filter

$memberOfGroups | fl

2. Documentez ce que contrôle chaque groupe retourné et identifiez les ID d'objet des groupes sources présents dans la règle.
3. Déterminez si des attributs supportés (utilisateur ou appareil) peuvent exprimer la même appartenance. Lorsque ce n'est pas possible, convertissez le groupe de destination en appartenance attribuée (assigned membership) ou utilisez un processus d'automatisation pour la maintenir. L'appartenance attribuée est l'option de remplacement la plus simple pour une action immédiate, mais quelqu'un devra alors gérer chaque mouvement (joiner, mover, leaver).
4. Ne supprimez pas simplement la règle en espérant que l'appartenance actuelle soit correcte. Exportez la liste des membres existants avant de construire la solution de remplacement.

Voici le guide de migration

Plus d'informations sur : Configure dynamic membership groups with the memberOf operator in the Entra Admin Center (preview) - Microsoft Entra ID | Microsoft Learn

Microsoft poursuit le renforcement de la sécurité des expériences de connexion Microsoft Entra dans le cadre de sa Secure Future Initiative (SFI). À partir d'octobre 2026, certaines propriétés CSS personnalisées utilisées dans le branding des pages de connexion ne seront plus prises en charge.

Les propriétés CSS permettant de modifier le positionnement ou l'apparence des éléments de la page de connexion seront progressivement retirées.

Parmi les propriétés concernées :

• position, top, left, right, bottom, z-index
• margin
• transform
• opacity
• overflow
• filter
• pointer-events
• clip-path
• mix-blend-mode
• translate

À compter du 26 octobre 2026, ces propriétés ne seront plus appliquées.

Impact pour votre organisation

Vous êtes concerné si vous utilisez du CSS personnalisé dans le branding Microsoft Entra ID afin de modifier la disposition des éléments de la page de connexion.

Après la mise à jour :

• Les logos, images et textes resteront affichés.
• Leur positionnement pourra revenir à l'affichage par défaut.
• Aucun mécanisme de migration ou remplacement n'est prévu.

Les tenants n'utilisant pas ces personnalisations ne sont pas impactés. Les tenants Microsoft Entra ID créés après le 5 janvier 2026 ne disposent déjà plus de cette fonctionnalité.

Pourquoi ce changement ?

Microsoft souhaite limiter les possibilités de créer des pages de connexion trompeuses ou atypiques pouvant faciliter des attaques de type phishing.

L'objectif est d'offrir une expérience d'authentification plus cohérente, fiable et sécurisée pour les utilisateurs.

Actions recommandées

Avant octobre 2026, Microsoft recommande de :

1. Vérifier votre configuration de branding Entra ID.
2. Identifier l'utilisation éventuelle des propriétés CSS retirées.
3. Adapter ou simplifier les personnalisations concernées.
4. Tester l'affichage des pages de connexion après modification.

Cette évolution s'inscrit dans la stratégie de Microsoft visant à renforcer la sécurité des expériences de connexion. Les organisations utilisant du CSS personnalisé pour modifier la mise en page des écrans de connexion devront anticiper la suppression de ces propriétés avant le 26 octobre 2026 afin d'éviter toute dégradation visuelle de leur branding.

Microsoft annonce une amélioration importante pour Microsoft Purview Information Protection. La capacité maximale d’auto-labellisation côté serveur pour SharePoint Online et OneDrive passera de 100 000 à 500 000 fichiers par jour et par tenant.

Avec cette évolution :

• La capacité d’auto-labellisation est multipliée par 5.
• Jusqu’à 500 000 fichiers par jour pourront être analysés et étiquetés automatiquement.
• Les politiques d’auto-labellisation existantes bénéficieront automatiquement de cette augmentation.
• Aucun changement de configuration ou d’expérience utilisateur n'est nécessaire.

Cette amélioration permettra de :

• Réduire plus rapidement les écarts de classification sur les données existantes.
• Étendre la protection à un plus grand volume de fichiers dans SharePoint et OneDrive.
• Accélérer les projets de gouvernance et de protection de l'information.
• Mieux préparer les données à une utilisation sécurisée avec Microsoft 365 Copilot.

Les politiques actuellement actives continueront à fonctionner exactement de la même manière, mais pourront traiter davantage de contenu chaque jour.

Le déploiement de la Public Preview est prévu pour septembre 2026 et la disponibilité générale en octobre 2026