Most non-human identity programs fail by being too ambitious in the wrong order: they try to rotate secrets before they know which identities exist, or scope permissions before anyone can say what an identity is for. This plan does four things in four weeks, in an order where each week’s output is the next week’s input. It is tool-agnostic; where the Trustivan platform automates a step, we say so and label the capability honestly.
The four outcomes
| Week | Outcome | Evidence you should hold at the end |
|---|---|---|
| 1 | Inventory | A list of every identity in scope, with source, environment and last-seen |
| 2 | Classification | Each identity typed, with criticality and environment |
| 3 | Ownership | An attested owner and purpose for every production identity |
| 4 | Lifecycle and evidence | Dormant and orphaned identities queued, attestation cadence live, evidence retained |
Week 1 — scope and discover
Decide the scope in writing. Pick the environments that matter most and be explicit about what is out of scope for the first pass. A typical starting scope: the production cloud accounts, the primary identity provider, source control and CI/CD, and the two or three SaaS platforms that hold customer or financial data.
Enumerate from the systems that issue authority. Do not start from a secret scanner; start from the places identities are created:
- Cloud IAM: users without console access, roles and their trust policies, service accounts and keys, managed identities, workload identity bindings.
- Identity provider: applications, service users, API tokens, OAuth grants and the individuals who consented to them.
- Kubernetes: service accounts, role bindings, secrets mounted into workloads.
- Source control and CI/CD: apps, deploy keys, personal access tokens used by automation, pipeline variables, OIDC trust configuration.
- SaaS: connected apps, integration users, bot installations and their scopes.
- Secrets managers and vaults: the identities that hold secrets, and the secrets that exist with no identity attached.
Capture four fields per identity and nothing more this week: where it came from, which environment it lives in, when it was last seen authenticating (if the source exposes it) and the raw source record. Resist enriching anything yet.
Checklist
- Scope document agreed with platform, security and at least one application team
- Read-only access to every in-scope system, with the scopes recorded
- Inventory with source, environment, last-seen and raw record per identity
- A count of identities the sources could not fully describe (missing last-use, missing creator)
With Trustivan: five connectors — AWS IAM, GitHub, Kubernetes, HashiCorp Vault and Model Context Protocol — do their part of this enumeration read-only, on demand or on a schedule you enable, and every record carries its source and observation time. (Available.)
Week 2 — classify and prioritize
Apply a taxonomy. Eight classes are enough: service, workload, machine, integration, automation, credential-backed, AI and emerging identities. The point of classification is that each class fails differently, so each class gets different questions in week 3. An integration identity needs its consenting user and scopes reviewed; a workload identity needs its role and binding reviewed.
Add two attributes. Criticality — what does this identity exist to do, and what does it touch? — and environment boundary — does it only exist in non-production, only in production, or can it cross? Use tags, naming conventions and the account or project hierarchy; do not interview anyone yet.
Prioritize ruthlessly. Production identities that can reach customer data, money or deployment are the week-3 population. Everything else is a week-5-and-beyond population, and writing that down is part of the deliverable.
Checklist
- Every identity has a class, or is explicitly unclassified
- Criticality and environment assigned from metadata, with the source of each noted
- A priority list of production identities for ownership attribution
- A written deferral list for everything else
With Trustivan: each connector assigns a type from one closed set and keeps the provider’s own type as evidence; what no rule recognizes is shown as unknown. (Available.)
Week 3 — attribute and attest ownership
This is the week that decides whether the program becomes real. An owner is not the person who created the identity; it is the person or team who can state its purpose, name what depends on it and say when it should stop existing.
Gather attribution signals before asking anyone. Creator and last modifier from audit logs, infrastructure-as-code commit authors, CODEOWNERS entries, team and cost-center tags, and the pipelines that use the credential. Combine them into a suggestion with the supporting evidence listed.
Ask for attestation, not information. A message that says “we believe your team owns svc-billing-export because the deploy pipeline lives in your repository and it is tagged with your cost center — can you confirm and tell us its purpose?” gets answered. A spreadsheet with four hundred rows does not.
Record three things per attested identity: purpose in one sentence, dependent systems, and an end date or review cadence. Record the decline reasons too; “not ours” with a pointer to who it might be is valuable routing data.
Checklist
- Suggestions with ranked evidence for every priority identity
- Attestation requests sent, with a two-line ask and the evidence attached
- Purpose, dependencies and end date recorded for each attested identity
- A list of identities nobody claimed — these are orphans, and they are your first real findings
With Trustivan: ownership is taken from provider tags or assigned by a person, with its source recorded, and unresolved and unowned are shown as states rather than hidden. (Available.) Signal-ranked owner suggestions and attestation requests are not built.
Week 4 — lifecycle and evidence
Set lifecycle states. Active, dormant, pending decommission, decommissioned. Dormancy should be computed from observed authentication where the source exposes it, and shown as unknown where it does not — do not infer dormancy from silence.
Queue the orphans and the dormant. Orphaned production identities get a two-week clock: find an owner or begin decommissioning. Dormant identities get a disable-then-delete path with a rollback window. Both need a change ticket, because the first one that breaks something will define how the rest are treated.
Make attestation recurring. Quarterly for production, annually for the rest, with owner departures triggering an immediate re-attestation of everything they owned.
Keep the evidence. For every identity you should now be able to show: where it came from, what it is, who owns it and why you believe that, what it is for, and when it was last used. That evidence is what an auditor, an incident responder or a sceptical engineer will ask for, and it is what credential and access work in the following months will stand on.
Checklist
- Lifecycle state for every identity, unknown where data is missing
- Orphan and dormant queues with owners and tickets
- Attestation cadence configured and tied to offboarding
- Evidence retained per identity, retrievable in one place
With Trustivan: lifecycle states and per-identity evidence are available today, and so are the natural next steps: credential rotation, expiry and exposure findings, and effective access as an upper bound. Certification campaigns exist as an API with no console screen yet.
What not to do in the first 30 days
- Do not rotate secrets at scale. You do not yet know what depends on them. Rotation is a month-two activity and it goes smoothly precisely because ownership exists.
- Do not scope permissions yet. Without purpose statements, every scoping change is a guess.
- Do not hide the gaps. Unknown last-use, unclassified identities and unclaimed orphans are findings. A program that reports 100% coverage in week four is reporting its assumptions.
- Do not forget the agents. Coding agents, assistants with OAuth consents and automation bots belong in week 1’s inventory. They are non-human identities with unusually broad inherited authority, and week 3’s ownership question is the most important one you will ask about them.
After day 30
With an owned, classified inventory, the next two programs become tractable: credentials (which identity does each key belong to, how old is it, where has it been copied) and access (what can each identity actually reach, versus what it uses). Both depend on every week of this plan — and both are easier to explain to the people who have to do the work when each finding arrives with an owner already attached.