NHI governance for platform engineers

Why this lands on you

Non-human identities are created at the moment an engineer needs something to work. That makes platform teams the de facto issuing authority for most of the estate, whether or not anyone wrote that down. When a security or audit finding arrives, it arrives with your name on it, because you own the issuers.

That is also the leverage. Security teams can ask for an inventory; platform teams can produce one, because the issuers are enumerable and the humans are not. Nearly every successful NHI programme we have seen was carried by a platform team that treated identity issuance as a platform capability rather than a compliance obligation.

Finding what you issued

Enumerate by issuer. Asking teams what credentials they hold produces an undercount every time, because the credentials people forget are exactly the ones that matter.

• Cloud IAM: users with access keys, roles with trust policies, and the age of every key. Key age alone usually identifies the worst tail.
• Kubernetes: service accounts, bound roles, and any long-lived token secrets that predate projected tokens.
• CI/CD: repository and organisation secrets, deploy keys, and self-hosted runner credentials. Include archived repositories; the credential is still valid.
• Secrets store: what is stored versus what is dynamically issued. The static half is the problem.
• Authorization server: registered OAuth clients, especially ones created for a proof of concept that outlived it.
• SaaS admin consoles: third-party OAuth grants. Usually created by business users, invisible to engineering, and the source of the Salesloft/Drift pattern.

Expect the true count to be several times the tracked count. That gap is the finding, and it is more useful to a budget conversation than any risk score.

Attributing ownership when the creator has left

This is the genuinely hard part, and it is not solved by a spreadsheet column. Signals that work, in rough order of reliability:

1. Infrastructure-as-code provenance. If the identity is declared in a repository, the CODEOWNERS file and commit history give you a current team, not a departed individual. This is the strongest argument for moving identity creation into IaC even where it is more work up front.
2. Deployment metadata. The workload consuming the credential usually carries labels or tags identifying its service and team.
3. Call-graph evidence. What calls this identity, and who owns that? Ownership propagates along the dependency graph more reliably than it survives in documentation.
4. Last-touch. Weakest signal, and it produces false attribution to whoever most recently responded to an incident. Use only to open a conversation.

Where none of these resolves, the honest answer is a documented exception with a review date rather than an arbitrary assignment. An owner who does not know they own something is worse than a recorded gap, because it produces false assurance.

Shortening lifetimes without an outage

The instinct is a cutover: set a maximum lifetime and enforce it. That produces a simultaneous, correlated failure across every consumer that cannot rotate, usually at the worst moment. Staged reduction is slower and far safer.

1. Measure the current distribution before changing anything. You need to know how many credentials have no expiry at all.
2. Alert before enforcing. Run a period where approaching expiry generates a ticket but nothing breaks. The tickets are your inventory of unautomatable consumers.
3. Halve the maximum, then wait a full cycle. Each halving surfaces the next tranche of consumers that cannot automate. Fix those, then halve again.
4. Register the residue. Some consumers genuinely cannot rotate: appliances, embedded devices, vendor software with no API. These need an exception with an approver and a review date, not a quiet permanent extension.

The same staged logic applies to certificates under the CA/Browser Forum reductions, which move to 100 days in March 2027 and 47 days in March 2029. Treat those dates as a forcing function you can rehearse against rather than a deadline you meet at the end.

The paved road

Cleanup without a paved road is a project you repeat. The governed path has to be the fastest path, or engineers will route around it exactly as they did the first time.

• Self-service issuance that is quicker than creating a static key by hand, with owner and expiry captured at creation because they are required fields rather than a later audit.
• Runtime-attested identity by default: cloud workload identity federation, Kubernetes projected tokens, SPIFFE-issued SVIDs, so that the easy path issues no static secret at all.
• Dynamic credentials for datastores, minted per use rather than stored.
• Expiry as a default, with extension requiring justification rather than expiry requiring approval. Inverting that default does more than any policy document.

Pushing back well

You will be asked for things that are not achievable on the timeline offered. Two responses that work:

Trade scope for date. "Every credential inventoried by quarter end" is usually not deliverable. "Every credential that can reach production data, inventoried with owners, by quarter end, and the remainder by the following quarter" often is, and it is a better risk outcome because it front-loads blast radius.

Convert a demand into a measurement. When asked whether you can revoke a compromised credential quickly, do not answer from intuition. Run the drill, record the time, and report the number. A measured four hours is a fundable problem; an unmeasured assurance is a future incident.

Frequently asked questions

How do you inventory non-human identities across a platform?

Enumerate by issuer rather than by asking teams. The reliable sources are cloud IAM access keys and roles, Kubernetes service accounts and token secrets, CI/CD repository and organisation secrets including archived repositories, the secrets store split into static versus dynamically issued, registered OAuth clients on the authorization server, and third-party OAuth grants in SaaS admin consoles. Asking teams what they hold reliably undercounts, because the forgotten credentials are the risky ones.

How do you find the owner of a service account when the creator has left?

In order of reliability: infrastructure-as-code provenance via CODEOWNERS and commit history, deployment metadata on the consuming workload, and the call graph of what depends on the identity. Last-touch data is the weakest signal and tends to misattribute ownership to whoever last handled an incident. Where nothing resolves, record a documented exception with a review date rather than assigning an owner who does not know they own it.

How do you shorten credential lifetimes without causing outages?

Stage the reduction rather than cutting over. Measure the current distribution, run an alert-only period where approaching expiry raises a ticket but nothing breaks, then halve the maximum lifetime and wait a full cycle before halving again. Each stage surfaces exactly the consumers that cannot automate, in a manageable tranche rather than as one correlated failure.

What is a paved road for non-human identity?

A self-service issuance path that is faster than creating a static credential by hand, captures owner and expiry as required fields at creation, defaults to runtime-attested workload identity so no static secret exists, and mints datastore credentials dynamically. The defining property is that the governed path is the path of least resistance; if it is not, engineers will route around it exactly as they did before.

Should identity creation move into infrastructure as code?

Where practical, yes, and ownership attribution is the strongest argument. An identity declared in a repository inherits a current owning team from CODEOWNERS and retains its history when individuals leave, which solves the problem that makes retrospective cleanup expensive. The cost is more work at creation time; the benefit is not needing to run an attribution exercise later.