Sécurité du transport e-mail : la preuve NIS2 la moins chère qu'un fournisseur du Mittelstand puisse produire

Un équipementier industriel allemand de 180 salariés n’est pas directement dans le périmètre de NIS2. Ses clients le sont, et cela suffit.

L’article 21(2)(d) de NIS2 oblige les entités essentielles et importantes à gérer le risque de la chaîne d’approvisionnement, y compris la sécurité de leurs fournisseurs directs. La conséquence pratique descend la chaîne sous forme de questionnaire, d’annexe à un renouvellement de contrat, ou de demande de preuve assortie d’une échéance.

La plupart des fournisseurs dans cette situation affrontent le même problème : une demande de conformité réelle, aucune équipe sécurité, aucune ligne budgétaire pour en créer une. Le bon réflexe est de chercher les contrôles au meilleur rapport preuve démontrable sur effort.

La sécurité du transport e-mail en est l’exemple le plus net en 2026.

Pourquoi ce contrôle précisément

Quatre propriétés le rendent inhabituel.

Il est bon marché. Deux enregistrements DNS et un fichier statique sur n’importe quel hébergement HTTPS. Un après-midi, pas un projet.

Il est vérifiable de l’extérieur. L’équipe sécurité de votre client le confirme elle-même avec une commande, sans appel, sans avoir à vous croire. Une preuve qui n’exige pas de confiance vaut démesurément plus dans une évaluation fournisseur.

Il se mappe proprement. NIS2 article 21(2)(h) cryptographie, ISO/IEC 27001:2022 A.8.24 et A.5.14, et BSI TR-03108 en contexte de supervision allemande.

Presque personne ne l’a. Les mesures publiées situent l’adoption de MTA-STS sur le million de domaines les plus visités sous un pour cent. Les contrôles à la fois bon marché et rares sont inhabituels, et celui-ci en est un.

Le trou qu’il comble

SPF, DKIM et DMARC sont largement déployés et largement pris à tort pour une couverture générale de la sécurité e-mail. Ils authentifient l’expéditeur : ils empêchent quelqu’un d’envoyer du courrier paraissant venir de votre domaine.

Ils ne chiffrent rien. SMTP négocie le chiffrement par une annonce STARTTLS qui n’est elle-même pas authentifiée, donc un attaquant placé sur le chemin réseau peut la retirer et forcer une remise en clair. DMARC passe toujours. Le courrier est simplement lisible en transit.

Pour un fournisseur qui échange plans, spécifications, tarifs et contrats par e-mail, c’est l’exposition de confidentialité qui compte, et c’est celle que personne n’a mesurée.

Le déploiement

Deux enregistrements DNS :

_mta-sts.votredomaine.de.   IN TXT "v=STSv1; id=20261001120000"
_smtp._tls.votredomaine.de. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Un fichier, servi sur https://mta-sts.votredomaine.de/.well-known/mta-sts.txt :

version: STSv1
mode: testing
mx: mail.votredomaine.de
max_age: 604800

Le sous-domaine a besoin d’un certificat valide, que tout hébergement statique fournit. Les tenants Microsoft 365 indiquent le motif *.mail.protection.outlook.com dans le champ mx.

Notez mode: testing. Commencez là, lisez les rapports TLS-RPT deux à quatre semaines, corrigez ce qu’ils révèlent, puis changez un mot pour enforce.

Le piège à nommer

mode: testing signale les échecs et délivre le courrier quand même. Un domaine laissé en test a l’apparence du contrôle et aucune protection.

C’est l’issue la plus fréquente, parce que personne ne planifie la bascule. Posez la date dans un agenda au moment du déploiement, pas après. Si un client demande dans quel mode vous êtes et que la réponse est testing, la réponse honnête est la date de bascule en enforce, pas une affirmation vague.

Ce qu’il faut envoyer au client

Une réponse fournisseur qui pèse ressemble à ceci :

Le transport du courrier entrant est protégé par MTA-STS (RFC 8461) en mode enforce, imposant aux serveurs émetteurs un TLS authentifié. Cela traite le déclassement STARTTLS, que SPF, DKIM et DMARC ne couvrent pas, puisqu’ils authentifient l’expéditeur et non la connexion. TLS-RPT (RFC 8460) est actif et les rapports quotidiens sont examinés.

Vérifiable indépendamment : dig TXT _mta-sts.votredomaine.de curl https://mta-sts.votredomaine.de/.well-known/mta-sts.txt

Mappage : NIS2 art. 21(2)(h), ISO/IEC 27001:2022 A.8.24 et A.5.14, BSI TR-03108.

Court, précis, vérifiable. Cela démontre que vous comprenez une distinction que le questionnaire lui-même manque généralement, et cette impression se propage au reste de l’évaluation.

Ce qui vient ensuite

Une fois cela en ligne, la même logique à l’échelle d’un après-midi s’applique à deux autres contrôles tout aussi bon marché et tout aussi rares :

• HSTS avec préchargement, s’il n’est pas déjà en place.
• Accord de clés hybride post-quantique, une ligne sur la terminaison TLS, qui pré-répond à une question que les clients régulés commencent à poser.

DANE est le contrôle e-mail le plus fort et exige DNSSEC sur votre zone. Traitez-le comme le projet suivant, et non comme une raison de retarder la paire déployable maintenant.

Où cela s’inscrit dans l’obligation générale

Les demandes de preuve sur la chaîne d’approvisionnement ne s’arrêteront pas à l’e-mail. Ce que la clause de chaîne d’approvisionnement exige réellement des fournisseurs.

Le principe général à retenir : privilégiez les contrôles dont la preuve est une observation plutôt qu’une affirmation. Une mesure datée et reproductible indépendamment ne coûte rien à vérifier pour votre client, et c’est précisément pourquoi elle le satisfait plus vite qu’un document de politique.

En résumé

Deux enregistrements DNS, un fichier, un après-midi. Commencez en test, lisez les rapports, passez en enforce.

Le résultat est une preuve NIS2 vérifiable de l’extérieur dans un domaine de contrôle où presque aucun fournisseur concurrent n’a quoi que ce soit à montrer.