ContactBook a demo

Decommission Tracking

Tracked from discovery.Retired on purpose.

Most non-human identities are created in a hurry and deleted never. Trustivan tracks each one's lifecycle state from discovery, flags the stale and the orphaned, and turns decommissioning into an approved, evidenced proposal instead of a leap of faith — carried out at the provider by a person.

AvailableExecution at a provider: future capabilityM2 · ownership & lifecycle
Book a demoSee Ownership & Lifecycle

Quarantine first · a second person approves · the provider change stays with people

Lifecycle stages

Discover. Go stale. Propose. Quarantine. Retire.

Five stages, each producing a record the next one depends on — and that an auditor can read two years later.

Track the state

Discovered, active, inactive, stale, orphaned, quarantined, decommissioned — recomputed from each sync and ownership change

Propose with approval

Decommission and revoke proposals approved by a second person, with the identity’s relationships and reach in view

Retire without fear

Quarantine inside the platform first — every action denied at the gate — while the provider-side change is made by a person

How it works

A decommission that answers the questions auditors ask later

Who owns it, what state it is in, what it can reach and what it is related to — known before anything is proposed, and carried for the identity's whole life.

Lifecycle states

States are records that travel with the identity

Every identity carries a lifecycle state — discovered, active, inactive, stale, orphaned, quarantined, decommissioned — set from sync evidence and ownership. A stale or orphaned identity raises a finding with its owner, its credentials and its reach, so retirement starts from evidence rather than a hunch.

  • Stale from reported last use, which AWS provides for roles; unreported stays unknown.
  • Orphaned when no owner resolves: a tag naming nobody is not an owner.
  • Absent from a sync is not deleted: the identity keeps its history.
Approvals

Approvers decide with the blast radius in front of them

Approval is only meaningful if the approver understands what is being removed. Trustivan shows the identity's effective access, the resources it reaches and the relationships attached to it — then records the decision, made by someone other than the proposer, with that context.

  • Effective access, not role names: what the identity reaches across accounts, as an upper bound.
  • A second person approves, and execution stays behind a switch and a dry run.
  • Every approval is audited in the hash-chained trail, so later reviews can see what was known.
Decommission

Retire the identity. Keep the evidence.

Safe decommissioning is a sequence: confirm it is stale, list what it is related to, quarantine it in the platform, have the owner make the change at the provider, keep the record. Orphans — identities with nobody to ask — take the quarantine-first path, which removes risk at the gate without deleting history.

  • Relationships from the graph before anything is proposed — the workloads, trusts and grants attached.
  • Quarantine is immediate: a quarantined identity is denied every action at the runtime gate.
  • Provider-side disable and revoke have no executor yet; today the workflow proposes, approves and records each step.
Execution at a provider: future capability
See the orphaned NHI use case

What you get

A lifecycle with a paper trail

From discovery to decommission, every step leaves a record attached to the identity it concerns.

Lifecycle states

Every identity’s current state and the sync or decision that put it there

Approval trail

Who proposed and who approved each remediation, with the evidence they saw

Expiry findings

Credentials approaching or past expiry, flagged the moment the date passes

Orphan queue

Identities with no resolvable owner, with a quarantine-first path

Safe retirement

Quarantine in the platform first; the provider-side removal proposed, approved and carried out by a person

Lifecycle evidence

The complete record from discovery to decommission, exportable for audit

Example

A one-week migration identity, eight months later

Temporary identities are only temporary if something notices. This one kept its access because nobody did.

HighStalePrivilegedOwner unconfirmed

Temporary migration role stale for 241 days, still holding write access

Why
A role created for a one-week data migration has not been used in 241 days and still holds write access to production
What
aws-role/migrate-2025 (IAM role)
Who
Owner: Data services (inferred from a Team tag) · creator tag names a departed contractor
Where
AWS account analytics-prod · environment prod
How
AWS reports the role last used 241 days ago; its trust policy still lets the migration host assume it
Blast radius
Write on 9 resources, 2 classified high impact · effective access, an upper bound
Recommendation
Confirm with Data services, then delete the role at AWS and keep the record
Action
Notify owner · quarantine in the platform · propose decommission for second-person approval
Evidence
IAM snapshot · role last used (AWS-reported) · ownership record
Nine questions, source records attached. Missing evidence is shown as unknown.Illustrative finding · sample environment

Related capabilities

Retirement is where good lifecycle ends

Ownership keeps it honest, rotation findings keep its credentials visible, discovery catches what appeared unannounced.

All solutions

Give every identity a beginning and an end.

See how TRUSTIVAN connects identity, credential, access, agent and action context into one control plane.

Book a demo