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

Voici un résumé des changements et fonctionnalités apportés à Microsoft Defender for Endpoint introduits dans le mois.

• (Preview) Mises à jour de la protection à l'exécution des agents IA (AI agent runtime protection). Cette protection bénéficie des améliorations suivantes :
  • Les interfaces d'événements des agents prises en charge par les éditeurs fonctionnent désormais avec les canaux de mise à jour standard (plateforme et moteur) : aucune configuration du canal Beta n'est requise. L'inspection native des événements d'agent prend désormais en charge Codex CLI et l'application GitHub Copilot. 
  • L'inspection réseau est désormais prise en charge pour les agents qui n'exposent pas d'interfaces d'événements prises en charge par les éditeurs, notamment OpenClaw et les agents Claw similaires basés sur Node.js.
• (Disponibilité Générale) L'outil de déploiement Defender pour Linux (Defender Deployment Tool for Linux), disponible à partir de la version 101.26042.0011 de Defender for Endpoint sur Linux. Il simplifie le déploiement en regroupant l'installation, l'onboarding, les mises à niveau et la désinstallation dans un flux de travail unique :
  • L'outil automatise la validation des prérequis, prend en charge les chemins d'installation personnalisés, permet de déployer des versions spécifiques de Defender depuis les canaux de mise à jour de votre choix et fonctionne dans les environnements utilisant des référentiels locaux.
  • Il apporte également une visibilité complète sur l'avancement du déploiement grâce à l'intégration à la Device Timeline (statut étape par étape de l'installation, de la mise à niveau et de l'onboarding), à des requêtes de Advanced Hunting pour le suivi du déploiement à l'échelle du parc, et à un rapport d'erreurs détaillé (étape du déploiement, statut, code de sortie et motif d'échec) facilitant le dépannage.
• Dans la version du client Defender for Endpoint pour Windows (Platform 4.18.26070.9 / Engine 1.1.26070.7), on retrouve l'amélioration des performances et des corrections de bugs. Cette version s'accompagne de la version de renseignement de sécurité 1.457.11.0.
• Dans la version du client Defender for Endpoint pour macOS (101.26062.0009), on retrouve :
  • Des corrections de bugs et des améliorations de performances.
  • L'extension des diagnostics réseau via la commande mdatp health --details network_configuration.
• Dans la version du client Defender for Endpoint pour Linux (101.26052.0012), on retrouve l'amélioration des performances et des corrections de bugs.
• Dans la version du client Defender for Endpoint pour Android (1.0.9107.0101, publiée le 21 juillet 2026), on retrouve l'amélioration des performances et des corrections de bugs.
• Dans la version du client Defender for Endpoint pour iOS (1.1.79080103, publiée le 20 juillet 2026), on retrouve l'amélioration des performances et des corrections de bugs.

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

Microsoft vient d’annoncer la mise à disposition d’un nouvel ensemble de fonctionnalités pour Microsoft Intune.

Les fonctionnalités suivantes sont ajoutées :

Enregistrement des périphériques

• [tvOS / visionOS] Masquage des écrans de l'Assistant de configuration lors de l'inscription ADE. Intune prend désormais en charge le masquage ou l'affichage de nouveaux écrans de l'Assistant de configuration (Setup Assistant) pendant l'inscription automatisée des appareils (ADE) pour tvOS et visionOS. Lors de la configuration d'un profil d'inscription, vous pouvez choisir quels écrans (Apple ID, Diagnostics Data, Location Services, etc.) apparaissent durant la configuration. Par défaut, ces écrans sont affichés.

• [Android Enterprise] Permission RBAC dédiée pour l'inscription zero-touch. Intune fournit désormais une permission RBAC dédiée pour l'accès au portail d'inscription zero-touch de Google. Auparavant, l'iframe zero-touch dans le centre d'administration Intune nécessitait la permission « Update app sync », qui accordait également des droits de gestion de la synchronisation des applications Managed Google Play. Avec la permission dédiée, vous pouvez accorder l'accès au portail zero-touch indépendamment des permissions de gestion des applications.

Configuration des périphériques

• [Android Enterprise] Gestion des mises à jour de firmware via Samsung Knox E-FOTA. Microsoft Intune s'intègre désormais à Samsung Knox E-FOTA (Firmware Over-The-Air), vous permettant de gérer les mises à jour de firmware des appareils Samsung détenus par l'entreprise directement depuis le centre d'administration Intune. Vous pouvez contrôler la version de firmware reçue par chaque appareil, déployer les mises à jour sans interaction de l'utilisateur, et planifier les téléchargements et installations pour réduire les temps d'arrêt. S'applique aux appareils Android Enterprise corporate-owned dédiés (COSU), entièrement gérés (COBO) et avec profil professionnel (COPE). Pour en savoir plus, consultez Samsung Knox E-FOTA integration with Microsoft Intune.

• [Windows] Nouveaux paramètres dans le catalogue de paramètres Windows. Intune inclut désormais de nouveaux paramètres dans le catalogue de paramètres (settings catalog) pour les appareils Windows. Vous pouvez configurer des options relatives au comportement de la caméra, aux contrôles Keyboard Filter (pour les appareils Windows Insider) et à Windows Subsystem for Linux (WSL). Rendez-vous dans Appareils > Gérer les appareils > Configuration > Créer > Nouvelle stratégie > Windows 10 et ultérieur > Catalogue de paramètres.

• [Windows] Nouveaux paramètres Microsoft Edge dans le catalogue de paramètres. Les modèles d'administration Microsoft Edge ont été mis à jour vers Microsoft Edge 149 (version 149.0.4022.21), ajoutant les derniers paramètres de stratégie Edge 148 et 149 au catalogue de paramètres Windows. Parmi les nouveaux paramètres :

  • gestion des polices locales (LocalFontsAllowedForUrls / BlockedForUrls / DefaultLocalFontsSetting),

  • pop-ups d'authentification M365 dans les profils professionnels,

  • inscription MAM avec stratégie DLP Purview,

  • contrôle du Browsing with Copilot (listes d'autorisation/blocage, disponibilité, suggestions dans la barre d'adresse),

  • configuration de la page Copilot new tab, outils de développement (allow/block lists),

  • et divers réglages de performance (CpuPerformanceTierOverride, WebSocket, SharedWorkers, etc.).
    Pour la liste complète, consultez la référence des stratégies Microsoft Edge.

• [Windows] Nouveaux paramètres Windows App (Azure Virtual Desktop) dans le catalogue de paramètres, notamment : désactivation des mises à jour automatiques de Windows App, déconnexion automatique après une période d'inactivité, saut de la First Run Experience (FRE), Admin Release Ring Policy, et création automatique de raccourcis Windows App sur le bureau. Pour en savoir plus, consultez Configure updates for Windows App.

• [Windows] Nouvelle option pour le paramètre « Remove Default Microsoft Store packages ». Ce paramètre de la zone ApplicationManagement dispose d'un nouveau sous-paramètre, « Specify additional package family names to remove », qui permet de fournir une liste personnalisée de package family names (PFN) à supprimer, en plus de l'ensemble par défaut des packages Microsoft Store. Voir le CSP ApplicationManagement.

• [Windows] Nouveau paramètre pour désactiver l'application Get Started. Le nouveau paramètre « Disable Get Started » empêche la mise à disposition de l'application Windows Get Started aux utilisateurs.

• [Windows] Nouveaux paramètres OneDrive dans le catalogue de paramètres, incluant :

  • nom personnalisé du dossier OneDrive,

  • authentification OpenID Connect (OIDC) pour la synchronisation depuis un SharePoint Server on-premises (et URI d'ID d'application Entra associé),

  • blocage du mode hors connexion sur OneDrive web (y compris pour les bibliothèques et dossiers partagés par d'autres organisations),

  • suppression définitive (hard-delete) du contenu d'un raccourci de dossier lors de son démontage ou en cas de perte des autorisations.

• [Windows] Mise à jour des modèles d'administration Visual Studio vers la version 1.0.184.40051, ajoutant le nouveau paramètre « Disable Model Context Protocol (MCP) » (DisableMCP) au catalogue de paramètres. Voir la documentation des modèles d'administration Visual Studio.

Gestion des périphériques

• [Windows] Collecte des données du registre Windows via le catalogue de propriétés. Intune permet désormais de collecter des données du registre Windows via le properties catalog. Lors de la création d'une stratégie d'inventaire des appareils, vous pouvez définir des clés et valeurs de registre spécifiques à collecter depuis les appareils Windows inscrits; une valeur unique, toutes les valeurs directement sous une clé, ou la même valeur à travers les sous-clés sous HKEY_LOCAL_MACHINE. Cela offre une meilleure visibilité sur l'état des appareils et des requêtes avancées, sans scripts personnalisés. Voir Use the Intune properties catalog to get device hardware properties.

• [Windows] Synchronisation à la demande améliorée pour les appareils Windows. Intune prend désormais en charge une synchronisation à la demande plus complète. Lorsque vous sélectionnez l'action Sync dans le centre d'administration, Intune lance une synchronisation complète des principaux workloads (stratégies de configuration, applications et scripts), afin que les appareils reflètent plus rapidement vos dernières modifications. Particulièrement utile lors du dépannage, de la réponse aux incidents et des déploiements prioritaires.

Sécurité des périphériques

• [macOS] Paramètres de conformité personnalisés pour macOS. Intune prend désormais en charge les paramètres de conformité personnalisés (custom compliance) pour macOS. En tant qu'administrateur, vous pouvez définir des vérifications de conformité à l'aide de scripts et de règles JSON, à l'instar de la prise en charge existante pour Windows et Linux. Cela permet d'évaluer la configuration des appareils, la posture de sécurité et d'autres attributs personnalisés non couverts par les paramètres intégrés. Les résultats apparaissent aux côtés des rapports de conformité standard. Voir Custom compliance settings in Microsoft Intune.

• [Windows] Configuration contrôlée (Controlled Configuration) pour les paramètres antivirus Microsoft Defender (préversion). En préversion, Intune prend désormais en charge la Controlled Configuration pour les paramètres antivirus Microsoft Defender. Lorsqu'elle est activée, les paramètres antivirus Defender livrés par Intune ou par la gestion des paramètres de sécurité Microsoft Defender for Endpoint deviennent prioritaires et remplacent les configurations issues d'autres canaux (stratégie de groupe, Configuration Manager, scripts locaux). En complément de la Tamper Protection, cette capacité verrouille les paramètres sur les valeurs que vous définissez, pour des états d'appareils cohérents et prévisibles. Voir Controlled configuration for Microsoft Defender settings.

Gestion des applications (App management)

• [Windows] Prise en charge régionale pour les applications Microsoft Store. Intune prend désormais en charge la sélection régionale pour les applications Microsoft Store. Lors de l'ajout d'une application Store, vous pouvez choisir la région (market) dont le catalogue Store sera utilisé pour la recherche et le déploiement. Auparavant, Intune ne recherchait que dans le catalogue des États-Unis. Vous pouvez désormais déployer des applications publiées pour des marchés spécifiques (par exemple le Japon ou l'Espagne) qui ne sont pas disponibles dans le catalogue US.
• [iOS/iPadOS] Comptes gérés multiples (Multiple Managed Accounts) dans APP. La gestion des applications mobiles (MAM) de Microsoft Intune étend désormais la prise en charge des Multiple Managed Accounts à Microsoft Outlook sur iOS/iPadOS (v5.2626.0 ou ultérieur), permettant aux utilisateurs d'ajouter et de gérer plusieurs comptes gérés au sein d'une même application. Remarque : ce déploiement est progressif et peut ne pas être encore disponible dans votre tenant. Voir Multiple managed accounts for app protection policies.

Plus d'informations sur : What's new in Microsoft Intune | Microsoft Learn

Microsoft a introduit un ensemble de nouveautés dans Windows 365. Comme pour les autres services, je vous propose un résumé des changements et fonctionnalités que Microsoft a pu introduire dans le mois.

Provisionnement de périphériques

• La préparation des appareils Autopilot (Autopilot Device Preparation) pour les Cloud PC Citrix est désormais disponible. Windows Autopilot Device Preparation (DPP) est maintenant pris en charge pour les Cloud PC avec intégration Citrix. Cela aligne l'expérience de provisionnement des Cloud PC Citrix sur les autres scénarios de déploiement Windows 365 pris en charge et garantit que les applications et scripts requis sont installés avant que les utilisateurs n'accèdent à leurs Cloud PC. Les administrateurs peuvent désormais inclure des stratégies de préparation des appareils pour les Cloud PC Citrix dans leur workflow de provisionnement.

• Renforcement de la stratégie d'exécution PowerShell lors du provisionnement des Cloud PC. Windows 365 définit désormais la stratégie d'exécution PowerShell sur RemoteSigned au niveau de la portée LocalMachine pendant le provisionnement des Cloud PC. Ce changement améliore la sécurité en exigeant que les scripts téléchargés soient signés numériquement, tout en permettant l'exécution sans signature des scripts créés localement et des scripts Custom Script Extension (CSE). Ce paramètre s'applique à tous les produits Cloud PC. Si votre organisation définit la stratégie d'exécution PowerShell sur AllSigned via Intune ou une stratégie de groupe (Group Policy), le provisionnement et d'autres opérations basées sur CSE peuvent échouer. Pour en savoir plus, consultez Automated provisioning steps et Known issues.

• Modèles de nommage des appareils plus flexibles pour Windows 365 Flex en mode partagé. Les administrateurs peuvent désormais créer des modèles de nommage plus flexibles pour les Cloud PC Windows 365 Flex en mode partagé (shared mode). Les noms d'appareils peuvent comporter de 5 à 15 caractères et inclure un préfixe pouvant aller jusqu'à 10 caractères, avec prise en charge des tirets et un suffixe alphanumérique aléatoire obligatoire d'au moins 5 caractères. Cette mise à jour aligne les capacités de nommage entre Windows 365 Enterprise et Windows 365 Flex, aidant les organisations à appliquer des conventions de nommage conformes à leurs besoins métier et opérationnels.

Gestion des périphériques

• Le déprovisionnement en masse des Cloud PC en période de grâce (grace period) est désormais disponible en Public Preview pour Windows 365 Enterprise et Windows 365 Frontline Dedicated. Les administrateurs peuvent déprovisionner plusieurs Cloud PC à la fois depuis l'expérience d'administration Windows 365, au lieu d'attendre l'expiration de la période de grâce de sept jours ou de mettre fin à cette période Cloud PC par Cloud PC. Cette mise à jour simplifie la gestion du cycle de vie des Cloud PC et aide les administrateurs à supprimer rapidement les Cloud PC devenus inutiles.

• Cloud PC Settings est désormais disponible en disponibilité générale (GA) dans Microsoft Intune. Les administrateurs peuvent configurer quatre types d'objets différents : Cloud PC configurations, Windows App settings, Remote connection experience et User settings. Cela offre une approche centralisée pour la gestion des paramètres et stratégies des Cloud PC.

• Ajout de Cloud Apps à partir d'un chemin de fichier (Public Preview). Les administrateurs Windows 365 peuvent désormais ajouter manuellement des Cloud Apps en spécifiant un chemin de fichier. Cette capacité élargit l'ensemble des applications que vous pouvez diffuser via Windows 365 Cloud Apps sur les Cloud PC partagés Windows 365 Flex, y compris les applications non détectées via le menu Démarrer (Start Menu discovery). Cette fonctionnalité permet aux administrateurs de dupliquer des applications, de définir des propriétés d'application personnalisées et de configurer des paramètres de ligne de commande. Pour en savoir plus, consultez Windows 365 Cloud Apps.

• Page des stratégies de provisionnement mise à jour dans Microsoft Intune. Dans le centre d'administration Microsoft Intune, en accédant à Provision Cloud PCs > Provisioning policies puis en sélectionnant une stratégie, vous constaterez une nouvelle mise en page à plusieurs onglets : Overview, Properties, Devices et Action Status. Les administrateurs peuvent désormais visualiser les Cloud PC depuis la stratégie, initier des actions en masse sur les appareils et consulter le statut des actions. De plus, les stratégies de provisionnement Windows 365 Flex partagées de type d'expérience Cloud App disposent d'un nouvel onglet Cloud Apps. Pour en savoir plus, consultez View provisioning policies.

• Réordonnancement des stratégies de paramètres (Rerank settings policies) en Public Preview. Windows 365 prend désormais en charge le réordonnancement des stratégies de paramètres. Les administrateurs peuvent prioriser les stratégies de paramètres afin de déterminer laquelle prévaut en cas de conflit de configuration. Les stratégies peuvent être réordonnées en modifiant leur rang, à l'aide des contrôles de glisser-déposer (drag-and-drop), ou en déplaçant les stratégies vers le haut ou le bas de la liste. Pour en savoir plus, consultez Settings overview.

• Régions alternatives pour la continuité d'activité et la reprise après sinistre (BCDR) en Public Preview. Windows 365 prend désormais en charge des régions Azure alternatives pour les scénarios de Business Continuity and Disaster Recovery (BCDR), aidant les organisations à répondre aux exigences de reprise après sinistre et de souveraineté des données dans les zones géographiques où une seule région prise en charge par Windows 365 est disponible. Les administrateurs peuvent sélectionner des régions alternatives pour les configurations Cross-region Disaster Recovery (CRDR) et Disaster Recovery Plus (DR+), notamment Australia Southeast et South India. Les régions alternatives sont disponibles uniquement pour les scénarios de reprise après sinistre et ne sont pas prises en charge pour le provisionnement des Cloud PC.

Sécurité et chiffrement

• Chiffrement géré par le client (Customer-managed encryption) pour Windows 365 Reserve en Public Preview. Windows 365 Reserve prend désormais en charge Microsoft Purview Customer Key (CMK), permettant aux administrateurs de chiffrer les disques des Cloud PC Reserve avec des clés gérées par le client, stockées dans Azure Key Vault. Cette capacité aide les organisations à répondre aux exigences de sécurité et de conformité en offrant un meilleur contrôle sur la gestion des clés de chiffrement, y compris la rotation, la révocation et l'audit des clés. La prise en charge de Customer Key dans Reserve étend l'expérience CMK déjà disponible pour les Cloud PC Windows 365. 

Expérience utilisateur

• Prise en charge des identités externes sur Android en disponibilité générale (GA). La prise en charge des identités externes (External identity) est désormais en disponibilité générale pour la Windows App sur Android. Pour plus d'informations sur les versions clientes et les capacités, consultez Compare Windows App features across platforms and devices.

• Prise en charge en préversion de l'authentification sans mot de passe en session (in-session passwordless) sur Android. L'authentification sans mot de passe en session est disponible en préversion pour la Windows App sur Android. Elle permet aux utilisateurs de compléter les défis WebAuthn en session à l'aide de passkeys stockées sur l'appareil Android via un fournisseur de passkey logiciel comme Microsoft Authenticator. L'utilisation de passkeys provenant d'autres appareils (clé de sécurité physique ou via QR code) n'est pas prise en charge.

• RDP Multipath avec chemins de transport TCP redondants en disponibilité générale (GA). Le RDP Multipath avec chemins de transport TCP redondants est désormais en disponibilité générale pour les Cloud PC Windows 365. Cette amélioration étend les bénéfices de résilience du RDP Multipath aux connexions basées sur TCP, permettant aux Cloud PC Windows 365 de maintenir plusieurs chemins de transport TCP en veille (standby) et de basculer automatiquement entre eux lorsqu'une dégradation réseau est détectée. Les principaux bénéfices sont les suivants :

  • Amélioration de la résilience des sessions dans les environnements réseau restrictifs
  • Basculement automatique (failover) entre les chemins de transport disponibles
  • Réduction des interruptions et déconnexions de session
  • Aucune configuration supplémentaire requise lorsque les prérequis sont remplis

Plus d'informations sur : What's new in Windows 365 Enterprise | Microsoft Learn

Microsoft a introduit un ensemble de nouveautés dans Microsoft Sentinel, sa solution SIEM (Security Event Information Management) Cloud. Comme pour les autres services, je vous propose un résumé des changements et fonctionnalités que Microsoft a pu introduire dans le mois.

• Prise en charge des règles de détection personnalisées dans Microsoft Sentinel Repositories (Preview) : vous pouvez désormais gérer les règles de détection personnalisées as code (sous forme de code) dans votre dépôt GitHub ou Azure DevOps grâce à l'extension Microsoft Security BICEP. Vous pouvez synchroniser les règles de détection personnalisées vers Microsoft Sentinel via la fonctionnalité Repositories, ou les déployer directement à l'aide de l'interface en ligne de commande BICEP (BICEP CLI). Pour en savoir plus, consultez

Plus d'informations sur : What's new in Microsoft Sentinel | Microsoft Learn

Le service Microsoft Defender XDR est une solution intégrée qui fournit des éléments provenant de tous les outils de sécurité dont Microsoft Defender for Endpoint, Microsoft Defender for Office 365, Microsoft Defender for Identity, Microsoft Defender for Cloud Apps. Ces solutions regroupent des mécanismes et concepts communs comme la détection et l’investigation et la réponse automatique. Cette console regroupera les alertes et les incidents agrégés des différents services.

• (Preview) Risque de posture des agents d'IA dans Microsoft Defender : Microsoft Defender évalue désormais le risque de posture des agents d'IA, y compris les agents d'entreprise et les agents locaux découverts sur les terminaux. Les niveaux de risque reposent sur des indicateurs de risque actifs, tels que la configuration, les accès, l'activité à l'exécution (runtime), le contexte du terminal et de l'utilisateur, ainsi que les alertes actives. Les équipes de sécurité peuvent s'appuyer sur ce risque de posture et sur les recommandations associées pour prioriser les agents à risque et améliorer la posture de sécurité des agents. 

• (Disponibilité générale) La page Domain investigation vous permet d'investiguer un domaine Active Directory. Elle présente la sécurité du domaine Active Directory, notamment les propriétés du domaine, l'état de santé du déploiement, la synthèse des identités, la répartition des comptes de service, les entités sensibles, les recommandations actives, les stratégies de groupe (group policies) et les relations d'approbation (trust relationships). 

• (Preview) Détection des menaces pour les agents Microsoft Agent 365 : Microsoft Defender analyse les signaux à l'exécution (runtime) issus des interactions des agents, de l'utilisation des outils et des schémas d'exécution afin de faire remonter des alertes dans Microsoft Defender XDR. La détection s'appuie sur les données d'observabilité provenant de Microsoft Copilot Studio, Microsoft Foundry, Microsoft 365 Copilot Agent Builder et des agents intégrés via le SDK Microsoft Agent 365. Les analystes peuvent investiguer les alertes à travers les incidents et l'advanced hunting. 

• (Disponibilité générale) Protection en temps réel pour les serveurs d'outillage Microsoft Agent 365 : Microsoft Defender évalue les invocations d'outils et les réponses au regard des stratégies de sécurité et peut autoriser ou bloquer les interactions avec les outils Work IQ MCP et les outils MCP clients intégrés (onboarded) à Agent 365. 

Plus d’informations sur : What's new in Microsoft Defender XDR | Microsoft Learn

Microsoft renforce la sécurité de Self-Service Password Reset (SSPR) dans Microsoft Entra ID. À partir du 9 novembre 2026, les utilisateurs devront disposer de méthodes d’authentification explicitement enregistrées pour réinitialiser leur mot de passe.

Aujourd'hui, SSPR peut s'appuyer sur certaines informations présentes dans l'annuaire, comme :

• Numéro de téléphone mobile
• Numéro de téléphone professionnel
• Adresse e-mail secondaire

Même si ces informations n'ont jamais été enregistrées comme méthodes d'authentification.

À compter du 7 septembre 2026, seules les méthodes enregistrées dans Authentication Methods seront acceptées pour la vérification d'identité lors d'une réinitialisation de mot de passe.

Vous êtes concerné si SSPR est activé dans votre tenant Microsoft Entra ID.

Après cette date :

• Les attributs présents dans l'annuaire ne seront plus suffisants pour valider l'identité d'un utilisateur.
• Les utilisateurs ne disposant d'aucune méthode enregistrée ne pourront plus réinitialiser leur mot de passe via SSPR.
• Ils devront enregistrer une méthode d'authentification ou contacter le support. 

Microsoft indique que 86 % des vérifications SSPR utilisent déjà des méthodes enregistrées et ne devraient donc pas être impactées.

Avant le 9 novembre 2026, Microsoft recommande de :

1. Vérifier la couverture d'enregistrement des méthodes d'authentification via :
   • Entra Admin Center
   • Authentication Methods
   • User Registration Details
2. S'assurer que tous les utilisateurs, y compris les administrateurs, disposent d'au moins une méthode conforme à votre politique SSPR.
3. Activer la campagne de sensibilisation SSPR afin d'inciter automatiquement les utilisateurs à enregistrer leurs méthodes.
4. Prévoir un processus de support pour les utilisateurs n'ayant pas encore effectué leur enregistrement.

Cette évolution s'inscrit dans la stratégie Secure Future Initiative (SFI) de Microsoft et vise à renforcer la fiabilité des vérifications d'identité lors des réinitialisations de mot de passe. Les organisations utilisant SSPR doivent dès maintenant vérifier le taux d'enregistrement des méthodes d'authentification afin d'éviter que certains utilisateurs ne se retrouvent bloqués à partir du 9 novembre 2026.

Microsoft a annoncé une mise à jour de sa politique de support macOS dans Intune. Suite à la future sortie de macOS 27 Golden Gate, Intune, Company Portal et l'agent Intune MDM nécessiteront macOS 15 Sequoia ou une version ultérieure pour les nouveaux appareils à enrôler.

Ce qui change

Une fois cette évolution déployée :

• Les nouveaux appareils sous macOS 14 Sonoma ou inférieur ne pourront plus être inscrits dans Intune.
• Les appareils déjà enrôlés continueront à être gérés normalement.
• Cette évolution est liée à l'application Company Portal, désormais commune à iOS et macOS.

Aucun impact n'est attendu sur les Mac déjà gérés par Intune.

Impact pour votre organisation

Vous êtes concerné si :

• Vous gérez des appareils macOS avec Intune.
• Vous disposez encore de postes sous macOS 14 Sonoma ou une version antérieure.
• Vous prévoyez l'acquisition ou le renouvellement de Mac dans les prochains mois.

Microsoft précise également que les appareils enrôlés sans affinité utilisateur (ADE sans User Affinity ou Direct Enrollment) disposent d'un cycle de support spécifique.

Actions recommandées

Pour anticiper ce changement :

1. Accédez à Devices > All devices dans Intune.
2. Filtrez sur la plateforme macOS.
3. Identifiez les appareils exécutant macOS 14.x ou une version antérieure.
4. Planifiez leur mise à niveau vers macOS 15 Sequoia ou une version plus récente.

Cette annonce s'inscrit dans la politique habituelle de Microsoft visant à aligner Intune sur les versions récentes de macOS. Même si les appareils déjà gérés restent supportés, les organisations doivent dès maintenant identifier les postes sous macOS 14 ou inférieur afin d'éviter tout problème lors des futurs enrôlements.

Microsoft a introduit un ensemble de nouveautés dans Microsoft Entra (incluant Entra ID, Permissions Management, etc.) en juin 2026.

Microsoft apporte les nouveautés suivantes :

Général

• Disponibilité de Microsoft Entra Backup and Recovery. Il s’agit d’une solution intégrée qui aide à restaurer votre locataire après des modifications accidentelles ou des mises à jour malveillantes. Activée par défaut, elle sauvegarde automatiquement les objets d’annuaire critiques — utilisateurs, groupes, applications, principaux de service, identités managées, stratégies d’accès conditionnel, emplacements nommés, identités d’agent, ainsi que les stratégies d’authentification et d’autorisation — afin que les administrateurs puissent les restaurer rapidement dans un état antérieur connu comme sain. En préversion, une sauvegarde quotidienne des objets d’annuaire pris en charge est réalisée ; avec des licences Microsoft Entra ID P1 ou P2, une sauvegarde est effectuée chaque jour et conservée pendant 7 jours. Les administrateurs peuvent consulter les instantanés disponibles, générer des rapports de différences pour comprendre ce qui a changé, et exécuter des travaux de récupération pour restaurer les objets dans un état antérieur.

Microsoft Entra ID

• Disponibilité Générale de l’amélioration de la fiabilité de la rotation des clés Kerberos Microsoft Entra, en particulier pour les environnements utilisant des flux de renvoi (referral) d’approbation entrante. Auparavant, des échecs d’authentification pouvaient survenir pendant la rotation des clés Kerberos si les tickets de renvoi étaient chiffrés avec une clé secondaire. La logique de validation tente désormais le déchiffrement avec la clé Kerberos primaire et la clé secondaire, améliorant la résilience lors des opérations de roulement de clés et réduisant les interruptions d’authentification.
• Disponibilité Générale de la détection du jailbreak/root dans l’application Microsoft Authenticator. Pour les comptes professionnels ou scolaires, les utilisateurs disposant d’appareils rootés ou jailbreakés seront bloqués pour l’ajout ou l’utilisation de ces comptes dans Authenticator ; ils devront passer sur un appareil conforme pour continuer. Cette protection est active par défaut et ne nécessite aucune configuration ni contrôle administrateur.
• Public Preview de l’extension des protections d’Accès Conditionnel aux comptes utilisateur des agents. L’Accès Conditionnel offre des contrôles plus larges pour sécuriser les agents IA disposant d’un compte utilisateur :
  • Ciblage précis des comptes d’agents (inclusion ou exclusion individuelle, ou regroupement dynamique via des attributs de sécurité personnalisés),
    
  • Application de stratégies selon le risque de l’agent (Agent Risk),
    
  • Exigence d’appareils conformes pour les agents s’exécutant sur des points de terminaison gérés (y compris Windows 365 for Agents), 
    
  • Application de conditions de plateforme d’appareil, de filtres d’appareils et de réseau conforme.
    Ces capacités étendent les protections Zero Trust aux comptes des agents tout en s’appuyant sur l’expérience familière des stratégies d’Accès Conditionnel.
    

• Disponibilité Générale des API SCIM 2.0 pour Microsoft Entra ID dans le cloud US Gov. Les clients, développeurs et partenaires disposent désormais d’une option standardisée pour gérer les utilisateurs et les groupes dans Microsoft Entra à l’aide de la spécification System for Cross-domain Identity Management (SCIM) 2.0.
• Public Preview d’un nouveau rôle intégré Entra « SOC Identity Responder » pour la réponse aux incidents d’identité depuis Microsoft Defender. À compter du 8 juin, ce rôle dédié permet aux analystes SOC d’exécuter des actions de confinement d’identité — désactivation d’utilisateurs, révocation de sessions, réinitialisation forcée des mots de passe — selon un modèle de moindre privilège, sans disposer de privilèges d’administration d’annuaire étendus. Il prend en charge des modèles d’attribution flexibles (groupes assignables à un rôle, propriété déléguée) et une intégration optionnelle avec Privileged Identity Management (PIM) pour l’activation juste-à-temps. Ces actions restent appliquées et auditées par Microsoft Entra, en cohérence avec les contrôles RBAC et de conformité existants.

• Public Preview de la prévention des modifications non autorisées des groupes AD grâce à l’application (enforcement) des groupes AD. Pour les clients utilisant le provisionnement de groupes vers AD, cette capacité garantit que les modifications des groupes AD restent cohérentes avec celles gérées dans Microsoft Entra. Vous pouvez désigner des groupes AD spécifiques afin que leurs modifications ne puissent être réalisées que via le service de provisionnement Entra ; les changements effectués en dehors d’Entra sont bloqués, ce qui prévient les dérives et maintient l’alignement entre Entra ID et AD.

Microsoft Entra Identity Governance

• Disponibilité Générale de l’attribution directe d’utilisateurs externes à des packages d’accès. Les administrateurs de la gestion des droits d’utilisation (Entitlement Management) peuvent désormais attribuer directement des utilisateurs externes ne figurant pas dans l’annuaire à un package d’accès à l’aide de leur adresse e-mail. Ces utilisateurs sont invités dans le locataire en tant qu’utilisateurs invités (Guest) et sont gouvernés, dès lors qu’Entra ID Governance est configuré.

Microsoft Entra External ID

• Disponibilité Générale de la fédération SAML sans domaine (domainless) avec un fournisseur d’identité SAML pour les locataires workforce. Cette fédération permet aux utilisateurs externes de s’authentifier dans vos applications ou ressources workforce à l’aide des identifiants gérés par leur fournisseur d’identité, quel que soit leur domaine de messagerie. Elle supprime le besoin de correspondance de domaine entre l’e-mail de l’utilisateur et les domaines de fournisseur d’identité préconfigurés lors de la connexion ou de l’acceptation d’une invitation.

Microsoft Entra Global Secure Access (Internet Access/Private Access)

• Disponibilité Générale de la prise en charge du BYOD (Bring Your Own Device) pour les clients Windows via l’inscription Entra (Entra-registered). Les organisations peuvent permettre aux utilisateurs et partenaires d’accéder aux ressources d’entreprise depuis leurs propres appareils. Les administrateurs peuvent attribuer le profil de trafic Private Application aux utilisateurs disposant de comptes internes, y compris les invités internes, ce qui supprime l’exigence précédente d’avoir des appareils Windows joints au domaine.

Modifications de service

• Amélioration de l’expérience de restauration des clés d’accès (passkeys) liées à l’appareil de l’application Authenticator sur iOS. À partir d’août 2026, les utilisateurs bénéficieront d’une expérience de restauration améliorée pour les passkeys Authenticator liées à l’appareil sur iOS, sans action administrateur ou utilisateur requise. Les utilisateurs ayant déjà activé la sauvegarde iCloud et le Trousseau iCloud et disposant de passkeys liées à l’appareil sur leur ancien appareil profiteront automatiquement de cette amélioration ; ceux restaurant l’application sur un nouvel appareil iOS bénéficieront d’un flux de restauration mis à jour. Cette mise à jour concerne uniquement iOS, la prise en charge Android suivra..

Plus d’informations sur : What’s new? Release notes - Microsoft Entra | Microsoft Learn et What’s new for Microsoft Entra Verified ID

Je vous propose un petit aperçu des nouveautés de ce mois autour de la gouvernance, de la conformité et de la protection de données proposées via Microsoft Purview (MIP, DLP, etc.).

On retrouve notamment :

Prévention de fuite de données (DLP)

• Preview de la protection des données sensibles dans le texte et les invites grâce à l'intégration avec Microsoft Entra Global Secure Access (GSA). Cette intégration permet aux organisations d'intercepter et d'inspecter le texte et les interactions d'IA au niveau de la couche réseau, d'appliquer des actions restrictives selon les stratégies DLP, et de détecter les activités utilisateur à risque via la gestion des risques internes. Elle aide à empêcher le partage de données sensibles avec des applications cloud non approuvées via les navigateurs, applications, API et compléments — y compris les plateformes d'IA générative, les réseaux sociaux et les plateformes collaboratives.

Gestion des risques internes (Insider Risk Management)

• (Preview) Une expérience d'alerte unifiée regroupe les tableaux de bord de l'agent de triage et des alertes standard en une seule page de liste d'alertes. Vous pouvez consulter et gérer à la fois les alertes classiques et celles triées par l'agent depuis un emplacement unique, avec la possibilité de prévisualiser les résumés de l'agent ainsi que les détails de l'alerte et de l'utilisateur directement sur la page.
• (Preview) Des détails de profil utilisateur enrichis dans l'expérience d'alerte unifiée ajoutent des signaux de profil supplémentaires issus de Microsoft Entra : emplacement du bureau, type d'employé, service et date du dernier jour travaillé.
• (Preview) Des capacités de notes étendues aux alertes et aux cas. Les analystes et enquêteurs peuvent désormais ajouter et consulter des notes à la fois sur les alertes et les cas. Des notes générées par le système sont automatiquement ajoutées lors d'un changement de statut d'alerte ou de cas, d'utilisateur assigné, de clôture ou d'escalade de cas.

 Plus d’informations sur : What's new in Microsoft Purview - Microsoft Purview | Microsoft Docs

Microsoft Defender for Identity étant un service Cloud, on retrouve des mises à jour de service continuelle. Comme pour les autres services, je vous propose un résumé des changements et fonctionnalités que Microsoft a pu introduire dans le mois.

• La migration des capteurs Defender for Identity de la version 2.x vers la version 3.x est désormais en disponibilité générale (GA). Pour plus d’informations, consultez migrer vers le capteur Defender for Identity v3.x.
• Vous pouvez désormais migrer les contrôleurs de domaine exécutant Windows Server 2025 du capteur v2.x vers le capteur v3.x. Pour plus d’informations, consultez migrer vers le capteur Defender for Identity v3.x.
• Lorsqu’un serveur est marqué « Not ready for migration » sur la page Sensors, vous pouvez désormais survoler le statut pour afficher une info-bulle qui liste les raisons précises pour lesquelles le serveur ne répond pas aux prérequis de migration. Pour plus d’informations, consultez résoudre le statut « Not ready for migration ».
• La page Password protection (Preview) inclut désormais les risques liés aux mots de passe des applications SaaS connectées via Microsoft Defender for Cloud Apps, en plus d’Active Directory, Microsoft Entra ID et Okta. Les applications SaaS prenant en charge la gestion de la posture de sécurité SaaS (SSPM), telles que Salesforce et ServiceNow, apparaissent sous les onglets Password Hygiene et Password Policies. Chaque application SaaS nécessite un connecteur d’application Defender for Cloud Apps. Pour plus d’informations, consultez investiguer la protection des mots de passe des identités.

• La page Domain investigation est désormais en disponibilité générale (GA). Elle permet d’investiguer un domaine Active Directory et présente la sécurité du domaine : propriétés du domaine, état du déploiement, récapitulatif des identités, répartition des comptes de service, entités sensibles, recommandations actives, stratégies de groupe et relations de confiance. Pour plus d’informations, consultez investiguer un domaine.

• Defender for Identity active désormais automatiquement l’audit RPC sur les contrôleurs de domaine lorsque vous effectuez la mise à niveau vers le capteur version 3.0.8 ou ultérieure. Il n’est plus nécessaire d’appliquer une balise manuellement pour activer l’audit RPC.

Plus d’informations sur: What's new in Microsoft Defender for Identity

Je vous propose un petit aperçu des nouveautés apportées en ce mois autour du service Microsoft Agent 365. Pour rappel, Agent 365 est la plateforme de gestion et de contrôle des agents de l’organisation.

On retrouve notamment :

Général

• Maintenir la visibilité et le contrôle devient de plus en plus complexe à mesure que les organisations déploient des agents sur plusieurs tenants Microsoft 365, via un ensemble hétérogène de plateformes d’agents et au sein d’équipes ou de périmètres différents. Les nouveautés de juillet 2026 apportent les signaux de risque des partenaires dans une vue de sécurité unifiée, améliorent le suivi des dépenses d’IA à l’usage, livrent des insights d’adoption à l’échelle de l’organisation, étendent la découverte et la gouvernance des agents aux plateformes de l’écosystème, et permettent une gestion centralisée multi-tenants.
• La gestion des coûts (Cost Management) dans le centre d’administration Microsoft 365 offre aux administrateurs un moyen centralisé de suivre et de contrôler la consommation de Copilot Credits pour les services agentiques facturés à l’usage. Cette version se concentre sur les dépenses Cowork et Work IQ. Elle fiabilise les alertes de dépenses, rend l’affectation des stratégies plus cohérente et clarifie la vue sur la capacité prépayée :
  • lorsqu’un utilisateur relève de plusieurs stratégies de dépenses pour un même service, la stratégie applicable est désormais choisie selon des critères clairs : la limite par utilisateur la plus élevée, puis la limite globale la plus élevée, puis la stratégie la plus récemment créée — la stratégie retenue s’applique intégralement, sans combinaison de paramètres ;
  • si une tâche dépasse la limite individuelle d’un utilisateur alors qu’elle est déjà en cours d’exécution, Microsoft peut la laisser se terminer sans imputer le dépassement au pool partagé ni le facturer, afin de préserver les crédits du reste du groupe ;
  • Cost Management distingue désormais les crédits déjà consommés ou alloués via d’autres centres d’administration (dont la capacité affectée aux environnements ou agents Power Platform), pour refléter plus fidèlement la capacité prépayée réellement disponible.

Observation & Découverte

• (Disponibilité générale) Le tableau de bord Agent 365 (Agent 365 Dashboard) offre aux décideurs une vue centralisée de l’adoption, de l’engagement et de l’impact métier des agents dans toute l’organisation. En consolidant la télémétrie d’Agent 365 dans une expérience de reporting unique, il permet de comprendre comment les agents sont utilisés et d’identifier où l’adoption accélère ou stagne. Grâce au reporting intégré et au filtrage organisationnel, les analystes évaluent l’usage par équipe, entité ou zone géographique, tandis que les responsables suivent des indicateurs clés (utilisateurs actifs, tendances de rétention, agents les plus performants, schémas d’engagement). Les capacités d’exploration interactive (drill-down) donnent une visibilité fine sur la performance de chaque agent.
• (Disponibilité générale) La synchronisation du registre (Registry sync) permet de découvrir et d’inventorier les agents existant au-delà des plateformes Microsoft. Les administrateurs IA connectent de façon sécurisée les plateformes d’agents partenaires prises en charge et synchronisent les agents et leurs métadonnées dans le registre Agent 365 selon une cadence quotidienne ou hebdomadaire, établissant ainsi un système de référence unique pour l’ensemble du parc d’agents. Les plateformes prises en charge à la disponibilité générale sont Amazon Bedrock, Google Cloud Gemini Enterprise Agent Platform, Anthropic Claude, Databricks Genie et Salesforce Agentforce ; Snowflake, Oracle OCI et UiPath suivront prochainement.

Gouvernance

• Registry sync ne se limite pas à la visibilité : lorsque les API de la plateforme sous-jacente le permettent, les administrateurs peuvent mener des actions de gouvernance au niveau de l’agent directement depuis Agent 365, y compris des actions de gestion du cycle de vie telles que la suppression des agents synchronisés. Les organisations gouvernent ainsi leurs agents depuis un plan de gestion commun, tout en continuant d’utiliser les environnements de développement et d’exécution les mieux adaptés à leurs besoins.
• (Public Preview) La gestion multi-tenants des agents (multi-tenant agent management) permet d’afficher et de gérer de façon centralisée les agents de plusieurs tenants connectés depuis Agent 365 dans le centre d’administration Microsoft 365. Depuis All tenants > Agents, les administrateurs consultent un inventaire consolidé, ajoutent des agents personnalisés, déploient des agents sur des tenants sélectionnés, comparent la disponibilité et les autorisations propres à chaque locataire, examinent le risque et l’activité des agents, et bloquent des agents ou modifient leur disponibilité. Le sélecteur de locataire (tenant switcher) permet d’entrer dans un locataire connecté via un accès délégué, sans maintenir de compte d’administrateur distinct. L’expérience s’appuie sur les relations d’administration inter-tenants existantes et sur les privilèges d’administration délégués granulaires (GDAP) : les partenaires les configurent dans le Partner Center, les entreprises via Microsoft Entra Tenant Governance.

Sécurisation & Protection

• Agent 365 étend la visibilité sur le risque des agents en prenant en charge des signaux de risque de partenaires dans le registre des agents (Agent Registry), à commencer par Cyera, Darktrace et Zenity. Jusqu’ici, les signaux affichés dans l’onglet Security des détails d’un agent provenaient de Microsoft Entra, Defender et Purview ; désormais, lorsqu’un administrateur l’active, Agent 365 peut aussi ingérer un signal de risque généré par un partenaire et le rattacher au bon agent via Microsoft Entra Agent ID, qui sert d’ancre d’identité.
  Pour les administrateurs, cela se traduit par : une vue consolidée — le nombre de signaux de risque réunit les signaux natifs Microsoft et les détections des solutions partenaires prises en charge ; une priorisation du risque en catégories Élevé, Moyen et Faible, chaque type de signal indiquant un nombre d’occurrences pour repérer les schémas récurrents à investiguer ; et un principe de consentement par conception (consent by design) — les intégrations partenaires sont optionnelles et aucune donnée partenaire ne circule tant qu’un administrateur n’a pas activé les signaux de risque partenaires sous Agents > Settings dans le centre d’administration Microsoft 365 (certains partenaires pouvant exiger une configuration dans leur propre produit). L’API partenaire Agent 365 qui véhicule ces signaux est ouverte aux éditeurs de sécurité de l’écosystème, et la liste des fournisseurs pris en charge devrait s’élargir.

Plus d’informations sur : What’s new in Agent 365 – July 2026 | Microsoft Community Hub

Microsoft a introduit un ensemble de nouveautés dans Microsoft Defender for IoT. Comme pour les autres services, je vous propose un résumé des changements et fonctionnalités que Microsoft a pu introduire dans le mois.

Réseaux OT

• La version 26.1.1 du capteur est désormais disponible. Cette version inclut des mises à jour de CVE ainsi que des corrections de bogues visant à améliorer la stabilité.

Plus d’informations sur : What's new in Microsoft Defender for IoT - Microsoft Defender for IoT | Microsoft Learn