Wendy Device Enrollment

Wendy does not manufacture hardware. There is no factory birth-key — the root of trust at first touch is an authenticated operator flashing the Wendy-built OS image onto off-the-shelf hardware and enrolling it. The device generates its own keypair (hardware-backed where the SoC allows), and the private key never leaves the device (D15).

The Three Rules Every Enrollment Change Must Keep

1. The platform Root is baked into the OS image — never trust-on-first-use. The enrollment-delivered chain must validate up to the Root the operator already flashed, not to whatever chain the first enrollment happens to hand the device (§5.4).
2. No roll-forward from an expired cert. Renewal always requires a currently-valid cert to present. Once a cert has expired, the only way back is a standing proof — an unattended re-attestation, or an operator-approved grant (D14). A bare expired cert is never enough on its own.
3. Trusted time is seeded at enrollment and must fail safe. Every freshness/TTL check downstream depends on it; if trusted time can't be established, the device holds state and alerts — it never guesses (§4.4).

Choosing the Flow

• Online (has internet). The operator requests an enrollment token at OS-install; cloud relays the signed request to pki-core, which mints a device- and tenant-bound, single-use token for the device to redeem. Fast, unattended once the operator has acted.
• Offline / airgapped (no internet). The device is connected to the operator's PC at first boot, emits a CSR (key never leaves it), and the operator carries a signed request to cloud for a grant. Slower, requires physical operator presence at both ends.

See references/first-touch.md for the full mechanics of both, plus post-expiry recovery.

Renewal