VG Düsseldorf (02/04/2026) : le chiffrement transport peut suffire

Résumé — Le 2 avril 2026, le tribunal administratif de Düsseldorf (VG Düsseldorf) a jugé que, pour l’email, un chiffrement « en transit » correctement gouverné peut répondre à l’article 32 RGPD, sans imposer systématiquement le chiffrement de bout en bout. L’enjeu pratique : comment l’implémenter et en apporter la preuve, notamment sous CSSF 22/806.

Les faits

Le tribunal administratif de Düsseldorf (VG Düsseldorf) a rendu, le 2 avril 2026 (affaire 29 K 7351/23), un jugement commenté par la revue juridique MIR. Le tribunal y examine le « niveau de protection adéquat » au sens de l’article 32 RGPD lors de la transmission de données personnelles par courriel. Il retient qu’un chiffrement de transport (TLS) correctement déployé peut être suffisant en l’état des risques, et que le chiffrement de bout en bout n’est pas automatiquement requis dans tous les cas. La motivation souligne l’analyse de risque (gravité/probabilité), l’état de l’art et le contexte du traitement ; dans l’espèce, exiger l’E2E n’était pas proportionné. Source : MIR — VG Düsseldorf, 02.04.2026, 29 K 7351/23 (renvoi dejure.org — Art. 32 DSGVO).

Pourquoi c’est structurant pour les dirigeants au Luxembourg ? Parce que l’article 32 RGPD est directement applicable et que, dans les secteurs régulés (banque, PSF, assurances, fonds), il faut démontrer par la technique et par la preuve la sécurité des échanges — y compris en cloud — selon la CSSF 22/806 et le cadre DORA. Cette décision précise quand le « transport » bien gouverné suffit et quand l’E2E s’impose.

Le cadre légal applicable

• RGPD — Article 32 : exige des « mesures techniques et organisationnelles appropriées » tenant compte de l’état de l’art, des coûts, de la nature/portée, et des risques. Le chiffrement est cité comme mesure possible. Texte consolidé : EUR‑Lex — RGPD, art. 32.
• VG Düsseldorf (02/04/2026) : en contexte email, un chiffrement de transport peut satisfaire l’article 32 si le risque résiduel est maîtrisé ; l’E2E n’est pas exigé « par principe ». Source : MIR.
• Luxembourg (secteur financier) — CSSF 22/806 : pour les externalisations TIC et le cloud, impose évaluation/contrôle du niveau de sécurité (chiffrement, gestion de clés, journalisation, preuves), avec alignement DORA depuis 17/01/2025. Référence : CSSF — Circulaire 22/806 (mod. 25/883) et version PDF (FR). Guidance : CNIL — Chiffrement dans le cloud public.

Conséquence : l’« obligation technique » n’est pas monolithique. Le juge attend une démonstration proportionnée : 1) politique de classification ; 2) contrôles de transport email à l’état de l’art ; 3) E2E lorsque les risques/volumétries/contenus l’exigent (santé, M&A, investigations sensibles) ; 4) preuves d’effectivité (journaux, rapports de tests, contrôles récurrents). Un pilotage cyber par un CISO externalisé aide à formaliser ces critères et à les faire valider par le DPO.

Architecture technique de référence

1) Chiffrement « en transit » (email)

• Forcer TLS entre MTA sortants/entrants : STARTTLS obligatoire, ciphers modernes (TLS 1.2/1.3), PFS, désactivation des suites obsolètes.
• MTA‑STS (policy « enforce ») + TLS‑RPT pour surveiller les échecs de négociation TLS à l’échelle du domaine.
• DANE for SMTP (DNSSEC) quand possible, pour authentifier les serveurs de destination.
• DMARC/SPF/DKIM pour l’authenticité et la réduction du phishing.
• Journalisation : logs d’établissement TLS, taux d’envoi chiffré, échecs, alertes corrélées (SIEM).

2) Chiffrement « at‑rest » et gestion des clés

• Stockages (boîtes, archives, sauvegardes) : chiffrement AES‑256 côté serveur, rotation des clés, séparation des rôles, KMS/HSM.
• Cloud (CSSF 22/806) : choisir un modèle de détention de clés (provider‑managed, customer‑managed keys, customer‑supplied keys, ou client‑side encryption) adapté au risque et aux contraintes réglementaires. Voir les pratiques CNIL.

3) Chiffrement de bout en bout (par exception)

• S/MIME v3.2 ou OpenPGP, au client ou via gateway E2E, pour des classes d’information prédéfinies : santé, secrets d’affaires, juridique sensible, RH très confidentiel.
• Politiques data‑aware : déclenchement E2E par mots‑clés/étiquettes/classification (DLP) et approbations métier.

4) Gouvernance et preuves

• Politique de classification + matrice de décision « transport vs E2E » avec critères objectifs (gravité/probabilité/volume/partenaires).
• Tests récurrents (CIS Controls 14, ISO 27001 Annexe A – A.8.24, A.8.25) : vérif TLS, rapports MTA‑STS/TLS‑RPT, scans DANE, revues de ciphers.
• Conformité cloud (CSSF 22/806) : fiches d’externalisation, clauses chiffrement/clefs, preuves KMS/HSM, revues de key custody, pistes d’audit. Voir aussi le cadre DORA et résilience opérationnelle.

L’agrégation des journaux et des rapports dans un SIEM avec alertes 24/7 accélère la détection et la preuve ; le recours à un SOC managé facilite la supervision (taux de courriels chiffrés, échecs TLS, certificats expirants, incidents DMARC).

Cas concret en UE/Luxembourg

Une fiduciaire soumise à la CSSF externalise sa messagerie en cloud EU. En 6 semaines : 1) classification « Confidentiel/Très Confidentiel » ; 2) durcissement SMTP (TLS 1.3, MTA‑STS enforce, TLS‑RPT, DANE), politique DMARC « reject », SEG activé ; 3) chiffrement at‑rest + customer‑managed keys sous HSM ; 4) playbook E2E (S/MIME) pour M&A et RH sensibles ; 5) tableaux de bord de preuves (taux chiffré, incidents TLS, audits de clés). Résultat : conformité démontrable à l’article 32 RGPD, et dossier CSSF 22/806 prêt (fiches d’externalisation, clauses chiffrement, rapports TLS‑RPT).

Premiers pas concrets

1. Mesurez cette semaine votre taux d’emails chiffrés sortants/entrants et la présence de MTA‑STS, TLS‑RPT, DANE.
2. Publiez/renforcez une politique de classification et une matrice de chiffrement (quand le transport suffit, quand l’E2E est requis) — validez‑la avec le métier et le DPO.
3. Activez DMARC en p=quarantine puis p=reject, corrigez vos sous‑domaines, alignez SPF/DKIM.
4. Choisissez votre modèle de clés cloud (provider‑managed vs CMK vs CSE) et documentez‑le pour la CSSF 22/806 : responsabilités, rotation, accès, journaux HSM/KMS.
5. Branchez la preuve dans votre SIEM (rapports TLS‑RPT, logs MTA, audits de ciphers, métriques DMARC) et programmez un health‑check trimestriel.

Sources officielles

• Jurisprudence : MIR — VG Düsseldorf, 02/04/2026, 29 K 7351/23 (Transportverschlüsselung) ; référence : dejure.org — Jurisprudence Art. 32.
• Texte RGPD : EUR‑Lex — Règlement (UE) 2016/679 (art. 32).
• Luxembourg (secteur financier) : CSSF — Circulaire 22/806 (mod. 25/883) et version PDF (FR).
• Guide chiffrement cloud : CNIL — Les pratiques de chiffrement dans le cloud public.

Besoin d’un accompagnement ? Contactez‑nous pour cadrer votre gouvernance, vos preuves et vos choix techniques.

Cabinet luxembourgeois Luxgap : SOC managed, DPO et CISO externalises, ISO 27001 Lead Implementer, e-learning cyber, surveillance Dark Web. Configurer un devis personnalise ou nous contacter.