Vous voyez dans l’historique Microsoft des « Successfully Signed in » assortis de « Session activity / additional verification requested », parfois depuis un autre État australien ? Voici comment interpréter ces entrées, confirmer s’il s’agit d’une anomalie et sécuriser votre compte.
Contexte : pourquoi ces événements apparaissent-ils ?
La page d’activité de votre compte Microsoft agrège tout ce qui touche à l’authentification : tentatives échouées, connexions abouties, vérifications supplémentaires, changements d’appareils, etc. Trois éléments reviennent souvent dans les cas qui nous intéressent :
- Une avalanche d’échecs de connexion issus d’adresses IP étrangères : c’est le bruit de fond de l’Internet moderne (credential stuffing, robots qui testent des combinaisons connues). Avec un mot de passe robuste et la double authentification (2FA), ces tentatives restent sans effet.
- Quelques « Successfully Signed in » annotés Session activity – additional verification requested et géolocalisés dans un autre État.
- Aucune notification 2FA reçue au moment de ces événements, alors que la 2FA fonctionne par ailleurs (alerte bien reçue lors d’une première connexion sur un PC d’entreprise, par exemple).
Pris ensemble, ces signaux interrogent : y a‑t‑il eu intrusion ? une erreur de géolocalisation ? un comportement normal mais mal compris ? La réponse tient à la mécanique exacte du processus de connexion.
Décrypter la mention « additional verification requested »
Cette mention signifie qu’après la saisie d’un mot de passe correct, Microsoft a exigé une étape supplémentaire d’authentification (2FA) mais que cette étape n’a pas été menée à son terme (abandon, échec, choix d’une méthode indisponible, etc.).
Ce point est subtil : certaines vues de l’historique résument l’événement comme « Successfully Signed in » parce que la partie mot de passe est réussie. Mais l’accès complet au compte et aux données est bloqué tant que la 2FA n’est pas validée. C’est pourquoi le libellé ajoute « additional verification requested » ou « MFA required » lorsque vous ouvrez le détail.
Pourquoi vous n’avez reçu aucune alerte 2FA
- L’étape 2FA n’a jamais été déclenchée côté serveur jusqu’à son envoi effectif (ex. : l’attaquant abandonne dès l’écran demandant l’approbation). Dans ce cas, vous ne recevez rien.
- Méthode choisie non atteignable par l’attaquant (il bascule sur « utiliser une autre méthode », puis annule). Là encore, aucun « push » ni code ne vous est envoyé.
- Appareil de confiance et session déjà validée : lorsque vous avez coché « ne plus demander sur cet appareil », les relogins routiniers réutilisent un jeton et ne déclenchent pas systématiquement une sollicitation 2FA, sauf si le système juge la session atypique (changement d’IP, d’empreinte navigateur, effacement de cookies, etc.).
Localisation affichée dans un autre État : normal ou suspect ?
La position affichée dans l’historique reflète une géolocalisation IP, pas votre GPS. Or, en environnement Microsoft :
- Les infrastructures (CDN, proxys, nœuds d’entrée régionaux) peuvent vous faire apparaître depuis une ville/État différent, tout en étant une connexion parfaitement légitime.
- Les bases de géolocalisation IP sont inexactes ou retardées : une IP fraîchement réaffectée peut pointer vers une ancienne localisation.
- Les opérateurs mobiles et certains FAI concentrent les sorties Internet dans des datacenters éloignés de l’abonné.
| Symptôme | Cause probable | Que vérifier |
|---|---|---|
| Ville/État différent mais mêmes plages horaires que vos habitudes | Routage via nœud Microsoft (CDN/edge), IP NAT opérateur | Comparer l’horodatage, l’adresse IP et le navigateur avec une session connue |
| Plusieurs entrées avec la même IP « lointaine » | Point de sortie FAI/entreprise stable | Si l’IP revient quand vous vous connectez, c’est probablement vous |
| Heure incongrue (ex. : 02:17), appareil inconnu | Essai d’intrusion ou app/service tiers | Vérifier si la 2FA a abouti ; si oui et que ce n’est pas vous, agir immédiatement |
Réponses directes aux questions les plus fréquentes
| Question | Explication | Actions recommandées |
|---|---|---|
| Que signifie « additional verification requested » ? | Quelqu’un a saisi le bon mot de passe, puis a échoué/annulé la 2FA. L’accès complet n’a pas été accordé. | Aucune alerte n’est émise si la seconde étape ne part pas ou n’aboutit pas. Surveillez simplement l’activité. |
| Pourquoi la géolocalisation pointe un autre État ? | Routage Microsoft (CDN/proxy) ou sortie opérateur distante ; l’IP peut refléter un nœud géographiquement éloigné. | Comparez heure, IP et contexte : si l’IP recoupe vos usages, l’événement est probablement légitime. |
| Pourquoi je ne vois pas ces événements tous les jours ? | Une fois l’appareil marqué « de confiance », Microsoft peut omettre la 2FA et enregistrer la session en silence, sauf anomalie. | Rien à corriger ; c’est un fonctionnement normal de la gestion de session. |
| « Unknown » dans le type d’appareil ? | Navigateur/app avec empreinte incomplète (anti‑pistage, proxy, client email en arrière‑plan, etc.). | Isolé, ce n’est pas alarmant. Surveillez si d’autres anomalies s’ajoutent. |
Grille d’analyse : faut‑il s’inquiéter ?
| Indicateur | Niveau de risque | Interprétation | Action |
|---|---|---|---|
| « Additional verification requested » sans 2FA réussie | Faible à modéré | Mot de passe connu d’un tiers, mais 2FA a bloqué l’accès | Changer le mot de passe si doute ; renforcer 2FA; surveiller |
| Localisation incohérente, même IP récurrente lors de vos connexions | Faible | Routage/CDN ou sortie FAI | Aucune action, noter l’IP comme « connue » |
| 2FA réussie à un horaire/lieu incompatibles | Élevé | Accès non autorisé | Changer mot de passe + révoquer sessions/tokens + vérifier infos de sécurité |
| Multiples tentatives rapprochées depuis des pays variés | Modéré | Attaques automatisées | Activer Authenticator, désactiver SMS si possible, activer alertes |
Procédure pas à pas pour vérifier un événement
- Ouvrir l’historique : dans votre compte, menu Sécurité > Activité de connexion. Affichez le détail de l’événement suspect.
- Noter l’horodatage exact (date, heure, fuseau). Comparez avec vos usages (étiez‑vous actif ?).
- Relever l’adresse IP et le fournisseur. Cherchez si la même IP apparaît sur des sessions dont vous êtes sûr(e). Si oui, c’est probablement votre propre trafic routé différemment.
- Identifier l’appareil et l’application : Windows, iOS, Android, navigateur, Outlook, OneDrive, etc. « Unknown » n’est anormal qu’en présence d’autres signaux.
- Vérifier la 2FA : l’entrée mentionne‑t‑elle une validation réussie ? Si non, l’accès a été bloqué. Si oui et que ce n’est pas vous, appliquez immédiatement le plan d’urgence ci‑dessous.
Plan d’urgence en cas de doute (à appliquer sans attendre)
- Changer le mot de passe du compte (long, unique, aléatoire). Éviter la réutilisation sur d’autres services.
- Révoquer les sessions actives : utilisez l’option « se déconnecter de tous les appareils » si disponible. Pour les comptes d’organisation, demandez à l’administrateur de révoquer les tokens d’actualisation.
- Passer à Microsoft Authenticator comme méthode 2FA principale (au lieu du SMS/e‑mail). Si possible, activez la validation par saisie d’un nombre dans l’app.
- Nettoyer les méthodes redondantes : supprimez les anciennes applications d’authentification, téléphones obsolètes et adresses e‑mail de secours non utilisées.
- Activer un mode sans mot de passe (passkey, Windows Hello, ou validation via l’app) si votre compte le propose. Cela réduit fortement l’efficacité du phishing.
- Activer les codes de récupération et conservez‑les hors ligne (coffre chiffré, impression papier sécurisée).
Paramétrage 2FA recommandé (sécurité & ergonomie)
- Méthode par défaut : App Microsoft Authenticator avec notification et (si disponible) saisie d’un nombre. C’est résistant aux « fatigue attacks ».
- Méthode de secours : codes TOTP dans une seconde application (sur un autre appareil) ou codes de récupération imprimés.
- Éviter le SMS comme unique méthode (cible du SIM‑swap, couverture réseau inégale). Conservez‑le seulement comme secours.
- Appareils de confiance : n’activez cette option que sur vos machines personnelles et protégées (chiffrement du disque, verrouillage auto, antivirus à jour).
Hygiène réseau et poste : réduire la surface d’attaque
- Ne restez pas connecté sur des postes partagés ou gérés par un tiers. Utilisez des profils séparés.
- Activez le chiffrement de disque (BitLocker sur Windows) et un verrouillage automatique court (3–5 minutes d’inactivité).
- Mettez à jour Windows, les navigateurs, les extensions et l’app Authenticator dès que des correctifs sont disponibles.
- Protégez votre navigateur : gestionnaire de mots de passe réputé, blocage du chargement de scripts tiers superflus, désactivation de l’installation d’extensions hors boutiques officielles.
Scénarios concrets : comment décider rapidement
Scénario A : probablement légitime
Le journal affiche « Successfully Signed in – Session activity / additional verification requested » à 09:30, depuis un autre État. L’IP est la même que lorsque vous télétravaillez via votre FAI. L’appareil est « Windows », navigateur « Edge ». Aucune 2FA réussie n’est listée.
Conclusion : il s’agit d’une connexion réelle de votre poste, routée par un nœud Microsoft/FAI situé ailleurs. Action : aucune, en dehors d’un contrôle de routine (mots de passe et 2FA à jour).
Scénario B : suspect
Événement à 02:17, « Android » alors que vous n’avez aucun téléphone Android, localisation lointaine, et la 2FA est marquée comme réussie. Dans ce cas, un tiers a pu approuver une demande (appareil volé, méthode de secours compromise, phishing).
Conclusion : compromission probable. Action immédiate : changer le mot de passe, révoquer les sessions/tokens, retirer les méthodes 2FA non reconnues, et vérifier toute activité sensible (OneDrive, Outlook, acheminement de règles, etc.).
FAQ ciblée
Les échecs de robots étrangers sont‑ils dangereux ?
Ils sont inévitables, mais neutralisés par un mot de passe solide et la 2FA. L’objectif est qu’aucune tentative ne se transforme en 2FA validée.
Pourquoi certaines connexions « réussies » ne me demandent plus la 2FA ?
Vous avez consenti à faire confiance à l’appareil (cookie/jeton longue durée). La 2FA réapparaîtra si Microsoft détecte une anomalie (IP, empreinte, période anormale) ou si vous vous déconnectez.
Puis‑je empêcher totalement ces tentatives ?
Non, vous ne pouvez pas empêcher le monde extérieur de tenter des connexions. En revanche, vous pouvez rendre ces tentatives inefficaces (2FA robuste), et rendre visibles les anomalies (alertes, revue régulière).
« Unknown device » signifie‑t‑il un malware ?
Pas nécessairement. Les paramètres de confidentialité et certains clients (ex. : services Outlook/Exchange en arrière‑plan) limitent les informations transmises. Un « Unknown » isolé n’est pas alarmant.
Checklist de sécurité à conserver
- 2FA activée, Authenticator en méthode principale, SMS en secours.
- Mots de passe longs et uniques, gestionnaire de mots de passe fiable.
- Appareils de confiance limité́s à vos machines personnelles sécurisées.
- Vérification mensuelle de l’onglet Activité de connexion et des méthodes de sécurité.
- Codes de récupération imprimés et stockés hors ligne.
- Révocation immédiate des méthodes 2FA ou appareils que vous ne reconnaissez pas.
Bonnes pratiques supplémentaires (entreprise / Microsoft 365)
Si votre compte est géré par une organisation (Microsoft 365/Entra ID) :
- Demandez l’activation des protections « anti‑fatigue » (approbation dans l’app avec saisie d’un nombre) et des politiques exigeant l’Authenticator.
- En cas d’alerte, faites révoquer les tokens d’actualisation par un administrateur pour forcer la reconnexion sur tous les appareils.
- Faites auditer les règles de boîte aux lettres et d’acheminement (Outlook) : des règles malveillantes peuvent rediriger vos messages à votre insu.
Synthèse
Dans la grande majorité des cas, deux événements « Successfully Signed in – Session activity / additional verification requested » géolocalisés dans un autre État australien correspondent à vos propres connexions, vues à travers le prisme des infrastructures Microsoft (CDN, proxys, sorties FAI). L’absence d’alerte 2FA est cohérente si la seconde étape n’a pas été effectivement menée ou si l’appareil est de confiance. Aucun signe d’intrusion ne transparaît tant que la 2FA n’est pas validée à votre insu.
Pour autant, appliquez une hygiène stricte : Authenticator en méthode principale, nettoyage des méthodes 2FA obsolètes, mots de passe solides, revue régulière de l’activité, révocation rapide en cas de doute. Cette discipline transforme des journaux anxiogènes en de simples indicateurs de bonne santé de votre sécurité.
Résumé exécutable
- Interprétation : mot de passe correct + 2FA non validée = accès bloqué.
- Localisation : peut refléter un nœud Microsoft/FAI distant.
- Décision : pas d’action si contexte concordant ; sinon, changer mot de passe et renforcer 2FA.
- Surveillance : consulter périodiquement l’activité et éliminer les méthodes 2FA/ appareils inconnus.
Annexe : guide d’interprétation des journaux
| Champ du journal | Ce que ça décrit | Piste d’analyse |
|---|---|---|
| Heure & Fuseau | Moment exact de l’événement | Comparez à votre agenda et vos habitudes (heure de bureau, déplacements) |
| Adresse IP / Fournisseur | Point de sortie sur Internet | Une IP récurrente sur vos connexions = indice de légitimité |
| Emplacement | Géolocalisation par IP | À relativiser (CDN/proxy). Croiser avec IP et appareil |
| Appareil / Navigateur | Type d’OS, version, user‑agent | « Unknown » n’est pas suspect isolément |
| Statut 2FA | MFA required / succeeded / failed | Seul un « succeeded » non reconnu justifie l’urgence |
En résumé : les lignes « Session activity / additional verification requested » témoignent surtout de l’efficacité de votre 2FA, pas d’une brèche. Continuez à surveiller, durcissez vos méthodes d’authentification et intervenez immédiatement si une 2FA réussie ne vient pas de vous.