diff --git a/docs/Limitations.md b/docs/Limitations.md
index 4295dc757a..23a5eed1f2 100644
--- a/docs/Limitations.md
+++ b/docs/Limitations.md
@@ -180,14 +180,12 @@ shim, the Kata agent bind mounts the source path directly from the
 ### Privileged containers
 
 Privileged support in Kata is essentially different from `runc` containers.
-The container runs with elevated capabilities within the guest and is granted
-access to guest devices instead of the host devices.
+The container runs with elevated capabilities within the guest.
 This is also true with using `securityContext privileged=true` with Kubernetes.
 
-The container may also be granted full access to a subset of host devices
-(https://github.com/kata-containers/runtime/issues/1568).
-
-See [Privileged Kata Containers](how-to/privileged.md) for how to configure some of this behavior.
+Importantly, the default behavior to pass the host devices to a
+privileged container is not supported in Kata Containers and needs to be
+disabled, see [Privileged Kata Containers](how-to/privileged.md).
 
 # Appendices
 
diff --git a/docs/how-to/privileged.md b/docs/how-to/privileged.md
index 048509ff17..f361d2a818 100644
--- a/docs/how-to/privileged.md
+++ b/docs/how-to/privileged.md
@@ -1,22 +1,25 @@
 # Privileged Kata Containers
 
+> [!WARNING]
+> Whilst this functionality is supported, it can decrease the security of Kata Containers if not configured correctly.
+
 Kata Containers supports creation of containers that are "privileged" (i.e. have additional capabilities and access
 that is not normally granted).
 
-## Warnings
+## Enabling privileged containers without host devices
 
-**Warning:** Whilst this functionality is supported, it can decrease the security of Kata Containers if not configured 
-correctly.
+> [!TIP]
+> When Kata Containers is installed through
+> [kata-deploy](/tools/packaging/kata-deploy/helm-chart/README.md#kata-deploy-helm-chart), this mitigation is configured
+> out of the box, hence there is no action required in that case.
 
-### Host Devices
+By default, a privileged container attempts to expose all devices from the host. This is generally not supported in Kata
+Containers as the container is running a different kernel than the host.
 
-By default, when privileged is enabled for a container, all the `/dev/*` block devices from the host are mounted
-into the guest. This will allow the privileged container inside the Kata guest to gain access to mount any block device 
-from the host, a potentially undesirable side-effect that decreases the security of Kata.
+Instead, the following sections document how to disable this behavior in different container runtimes. Note that this
+mitigation does not affect a container's ability to mount *guest* devices.
 
-The following sections document how to configure this behavior in different container runtimes.
-
-#### Containerd
+## Containerd
 
 The Containerd allows configuring the privileged host devices behavior for each runtime in the containerd config. This is
 done with the `privileged_without_host_devices` option. Setting this to `true` will disable hot plugging of the host 
@@ -43,7 +46,7 @@ See below example config:
  - [How to use Kata Containers and containerd with Kubernetes](how-to-use-k8s-with-containerd-and-kata.md)
  - [Containerd CRI config documentation](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)
 
-#### CRI-O
+## CRI-O
 
 Similar to containerd, CRI-O allows configuring the privileged host devices
 behavior for each runtime in the CRI config. This is done with the