diff --git a/docs/plans/2026-08-13-vd03-nam-ldap-cutover.md b/docs/plans/2026-08-13-vd03-nam-ldap-cutover.md
index f2eab76..3bb8093 100644
--- a/docs/plans/2026-08-13-vd03-nam-ldap-cutover.md
+++ b/docs/plans/2026-08-13-vd03-nam-ldap-cutover.md
@@ -24,6 +24,12 @@ Out of scope: windev's OtOpcUa/mxgw instances, the QA pair (VQ03/VQ04 — do it
 follow-on once VD03 has soaked; QA is where the 2-node/failover behaviour actually gets
 exercised), and OtOpcUa's OPC UA data plane (API-key auth since Gitea #520).
 
+> ⚠️ **ignitionoee (router): LDAP setup ON HOLD** — explicit decision 2026-08-13. Its role
+> vocabulary is not the canonical set (its admin role is literally `"Admin"`, not
+> `"Administrator"`), so no existing `UG_WW_*` group maps onto it — a NAM cutover there
+> would first require **minting new AD groups**. Do not wire its LDAP as part of this plan
+> or its follow-ons; it keeps its current auth until the groups exist and are decided.
+
 ## The target LDAP block (identical shape in all four apps)
 
 ```jsonc
@@ -251,3 +257,5 @@ Phase 1's redeploys are independent and should NOT be rolled back for an auth pr
   glauth-redundant pair (uncommitted working-tree change, independent of this plan).
 - ldap_mapping.md is still untracked in scadaproj — commit it when its DECIDE items
   settle; this plan depends on its §4 tables.
+- ignitionoee LDAP: **held** (see the Scope flag) until new `UG_WW_*` groups matching its
+  role vocabulary are minted and mapped — a group-creation request, not a config task.