Non-human identities need an owner beyond the next secret rotation

A secret vault can tell you when a credential expires without telling you whether the job using it should still exist. That gap matters to an identity lead: a perfectly rotated credential can keep an obsolete integration running with excessive access for years.

Non-human identity governance starts with the work being authorised. Identify the scheduled export, application service, deployment pipeline or vendor integration, then connect it to its identity, credentials and permissions. Those connections reveal who can change its access and who would be affected if it stopped.

Four things that should not become one inventory row

The workload is the software doing the work. The identity is the principal it presents to another system. The credential proves that identity, while the permission determines what the resource allows it to do. A workload may use several identities, and several workloads may share one identity. Both arrangements need to be visible.

Suppose a finance integration reads invoices from one service and writes payment proposals to another. Counting its two API keys tells you little about its authority. You need to know which principal each key represents, which operations that principal can perform and whether unrelated jobs use the same access.

Do not put the secret value into the inventory. Keep a reference to its protected location, issuance mechanism and maintenance owner. The useful question is whether someone can trace an observed request back to an approved workload and accountable team without copying credentials around.

Short-lived credentials change the control point

SPIFFE defines standards for identifying software systems, including short-lived identity documents called SVIDs that workloads can use to authenticate. That can reduce dependence on manually distributed, long-lived credentials. It does not decide which business team owns a service or which database records the service should be allowed to change.

With automated issuance, governance moves upstream. Review the rules that decide which workload receives an identity and the permissions granted to that identity. If an obsolete deployment can still obtain fresh credentials, their short lifetime has not retired its access. The issuer and its configuration become important dependencies in the access lifecycle.

Kubernetes makes the distinction concrete. Its service-account documentation recommends obtaining short-lived tokens through the TokenRequest API rather than relying on indefinitely valid tokens. But token lifetime is only part of the design. A service account still needs an intended workload, permissions and someone responsible for changing or removing it.

Apply that reasoning across technologies without forcing them into one implementation. A legacy batch tool using a stored password, a cloud workload receiving federated credentials and a Kubernetes service account have different mechanisms. They can still share requirements for purpose, ownership, least necessary access and a tested way to stop use.

Make ownership survive a reorganisation

Consider a hypothetical scheduled export created by a team that has since split into two departments. The old team mailbox still receives expiry notifications, the job still runs, and neither successor team knows whether a supplier consumes its output.

Immediate credential replacement might interrupt legitimate work without resolving ownership. First identify the executing workload, destinations, recent use and downstream dependency. Assign an accountable successor who can confirm the purpose and approve retention, restriction or retirement. Use an operational contact or on-call team for failures, rather than relying on the original developer’s name.

The minimum useful inventory therefore links:

• The workload and environment to an accountable owner and operational contact.
• Each identity to the resources and operations it is allowed to use.
• Credential types to their issuer, expiry or rotation mechanism and consumer.
• The business purpose to a review event and a retirement trigger.

A contract ending, service replacement or team change should prompt a decision. Lack of recent use is evidence to investigate, not automatic proof that a quarterly or disaster-recovery job is redundant.

Retirement must reach the accepting system

Ask what actually stops access: disabling the workload, withdrawing its ability to obtain credentials, removing a resource permission, invalidating existing credentials, or some combination. These controls may operate on different timescales.

Kubernetes documents an important example. A service validating bound service-account tokens through TokenReview can detect deletion of the associated objects. A client using OIDC validation can continue accepting a token until its expiry. The same lifecycle event can therefore have different consequences depending on the recipient’s validation method.

Test the retirement path with a representative non-production workload: stop new issuance, remove the intended access, try an already issued credential and check the resource’s observed behaviour. Include dependent jobs in the test so that the team can distinguish a deliberate denial from an unexpected outage.

Start with one critical integration and make its full access chain explainable. Once the owners and consumers are known, credential rotation can be planned around the integrations that must keep working. Rotation then becomes one maintained part of an owned lifecycle.