First run of a fresh vault
A brand-new SkyKeep vault opens as a plain sign-in page and has exactly
one account: the bootstrap administrator, admin001, whose initial
password is publicly documented. That first sign-in needs only the
password — no one-time code, because a fresh vault has no mail relay and
the account has no email address yet — and it is useful for exactly one
thing: choosing a real password, along with the email address future
sign-in codes will be delivered to. Until both are set, the vault
refuses every other operation on that account, whichever interface
asks; afterwards the old password never works again. Replacement
passwords have to meet the vault's floor, and a refused replacement
always says why — it is your own choice being refused, not an access
decision.
A too-short replacement password is refused with the reason
- Given an account holder choosing a replacement password
- When they propose a password shorter than the vault's floor
- Then the vault refuses the replacement and states the reason
A replacement password identical to the current one is refused
- Given an account holder choosing a replacement password
- When they propose the password they already have
- Then the vault refuses the replacement and states the reason
The first sign-in is password-only and can do nothing but finish the setupstack
- Given a fresh account that still carries the forced password change
- When they sign in with just their password
- Then the vault signs them in but requires the password change first
- When they try to use the vault before changing the password
- Then the vault refuses the operation
- When they set a new password without offering an email address
- Then the vault refuses the change because an email address is required
- When they set a new password and an email for sign-in codes
- Then the vault serves them normally