Lifecycle & JML
The change gate (F1 · F3 · F4)
flowchart LR REQ[Self-service
access request]:::req --> IGA[IGA
reconcile / govern]:::g IGA -->|F1 · HR event| ITSM{ITSM
change gate}:::gate IGA -->|F3 · RFC| ITSM ITSM -->|awaiting_approval · Duo push| CAB[CAB approver
approver group · serialized]:::cab CAB -->|allow / deny on device · F4| APPLY[IGA apply
DRY_RUN by default]:::a APPLY -->|real write when DRY_RUN=false| DIR[Duo · AD / Entra]:::d APPLY -.grant → assurance-level-change.-> TX[SSF → CII]:::s ITSM -.audit spine.-> LOG[(tamper-evident log)]:::x classDef req fill:#160f22,stroke:#3b3170,color:#e6edf3; classDef g fill:#160f22,stroke:#3b3170,color:#e6edf3; classDef gate fill:#201a10,stroke:#a98f2a,color:#f0f6fc; classDef cab fill:#201a10,stroke:#a98f2a,color:#f0f6fc; classDef a fill:#1b2838,stroke:#3d6ea5,color:#f0f6fc; classDef d fill:#16202e,stroke:#2c3e57,color:#e6edf3; classDef s fill:#101b16,stroke:#2c623a,color:#e6edf3; classDef x fill:#16202e,stroke:#31465f,color:#93a4bb;
Every identity change is a typed change: IGA reconciles the desired state, emits an HR event and an
RFC to ITSM, a human approves it, and only then does IGA apply it (real writes only when DRY_RUN=false).
Provisioning is slow and gated; SSF/CAEP-capable signaling does the fast, real-time revoke.
Joiner / mover / leaver — governed end to end
The four paths
Each identity class onboards and offboards differently — but all through the same gate.
| Path | Trigger | What happens |
|---|---|---|
| Human joiner | HRIS hire (T3) | worker feed → IGA JOINER → RFC → approve → create in AD + Entra + Duo · SSO + MFA enroll |
| Human leaver | HRIS terminate | IGA LEAVER fans out: cascade-disable elevated (t0/t1/t2 admin) · orphan-detect owned service accounts → reassign RFC (never delete) · flag sponsored agents to re-own/retire |
| Service / NHI onboard | request | owner + backup + service + tier → validate (owner active? service exists?) → RFC → registry entry → provision into the directory, vaulted |
| Agent onboard | request | on-behalf-of human + service + scope → validate → RFC → Duo agent identity + sponsor bind + scoped, revocable token |
The leaver path is the case the ownership model exists for: a departing human's service keeps running — its accounts are reassigned, not deleted — while their elevated accounts and agents are pulled.
Beyond JML, a self-service access request (the request intake on the governance console) proposes an entitlement grant through the same gate — a Duo-push CAB approval by a CAB approver, SoD-routed for privileged groups, applied only on approval and broadcast as an assurance-level-change.
Proving who they are — Duo Identity Verification
Provisioning grants access; identity verification (IDV) proves the human is who they claim before high-stakes lifecycle actions — document + selfie proofing via Persona.
| Workflow | When | Status |
|---|---|---|
| Enrollment verification | New user proves identity (gov ID + selfie) before completing Duo enrollment | GA |
| Help-desk verification | Help desk proves a caller's identity before an account action (reset, unlock, re-enroll) | GA |
| Self-service account recovery | User proves identity to recover access via the self-service portal | roadmap |
IDV plugs the assurance gap at the joiner (enrollment) and the help-desk — the two moments an attacker impersonates a human. Document + facial match via Persona; more workflows to follow.