L’équipe de support déploie l’authentification multifacteur, puis reçoit une demande inattendue de retour en arrière

Une équipe de support systèmes travaillant sur un projet de sécurité Microsoft 365 affirme que le déploiement prévu de l’authentification multifacteur a été compromis après qu’un cadre dirigeant s’est plaint que le changement avait perturbé une partie du processus de facturation de l’entreprise.

Selon un lecteur qui a décrit l’incident, l’équipe avait collaboré avec le client pour améliorer son Microsoft Secure Score et mettre en place l’AMF dans toute l’organisation, dans le cadre d’une base de référence de sécurité. Le déploiement se serait d’abord déroulé sans incident, les changements ayant été appliqués comme prévu.

Le lendemain, toutefois, un directeur général de l’entreprise a appelé le service d’assistance, furieux, affirmant que les nouveaux contrôles d’authentification submergeaient l’entreprise. Le cadre aurait soutenu que l’obligation d’utiliser l’AMF avait paralysé l’organisation et mis en danger le système de facturation.

Le personnel du support a ensuite déterminé que la perturbation était bien plus limitée que ce qui avait été initialement affirmé. Seul un petit nombre de téléphones était affecté, et le problème sous-jacent semblait provenir de l’application de facturation elle-même. Le logiciel était réputé compatible avec l’AMF, mais dépendait d’un code défectueux pour fonctionner.

Même après cette explication, le directeur aurait insisté pour qu’un retour en arrière soit effectué immédiatement. La modification de sécurité a été annulée, laissant l’organisation avec une protection plus faible qu’auparavant.

Problèmes de sécurité et messages contradictoires

Le lecteur qui a partagé cette histoire a déclaré que la réaction était particulièrement surprenante, car le cadre dirigeant était présenté comme un ancien directeur des opérations d’une entreprise de cybersécurité. Ce récit laisse apparaître un décalage entre les objectifs de sécurité du projet et la réaction de la direction lorsqu’un processus métier rencontre des difficultés.

Le même client était également décrit comme ayant l’habitude de formuler des demandes inhabituelles, notamment de demander à un ingénieur qui ne pouvait pas conduire de se rendre sur un site isolé pour réparer une imprimante. Lors d’un autre incident, le cadre aurait reproché au travail effectué sur Microsoft 365 d’avoir provoqué une panne de courant.

• Le déploiement de l’AMF s’inscrivait dans une base de référence de sécurité plus large pour Microsoft 365.
• La panne signalée n’a affecté qu’un petit nombre d’appareils mobiles.
• Le logiciel de facturation, et non l’AMF elle-même, aurait été à l’origine du problème.
• Le retour en arrière a laissé l’organisation avec une protection moindre en matière d’authentification.

Cet épisode souligne un défi courant pour les équipes informatiques : même des améliorations de sécurité soigneusement planifiées peuvent être rapidement annulées lorsque les utilisateurs métier interprètent toute perturbation comme un échec de la sécurité.