diff --git a/doc/source/asym_encrypted_images.rst b/doc/source/asym_encrypted_images.rst
new file mode 100644
index 0000000..aa7bc5c
--- /dev/null
+++ b/doc/source/asym_encrypted_images.rst
@@ -0,0 +1,153 @@
+.. SPDX-FileCopyrightText: 2023 Michael Glembotzki <michael.glembotzki@iris-sensing.com>
+.. SPDX-License-Identifier: GPL-2.0-only
+
+Asymmetrically Encrypted Update Images
+======================================
+
+Asymmetrically encrypted update images are realized by an asymmetrical
+encrypted sw-description, making it possible to decrypt images device specific.
+The artifacts themselves are still encrypted symmetrically. An AES key can
+optionally be provided in the sw-description, or the default AES key will be
+used. Cryptographic Message Syntax (CMS) is used for decryption.
+
+
+Use Cases
+---------
+
+- Asymmetrically encrypted update images, with individual device key pairs, are
+  inherently more secure than a purely symmetrical solution, because one
+  compromised private device key does not affect the security of the others.
+- If ``CONFIG_SIGNED_IMAGES`` is enabled too and a device's private key is
+  compromised, the key pair can be excluded from the list of eligible devices
+  for receiving new update images.
+- The AES key can be securely **exchanged** with each new update image, as it is
+  part of the sw-description, even in the absence of direct access to the
+  device.
+
+
+Create a Self-Signed Device Key Pair
+------------------------------------
+
+As an example, an elliptic curve key pair (PEM) is generated for a single
+device. These steps must be repeated for all other devices. An RSA key pair
+could be used in the same way.
+
+::
+
+        # Create a private key and a self-signed certificate
+        openssl ecparam -name secp521r1 -genkey -noout -out device-key-001.pem
+        openssl req -new -x509 -key device-key-001.pem -out device-cert-001.pem -subj "/O=SWUpdate /CN=target"
+
+        # Combine the private key and the certificate into a single file
+        cat device-key-001.pem device-cert-001.pem > device-001.pem
+
+
+Symmetric Encryption of Artifacts
+---------------------------------
+
+Generate an AES key and IV, as familiar from
+:ref:`symmetric image encryption <sym-encrypted-images>`. The encryption
+process for the artifacts remains unchanged.
+
+
+Encryption of sw-description for Multiple Devices
+-------------------------------------------------
+
+All device certificates togther are used for encryption.
+
+::
+
+        # Encrypt sw-description for multiple devices
+        openssl cms -encrypt -aes-256-cbc -in <INFILE> -out <OUTFILE> -outform DER -recip <CERT_1> <CERT_2> <CERT_X>
+
+Replace ``<INFILE>`` with the plain `sw-description` (e.g.
+`sw-description.in`) and the encrypted ``<OUTFILE>`` with `sw-description`.
+``<CERT_1>``, ``<CERT_2>``, [...] ``<CERT_X>`` constitute the comprehensive
+list of devices intended for encryption.
+
+
+Decryption of sw-description for a Single Device
+------------------------------------------------
+
+The combined key pair (private key and certificate) is used for decryption.
+SWUpdate handles the decryption process autonomously. Manually executing this
+step is not necessary and is provided here solely for development purposes.
+
+::
+
+        # Decrypt sw-description for a single device
+        openssl cms -decrypt -in <INFILE>  -out ``<OUTFILE>`` -inform DER -inkey <PRIVATE_KEY_1> -recip <CERT_1>
+
+Replace the encrypted ``<INFILE>`` with `sw-description` and the
+``<OUTFILE>`` with plain `sw-description` (e.g. `sw-description.in`).
+``<PRIVATE_KEY_1>`` and ``<CERT_1>`` are used for the decryption.
+
+
+Example Asymmetrically Encrypted Image
+--------------------------------------
+
+The image artifacts should be symmetrically encrypted and signed in advance.
+Now, create a plain `sw-description.in` file. The ``encrypted`` attribute is
+necessary for encrypted artifacts. While it is strongly recommended to provide
+the attributes ``aes-key`` (global) and ``ivt`` (artifact-specific), they are
+not mandatory. If no ``aes-key`` or ``ivt`` is provided, the provided default
+``aes-key``/``ivt`` will be used.
+
+::
+
+        software =
+        {
+            version = "0.0.1";
+            aes-key = "ed73b9d3bf9c655d5a0b04836d8be48660a4a4bb6f4aa07c6778e00e342881ac";
+            images: ({
+                filename = "rootfs.ext4.enc";
+                device = "/dev/mmcblk0p3";
+                sha256 = "131159df3a4efaa890ff80173664a125c496c458dd432a8a6acae18872e35822";
+                encrypted = true;
+                ivt = "ea34a55a0c3476ed78f238ac87a7970c";
+            });
+        }
+
+
+Asymmetrically encrypt the `sw-description` for multiple devices:
+::
+
+        openssl cms -encrypt -aes-256-cbc -in sw-description.in -out sw-description -outform DER -recip device-cert-001.pem device-cert-002.pem device-cert-003.pem
+
+
+Create the new update image (SWU):
+
+::
+
+        #!/bin/sh
+
+        FILES="sw-description sw-description.sig rootfs.ext4.enc"
+
+        for i in $FILES; do
+            echo $i;done | cpio -ov -H crc >  firmware.swu
+
+
+Running SWUpdate with Asymmetrically Encrypted Images
+-----------------------------------------------------
+
+Asymmetric encryption support can be enabled by configuring the compile-time
+option ``CONFIG_ASYM_ENCRYPTED_SW_DESCRIPTION``. To pass the combined key pair
+(PEM) generated earlier to SWUpdate, use the ``-a`` argument. Alternatively,
+use the ``asym-decryption-keypair`` parameter in the ``swupdate.cfg``.
+
+
+Security Considerations
+-----------------------
+- Ideally, generate the private key on the device during factory provisioning,
+  ensuring it never leaves the device. Only the public certificate leaves the
+  device for encrypting future update packages.
+- This feature should be used in conjunction with signature verification
+  (``CONFIG_SIGNED_IMAGES``) to ensure data integrity. In principle, anyone
+  with the corresponding device certificate can create update packages.
+- As a side effect, the size of the update package may significantly increase
+  in a large-scale deployment. To enhance scalability, consider using group
+  keys. Smaller groups should be preferred over larger ones.
+- Exchange the AES key in the sw-description with each update package.
+- Avoid encrypting new update packages for compromised devices, if there is no
+  direct access to the device or if unauthorized users have access to new update
+  packages.
diff --git a/doc/source/encrypted_images.rst b/doc/source/encrypted_images.rst
index 2b7c1ee..bc23681 100644
--- a/doc/source/encrypted_images.rst
+++ b/doc/source/encrypted_images.rst
@@ -1,6 +1,8 @@
 .. SPDX-FileCopyrightText: 2013-2021 Stefano Babic <sbabic@denx.de>
 .. SPDX-License-Identifier: GPL-2.0-only
 
+.. _sym-encrypted-images:
+
 Symmetrically Encrypted Update Images
 =====================================
 
diff --git a/doc/source/index.rst b/doc/source/index.rst
index c3a8e88..3ed531a 100644
--- a/doc/source/index.rst
+++ b/doc/source/index.rst
@@ -41,6 +41,7 @@ SWUpdate Documentation
    sw-description.rst
    signed_images.rst
    encrypted_images.rst
+   asym_encrypted_images.rst
    handlers.rst
    mongoose.rst
    suricatta.rst
diff --git a/doc/source/roadmap.rst b/doc/source/roadmap.rst
index dc7d547..4e6caf4 100644
--- a/doc/source/roadmap.rst
+++ b/doc/source/roadmap.rst
@@ -138,11 +138,6 @@ BTRFS supports subvolume and delta backup for volumes - supporting subvolumes is
 to move the delta approach to filesystems, while SWUpdate should apply the deltas
 generated by BTRFS utilities.
 
-Security
-========
-
-- add support for asymmetryc decryption
-
 Support for evaluation boards
 =============================
 
diff --git a/doc/source/sw-description.rst b/doc/source/sw-description.rst
index 480ff4d..6e7e9bb 100644
--- a/doc/source/sw-description.rst
+++ b/doc/source/sw-description.rst
@@ -1441,8 +1441,17 @@ There are 4 main sections inside sw-description:
    |             |          | scripts    | and must be decrypted before          |
    |             |          |            | installing.                           |
    +-------------+----------+------------+---------------------------------------+
-   | ivt         | string   | images     | IVT in case of encrypted artefact     |
-   |             |          | files      | It has no value if "encrypted" is not |
+   | aes-key     | string   |            | Optional AES key for encrypted        |
+   |             |          |            | artefacts. It has no effect if not    |
+   |             |          |            | compiled with                         |
+   |             |          |            | `CONFIG_ASYM_ENCRYPTED_SW_DESCRIPTION`|
+   |             |          |            | or if attribute "encrypted" is not    |
+   |             |          |            | set. If no AES key is provided the    |
+   |             |          |            | default AES key is used. It is an     |
+   |             |          |            | ASCII hex string of 16/24/32 chars.   |
+   +-------------+----------+------------+---------------------------------------+
+   | ivt         | string   | images     | Optional IVT for encrypted artefacts. |
+   |             |          | files      | It has no effect if "encrypted" is not|
    |             |          | scripts    | set. Each artefact can have an own    |
    |             |          |            | IVT to avoid attacker can guess the   |
    |             |          |            | the key.                              |
