Quand ChatGPT peut envoyer des messages, le SMS n’est plus hors bande : le playbook sécurité du CTO

Votre produit traite encore le SMS et l’email comme des canaux de contrôle « hors bande ». Cette hypothèse vient de tomber. ChatGPT peut désormais envoyer des messages via Apple Messages. Les assistants lisent déjà les notifications, parcourent les boîtes de réception et suivent des instructions entre applications. Si un agent peut voir et envoyer le message, ce n’est plus hors bande — c’est de l’en‑bande automatisé avec une nouvelle surface d’attaque.

Si vous attendiez un geste fort d’un grand fournisseur avant de déprécier la 2FA par SMS et les approbations par email, le voilà. Dans ce billet, je vous propose un cadre de décision concret pour inventorier où vous dépendez du « hors bande », évaluer votre exposition maintenant que les assistants peuvent envoyer des messages, et livrer en un trimestre un modèle d’authentification et d’autorisation plus sûr.

Ce qui a changé : SMS et email sont désormais automatisables par défaut

Deux signaux pertinents sont arrivés récemment :

• ChatGPT a gagné une intégration Apple Messages. C’est un accès grand public, au niveau de l’OS, à un canal que la plupart des apps grand public considèrent encore fiable pour les OTP et les approbations.
• On peut amener des assistants à exfiltrer des données même lorsque des filtres « devraient » les bloquer — y compris via des injections de consignes obfusquées ou chiffrées. Si un modèle suit des instructions malveillantes, votre code soi‑disant hors bande n’est qu’un jeton de plus à copier‑coller.

Ajoutez à cela des années d’évolutions de plateformes — aperçus d’OTP sur écran verrouillé, synthèse de notifications, « smart reply » email, synchronisation multi‑appareils — et la frontière de sécurité que vous pensiez avoir autour du SMS et de l’email n’a jamais vraiment tenu. Désormais, elle est complètement poreuse.

Mise à jour du modèle de menace : du second facteur humain à un canal scriptable

Voici comment vos contrôles actuels se dégradent en présence d’assistants au niveau de l’OS capables de lire et d’envoyer des messages :

• OTP par SMS : les agents peuvent lire les aperçus de notifications, les messages complets et, dans certains cas, répondre sans intervention de l’utilisateur. Assistant compromis = OTP récolté.
• Liens magiques par email : si un assistant gère votre boîte, « cliquer sur le lien » devient une automatisation triviale. Les heuristiques qui bloquent les clics ne vous protégeront pas d’une automatisation de première partie.
• Rappels téléphoniques/IVR : avec la synthèse vocale et les API d’appel, des agents peuvent passer et naviguer des appels. L’identifiant d’appelant se falsifie ; la « vérification vocale » ne vaut rien face aux voix clonées.
• Approbations par push : si votre push se résume à « Approuver/Refuser », un agent ayant accès aux notifications peut appuyer sur Approuver plus vite que votre utilisateur ne s’en aperçoit.

Les recommandations de sécurité vous avaient déjà averti. NIST SP 800‑63B classe le SMS pour les OTP comme restreint en raison des risques de SIM swap, d’interception et de malware. Et c’était avant que des assistants ne puissent relayer des messages en votre nom. Aujourd’hui, SMS et email ne sont que du transport de processus — et tout ce qui peut piloter ce transport peut piloter vos contrôles.

Cadre de décision : tuez les hypothèses hors bande en 4 étapes

1) Recensez où vous dépendez du « hors bande »

Faites une liste à deux colonnes avec propriétaire métier et propriétaire technique. Vous cherchez tout endroit où un acteur hors de votre session authentifiée peut déclencher un changement sensible à la sécurité :

• Authentification : OTP par SMS, OTP par email, liens magiques par email, rappels téléphoniques, TOTP d’app d’authentification.
• Autorisation : approbations de paiement, ajout de bénéficiaire, rotation de clés, changements de rôles, enrôlement d’appareil, confirmations d’export de données.
• Support/Récupération : réinitialisations de mot de passe par email ou SMS, déverrouillage de compte via ticket téléphonique, re‑vérification KYC via lien envoyé par email.

Pour chacun, notez le(s) canal(aux), le(s) parcours de repli, et l’artéfact affiché à l’utilisateur (OTP, lien, bouton d’approbation, etc.). Attendez‑vous à trouver 12 à 30 parcours distincts dans un SaaS B2C typique ; moins en B2B mais avec un rayon d’impact plus élevé.

2) Classez le contrôle du canal et l’exposition aux assistants

Scorez chaque flux sur trois dimensions (Élevé/Moyen/Faible) :

• Visibilité par l’assistant : un assistant OS grand public peut‑il le lire par défaut ? (OTP sur écran verrouillé, aperçu email, intégration Messages, contenu de notification.)
• Actionnement par l’assistant : un assistant peut‑il envoyer/valider/répondre dans ce canal ?
• Force de vérification utilisateur : l’utilisateur prouve‑t‑il la possession d’une clé privée dans un matériel sécurisé, ou répond‑il simplement à un défi que n’importe quelle app peut voir ?

Si un flux a une visibilité Élevée + un actionnement Moyen/Élevé + une vérification Faible, considérez‑le comme compromis. Tout argument du type « mais il faut que l’utilisateur appuie » est obsolète dès lors qu’un modèle peut appuyer.

3) Choisissez un remplacement cryptographique, pas un autre canal

Remplacez la confiance dans le canal par la confiance dans la clé. Vos options :

• WebAuthn (FIDO2) avec clés résidentes : adossé au matériel, résistant au phishing, fonctionne sur desktop et mobile. Utilisez credProtect et exigez la vérification utilisateur (UV) requise. Préférez les authentificateurs plateforme liés à l’appareil aux clés itinérantes pour les parcours grand public ; autorisez les clés itinérantes pour les administrateurs.
• Attestation liée à l’app pour les approbations : sur mobile, utilisez Apple App Attest et Android Play Integrity pour attester votre app ; dans l’app, effectuez une signature de transaction avec le « ce que vous signez » en clair (montant, bénéficiaire, action) affiché et lié à une signature. Hors du navigateur, utilisez les éléments sécurisés fournis par l’OS (Secure Enclave/StrongBox) via les API de plateforme.
• Push avec défi cryptographique par transaction : si vous devez utiliser le push, n’envoyez jamais un « Approuver » aveugle. Envoyez un défi signé incluant les champs critiques et exigez en retour une assertion adossée au matériel. Stockez et auditez les assertions.

Ne remplacez pas le SMS par l’email ou l’inverse. Vous ne luttez pas contre la fiabilité des canaux. Vous éliminez totalement la confiance accordée au canal.

4) Éliminez progressivement les parcours de repli qui réintroduisent la faille

La plupart des compromissions surviennent via le parcours de repli le moins résistant : « Ça n’a pas marché ? Utilisez le SMS. » Supprimez‑les ou mettez‑les sous contrôle :

• Supprimez le SMS en repli là où vous déployez WebAuthn. Si vous devez le garder pour une minorité, isolez ces utilisateurs dans un palier de risque restreint avec des limites de transaction plus basses.
• Retirez les liens magiques par email pour les rôles admin et les comptes à forte valeur. Imposez WebAuthn ou la signature in‑app.
• Remplacez la récupération par téléphone par des kits de récupération vérifiés : codes de récupération à usage unique pré‑générés et stockés hors ligne, ou identifiants FIDO secondaires enrôlés à l’avance.

Modifications de design à réaliser ce trimestre

Authentification

• Faites de WebAuthn le premier facteur par défaut pour les nouvelles inscriptions. Cessez de le traiter comme un réglage « avancé ». Ne stockez que des identifiants avec vérification utilisateur (UV = requis). Testez les passkeys synchronisées entre appareils et proposez une option de refus pour les rôles à haute assurance qui exigent des passkeys liées à l’appareil uniquement.
• Contrôlez les OTP hérités avec la posture de l’appareil : si un OTP apparaît (utilisateurs existants), exigez des signaux d’appareil supplémentaires (App Attest/Play Integrity) et une liaison de session avant de l’accepter.
• Bloquez les OTP dans les notifications : pour les apps mobiles que vous contrôlez, supprimez le contenu OTP des notifications. Ce n’est pas une correction, mais cela réduit la collecte opportuniste.

Autorisation (approbations et step‑up)

• Signature de transaction, pas oui/non : affichez l’action exacte (ex. « Payer 4 200 $ à ACME LLC, US‑123456789, aujourd’hui ») et exigez une signature adossée au matériel sur cette charge utile. Conservez‑la. Rendez‑la visible dans la piste d’audit.
• Les changements de rôles et permissions exigent WebAuthn ou une signature in‑app. N’approuvez jamais via un lien envoyé par email.
• L’export de données exige un step‑up cryptographique et un jeton à usage unique, de courte durée, lié à la session et à l’appareil.

Support et récupération

• Kits de récupération à l’épreuve des agents : fournissez 8 à 12 codes de récupération à usage unique imprimables lors de l’enrôlement. Autorisez l’enrôlement de 2 à 3 identifiants FIDO secondaires. Désactivez totalement la réinitialisation par SMS après la mise en place réussie des passkeys.
• Aucune approbation par email/téléphone : le support ne peut initier qu’un flux de récupération in‑app attesté. Si un utilisateur n’a que l’email, imposez une période de refroidissement (24–72 heures) avant de réactiver l’accès.
• Les changements à haut risque exigent deux clés différentes (p. ex., deux admins, ou admin + conformité), pas deux canaux.

« Mais les régulateurs exigent du hors bande » — lisez les petites lignes

De nombreuses normes mentionnent le « hors bande » comme mitigation. Peu exigent que ce soit le SMS ou l’email en 2026. Ce que les auditeurs veulent, c’est une vérification indépendante et la preuve d’altération :

• PCI DSS, FFIEC et SOX se soucient que l’approbateur soit bien l’approbateur et que vous puissiez le prouver plus tard. WebAuthn adossé au matériel avec UV, plus des signatures spécifiques à chaque transaction et des journaux immuables, répond au principe mieux que le SMS ne l’a jamais fait.
• NIST SP 800‑63B décourage explicitement le SMS OTP comme facteur de haute assurance. Utilisez‑le pour justifier votre plan de migration.

Si un régulateur particulier assimile encore « hors bande » à « envoyer un SMS », documentez pourquoi ce canal est désormais automatisable et proposez un hors bande cryptographique : un second appareil attesté indépendamment avec une clé distincte, ou un second administrateur avec un identifiant séparé.

Détection et réponse : supposez que des assistants sont dans la boucle

Même avec des contrôles cryptographiques, vous devez repérer des schémas d’abus compatibles avec une médiation par assistant :

• Empreintes compatibles avec des flux pilotés par assistant : approbations quasi instantanées et répétées après livraison de la notification ; profils de vitesse de curseur/de gestes identiques ; cadence 24/7 atypique.
• Signatures de sortie d’agent : plages d’IP d’assistants connues, empreintes TLS ou motifs de referer. Ne bloquez pas en bloc, mais scorez le risque et exigez un step‑up.
• Appât via charge utile chiffrée : si l’assistant d’un utilisateur reçoit l’instruction de déchiffrer ou transférer des données, vous verrez des salves de copier‑coller. Limitez en débit les tentatives d’OTP et atténuez les aperçus sur l’écran verrouillé.

Implémentez des déclencheurs dans vos services d’authentification et d’approbation : quand des signaux suspects s’allument, rétrogradez les sessions et imposez un contrôle WebAuthn avec vérification utilisateur avant de traiter des actions sensibles.

Gouvernance : votre piste d’audit doit enregistrer le « quoi » que vous avez signé

Les audits qui disent « Utilisateur a approuvé à 10:03 » ne valent rien en cas de litige. Conservez :

• La charge utile canonique exacte vue par l’utilisateur (montant normalisé, devise, identifiant de contrepartie),
• L’appareil/l’app attesté qui l’a affichée,
• La signature cryptographique sur cette charge utile et le handle de clé/ID d’identifiant,
• Toute délégation ou le contexte de double approbation.

Mettez cela derrière un journal en écriture unique (WORM ou stockage append‑only) et faites de la récupération une fonctionnalité produit de premier plan pour votre équipe risque. Cela transforme les post‑mortems de séances de blâme en triages fondés sur des preuves.

Plan 30‑60‑90 jours

Jours 0–30 : arrêter l’hémorragie

• Désactivez les aperçus d’OTP sur écran verrouillé dans vos apps mobiles ; retirez le contenu OTP des notifications.
• Livrez WebAuthn pour tous les utilisateurs en option visible et recommandée ; rendez‑le obligatoire pour les employés et les administrateurs.
• Supprimez les approbations par lien email pour les actions admin. Exigez une confirmation in‑app avec WebAuthn.
• Instrumentez les comportements de type assistant dans les logs d’auth ; ajoutez des déclencheurs simples et une revue manuelle pour les événements de grande valeur.

Jours 31–60 : remplacez, ne colmatez pas

• Faites de WebAuthn le défaut à l’inscription et lors des événements de re‑authentification. N’offrez une courte période de grâce par SMS que lorsqu’inévitable, avec des privilèges plafonnés.
• Implémentez la signature de transaction sur mobile et web pour les paiements, l’export de données, la rotation de clés et les changements de rôles.
• Lancez les kits de récupération et l’enrôlement d’identifiants secondaires. Supprimez les réinitialisations par téléphone pour le personnel/admins.

Jours 61–90 : brûlez les amarres

• Retirez l’OTP par SMS des marchés et rôles à haut risque. Là où c’est imposé, isolez‑le dans un domaine de politique séparé avec des limites réduites et une surveillance renforcée.
• Activez les clés résidentes avec UV requis et bloquez les identifiants sans UV pour les parcours grand public.
• Finalisez le stockage d’audit pour les charges utiles signées avec des propriétés WORM et une récupération en self‑service pour risque/conformité.

Arbitrages à assumer

• Un peu de friction aujourd’hui pour moins d’incidents demain. L’enrôlement WebAuthn ajoute une minute à l’onboarding. C’est moins cher qu’une prise de contrôle de compte facilitée par le support.
• Passkeys liées à l’appareil vs synchronisées. Liées à l’appareil est plus fort mais augmente le risque de verrouillage. Pour les consommateurs, autorisez des passkeys synchronisées avec une récupération solide ; pour les admins, préférez les passkeys liées à l’appareil.
• Déplacement des coûts de support. Vous gérerez plus de flux de kits de récupération et de clés secondaires. Formez le support et exposez des parcours en self‑service. Le coût net de fraude baisse quand même.
• Partenaires legacy. Certains fournisseurs fintech et identité poussent encore les flux SMS. Escaladez maintenant ou préparez une sortie. Vos utilisateurs ne devraient pas hériter de la posture de risque de votre fournisseur.

Et le B2B ? Vos admins sont les joyaux de la couronne

Même si votre produit n’est pas orienté grand public, vos admins peuvent approuver des modifications de domaine SSO, des rôles SCIM, des portées de jetons API et exporter des données clients. Traitez toutes les approbations admin comme des événements de signature, pas des clics. Imposez WebAuthn avec des clés à UV requis, un double contrôle pour les changements irréversibles et une liaison de session à des appareils attestés.

Brazil/LatAm : n’attendez pas les opérateurs

Si vous servez l’Amérique latine, vous savez déjà que la délivrabilité SMS et la sécurité des SIM varient selon le marché. C’était autrefois un casse‑tête opérationnel ; c’est désormais un passif de sécurité. La bonne nouvelle : WebAuthn fonctionne partout sur iOS et Android, et les clés adossées au matériel sont omniprésentes. Des équipes nearshore peuvent vous aider à refondre vos flux sans douleur de fuseau horaire (6–8 heures de recouvrement avec les US), mais la direction architecturale reste la même : cryptographie plutôt que canaux.

La nouvelle règle

Si un assistant peut le voir ou l’envoyer, c’est en bande. Et c’est très bien — tant que ce qui pilote votre sécurité n’est pas le canal mais la clé. Déplacez vos contrôles là‑bas, prouvez ce qui a été signé, et vous vous ficherez de qui lit la boîte de réception.

Points clés

• Les assistants d’OS peuvent lire et envoyer des SMS et des emails. Les SMS/emails ne sont plus hors bande — traitez‑les comme de l’en‑bande automatisable.
• Remplacez la confiance canal par la confiance clé : WebAuthn avec des clés résidentes à UV requis et une signature explicite de transaction.
• Supprimez les parcours de repli qui réintroduisent le risque (SMS, liens email, approbations par téléphone), ou isolez‑les avec des limites strictes et une surveillance renforcée.
• Stockez les charges utiles signées « ce que vous avez approuvé » avec des propriétés WORM pour des audits recevables comme preuves.
• Détectez les comportements de type assistant et exigez un step‑up cryptographique sur les flux suspects.
• Les régulateurs veulent indépendance et assurance, pas spécifiquement du SMS. Les approbations cryptographiques répondent mieux à l’intention que le hors bande legacy.