Microsoft 365 et Entra ID : les échéances à traiter avant avril 2027

Chacun se traite par un réglage de configuration plutôt que par un projet de migration, mais pour chacun, il faut décider avant une date fixée. La première échéance est le 31 août 2026, sur EWS.

EWS : inversion du comportement de la liste d’autorisation en octobre

Exchange Web Services est l’interface par laquelle de nombreuses applications tierces lisent encore les boîtes aux lettres et les agendas : outils de signature, solutions de sauvegarde, connecteurs de salles de réunion, applications métier, systèmes de facturation, plateformes de recrutement. Microsoft a annoncé son retrait en 2018, fixé la date en 2023, et accéléré le calendrier après l’incident Midnight Blizzard de janvier 2024, qui impliquait EWS.

Le retrait est piloté par une propriété d’organisation, EWSEnabled, qui accepte trois valeurs : True, False et Null. Null est la valeur par défaut aujourd’hui, et elle autorise tout. Le 1er octobre 2026, Microsoft bascule les tenants restés sur Null vers False, ce qui coupe EWS pour toutes leurs applications.

À la même date, la signification de EWSEnabled = True associé à une liste d’autorisation vide change. Microsoft a précisé ce point en juin 2026, puis l’a reformulé en août 2026.

À partir d’octobre, EWSEnabled = True avec une liste d’autorisation vide bloque toutes les applications, au lieu de les autoriser toutes. Un tenant configuré avec True et une liste vide se retrouve donc dans la même situation qu’un tenant laissé sur Null : EWS coupé pour l’ensemble de ses applications.

Avant octobre, la logique est permissive : Null autorise tout et ignore la liste ; True avec une liste vide autorise tout ; True avec une liste remplie ne laisse passer que les applications listées ; False bloque tout. À partir d’octobre, la deuxième règle s’inverse.

La liste s’appelle EWSAllowedAppIDs. Elle se lit et s’écrit depuis Exchange Online PowerShell :

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs Set-OrganizationConfig -EwsAllowedAppIDs "11111111-2222-3333-4444-555555555555,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"

Trois points d’exploitation à connaître. L’écriture remplace intégralement la liste : pour ajouter un AppID, lisez la valeur courante, recomposez-la et réécrivez-la, sinon les entrées précédentes disparaissent. Une modification met jusqu’à 24 heures à prendre effet, le cache serveur ne se rafraîchissant qu’une fois par jour. Et le paramètre -RetrieveEwsOperationAccessPolicy est obligatoire à la lecture, sans quoi la liste n’est pas retournée.

La liste doit contenir aussi les applications Microsoft encore dépendantes d’EWS, comme Office ou Power Query pour Excel. Le rapport d’usage EWS du centre d’administration Microsoft 365 donne les AppID observés dans le tenant ; il ne les résout pas en noms, ce qui laisse un travail d’identification manuel pour les applications tierces.

Configurer la liste et passer EWSEnabled à True avant fin août exclut le tenant du basculement automatique du 1er octobre, et le protège des coupures temporaires de vérification que Microsoft se réserve d’effectuer d’ici là. Pour les tenants qui n’auront rien configuré, Microsoft préremplit la liste en septembre à partir de l’usage observé : cette liste automatique peut inclure des applications qui n’ont pas été validées par l’organisation, et elle demande donc une relecture.

Réactiver EWS après le blocage d’octobre reste possible jusqu’en avril 2027, avec une interruption de service entre les deux. Après le 1er avril 2027, aucune dérogation n’est prévue. Le chemin de sortie est Microsoft Graph, dont Microsoft publie l’état des écarts de parité restants.

Exchange Server et les scénarios hybrides

Exchange Server n’est pas touché. EWS reste en place sur les serveurs locaux. En hybride, les boîtes aux lettres restées sur site continuent d’utiliser EWS, celles qui sont dans le tenant doivent passer à Graph.

Le partage d’agendas entre tenants change de mécanisme

Conséquence directe du retrait d’EWS : le partage de disponibilités, des MailTips et des agendas avec une autre organisation Microsoft 365 repose aujourd’hui sur les Organization Relationships, les Availability Address Spaces et les Sharing Policies, trois mécanismes qui s’appuient sur EWS.

Ils sont remplacés par la Microsoft 365 Cross-Tenant Access Policy, qui s’appuie sur la Cross-Tenant Access Policy d’Entra et identifie l’organisation partenaire par son Tenant ID plutôt que par ses noms de domaine.

Deux caractéristiques déterminent la façon de planifier l’opération :

• La nouvelle stratégie est entrante. Chaque organisation contrôle ce que l’extérieur peut consulter chez elle, si bien qu’un partage bidirectionnel exige que les deux tenants créent des stratégies complémentaires.
• Les anciennes configurations restent prioritaires. Tant qu’une Organization Relationship est active, la stratégie Cross-Tenant ne s’applique pas. La validation impose donc de désactiver l’ancien avant de tester le nouveau, en coordination avec l’administrateur d’en face.

L’inventaire tient en trois commandes :

Get-OrganizationRelationship | Format-List Name, DomainNames, Enabled, FreeBusyAccessEnabled, MailTipsAccessEnabled Get-AvailabilityAddressSpace | Format-List ForestName, AccessMethod Get-SharingPolicy | Format-List Name, Enabled, Domains, Default

Ces configurations concernent en particulier les organisations qui partagent des agendas avec une filiale, une société sœur, un fiduciaire ou un partenaire de longue date. Le plus souvent, quelqu’un les a configurées une fois et personne n’y a retouché : elles ne figurent pas dans la documentation d’exploitation. Le déploiement de la fonctionnalité de remplacement est progressif : préparez la migration dès que la fonctionnalité atteint votre tenant, et avant l’échéance EWS.

SMS et appels vocaux : Entra ID bascule sur les passkeys

Le 1er septembre 2026, les passkeys deviennent l’expérience d’authentification par défaut dans Microsoft Entra ID. Les utilisateurs encore activés pour le SMS ou l’appel vocal — dans la stratégie de méthodes d’authentification comme dans les anciens réglages MFA par utilisateur — sont automatiquement placés dans un profil passkey, et la campagne d’enregistrement passe en état « Microsoft Managed ». À leur prochaine authentification forte, ils sont invités à enregistrer une passkey.

Cette invite reste reportable un nombre illimité de fois par défaut. Elle cesse de l’être le 1er février 2027 : à cette date, Microsoft retire la livraison SMS et voix qu’il fournit lui-même, et un utilisateur dont c’est la seule méthode disponible doit enregistrer une passkey avant de pouvoir se connecter. L’invite devient bloquante, et Microsoft indique qu’aucune dérogation n’est prévue, sur aucun tenant.

Deux dispositifs permettent de s’écarter du comportement par défaut, avec des portées différentes.

Le premier est un retrait temporaire de l’activation automatique, valable uniquement pour la période du 1er septembre 2026 au 1er février 2027. Il se pose par Microsoft Graph :

PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy { "optOutSettings": { "passkeyDynamicMigration": true } }

Il repousse l’activation et la campagne d’enregistrement, sans autre effet : le 1er février 2027, les règles standard s’appliquent quel que soit ce réglage.

Le second est la configuration d’un opérateur télécom tiers via le Microsoft Security Store, visible à partir du 18 septembre 2026 et configurable à partir du 30 octobre 2026. Cette option sert aux organisations qu’une réglementation oblige à garder un second canal de vérification, sur un autre appareil que celui de l’utilisateur. Il demande un contrat opérateur, des coûts récurrents et un pilote. Le 1er février 2027 s’applique de toute façon : cette option remplace le canal SMS, elle ne décale pas la date.

Le travail préalable est le même dans les deux cas : identifier les utilisateurs du tenant qui dépendent encore du SMS ou de la voix. Microsoft publie un script d’analyse à cet effet, exécutable avec le rôle Global Reader, Authentication Policy Administrator ou Security Reader.

Les populations à examiner en priorité sont les comptes de service, les collaborateurs sans téléphone d’entreprise, les intérimaires, le personnel de terrain et les comptes d’accès d’urgence, dont la configuration est rarement modifiée.

L’opérateur memberOf disparaît des groupes dynamiques

L’opérateur memberOf permet de définir un groupe dynamique dont les membres sont ceux d’autres groupes. Il est resté en préversion, et Microsoft met fin à cette préversion le 3 novembre 2026.

L’arrêt ne génère aucun message d’erreur : vous ne le détecterez qu’en cherchant memberOf dans vos règles.

Après le 3 novembre 2026, les groupes dynamiques, les unités administratives dynamiques et les stratégies d’attribution automatique qui reposent sur memberOf cessent de se mettre à jour et restent figés dans leur dernier état connu. Les appartenances existantes sont conservées, mais elles n’évoluent plus en fonction des groupes source.

Les conséquences suivent la chaîne des dépendances : accès Teams et SharePoint qui ne se retirent plus, ciblage des stratégies d’accès conditionnel qui dérive, attribution de licences par groupe qui se désynchronise, packages d’accès qui restent attribués. Un collaborateur qui change de service conserve les accès attachés à son ancien groupe ; un arrivant ne reçoit pas les siens. Vous les verrez arriver en tickets isolés, plusieurs semaines après le 3 novembre, sans que personne ne fasse le lien avec la fin de la préversion.

Ce point de dépendance demande une vérification particulière si vos stratégies d’accès conditionnel ciblent des groupes construits de cette manière ; notre guide sur l’accès conditionnel détaille la façon dont l’évaluation des stratégies s’appuie sur l’appartenance aux groupes.

La correction consiste à exporter les groupes dynamiques depuis le centre d’administration Entra, repérer les règles contenant memberOf, et les remplacer par des opérateurs pris en charge ou basculer le groupe en appartenance attribuée. Le même travail s’applique aux unités administratives dynamiques et aux stratégies d’attribution automatique, identifiables par Microsoft Graph PowerShell. Microsoft indique travailler à une solution de remplacement, sans en annoncer la disponibilité.

SMTP AUTH : l’authentification de base désactivée par défaut

L’authentification de base a disparu d’Exchange Online depuis plusieurs années pour Exchange ActiveSync, POP, IMAP, EWS, Remote PowerShell, Autodiscover et Outlook. SMTP AUTH était la dernière exception, maintenue parce qu’un grand nombre d’organisations s’en servent pour l’envoi d’e-mails par des équipements et des applications.

Le calendrier a été révisé en janvier 2026 :

• jusqu’en décembre 2026, le comportement reste inchangé ;
• fin décembre 2026, l’authentification de base pour SMTP AUTH est désactivée par défaut sur les tenants existants, les administrateurs pouvant encore la réactiver ;
• les tenants créés après décembre 2026 ne l’auront pas du tout, OAuth étant la seule méthode prise en charge ;
• au second semestre 2027, Microsoft annoncera la date de suppression définitive.

La désactivation par défaut n’est pas une suppression : la réactivation reste possible sur les tenants existants, pour une durée limitée dont le terme sera annoncé au second semestre 2027. Avant d’y recourir, identifiez quels émetteurs en dépendent.

Les émetteurs concernés figurent rarement dans un inventaire applicatif : imprimantes multifonctions qui envoient les numérisations par e-mail, alarmes techniques, ERP qui expédie des factures, outils de supervision, applications métier développées en interne. Les journaux d’envoi du tenant constituent la source d’inventaire fiable pour les recenser.

Vérifications à mener, par ordre d’échéance

1. Avant le 31 août — ouvrir le rapport d’usage EWS du centre d’administration, identifier les AppID actifs, écrire la liste EWSAllowedAppIDs et passer EWSEnabled à True. Si le délai ne permet pas un inventaire complet, une liste partielle et explicite reste préférable à la liste que Microsoft composera en septembre.
2. Avant le 1er septembre — lister les utilisateurs encore dépendants du SMS ou de la voix, décider s’il faut poser le retrait temporaire, et préparer la communication interne avant l’apparition de l’invite d’enregistrement.
3. En septembre — recenser les Organization Relationships, Availability Address Spaces et Sharing Policies actives, et contacter les administrateurs des tenants partenaires, dont l’action est nécessaire.
4. Avant le 3 novembre — exporter les règles de groupes dynamiques, d’unités administratives dynamiques et de stratégies d’attribution automatique, et rechercher memberOf.
5. Avant décembre — recenser les équipements et applications qui envoient des e-mails par SMTP authentifié, et vérifier lesquels acceptent OAuth.

Les deux premiers points se traitent en quelques heures sur un tenant de taille moyenne. Les trois suivants dépendent de la qualité de l’inventaire existant.

Les sources Microsoft

• Dépréciation d’Exchange Web Services dans Exchange Online
• Exchange Online EWS, Your Time is Almost Up
• Introducing EWSAllowedAppIDs
• Migrer vers Microsoft 365 Cross-Tenant Access Policy
• Clés d’accès par défaut et retrait de l’authentification SMS et vocale
• Groupes dynamiques configurés avec l’opérateur memberOf
• Message Center MC1448379, « memberOf operator in dynamic groups — end of preview » — Microsoft 365 Message Center (accessible depuis le centre d’administration du tenant)
• Calendrier révisé de la dépréciation de l’authentification de base pour SMTP AUTH
• Dépréciation de l’authentification de base dans Exchange Online