Gouverner la fatigue liée à la MFA et les attaques par bombardement de notifications push

La notification push de 2 h 13 devenue une question pour le conseil d’administration

À 2 h 13, une administratrice financière expérimentée reçoit une notification mobile : « Approuver la connexion ? » À moitié endormie, elle suppose qu’il s’agit d’une expiration de session provenant d’une plateforme financière cloud et appuie sur « Approuver ».

À 2 h 19, l’attaquant est dans le fournisseur d’identité. À 2 h 31, il tente d’accéder à un export de paie, à une console cloud à privilèges et à une boîte aux lettres partagée utilisée pour les paiements fournisseurs. À 3 h 05, le SOC observe des demandes MFA répétées, une géolocalisation inhabituelle, une approbation réussie et une nouvelle session depuis un appareil non géré.

La discussion du matin est familière :

• « Mais nous avions la MFA. »
• « Pourquoi l’utilisateur l’a-t-il approuvée ? »
• « Avons-nous journalisé les détails de la demande MFA ? »
• « S’agit-il d’une violation de données à caractère personnel ? »
• « Avons-nous des obligations de notification à 24 heures ou à 72 heures ? »
• « Notre auditeur ISO 27001:2022 considérera-t-il cela comme une défaillance de contrôle ? »
• « Cela a-t-il une incidence sur NIS2, DORA, GDPR, les contrats clients ou la cyberassurance ? »

C’est la lacune de gouvernance qui sous-tend la fatigue MFA et le bombardement de notifications push. Les attaquants ne cassent pas la cryptographie. Ils épuisent la capacité humaine de décision, exploitent une conception faible de l’authentification et recherchent des exceptions non surveillées. La défaillance de contrôle est rarement « MFA non activée ». Il s’agit le plus souvent d’une chaîne combinant une assurance d’identité insuffisante, une conception risquée de l’approbation push, l’absence de correspondance numérique, des règles d’accès à privilèges imprécises, une journalisation d’authentification insuffisante, un triage d’alertes défaillant, des utilisateurs insuffisamment formés et l’absence d’éléments probants documentés démontrant que l’organisation a revu et corrigé la faiblesse.

Pour les RSSI, responsables conformité, auditeurs et propriétaires métier, la fatigue MFA doit être traitée comme un enjeu de constitution d’éléments probants dans le SMSI, et non comme un simple paramétrage du fournisseur d’identité. La réponse combine le traitement des risques ISO 27001:2022, les contrôles ISO/IEC 27002:2022, les obligations de politique interne, la sensibilisation des utilisateurs, la réponse aux incidents, la gouvernance des fournisseurs et les mises en correspondance entre référentiels pour NIS2, DORA, GDPR, NIST CSF 2.0 et COBIT 2019.

La fatigue MFA est une défaillance d’assurance, pas un problème utilisateur

La fatigue MFA, également appelée bombardement de notifications push ou bombardement de demandes, survient lorsqu’un attaquant disposant d’un mot de passe valide déclenche de manière répétée des demandes d’approbation MFA jusqu’à ce que l’utilisateur en accepte une. L’attaquant y ajoute parfois de l’ingénierie sociale, par exemple un faux appel du centre d’assistance, un message indiquant « nous testons votre compte » ou une demande d’approbation d’une connexion pour faire cesser les notifications.

Le danger opérationnel tient au fait que les organisations traitent souvent toutes les formes de MFA comme équivalentes. Elles ne le sont pas.

Une simple notification push « approuver ou refuser » est plus faible que la correspondance numérique, les clés de sécurité FIDO2 résistantes au hameçonnage, l’authentification par certificat ou l’accès conditionnel qui bloque les déplacements impossibles et les appareils non gérés. La MFA échoue également lorsque les exceptions de contournement ne sont pas documentées, que les comptes de service sont interactifs, que les protocoles hérités restent ouverts ou que les accès à haut risque n’exigent pas une authentification renforcée.

Dans le Zenith Blueprint : feuille de route en 30 étapes pour les auditeurs, Clarysec positionne l’authentification sécurisée dans la phase Contrôles en action, étape 19 : Contrôles technologiques I. La recommandation est directe :

L’authentification constitue la première ligne de défense, et la plus critique, entre un acteur malveillant et vos systèmes, données et services. Si l’authentification est faible, tout le reste — chiffrement, surveillance, segmentation — peut être contourné.

Le même Zenith Blueprint traite également le contrôle ISO/IEC 27002:2022 5.17 à l’étape 22 :

Si l’identité répond à la question « Qui êtes-vous ? », l’authentification en est la preuve. Le contrôle 5.17 est le point où la théorie rencontre la confiance. Il exige que les informations d’authentification soient gérées de manière sécurisée tout au long de leur cycle de vie, afin que les méthodes et identifiants utilisés pour vérifier l’identité ne deviennent pas eux-mêmes le maillon faible.

Ces deux affirmations expliquent pourquoi le bombardement de notifications push doit figurer dans le registre des risques. Le chiffrement n’aide pas si l’attaquant devient un utilisateur approuvé. La segmentation réseau est moins efficace si un accès cloud à privilèges est approuvé au moyen d’une demande acceptée par fatigue. La surveillance ne fonctionne que si les événements d’authentification sont journalisés avec un niveau de détail suffisant et revus rapidement.

Un énoncé de risque mature doit être explicite :

C’est ici qu’ISO 27001:2022 est déterminante. La norme exige le contexte, les parties intéressées, le leadership, l’appréciation des risques, la planification du traitement, la maîtrise opérationnelle, la surveillance, l’audit interne, la revue de direction et l’amélioration continue. La fatigue MFA touche chacun de ces éléments.

Le groupe de contrôles ISO 27001:2022 que les auditeurs testeront

ISO 27001:2022 fournit la structure du système de management. ISO/IEC 27002:2022 fournit les recommandations de mise en œuvre des contrôles. Pour la fatigue MFA et le bombardement de notifications push, les auditeurs se concentreront généralement sur un ensemble de contrôles plutôt que sur un contrôle isolé.

Le Zenith Controls : guide de conformité croisée de Clarysec met en correspondance le contrôle ISO/IEC 27002:2022 8.5 Authentification sécurisée avec des contrôles d’appui tels que 5.17 Informations d’authentification, 8.2 Droits d’accès à privilèges, 8.16 Activités de surveillance, 5.24 Planification et préparation de la gestion des incidents de sécurité de l’information et 5.34 Protection de la vie privée et des données à caractère personnel. Cette articulation est importante, car une capture d’écran indiquant « MFA activée » ne suffit pas. Les auditeurs veulent la preuve que l’authentification est conçue, surveillée, revue et améliorée en fonction du risque.

Un dossier d’éléments probants défendable doit inclure :

1. Une appréciation des risques identifiant le bombardement de notifications push et l’ingénierie sociale visant les demandes MFA.
2. Une norme d’authentification définissant les méthodes MFA acceptables selon la criticité du système.
3. Une politique d’accès à privilèges exigeant une authentification renforcée pour les accès administrateur et à distance.
4. Un export de configuration du fournisseur d’identité montrant la correspondance numérique, les limites de demandes, l’accès conditionnel et le blocage de l’authentification héritée.
5. Des journaux montrant les événements MFA réussis et échoués, les demandes refusées, les déplacements impossibles et le contexte de l’appareil.
6. Des règles d’alerte pour les demandes MFA répétées, les échecs répétés et les approbations réussies inhabituelles.
7. Des enregistrements de réponse aux incidents pour les alertes liées à l’authentification.
8. Des supports de sensibilisation indiquant aux utilisateurs de ne pas approuver les demandes inattendues.
9. Des enregistrements de revue d’accès pour les systèmes à privilèges et à fort impact.
10. Un registre des exceptions avec dates d’expiration, approbations des propriétaires du risque et contrôles compensatoires.

La politique transforme « ne pas approuver les demandes inattendues » en éléments probants

De nombreuses organisations demandent aux utilisateurs de ne pas approuver les demandes suspectes. Ce conseil est utile, mais il ne suffit pas pour la certification ISO 27001:2022, la supervision NIS2, la résilience DORA, la responsabilité au titre du GDPR, les diligences raisonnables des clients ou la cyberassurance.

Le premier ancrage de politique est la P38 Politique relative aux communications sécurisées et à l’authentification multifacteur (MFA). Elle traite directement le facteur humain :

Sensibilisation des utilisateurs : les utilisateurs doivent recevoir une formation leur permettant de distinguer les canaux de communication sécurisés et non sécurisés. La formation doit couvrir l’utilisation appropriée de l’authentification multifacteur (MFA) (par exemple, ne pas approuver des demandes de connexion inattendues) et les pratiques de communication sécurisée (par exemple, vérifier les liens de visioconférence et ne pas discuter de sujets confidentiels sur des lignes non sécurisées).

Cela transforme la fatigue MFA en obligation de formation, et non en exercice de culpabilisation. Le RSSI peut ainsi démontrer que le bombardement de demandes est couvert lors de l’intégration, de la formation de rappel, de la formation fondée sur les rôles et des briefings destinés aux utilisateurs à privilèges.

La même P38 Politique relative aux communications sécurisées et à l’authentification multifacteur (MFA) crée également une obligation de surveillance :

La sécurité de l’information doit surveiller en continu les journaux d’authentification afin de détecter toute tentative de connexion à facteur unique ou tout échec anormal d’authentification multifacteur (MFA). Les journaux des systèmes de communication sécurisée, le cas échéant, doivent être surveillés afin de détecter les tentatives d’accès non autorisées ou les modifications de configuration.

Pour les PME, la P11S Politique de gestion des comptes utilisateurs et des privilèges - PME fixe un référentiel minimal pragmatique :

L’authentification multifacteur (MFA) doit être activée, lorsque cela est techniquement possible, pour les comptes administrateur ou les systèmes sensibles.

La formule « lorsque cela est techniquement possible » ne doit jamais devenir une faille. Si un système ne peut pas prendre en charge une MFA forte, l’exception doit être enregistrée avec un propriétaire, une date d’expiration, des contrôles compensatoires, une surveillance et un plan de migration. Les organisations de plus grande taille peuvent aligner la même exigence sur la P11 Politique de gestion des comptes utilisateurs et des privilèges, puis vérifier la correspondance entre la politique et la réalité opérationnelle.

Les éléments probants de détection proviennent de la P22S Politique de journalisation et de surveillance - PME, qui exige la journalisation des événements d’authentification :

Journaux d’authentification : tentatives de connexion réussies et échouées, durée de session, utilisation de la MFA

Elle exige également la revue urgente des signaux d’authentification à haut risque :

Revue immédiate lors de la détection d’alertes de gravité élevée (par exemple, logiciels malveillants, échec de l’authentification multifacteur (MFA), échecs de connexion répétés)

La sensibilisation doit évoluer avec les menaces. La Politique de sensibilisation et de formation à la sécurité de l’information - PME soutient cette boucle :

Les thèmes doivent inclure les menaces émergentes (par exemple, le phishing), les modifications de politiques pertinentes et les tendances internes des incidents.

Lorsque le SOC détecte des tentatives de fatigue MFA, ce renseignement doit alimenter les alertes utilisateurs, les scripts du centre d’assistance, les exercices sur table et les mises à jour de formation.

Un pack de contrôles gouverné pour la fatigue MFA

Supposons que votre organisation utilise un fournisseur d’identité cloud, un CRM SaaS, une plateforme financière, un VPN et un prestataire de services de sécurité managés. L’objectif est de gouverner la fatigue MFA à l’aide du Zenith Blueprint, de la bibliothèque de politiques et du guide de conformité croisée Zenith Controls de Clarysec.

Commencez par l’étape 19 du Zenith Blueprint, qui demande aux équipes de définir les exigences d’authentification par système et avertit que l’authentification par mot de passe seul doit être évitée pour les comptes administrateur, les consoles cloud, les outils d’accès à distance et les systèmes exposés à Internet. Appliquez ensuite l’activité de revue pratique :

Passez en revue votre déploiement MFA : identifiez les lacunes éventuelles et planifiez leur correction. Vérifiez que les comptes de service sont non interactifs lorsque cela est possible, disposent d’identifiants robustes et sont documentés. Confirmez qu’aucun identifiant par défaut ne subsiste sur un système ou une application.

Convertissez cette recommandation en pack de contrôles opérationnel.

Étape 1 : classer les systèmes selon le risque d’authentification

Étape 2 : supprimer les comportements push à haut risque

Pour les comptes administrateur et à fort impact, désactivez l’approbation push de base. Utilisez des authentificateurs résistants au hameçonnage lorsque cela est possible. Lorsque le push demeure, imposez la correspondance numérique, le contexte applicatif, le contexte géographique, l’association à l’appareil et des limites de fréquence des demandes. Bloquez l’authentification héritée et exigez une réauthentification pour les sessions risquées.

Étape 3 : définir des règles d’alerte pour la fatigue MFA

Une règle SIEM pragmatique doit se déclencher lorsqu’un ou plusieurs des schémas suivants surviennent dans une fenêtre courte :

• Trois demandes push MFA ou plus pour un même utilisateur.
• Deux demandes refusées suivies d’une demande approuvée.
• Approbation MFA depuis une nouvelle géolocalisation ou un appareil non géré.
• Demande MFA suivant un signal d’attaque par pulvérisation de mots de passe ou de bourrage d’identifiants.
• Approbation MFA pour un accès à privilèges en dehors des horaires de travail habituels.
• Enregistrement d’un nouvel authentificateur peu après des tentatives de connexion échouées.

L’alerte doit créer un ticket d’incident, notifier le SOC ou le responsable de la sécurité et exiger des mesures de confinement : suspendre la session, révoquer les jetons d’actualisation, imposer une réinitialisation du mot de passe, vérifier l’appareil, interroger l’utilisateur, examiner les accès utilisés pendant la session et déterminer si des données à caractère personnel ou un service critique ont été affectés.

Étape 4 : lier les enregistrements relatifs à la vie privée et aux incidents

Si le compte peut accéder à des données à caractère personnel, appliquez la Politique de sécurité et de contrôle d’accès des PII. Elle exige une authentification forte avant tout accès à des PII à fort impact :

[Applicable aux deux] Le responsable de la sécurité de l’information DOIT exiger une authentification forte pour tout accès à privilèges, à distance, administratif ou à fort impact aux PII avant l’activation de cet accès, et enregistrer l’exigence dans REG12.

Elle exige également que le périmètre de journalisation soit défini :

[Applicable aux deux] Le propriétaire du système / propriétaire d’application DOIT définir dans REG12 le périmètre de journalisation des PII pour les événements d’authentification, les événements d’accès, les actions à privilèges, les activités d’export de PII et les modifications substantielles de configuration avant l’utilisation en production ou toute modification substantielle.

Lorsque la surveillance suggère un accès non autorisé aux PII, elle crée une obligation d’enregistrement d’incident :

[Conditionnel] Le coordinateur de la réponse aux incidents DOIT ouvrir ou lier un enregistrement REG10 dans un délai d’un jour ouvré lorsque la surveillance indique un accès non autorisé suspecté aux PII, une divulgation suspectée de PII, une altération suspectée de PII ou une perte suspectée de disponibilité des PII.

L’escalade relative à la vie privée est complétée par la Politique de gestion des incidents et violations de PII :

[Conditionnel] Le référent confidentialité / responsable du PIMS DOIT évaluer les déclencheurs applicables de notification légale, sectorielle, financière, cybersécurité, contractuelle, client et destinataire du service pour chaque incident à fort impact relatif aux PII, et enregistrer le résultat d’applicabilité dans REG01, REG08 et REG10.

C’est ainsi qu’une alerte MFA devient un ensemble d’éléments probants exploitables en audit couvrant la sécurité, la vie privée et la conformité.

NIS2, DORA et GDPR : un incident, des questions différentes

La fatigue MFA constitue un test de résistance utile en matière de conformité croisée, car elle touche la gouvernance, l’hygiène cyber, le contrôle d’accès, la détection des incidents, les accès fournisseurs et la notification des violations.

NIS2 : responsabilité de la direction et hygiène cyber

NIS2 s’applique à de nombreuses entités essentielles et importantes, selon le secteur, la taille et la désignation par l’État membre. L’Article 20 impose aux organes de direction d’approuver les mesures de gestion des risques de cybersécurité, d’en superviser la mise en œuvre et de recevoir une formation. L’Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées, incluant la gestion des incidents, l’hygiène cyber, la sécurité de la chaîne d’approvisionnement, le contrôle d’accès, la gestion des actifs, la formation, ainsi que l’authentification multifacteur ou l’authentification continue lorsque cela est approprié. L’Article 23 introduit des obligations de notification par étapes pour les incidents importants, notamment une alerte précoce dans les 24 heures suivant la prise de connaissance et une notification d’incident dans les 72 heures.

Un incident de bombardement de notifications push devient donc une question pour le conseil d’administration : la MFA a-t-elle été conçue de manière sécurisée, ou simplement activée ?

DORA : l’authentification comme résilience opérationnelle numérique

Pour les entités financières couvertes, DORA s’applique à partir du 17 janvier 2025. Il attend une gestion des risques liés aux TIC, la détection, la réponse, le rétablissement, la notification des incidents, les tests de résilience opérationnelle numérique et la gestion des risques liés aux prestataires tiers de services TIC.

L’Article 9 de DORA traite de la protection et de la prévention, notamment des mesures de contrôle d’accès et d’authentification. L’Article 10 traite de la détection des activités anormales. L’Article 17 exige un processus de gestion des incidents liés aux TIC. Dans un contexte DORA, les éléments probants relatifs à la fatigue MFA doivent montrer que les actifs TIC concernés ont été identifiés, que la surveillance a détecté le comportement anormal, que l’incident a été classé selon des critères d’impact, que l’escalade vers la haute direction a été effectuée lorsque nécessaire et que les enseignements tirés ont été réintégrés dans le cadre de gestion des risques liés aux TIC.

GDPR : sécurité du traitement et responsabilité

L’Article 5(1)(f) du GDPR exige l’intégrité et la confidentialité. L’Article 5(2) exige la responsabilité. L’Article 32 exige une sécurité appropriée au risque. L’Article 4 définit une violation de données à caractère personnel comme une violation de la sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l’altération, la divulgation non autorisée de données à caractère personnel transmises, conservées ou traitées d’une autre manière, ou l’accès non autorisé à de telles données.

Si un incident de fatigue MFA concerne des données à caractère personnel, la question probatoire est simple : l’organisation peut-elle démontrer des contrôles d’authentification appropriés, une surveillance, une réponse aux incidents et une évaluation de violation ?

Table de correspondance pour ISO, NIST CSF 2.0, COBIT 2019 et les éléments probants d’audit

NIST CSF 2.0 est utile, car il traduit la gouvernance MFA en résultats GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND et RECOVER.

COBIT 2019 apporte de la clarté en matière de gouvernance. Un auditeur orienté COBIT peut examiner DSS05.04 Gérer l’identité et l’accès logique, DSS05 Gérer les services de sécurité, APO13 Gérer la sécurité et MEA03 Gérer la conformité aux exigences externes. L’enjeu n’est pas le fournisseur MFA. Il s’agit de déterminer si l’authentification soutient les objectifs métier, si les droits d’accès sont gouvernés, si la surveillance est efficace et si la direction reçoit une assurance pertinente.

Une cartographie consolidée aide les équipes conformité à éviter les demandes d’éléments probants fragmentées :

Ce que les auditeurs et les régulateurs demanderont

Un programme robuste de gestion de la fatigue MFA doit résister à plusieurs styles d’audit. Le guide de conformité croisée Zenith Controls de Clarysec montre comment les contrôles ISO/IEC 27002:2022 sont testés selon les méthodologies ISO, NIST, COBIT et ISACA.

Un programme faible indique : « Nous avons interrogé l’utilisateur et réinitialisé le mot de passe. » Un programme gouverné produit une alerte SIEM, un ticket d’incident, un enregistrement de révocation de session, des éléments probants de réinitialisation de mot de passe, une revue des facteurs MFA, une analyse des journaux d’accès, une évaluation PII, une évaluation des déclencheurs de notification, un énoncé de cause racine, des actions correctives et un élément d’entrée pour la revue de direction.

Un plan d’action de 30 jours pour la gouvernance de la fatigue MFA

L’objectif n’est pas la perfection en 30 jours. L’objectif est la visibilité, la responsabilité et les éléments probants.

Semaine 1 : identifier et délimiter le périmètre

• Lister tous les fournisseurs d’identité, VPN, consoles cloud, plateformes SaaS et outils d’accès à privilèges.
• Identifier les systèmes contenant des données à caractère personnel, des données financières, des accès à l’environnement de production ou des fonctions ayant un impact sur les services.
• Exporter les méthodes MFA et exceptions actuelles.
• Identifier les comptes externes et fournisseurs.
• Ajouter la fatigue MFA et le bombardement de notifications push au registre des risques.
• Désigner un propriétaire du risque et un propriétaire du traitement.

Semaine 2 : durcir l’authentification

• Désactiver l’authentification héritée.
• Exiger une MFA résistante au hameçonnage pour les administrateurs lorsque cela est possible.
• Activer la correspondance numérique et le contexte applicatif pour la MFA par notification push.
• Appliquer l’accès conditionnel selon la localisation, la conformité de l’appareil et les déplacements impossibles.
• Limiter les demandes push répétées.
• Exiger une réauthentification pour les actions à haut risque.
• Rendre les comptes de service non interactifs lorsque cela est possible.
• Documenter les exceptions avec date d’expiration et contrôles compensatoires.

Semaine 3 : surveiller et s’exercer

• Vérifier que les journaux d’authentification capturent les réussites, les échecs, la durée de session et l’usage MFA.
• Créer des règles d’alerte pour les demandes répétées, les demandes refusées suivies d’une approbation, l’enregistrement d’un nouvel appareil et la localisation inhabituelle.
• Tester les alertes au moyen d’une simulation contrôlée.
• Valider la création et l’escalade des tickets d’incident.
• Former les utilisateurs avec un court exercice « demande MFA inattendue ».
• Mettre à jour les scripts du centre d’assistance afin de prévenir l’ingénierie sociale lors des réinitialisations de mot de passe et du réenrôlement MFA.

Semaine 4 : éléments probants et revue de direction

• Conserver les exports de configuration et les captures d’écran.
• Enregistrer les résultats des revues d’accès.
• Relier l’achèvement de formation aux utilisateurs à privilèges.
• Revoir les incidents et les quasi-accidents.
• Mettre à jour la Déclaration d’applicabilité et le plan de traitement.
• Présenter le risque résiduel et les indicateurs à la direction.
• Planifier l’échantillonnage d’audit interne.

Rendre la fatigue MFA auditable avant qu’elle ne devienne notifiable

La fatigue MFA rappelle que les contrôles de sécurité échouent aux interfaces : entre l’identité et la surveillance, entre la politique et la formation, entre les fournisseurs et les accès internes, entre la réponse aux incidents et le reporting relatif à la vie privée.

Les organisations qui la gèrent correctement ne se contentent pas « d’activer la MFA ». Elles gouvernent l’authentification comme un cycle de vie, la surveillent comme un signal de menace, forment les utilisateurs comme une composante du contrôle et préservent les éléments de preuve dans le cadre du SMSI.

Clarysec réunit trois actifs :

• Le Zenith Blueprint : feuille de route en 30 étapes pour les auditeurs, en particulier l’étape 19 pour l’authentification sécurisée, l’étape 22 pour les informations d’authentification et l’étape 16 pour le signalement des incidents par le personnel.
• Les modèles de politiques Clarysec, notamment la P38 Politique relative aux communications sécurisées et à l’authentification multifacteur (MFA), la P22S Politique de journalisation et de surveillance - PME, la P11S Politique de gestion des comptes utilisateurs et des privilèges - PME, la Politique de sensibilisation et de formation à la sécurité de l’information - PME, la Politique de sécurité et de contrôle d’accès des PII et la Politique de gestion des incidents et violations de PII.
• Zenith Controls : guide de conformité croisée, qui met en correspondance les contrôles ISO/IEC 27002:2022 5.17, 8.5, 8.15 et 8.16 avec les contrôles d’appui, les attentes d’audit ISO, GDPR, NIS2, DORA, NIST et COBIT.

Si vous êtes RSSI, responsable conformité, auditeur ou propriétaire métier, menez une revue d’une semaine des éléments probants relatifs à la fatigue MFA. Rassemblez votre configuration MFA, vos journaux d’authentification, votre liste d’accès à privilèges, votre liste d’accès fournisseurs, votre playbook d’incident, vos supports de formation et votre registre des exceptions. Si ces livrables justificatifs ne racontent pas une histoire cohérente, Clarysec peut vous aider à construire le pack de contrôles avant qu’un attaquant, un auditeur ou un régulateur ne le demande.

Explorez le Zenith Blueprint, consultez Zenith Controls ou planifiez un appel de découverte Clarysec afin de transformer la fatigue MFA, de surprise pour le conseil d’administration, en programme d’authentification défendable et auditable.