# Security Bootstrap User Lifecycle

Status: draft UX contract
Date: 2026-05-24

## Purpose

This document defines the first guided user lifecycle flows for the security
bootstrap experience. It is the product contract for `NET-WP-0016-T04`.

The goal is to make common access operations clear without granting platform
root by accident.

## Actor Classes

| Class | Meaning | Root risk |
| --- | --- | --- |
| Setup operator | Can assemble or observe early infrastructure | Must not imply root custody |
| Platform admin | Day-to-day delegated platform administration | Scoped and revocable |
| Tenant admin | Admin for one tenant or fabric | No platform root |
| Reviewer | Read-only inspection and audit role | No secret reads by default |
| Workload principal | Service account or automation identity | Least privilege |
| King credential | Rare platform-root custody | Break-glass only |

The UI must always distinguish actor class before granting access.

## Onboard User

Inputs:

- display name;
- contact address;
- actor class;
- tenant or fabric scope;
- requested groups/roles;
- MFA requirement;
- review date.

Flow:

1. Select actor class.
2. Select scope.
3. Show effective privileges before creation.
4. Highlight any platform-admin or root-adjacent role.
5. Require MFA for privileged roles.
6. Create or prepare identity in the selected IAM provider.
7. Record non-secret audit event.

Blocked conditions:

- actor class is missing;
- scope is missing for tenant/fabric roles;
- privileged role without MFA;
- ordinary onboarding tries to grant king custody.

## Temporarily Lock User

Purpose: suspend access without deleting identity history.

Flow:

1. Select user.
2. Show active groups, roles, sessions, keys, tokens, and owned resources where
   available.
3. Disable login or token issuance.
4. Revoke active sessions and short-lived tokens where supported.
5. Preserve audit subject and ownership records.
6. Record unlock instructions and review date.

The UI should label this as reversible.

## Permanently Lock And Offboard User

Purpose: remove operational access while preserving audit evidence.

Flow:

1. Select user.
2. Require reason and effective date.
3. Transfer owned resources or service principals.
4. Revoke sessions, tokens, app passwords, SSH keys, and OpenBao tokens.
5. Remove groups, roles, and tenant memberships.
6. Schedule rotation for shared material the user may have seen.
7. Record non-secret offboarding evidence.

Platform-admin offboarding requires a second confirmation. King credential
offboarding is not a normal lifecycle action; it is a custody replacement
ceremony.

## Review And Change Credentials

Purpose: inspect posture and rotate safely.

The review screen should show:

- MFA state;
- recovery confirmation age;
- SSH keys;
- active tokens;
- group and role memberships;
- last review date;
- owned service principals; and
- rotation recommendations.

Actions:

| Action | Meaning |
| --- | --- |
| Rotate credential | Replace a secret or key |
| Reset credential | Emergency replacement |
| Change authorization | Add/remove roles or groups |
| Schedule review | Set next review date |

The UI must keep rotation separate from authorization changes.

## New Fabric With Its Own Admin

Purpose: create a fabric with delegated administration but no platform-root
authority.

Flow:

1. Name the fabric.
2. Assign fabric admin.
3. Create IAM scope and group mapping.
4. Create OpenBao path prefix and policy request.
5. Define audit and backup expectations.
6. Produce a handover checklist.
7. Record non-secret progress event.

Blocked conditions:

- fabric admin missing;
- platform-root role requested;
- no OpenBao path prefix;
- no review date.

## UX Rules

- Show effective access before saving.
- Use plain labels: "locked", "offboarded", "needs review".
- Do not use red/yellow/green as the only indicator.
- Do not display secret values.
- Do not send secrets by email.
- Keep every high-risk action reversible where possible, or explain why it is
  not reversible.