The instructions say which key signed the build they ship with

docs/user-guide.md

@@ -60,9 +60,12 @@ sudo dd if=kryptik-VERSION-usb.img of=/dev/sdX bs=4M status=progress oflag=sync
 
 **Optical.** Burn `kryptik-VERSION.iso` as an image.
 
-**Secure Boot.** The kernel is signed with the developer key. A firmware
-that carries only Microsoft's keys refuses it (the acceptance run proves the
-refusal: `media-refused-foreign-keys`). To boot with Secure Boot on, enrol
+**Secure Boot.** The kernel is signed with the build's Secure Boot key: a
+release's is the one made offline ([release keys](release-keys.md)), enrolled
+once for every release after it; a development build's is made by that build
+and is its own. A firmware that carries only Microsoft's keys refuses either
+(the acceptance run proves the refusal: `media-refused-foreign-keys`). To
+boot with Secure Boot on, enrol
 `kryptik-sb.der` in the firmware's `db` (and, on most machines, PK/KEK) from
 the firmware setup menu; or turn Secure Boot off. The medium reports which it
 got: `KRYPTIK_SMOKE: secureboot=1` or `=0` on the console.
@@ -279,8 +282,12 @@ shows each timer, its timeout and whether it is running.
 
 ## Known limitations of this release
 
-- Signed with a developer key generated by the build. There is no
-  production signing, no key ceremony, and no independent security review.
+- A development build, which every `0.x` release is, is signed with keys
+  that build generated and then discarded, so its certificate is enrolled on
+  its own and no other build's release updates it; a production release is
+  signed with the keys made offline in the release ceremony
+  ([release keys](release-keys.md)). No independent security review has
+  been made.
 - Tested under QEMU with OVMF only. No physical machine has booted it; no
   hardware support beyond what the virtual machine exercised is claimed.
 - The builds are not reproducible bit for bit; the hashes name what was