diff --git a/geant-tcs/docs/de/376ca61dd09cfc71579e9bf49725c60742dd51c04d00f32686f6a824d9ba4482.md b/geant-tcs/docs/de/376ca61dd09cfc71579e9bf49725c60742dd51c04d00f32686f6a824d9ba4482.md
index 03cd5f7137a23faae8c773990ce317adb3847bec..bdc018c0498201212dc6d86f142471e379a5a520 100644
--- a/geant-tcs/docs/de/376ca61dd09cfc71579e9bf49725c60742dd51c04d00f32686f6a824d9ba4482.md
+++ b/geant-tcs/docs/de/376ca61dd09cfc71579e9bf49725c60742dd51c04d00f32686f6a824d9ba4482.md
@@ -8,9 +8,10 @@
 Der hier beschriebene Prozess hat die folgenden Probleme:
 
 1. Der private Schlüssel wird beim CA-Dienstleister erzeugt und nicht durch den Nutzer. Das bricht eine wichtige Grundannahme von Ende-zu-Ende-Verschlüsselung.
-2. Man kann genau eine E-Mail-Adresse im Zertifikat haben, diese entspricht den Nutzernamen bei HARICA.
-3. Zertifikate sind nur e-mail-validiert (und nicht organisations-validiert), es steht also nur die E-Mail-Adresse im Zertifikat. Es fehlt sowohl der reale Name als auch ein Bezug zum KIT. 
-4. Es gibt keinen Automatismus zum Veröffentlichen im globalen Adressbuch des KIT, das muss <a href="#publish-to-ad">händisch vom Nutzer angestoßen werden</a>.
+2. Man kann __genau eine__ E-Mail-Adresse im Zertifikat haben, diese entspricht den Nutzernamen bei HARICA.
+3. Zertifikate sind nur e-mail-validiert (und nicht organisations-validiert), es steht also nur die E-Mail-Adresse im Zertifikat. Es fehlt sowohl der reale Name als auch ein Bezug zum KIT.
+4. Der Prozess funktioniert nicht für E-Mail-Verteiler, bei denen nicht alle Empfänger Zugriff auf das Zertifikat haben sollen.
+5. Es gibt keinen Automatismus zum Veröffentlichen im globalen Adressbuch des KIT, das muss <a href="#publish-to-ad">händisch vom Nutzer angestoßen werden</a>.
 
 Wenn man beispielsweise ein Zertifikat für `beate.beispiel@kit.edu`, `b.beispiel@kit.edu` sowie `bb4711@sysmail.kit.edu`
 haben möchte, muss man die folgende Anleitung für jede dieser Adressen komplett durchlaufen.
diff --git a/geant-tcs/docs/en/376ca61dd09cfc71579e9bf49725c60742dd51c04d00f32686f6a824d9ba4482.md b/geant-tcs/docs/en/376ca61dd09cfc71579e9bf49725c60742dd51c04d00f32686f6a824d9ba4482.md
index d1189c22db842df8ce47a2652a9f50008657fd93..b3c5f9fc8b0a124d0b15a998b89f1b1c4a6afbd5 100644
--- a/geant-tcs/docs/en/376ca61dd09cfc71579e9bf49725c60742dd51c04d00f32686f6a824d9ba4482.md
+++ b/geant-tcs/docs/en/376ca61dd09cfc71579e9bf49725c60742dd51c04d00f32686f6a824d9ba4482.md
@@ -8,9 +8,10 @@
 The process described here has the following problems:
 
 1. The private key is generated by the CA service provider (HARICA) and not by the user. This breaks an important basic assumption of end-to-end encryption.
-2. The certificate can contain exactly one email address which corresponds to your username at HARICA.
+2. The certificate can contain __exactly one__ email address which corresponds to your username at HARICA.
 3. Certificates are only email-validated (and not organization-validated), it only contains the email address. Both the real name and a reference to KIT are missing.
-4. There is no automatic mechanism for publishing into the KIT global address book; this must be <a href="#publish-to-ad">manually initiated by the user</a>.
+4. The process does not work for e-mail distribution lists where not all recipients should have access to the certificate.
+5. There is no automatic mechanism for publishing into the KIT global address book; this must be <a href="#publish-to-ad">manually initiated by the user</a>.
 
 For example: if you wish to obtain a certificate for `beate.beispiel@kit.edu`, `b.beispiel@kit.edu` and `bb4711@sysmail.kit.edu`,
 you have to repeat the following instructions for each of these addresses.