diff --git a/docs/Detailinformationen/Encryption.md b/docs/Detailinformationen/Encryption.md
index ee5551a04c04f67a0ff528f135bcceda7a974914..e869185fe6c90ec5a814e3da694a9ebd40705296 100644
--- a/docs/Detailinformationen/Encryption.md
+++ b/docs/Detailinformationen/Encryption.md
@@ -11,34 +11,26 @@ Diese Informationen sind relevant, wenn man:
 Im Kontext von Anträgen an Behörden werden häufig höchstsensible Daten übermittelt, die im Rahmen von [Vorgaben des BSI](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03107/TR-03107-1.pdf?__blob=publicationFile&v=4) nur Ende-zu-Ende-Verschlüsselt übertragen werden dürfen. 
 Bei fitconnect ist die Zielsetzung einen möglichst einfachen, sicheren und klar definierten Standard zu etablieren. Deshalb ist richtig implementierte Krypotgraphie ein fundamentaler Standard von fitconenct.  
 
-## Architektur
-Jedes fitconenct-System verfügt über einen Endpunkt, an den Anträge gesendet werden (Fachverfahren/Subscriber-API) und einen oder mehrere Endpunkte von denen Anträge verschlüsselt versendet werden (in der Regel: Onlinedienst, App, …).
-
-
-
-## Vorgaben 
-
-### Grundlagen
+## Grundlagen
 
-1. Grundsätzlich muss die fitconnect-Verschlüsselung immer Ende-zu-Ende sein. Das bedeutet vom Endgerät der Nutzer*in bis in die Empfangsbehörde des Antrages.
+1. Grundsätzlich muss die fitconnect-Verschlüsselung immer Ende-zu-Ende sein. Das bedeutet vom Endgerät der Nutzer*in bis in das Fachverfahren bzw. die Empfangsbehörde des Antrages.
+<img src="../../assets/images/encryption/tls-no-tls.png" alt="Ende-zu-Ende-Verschlüsselung Bedeutung" width="400" height="320">
 
-2. 
+Es ist nicht vorgesehen, das Antragsdaten unverschlüsselt von einem Endgerät einer Nutzer*in an ein Backend weitergeleitet werden, um dann von dort verschlüsselt per fitconnect an die Empfangsbehörde gesendet zu werden. Antragsdaten dürfen nicht in einem Backend gespeichert werden. Sollte eine längerfristige Speicherung der Antragsdaten benötigt werden, so muss diese immer clientseitig (z.B. in der IndexDB des Browsers, per Download, …) erfolgen.
 
+2. Die für die Verschlüsselung verwendeten JSON Web Keys müssen signiert werden, über eine Verwaltungs-PKI verifizierbar sein und auch durch den verschlüsselnden Client vollständig mit Hilfe der Verwaltungs-PKI verfiziert werden.
+<img src="../../assets/images/encryption/pki-check.png" alt="PKI-um Man-in-the-Middle zu verhindern" width="400" height="320">
 
-### Anforderungen an die JSON Web Keys
-Unter Berücksichtigung der Vorgaben des BSI in der Richtlinie [TR-02102-1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) wurden die [Liste der möglichen Algorithmen](https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms) eingeschränkt.
-
-- Asymmetrisches Verschlüsselungsverfahren, um den "Content Encryption Key" zu verschlüsseln ("alg"): "RSA-OAEP-256"
-- Symmetrisches Verschlüsselungsverfahren zur Verschlüsselung des Payloads ("enc"): "A128GCM" oder "A256GCM"
-
+Es ist nicht vorgesehen nicht vertrauenswürdige Schlüssel für die Verschlüsselung von Anträgen zu verwenden. Das soll Angriffe wie Man-in-the-middle-Attacken erschweren.
 
+3. Der Json Web Key muss immer die komplette Zertifikatskette bis zur Root-CA enthalten, um clientseitig korrekt validierbar zu sein.
 
 ## Architektur
 
-![FIT-Connect Architektur](https://raw.githubusercontent.com/fiep-poc/assets/fa582b1bf765cbe5059b5f22f100923da595d6f9/images/encryption/Architektur_PoC_einfach_2.svg "FIT-Connect Architektur")
-
 Kern von FIT-Connect ist der Zustelldienst, der über die beiden APIs "Application Sender API" und "Application Subscriber API" den Absender (Sender) und Empfänger (Subscriber) eines Antrags verbindet.
 
+Jedes fitconenct-System verfügt über einen Endpunkt, an den Anträge gesendet werden (Fachverfahren/Subscriber-API) und einen oder mehrere Endpunkte von denen Anträge verschlüsselt versendet werden (in der Regel: Onlinedienst, App, …).
+
 
 ## Konzept
 
diff --git a/docs/Detailinformationen/Encryption_Key_Requirements.md b/docs/Detailinformationen/Encryption_Key_Requirements.md
index ac2e2fde4a1ffd4f74bbcc4a36e1fd3272f5448b..12abbe4c86dbf8f28211ee499d490ba08dbdf821 100644
--- a/docs/Detailinformationen/Encryption_Key_Requirements.md
+++ b/docs/Detailinformationen/Encryption_Key_Requirements.md
@@ -118,7 +118,7 @@ Im Header des JSON Web Encryption Objektes werden die Metadaten zu den verschlü
 | zip  | DEF                | Der Komprimieriungsalgorithmus für die Inhaltsdaten nach [RFC 7516 Abschnit 4.1.3](https://tools.ietf.org/html/rfc7516#section-4.1.3) |
 | kid  | ID des Public Keys | Die ID des JSON Web Keys mit dem Attribute "wrapKey", aus dem von der Subscriber-API bereitgestellten Keysets, der zur Verschlüsselung des unter enc verschlüsselten symmetrischen Keys verwendet wurde. (siehe [RFC 7516 4.1.6](https://tools.ietf.org/html/rfc7516#section-4.1.6)) |
 
-## Signaturverfahren zur Signierung von Security Event Tokens
+## Algorithmen zur Signierung von Security Event Tokens
 
 Für die Bereitstellung von signierten Statusinformationen über Security Event Tokens (vgl. [RFC 8417](https://tools.ietf.org/html/rfc8417)) wird das Verfahren [JSON Web Signature](https://tools.ietf.org/html/rfc7515) verwendet.