The technical problem is the same for everyone. What lands on your desk is not. These six guides take the same subject from a specific starting point, and each one answers the question that role is actually accountable for.
Start from your accountability.
Each guide assumes you already understand the general problem and gets straight to what you own, what you can evidence, and what to do first.
For cisos
The board question, the three numbers to hold, and what a defensible position looks like when you cannot fix everything at once.
Report four numbers, not a dashboard → Evidence and findingsFor internal auditors
What to request, what good evidence actually looks like, and the four findings that recur in almost every non-human identity audit.
Test the population, not the policy → Target architectureFor identity architects
Where non-human identity sits against IGA, PAM and ITDR, what each covers, and the seams between them that nothing owns.
Separate identity from authority → Paved roadFor platform engineers
Enumerate credentials by issuer, attribute ownership when the creator has left, and shorten lifetimes in stages without correlated outages.
Make the safe path the fast path → ObligationsFor compliance officers
Which obligations actually land on machine identity, which are inferred rather than stated, and what evidence satisfies each.
Map controls to artefacts → Buyer guidanceFor procurements
What to ask a vendor, how to design a proof of concept that produces a decision, and the commercial terms that matter in a consolidating market.
Two numbers decide the POC →Who owns what, and where it falls through
The recurring finding across every non-human identity programme is not a missing control. It is that the asset class sits between three functions and is fully owned by none of them. This is the ownership map we use when scoping a programme, and the last column is where the work usually stalls.
| Function | Usually owns | Usually assumes someone else owns |
|---|---|---|
| Identity and access management | Directory service accounts, joiner-mover-leaver, access reviews | Cloud IAM roles, CI/CD tokens, SaaS OAuth grants, agent credentials |
| Platform engineering | Cloud IAM, Kubernetes, CI/CD credentials, secrets tooling | Ownership attribution, review cadence, evidence retention |
| Security operations | Detection, incident response, alerting | Inventory completeness, credential lifetime policy, revocation testing |
| Application teams | The credentials they create for their own services | Everything after the service ships |
| Compliance and audit | Framework mapping, evidence requests, findings | Whether the population being sampled is complete |
The test that settles it
Ask each function which non-human identities they would list if an auditor asked tomorrow, then compare the lists. Where two functions each assume the other holds a category, that category is unowned, and it is almost always the one that shows up in the finding. Naming a single accountable owner is worth more than any tooling decision you will make this year.
What every role needs regardless
Four artefacts underpin all six guides. Whichever role you hold, these are what a conversation with any other function will come back to.
An inventory
With a named individual owner per identity and a stated method for how the list was produced.
Discovery method →A lifetime policy
Expiry automatic, extension requiring justification. The default matters more than the number.
Policy template →A review that executes
Reviewed against exercised permissions, complete only when revocations have actually been carried out.
Review runbook →A measured kill path
Revocation time as a number from a real drill, not an estimate of what would happen.
Kill paths →