La vulnérabilité de BeyondTrust Remote Support transforme un outil d’assistance en voie d’attaque

BeyondTrust fait face à une crise urgente de correctifs après que des attaquants ont exploité une faille critique de Remote Support plusieurs semaines avant sa divulgation publique. La vulnérabilité de BeyondTrust Remote Support, référencée CVE-2026-102764, affiche un score CVSS de 9,3. Elle affecte Remote Support versions 26.2.3 et antérieures.

La CISA a ajouté la vulnérabilité à son catalogue Known Exploited Vulnerabilities le 16 octobre 2026. Cette mesure confirme l’existence de preuves crédibles d’une exploitation réelle, plutôt que d’un risque de sécurité théorique. La CISA exhorte les opérateurs d’appliances auto-hébergées concernées à appliquer immédiatement le correctif BT26-05-RS.

Le problème central ne se limite pas à l’installation d’une mise à jour. Les appliances Remote Support servent d’intermédiaires pour l’accès privilégié aux systèmes internes, aux identifiants et aux sessions administratives. Mandiant a constaté que des attaquants avaient utilisé une appliance compromise pour établir une persistance, obtenir des privilèges root et atteindre des terminaux en aval.

Cela fait du correctif le début de la réponse, et non sa conclusion. Une organisation peut fermer la vulnérabilité d’origine tout en laissant intacts les comptes, implants ou identifiants volés de l’attaquant.

La CISA place la vulnérabilité de BeyondTrust Remote Support sur un calendrier d’urgence

L’avertissement de la CISA transforme CVE-2026-102764, d’une décision de correctif ordinaire, en priorité active de réponse à incident.

BeyondTrust a divulgué publiquement la vulnérabilité le 15 octobre. La CISA l’a ajoutée au catalogue Known Exploited Vulnerabilities le lendemain, sur la base d’éléments attestant d’attaques actives.

L’alerte de correctif de l’agence vise les appliances Remote Support auto-hébergées. Ces systèmes nécessitent une action directe du client, sauf si les mises à jour automatiques ont déjà installé le correctif.

Remote Support 26.2.3 et les versions antérieures sont affectées. Les installations prises en charge exécutant les versions 24.3.1 à 26.2.3 peuvent recevoir le correctif BT26-05-RS. Les clients utilisant une version plus ancienne doivent effectuer une mise à niveau avant de l’appliquer.

BeyondTrust indique avoir appliqué le correctif à tous les environnements Remote Support software-as-a-service au 9 octobre. Cette distinction compte, car les systèmes auto-hébergés peuvent rester exposés jusqu’à ce que chaque opérateur finalise son propre processus de mise à jour.

Le catalogue Known Exploited Vulnerabilities de la CISA, couramment appelé KEV, identifie les failles que des attaquants ont exploitées en dehors des environnements de recherche. Les agences civiles fédérales doivent corriger les vulnérabilités répertoriées avant les échéances qui leur sont attribuées en vertu de la Binding Operational Directive 22-01.

Pour CVE-2026-102764, l’échéance fédérale était fixée au 19 octobre, soit seulement trois jours après son ajout au catalogue. Ce délai resserré reflète à la fois la gravité de la vulnérabilité et les conséquences de la compromission d’une appliance d’accès distant privilégié.

Les organisations hors du gouvernement fédéral ne sont pas soumises à cette directive. Toutefois, la CISA recommande à chaque organisation d’utiliser le catalogue pour définir ses priorités de gestion des vulnérabilités.

L’avis du fournisseur classe la faille comme une validation incorrecte de l’origine dans un composant de messagerie interne. En pratique, l’appliance ne vérifiait pas l’origine de certains messages.

Dans les bonnes conditions, un attaquant distant peut exploiter cette faiblesse pour effectuer des opérations sur des fichiers sans authentification ni interaction de l’utilisateur. Mandiant indique que des téléversements de fichiers arbitraires peuvent conduire au contrôle de l’hôte.

Ce scénario explique pourquoi des fenêtres de maintenance ordinaires ne conviennent pas ici. Un attaquant distant non authentifié n’a besoin ni d’identifiants valides, ni d’une victime de phishing, ni d’une session d’assistance existante pour commencer l’exploitation.

La CISA exige également un triage forensique des systèmes fédéraux concernés. Cette exigence reconnaît une limite cruciale du correctif : l’installation d’un logiciel corrigé ne révèle pas si un attaquant est entré avant la mise à jour.

Les organisations doivent d’abord confirmer leur version exacte de Remote Support et leur statut de correctif. Elles doivent également déterminer à quel moment l’appliance était accessible depuis internet et préserver les journaux couvrant toute cette période d’exposition.

L’attaque a commencé avant que les défenseurs disposent d’un correctif

La période dangereuse a débuté fin août, soit environ six semaines avant que la divulgation publique n’offre à chaque défenseur une voie de remédiation claire.

Mandiant a identifié une exploitation par ARMORY CASTLE, un groupe d’espionnage présumé lié à la Chine, auparavant suivi sous le nom UNC5221. L’enquête date l’activité zero-day observée au 29 août 2026.

Une vulnérabilité zero-day est exploitée avant que les organisations affectées disposent d’un correctif accessible publiquement. Ce calendrier a donné à l’attaquant un avantage qu’aucun programme de gestion des correctifs ne pouvait éliminer à l’avance.

BeyondTrust indique que l’acteur a compromis une instance Remote Support hébergée par l’entreprise et une appliance auto-hébergée le 29 août. L’entreprise n’a signalé aucune preuve d’activité adverse supplémentaire après ces deux cas connus au moment de la publication.

Ce chiffre décrit des incidents confirmés, et non le nombre maximal de systèmes affectés. D’autres compromissions peuvent ne pas disposer de preuves conservées, en particulier lorsqu’un attaquant peut supprimer les journaux de l’appliance.

Le processus de découverte montre également à quel point les signaux d’alerte peuvent se fragmenter. BeyondTrust a lancé une chasse aux menaces connexe après que l’exploitation impliquant un autre fournisseur de sécurité est devenue publique le 27 septembre.

Le 28 septembre, l’équipe de cyberdéfense de BeyondTrust a identifié des éléments impliquant son environnement hébergé. L’entreprise affirme avoir contenu cette instance dans les 27 minutes suivant la première détection.

Son équipe de sécurité produit a reproduit la méthode d’intrusion ce soir-là, tandis que l’ingénierie commençait à développer un correctif. Mandiant a partagé les conclusions de l’enquête menée chez le client auto-hébergé le 30 septembre.

BeyondTrust a diffusé le correctif aux clients hébergés et auto-hébergés le 8 octobre. L’entreprise indique que ses environnements Remote Support SaaS avaient reçu le correctif au 9 octobre.

La divulgation publique coordonnée a suivi le 15 octobre. Ce calendrier a laissé aux clients peu de temps pour appliquer le correctif avant que les rapports techniques n’accroissent la visibilité de la vulnérabilité.

Mais la divulgation publique déclenche une seconde course. Les attaquants peuvent exploiter un avis, un correctif et le comportement du produit pour étudier la faille, même lorsqu’un fournisseur ne communique pas d’instructions détaillées d’exploitation.

BeyondTrust a retenu les détails techniques de l’exploitation pendant que les clients mettent leurs systèmes à jour. Toutefois, la description publique de l’entreprise identifie toujours le composant vulnérable et la frontière de sécurité qui a échoué.

ARMORY CASTLE a déjà ciblé des équipements de périphérie de Citrix et Ivanti. Les équipements de périphérie se situent entre les réseaux externes et les ressources internes sensibles, ce qui en fait des points d’entrée attractifs pour les opérations d’espionnage.

Google Threat Intelligence Group s’attend à ce que l’acteur continue d’exploiter des vulnérabilités zero-day dans de tels produits. Son évaluation repose sur des campagnes répétées, des outils spécialisés et une connaissance détaillée des plateformes ciblées.

Le groupe est également passé d’un usage sélectif des zero-days à une exploitation plus large après que de précédentes vulnérabilités sont devenues publiques. Cet historique rend chaque appliance Remote Support restante non corrigée plus exposée après la divulgation.

Les incidents initiaux constituent donc un avertissement, et non une limite supérieure rassurante. Les défenseurs doivent supposer que d’autres groupes peuvent développer des méthodes d’exploitation indépendantes après avoir étudié les éléments publics.

L’accès aux fichiers est devenu un contrôle root et un mouvement latéral

Cette attaque était importante parce qu’une faille d’opération sur les fichiers est devenue une voie de l’internet public vers un contrôle privilégié sur des systèmes connectés.

La capacité initiale de la vulnérabilité paraît plus limitée que l’intrusion qui en a résulté. BeyondTrust décrit des opérations non autorisées sur des fichiers, tandis que Mandiant a observé des attaquants transformer cet accès en un point d’ancrage administratif durable.

Selon l’analyse de l’incident, ARMORY CASTLE a téléversé un webshell PHP personnalisé appelé SAWFLY. Un webshell est un script côté serveur qui permet à un attaquant d’exécuter des commandes par l’intermédiaire de requêtes web.

Les enquêteurs ont constaté que SAWFLY utilisait des communications chiffrées de commande et contrôle et renvoyait une fausse réponse 404 lorsque les requêtes ne comportaient pas le paramètre attendu. Ce comportement l’a aidé à éviter les analyses automatisées de base.

L’attaquant a créé SAWFLY environ 11 minutes après la première requête observée associée à l’exploitation. Il s’exécutait initialement via un compte de service aux privilèges plus limités sur l’appliance.

ARMORY CASTLE a ensuite copié un shell système et lui a attribué des permissions Set User ID. SUID est une permission Unix qui permet à un programme de s’exécuter avec les privilèges de son propriétaire plutôt qu’avec ceux de l’appelant.

Comme le shell copié appartenait à root, ce changement a créé une voie vers une exécution de niveau root. Cet accès plaçait le système d’exploitation, la configuration et les secrets stockés de l’appliance à la portée de l’attaquant.

Mandiant a observé des tentatives d’utilisation d’un utilitaire propriétaire de BeyondTrust afin d’extraire des identifiants de la base de données de secrets de l’appliance. L’acteur a essayé plusieurs formats de commandes tout en recherchant des données de coffre spécifiques à des comptes et globales.

Les enquêteurs ont également découvert un script de démarrage accordant au compte de service des privilèges root sans mot de passe. Le script modifiait un modèle de configuration et reconstruisait le fichier de permissions actif.

Cette conception importait, car un simple redémarrage ne l’aurait pas supprimée. Mandiant indique que la persistance pouvait également survivre à une réinitialisation de configuration, mettant à mal deux hypothèses courantes de récupération.

Les attaquants ne se sont pas arrêtés au contrôle de l’appliance. Ils ont utilisé des identifiants d’administrateur compromis pour entrer dans le portail administratif de Remote Support.

Ils ont modifié les permissions Jump Item et Team, passant de « No Access » à « Administrator ». Les Jump Items représentent des systèmes ou appareils mis à disposition pour l’accès distant via la plateforme BeyondTrust.

Cette modification des permissions a créé un accès d’apparence autorisée aux terminaux en aval. L’attaquant pouvait lancer des sessions distantes via les mêmes flux de travail que le personnel d’assistance de confiance utilise habituellement.

Mandiant a observé une session vers un terminal interne et l’utilisation de la fonction de transfert de fichiers de Remote Support. L’acteur a téléchargé des documents sensibles, y compris des informations d’inventaire logiciel, depuis l’environnement de bureau d’un utilisateur.

Le groupe a également déployé BARECLAW, un outil de tunneling personnalisé qui créait un proxy SOCKS5 sur du trafic WebSocket. Un proxy SOCKS5 relaie les connexions réseau et peut offrir un accès au-delà de l’hôte initialement compromis.

L’attaquant a modifié la configuration HAProxy de l’appliance pour exposer BARECLAW via un chemin de requête accessible depuis internet. HAProxy est le proxy inverse qui achemine le trafic entrant de l’appliance vers les services internes.

Cette configuration dissimulait le tunnelier derrière un service public attendu. Elle offrait également une voie permettant d’atteindre d’autres destinations réseau par l’intermédiaire de l’appliance compromise.

La vulnérabilité de BeyondTrust Remote Support a donc créé bien davantage qu’un problème isolé d’appliance. Elle a transformé un point de contrôle d’assistance de confiance en plateforme de vol d’identifiants, de persistance et de mouvement latéral.

Le correctif ne supprime pas un attaquant déjà présent

Une mise à jour réussie bloque toute nouvelle exploitation, mais elle ne révoque pas les identifiants volés ni n’efface la persistance créée avant son installation.

Cette distinction constitue le principal compromis de l’article. Les organisations doivent appliquer rapidement le correctif pour fermer le point d’entrée, mais la rapidité ne peut remplacer l’enquête nécessaire après une éventuelle exposition.

Pour les déploiements auto-hébergés pris en charge, les administrateurs doivent installer BT26-05-RS via l’interface de l’appliance. Ils doivent confirmer l’installation plutôt que supposer que les mises à jour automatiques se sont terminées avec succès.

Les systèmes antérieurs à la version 24.3.1 nécessitent une mise à niveau avant de pouvoir recevoir le correctif. La mise à niveau ne corrige la faille qu’après l’application de la mise à jour de sécurité suivante.

Toute appliance vulnérable accessible depuis Internet pendant la période d’exploitation doit faire l’objet d’un examen approfondi. Mandiant recommande de considérer ces systèmes comme potentiellement compromis jusqu’à ce qu’une analyse démontre le contraire.

La préservation des preuves doit précéder le redémarrage ou la reconstruction d’un système suspect. Les appliances virtuelles doivent être capturées avec les données mémoire et disque lorsque les procédures opérationnelles le permettent.

Les opérateurs d’appliances matérielles doivent coordonner la préservation des preuves avec le support BeyondTrust. Les clients ne peuvent pas inspecter de manière indépendante toutes les parties protégées du système de fichiers hôte de l’appliance.

Les journaux externes deviennent particulièrement importants, car les enquêteurs ont observé une suppression massive de journaux. L’attaquant a supprimé les enregistrements système, applicatifs, de serveur web et d’outils d’identification durant l’intrusion.

Les équipes de sécurité doivent examiner les données des pare-feux, des pare-feux d’applications web, des proxys inverses, des systèmes d’identité, des endpoints et de gestion des informations et événements de sécurité. Un SIEM collecte et corrèle de manière centralisée les événements de sécurité provenant de plusieurs systèmes.

BeyondTrust recommande d’envoyer les événements syslog et de session de l’appliance vers un SIEM externe en quasi temps réel. Les enregistrements hors appliance restent disponibles lorsqu’un attaquant supprime les preuves locales.

Les comportements utiles à rechercher incluent des connexions administratives depuis des adresses VPN résidentielles ou commerciales inconnues. Les défenseurs doivent également enquêter sur les scripts inattendus dans les répertoires web et les shells lancés par des comptes de service web.

Les modifications d’autorisations méritent une attention particulière, notamment celles impliquant les Jump Items, les Teams, les comptes API ou les politiques de session. Chaque modification doit correspondre à une demande approuvée et à un administrateur identifié.

Une interruption de la transmission des journaux externes peut également être significative. BeyondTrust met spécifiquement en évidence les interruptions qui commencent et se terminent au cours d’une même session administrative.

Les hachages de fichiers connus et les règles YARA peuvent aider à la recherche de menaces, mais ils ne peuvent pas fournir une assurance complète. Les règles YARA identifient des fichiers ou des contenus mémoire au moyen de motifs et de conditions définis.

BeyondTrust indique que l’acteur a modifié son infrastructure et ses outils d’une victime à l’autre. Une organisation qui ne trouve aucun des indicateurs publiés n’a pas prouvé que son appliance était restée saine.

Une compromission confirmée ou non résolue peut justifier une reconstruction à partir d’une image neuve et entièrement corrigée. Le nettoyage de fichiers individuels est moins fiable lorsqu’un attaquant a obtenu les privilèges root et modifié les mécanismes de persistance.

La rotation des identifiants doit suivre le confinement ou la reconstruction. Faire tourner les secrets alors qu’un attaquant contrôle encore l’appliance peut exposer immédiatement les identifiants de remplacement.

Le périmètre de rotation doit inclure les administrateurs de l’appliance, les comptes Remote Support, les secrets API, les comptes de liaison d’annuaire et les identifiants intégrés d’accès privilégié. Il doit également couvrir les identifiants saisis pendant les sessions de support concernées.

Les équipes doivent examiner les endpoints en aval accessibles via l’appliance. Les rapports de session et les historiques de transfert de fichiers peuvent montrer quels systèmes l’attaquant a consultés et quelles informations en sont sorties.

Une évaluation technique recommande également une correction d’urgence et une enquête sur toute compromission antérieure. Elle avertit que l’application du correctif seule ne supprime pas une persistance déjà établie.

L’accès distant auto-hébergé impose une charge de sécurité différente

L’incident révèle une distinction opérationnelle fondamentale : les services hébergés peuvent recevoir un correctif centralisé, tandis que les appliances auto-hébergées dépendent de milliers de décisions locales.

BeyondTrust indique que ses clients SaaS ont reçu la correction avant sa divulgation publique. Les clients auto-hébergés doivent vérifier leurs versions, leurs chemins de mise à jour, leurs paramètres de mise à jour automatique et l’état réel des correctifs.

L’auto-hébergement peut offrir un contrôle direct des données, du réseau et de la maintenance. Il transfère également au client une responsabilité accrue concernant la correction rapide, la surveillance, la préservation des preuves et la reprise.

Cette responsabilité devient difficile lorsqu’une plateforme d’accès distant prend en charge des opérations essentielles. Isoler l’appliance peut interrompre le travail du support technique, l’assistance des fournisseurs et l’administration à distance dans toute l’organisation.

Les attaquants tirent parti de cette hésitation. Chaque heure consacrée à négocier une interruption de service peut préserver leur possibilité d’exploiter un système exposé à Internet.

L’équipe de sécurité a donc besoin d’un plan opérationnel avant la prochaine urgence. Ce plan doit identifier qui peut autoriser l’isolement, comment le support se poursuit et où les données forensiques seront stockées.

Les appliances d’accès distant créent également un risque concentré, car elles connectent intentionnellement des utilisateurs externes à des systèmes internes. Elles peuvent stocker des identifiants, injecter des secrets, maintenir des agents sur les endpoints et courtiser des sessions privilégiées.

La compromission d’une telle plateforme peut contourner les contrôles déployés ailleurs. La session malveillante peut passer par un produit approuvé et utiliser les autorisations associées à un administrateur légitime.

Ce schéma n’est pas propre à BeyondTrust. ARMORY CASTLE a précédemment exploité des vulnérabilités de Citrix NetScaler et Ivanti Connect Secure, selon les chercheurs en menaces de Google.

Ces produits diffèrent par leur conception et leur objectif, mais ils occupent une position stratégique à la frontière du réseau. Ils traitent des accès de confiance tout en restant accessibles depuis des réseaux externes.

Cette combinaison a fait des systèmes de périphérie une cible récurrente pour les opérations d’espionnage et criminelles. Les outils traditionnels de protection des endpoints peuvent avoir une visibilité limitée sur des appliances renforcées dont l’accès hôte est restreint.

Le cas BeyondTrust ajoute une autre difficulté. Un attaquant peut utiliser les propres fonctions de session distante et de transfert de fichiers du produit après avoir obtenu le contrôle administratif.

L’activité créée via des fonctions natives peut ressembler à un travail de support légitime. La détection doit donc prendre en compte l’identité, le moment, les réseaux sources, les changements d’autorisations et les tickets de service associés.

Les organisations doivent limiter les interfaces d’administration aux réseaux de confiance ou aux adresses approuvées. L’exposition publique doit être limitée aux services précis nécessaires aux clients et au personnel de support.

L’accès réseau sortant mérite également d’être contrôlé. Une appliance de support à distance ne doit atteindre que les services nécessaires de mise à jour, de licence, de journalisation, d’annuaire et d’intégration.

Un filtrage sortant avec refus par défaut peut limiter le tunneling et le trafic de commande et de contrôle. Il crée également des alertes utiles lorsque l’appliance contacte une destination inattendue.

L’accès administratif doit exiger une authentification multifacteur résistante au phishing lorsque celle-ci est prise en charge. Les comptes locaux doivent être réduits au minimum, et tout compte d’urgence doit être protégé et surveillé.

Ces contrôles ne remplacent pas BT26-05-RS. Ils réduisent le rayon d’impact lorsqu’une vulnérabilité contourne entièrement la première couche d’authentification.

Les clients Privileged Remote Access doivent également être attentifs. BeyondTrust indique que PRA partage le code concerné, bien que ses tests n’aient pas identifié de voie d’exploitation fonctionnelle dans ce produit.

L’entreprise a publié un correctif PRA par précaution et conseillé aux clients auto-hébergés de l’installer. Il s’agit d’une recommandation fondée sur le risque, et non d’une confirmation que les attaques observées ont compromis PRA via CVE-2026-102764.

Un périmètre clair est important lors d’une réponse urgente. Les équipes ne doivent pas présenter une exploitation non vérifiée de PRA comme un fait établi, mais elles ne doivent pas non plus ignorer le code vulnérable partagé.

Ce que les défenseurs doivent surveiller après CVE-2026-102764

La prochaine épreuve consistera à déterminer si l’adoption des correctifs dépasse l’exploitation plus large et si les enquêtes révèlent des intrusions dissimulées avant la divulgation.

Le premier signal est l’état des correctifs des appliances Remote Support auto-hébergées. Les équipes de sécurité doivent suivre l’installation vérifiée, et pas seulement les demandes de changement approuvées ou les maintenances planifiées.

Une population exposée en diminution réduirait les possibilités pour les attaquants qui copient la campagne initiale. La visibilité continue sur Internet de systèmes non corrigés renforcerait les attentes d’exploitation opportuniste.

Le deuxième signal est l’émergence de nouveaux comportements d’attaquants. Mandiant a documenté SAWFLY, BARECLAW, la manipulation des autorisations, la suppression de journaux et l’abus de sessions de support.

D’autres groupes n’ont pas besoin de réutiliser exactement ces outils. De nouveaux webshells, chemins de requête, comptes ou méthodes de tunneling montreraient que l’exploitation a dépassé un seul opérateur connu.

Les défenseurs doivent donc rechercher des séquences comportementales plutôt que des indicateurs exacts uniquement. Une création de fichier inattendue suivie de changements de privilèges et de sessions administratives est plus durable qu’un simple nom de fichier.

Le troisième signal est ce que les analyses forensiques révèlent sur la période précédant la divulgation. Des cas supplémentaires remontant à août ou septembre élargiraient la fenêtre d’exposition connue et la population affectée.

Ces preuves pourraient apparaître lentement. Les journaux des appliances peuvent être incomplets, et l’accès en aval peut se fondre dans l’activité de support ordinaire.

Les organisations doivent conserver les enregistrements pertinents pendant la poursuite des enquêtes. De courtes périodes de conservation des journaux peuvent effacer les preuves nécessaires pour distinguer une tentative d’exploitation d’une intrusion réseau complète.

L’incident soulève également des questions sur le triage automatisé des alertes. BeyondTrust a indiqué que ses capteurs avaient détecté une élévation de privilèges suspecte, mais qu’un système tiers avait classé les alertes comme faux positifs.

Les équipes de sécurité doivent conserver et examiner périodiquement les alertes rejetées par des systèmes automatisés. Un verdict de faible confiance ne doit pas retirer définitivement un comportement inhabituel de l’appliance du périmètre de recherche de menaces.

Le catalogue KEV demeure un signal important de priorisation, mais l’inclusion au catalogue ne doit pas déclencher le chronomètre. Des preuves confirmées d’un fournisseur ou d’une réponse à incident peuvent justifier une action avant que CISA ne publie une entrée.

Le même principe s’applique après l’application d’un correctif. Une analyse de vulnérabilités au vert confirme que le logiciel est corrigé, non que l’environnement est sain.

Pour les organisations qui exploitent BeyondTrust Remote Support, l’action immédiate est claire : vérifier le correctif BT26-05-RS et documenter le résultat. Les installations plus anciennes doivent être mises à niveau avant de recevoir la correction.

Ensuite, déterminez si l’appliance était accessible de l’extérieur alors qu’elle était vulnérable. Préservez les journaux hors appliance, examinez les changements administratifs et retracez chaque session de support suspecte jusqu’aux systèmes qu’elle a atteints.

Si la compromission ne peut être exclue, impliquez le support BeyondTrust et une équipe de réponse à incident. Reconstruisez les appliances douteuses, faites tourner les identifiants exposés et inspectez les endpoints atteints par leur intermédiaire.

La vulnérabilité BeyondTrust Remote Support constitue en définitive un test de deux vitesses de réponse. L’une corrige la faille, tandis que l’autre détermine ce qui s’est produit avant cette correction.

Les organisations qui n’accomplissent que la première tâche restent exposées aux conséquences de la seconde. Votre équipe vérifie-t-elle un correctif ou prouve-t-elle qu’un système d’accès de confiance est resté digne de confiance ?