diff --git a/modules/manage/pages/schema-reg/schema-reg-authorization.adoc b/modules/manage/pages/schema-reg/schema-reg-authorization.adoc
index 7f937534f8..deb3b40ca2 100644
--- a/modules/manage/pages/schema-reg/schema-reg-authorization.adoc
+++ b/modules/manage/pages/schema-reg/schema-reg-authorization.adoc
@@ -269,9 +269,11 @@ This grants:
 ====
 **Schema Registry ACLs are only for Schema Registry operations.** For complete data migration, you must also use Kafka ACLs:
 
-* **Topics:** READ (source), WRITE/CREATE/DESCRIBE/ALTER (target)
-* **Consumer groups:** READ (source), CREATE/READ (target)
-* **Cluster:** DESCRIBE (both), CREATE (target)
+* **Topics:** `READ`, `DESCRIBE_CONFIGS` (source); `WRITE`/`CREATE`/`DESCRIBE`/`ALTER`/`DESCRIBE_CONFIGS` (target)
+* **Consumer groups:** `READ` (source), `CREATE`/`READ` (target)
+* **Cluster:** `DESCRIBE` (both), `CREATE` (target)
+
+`READ` on a topic implicitly grants `DESCRIBE`, but not `DESCRIBE_CONFIGS`. Redpanda Migrator reads each source topic's configuration (`DESCRIBE_CONFIGS`) to recreate it on the target, so a consumer-only ACL on the source is not sufficient: without `DESCRIBE_CONFIGS` on the source topics, topic creation fails with `TOPIC_AUTHORIZATION_FAILED`.
 
 See xref:manage:security/authorization/acl.adoc[Configure Access Control Lists] for Kafka ACL configuration.
 ====