diff --git a/site/content/en/latest/tasks/operations/gateway-namespace-mode.md b/site/content/en/latest/tasks/operations/gateway-namespace-mode.md
index ad7f3cd51b..3c5d841bf6 100644
--- a/site/content/en/latest/tasks/operations/gateway-namespace-mode.md
+++ b/site/content/en/latest/tasks/operations/gateway-namespace-mode.md
@@ -14,10 +14,15 @@ For status updates or to provide feedback, please follow our [GitHub issues](htt
 
 In standard deployment mode, Envoy Gateway creates all data plane resources in the controller namespace (typically `envoy-gateway-system`).
 
-Gateway Namespace Mode changes this behavior by placing Envoy Proxy data plane resources like Deployments, Services and ServiceAccounts in each Gateway's namespace, providing stronger isolation and multi-tenancy.
+The motivation behind this was to operate with minimum permissions needed to be given for Envoy Gateway controller, as the control plane and data plane was deployed in the same namespace.
 
-Traditional deployment mode uses mTLS where both the client and server authenticate each other. However, in Gateway Namespace Mode, we've shifted to server-side TLS and JWT token validation between infra and control-plane.
+Gateway Namespace Mode changes this behavior by placing Envoy Proxy data plane resources like Deployments, Services and ServiceAccounts in each Gateway's namespace, which provides stronger isolation and multi-tenancy compared to the Controller Namespace mode, as it isolates Envoy proxy data plane across different tenants.
+This distributed architecture requires additional RBAC permissions for the Envoy Gateway controller to manage Kubernetes resources across multiple namespaces.
 
+The default (Controller Namespace) deployment mode uses mTLS where both the client and server authenticate each other. However, in Gateway Namespace Mode, we've shifted to server-side TLS and JWT token validation between infra and control-plane.
+
+* **Envoy proxy pods** (running in Gateway namespaces) act as clients and authenticate using JWT tokens
+* **Envoy Gateway controller pod** (running in controller namespace) acts as the server and validates JWT tokens
 * Only the CA certificate is available in pods running in Gateway namespaces
 * Client certificates are not mounted in these namespaces
 * The Envoy proxy still validates server certificates using the CA certificate
diff --git a/site/content/en/v1.4/tasks/operations/gateway-namespace-mode.md b/site/content/en/v1.4/tasks/operations/gateway-namespace-mode.md
index f71b2c688f..7789274463 100644
--- a/site/content/en/v1.4/tasks/operations/gateway-namespace-mode.md
+++ b/site/content/en/v1.4/tasks/operations/gateway-namespace-mode.md
@@ -14,10 +14,15 @@ For status updates or to provide feedback, please follow our [GitHub issues](htt
 
 In standard deployment mode, Envoy Gateway creates all data plane resources in the controller namespace (typically `envoy-gateway-system`).
 
-Gateway Namespace Mode changes this behavior by placing Envoy Proxy data plane resources like Deployments, Services and ServiceAccounts in each Gateway's namespace, providing stronger isolation and multi-tenancy.
+The motivation behind this was to operate with minimum permissions needed to be given for Envoy Gateway controller, as the control plane and data plane was deployed in the same namespace.
 
-Traditional deployment mode uses mTLS where both the client and server authenticate each other. However, in Gateway Namespace Mode, we've shifted to server-side TLS and JWT token validation between infra and control-plane.
+Gateway Namespace Mode changes this behavior by placing Envoy Proxy data plane resources like Deployments, Services and ServiceAccounts in each Gateway's namespace, which provides stronger isolation and multi-tenancy compared to the Controller Namespace mode, as it isolates Envoy proxy data plane across different tenants.
+This distributed architecture requires additional RBAC permissions for the Envoy Gateway controller to manage Kubernetes resources across multiple namespaces.
 
+The default (Controller Namespace) deployment mode uses mTLS where both the client and server authenticate each other. However, in Gateway Namespace Mode, we've shifted to server-side TLS and JWT token validation between infra and control-plane.
+
+* **Envoy proxy pods** (running in Gateway namespaces) act as clients and authenticate using JWT tokens
+* **Envoy Gateway controller pod** (running in controller namespace) acts as the server and validates JWT tokens
 * Only the CA certificate is available in pods running in Gateway namespaces
 * Client certificates are not mounted in these namespaces
 * The Envoy proxy still validates server certificates using the CA certificate