Credential and Identity Inventory (Onboarding)

Credential and Identity Inventory (Onboarding)

1. 01

   Map every human seat, service account, and AI agent that will touch client systems before provisioning begins

   List named employees, shared mailboxes, CI/CD service accounts, and any agent runtime that calls client APIs. Missing one non-human identity at this stage is the most common cause of orphaned credentials six months later.

2. 02

   Record the identity provider each client already runs and whether federation is possible

   Okta, Entra ID, and Google Workspace tenants each change the provisioning path. Where a client runs JumpCloud as a combined directory and device layer, confirm whether device enrollment is in scope or identity only.

3. 03

   Classify each credential by blast radius: production data, billing, or read-only reporting

   A retainer that only reads analytics does not need write scopes. Assign the minimum scope per identity and write the justification next to it so a reviewer can challenge it later.

4. 04

   Assign a named owner for every shared vault and secrets store

   Shared vaults without an owner accumulate stale entries. One owner per vault, recorded in the client file, so offboarding has a single person to notify.

5. 05

   Set the rotation interval per credential class and log it in the client record

   Long-lived API keys for client platforms should rotate on a fixed calendar, not on incident. Document the interval so the QA pass can verify it was honored.

6. 06

   Confirm which compliance regime the client operates under and flag gaps

   SOC 2, HIPAA, and GDPR each impose different access review and retention expectations. Flag any identity that cannot meet the client's stated regime before it is provisioned, not after.

7. 07

   Publish the inventory to the delivery lead and get written sign-off

   The inventory is the baseline for every later access review. An unsigned baseline cannot be used to prove scope creep or unauthorized access.