Thirty minutes from shipment to signed in
A walkthrough of the Operayde enrolment flow — token, TPM attestation, first sign-in.
We wanted enrolment to be boring. Most companies install an on-prem service once and rage at it for a month. Operayde has to install this thing at every customer, and in many cases, at many sites per customer. Boring was the design goal.
The measured sequence
We measure a fresh enrolment end-to-end on a Starter Micro. Typical times:
| Step | Elapsed |
|---|---|
| Power on → POST complete | 0:35 |
| First-boot UI → token paste | 2:10 |
| Token exchange + cert mint | 0:40 |
| TPM attestation + identity seal | 0:20 |
| Workspace Runtime start | 2:00 |
| Fleet policy initial pull | 0:15 |
| IdP SSO bootstrap | 3:00 |
| First sign-in complete | ≈ 9:00 |
Add a few minutes of standing around, a network hiccup, and a biscuit, and you get “under thirty”.
What could go wrong
We’ve catalogued (and fixed) the failure modes we’ve seen so far:
- Token expired during shipping — 72 h TTL, extendable from the portal.
- Network policy blocks outbound to our region — surfaces on the first-boot screen with the exact blocked host.
- Clock skew > 5 minutes on first boot — NTP runs before enrolment; if NTP is blocked the screen says so explicitly.
- DNS not yet propagated for
appliance.<your-domain>— enrolment completes but staff sign-in fails with a specific error.
The pattern: fail early, say why, don’t hide.
Why TPM attestation
Because without it, a skilled attacker could clone an appliance, enrol the clone with a stolen token, and talk to us as if it were the real one. The TPM quote binds enrolment to the physical firmware measurements of a specific chassis.
Why boring wins
The most important number isn’t the 9 minutes. It’s the number of support tickets per enrolment in week one. Our target is zero; our current running average is 0.13. We pay attention to the outliers.