diff --git a/src/starkernel/capsule/capsule_zuse_boot.c b/src/starkernel/capsule/capsule_zuse_boot.c
index 14d813be..e679c145 100644
--- a/src/starkernel/capsule/capsule_zuse_boot.c
+++ b/src/starkernel/capsule/capsule_zuse_boot.c
@@ -73,6 +73,24 @@ static void install_and_activate(VM *mama_vm, struct blkio_dev *dev,
      * attach -- gating it on install's success/failure made re-login
      * impossible, since a second install always fails by design. */
     vm_zuse_cert_install(mama_vm, seed, pubkey);
+    /* Real defect found live 2026-09-22 verifying FABRIC-3.6.md task 3.9:
+     * capsule_zuse_boot_load_root_pubkey() is the only other writer of
+     * zuse_root_pubkey_known, and it only runs once, at Artemis's
+     * boot-time virtio-blk attach (kernel_main.c) -- before genesis mint
+     * has happened on a fresh artemis.img, so it finds no marker yet and
+     * leaves the flag 0. Nothing re-triggers it after genesis mint
+     * completes. Silent result: capsule_wirebind_try_attach()'s own
+     * `if (!mama_vm->zuse_root_pubkey_known) return;` gate (this file's
+     * sibling function) then refuses every identity attach for the rest
+     * of the boot, with no message at all -- exactly the failure mode
+     * FABRIC-3.5.md SXXXV.0 names. Fixed at the source: the pubkey this
+     * function was just handed (from genesis mint, above, or from an
+     * already-Zuse re-attach, below) IS the root pubkey -- activate it
+     * directly here instead of relying on a disk re-read that may never
+     * happen this session. Matches vm_zuse_cert_install()'s own one-way
+     * idempotence (harmless to set twice). */
+    memcpy(mama_vm->zuse_root_pubkey, pubkey, 32);
+    mama_vm->zuse_root_pubkey_known = 1;
     /* zuse.4th's ACL-ZUSE-BOOT self-activated once already at Mama's own
      * birth, when no cert was installed yet (the thumbdrive wasn't
      * attached at that early, one-shot point) -- ACL-PIN only blocks