A non-human identity inventory is a reconciled record of software principals that can authenticate or receive authority: service accounts, cloud roles, managed identities, Kubernetes service accounts, CI/CD jobs, applications, bots, integration users, devices, certificates, API clients, and AI agents. It is not the same as a vault export. One principal may use several credentials, and one poorly designed credential may be shared by several principals. Governance begins when the organization can identify the principal, its purpose, owner, runtime, effective access, dependencies, credentials, recent use, and retirement conditions.
NIST's cloud-native zero-trust model shifts application security from network location toward application and service identities with granular policy. That shift requires visibility. An unknown service account cannot be scoped, attested, reviewed, or safely disabled. The inventory should therefore join desired configuration with issuance and runtime evidence, expose uncertainty, and feed remediation work. A static spreadsheet assembled once for audit will age faster than the workloads it describes.
Define what counts as a non-human identity
Use a functional definition: any non-person principal that a control plane, application, platform, or resource recognizes for authentication, authorization, delegation, signing, or encryption. Include dormant and disabled identities because they affect recovery and reactivation risk. Keep credentials as linked objects: passwords, API keys, client secrets, private keys, certificates, tokens, and cloud key files. Also record identity issuers and trust mechanisms such as OIDC providers, SPIFFE trust domains, certificate authorities, and cloud security-token services.
Set boundaries across cloud accounts, SaaS, directories, source control, CI/CD, container platforms, data systems, integration middleware, observability, on-premises hosts, secrets stores, and AI tooling. Assign a source owner for each. Do not exclude vendor-created accounts or identities embedded in appliances. The secrets-management checklist helps locate credential stores; the identity inventory adds principals, relationships, effective privilege, and lifecycle decisions that secrets tools alone cannot supply.
Discover principals from independent evidence
Collect directory and IAM objects, cloud roles and service accounts, Kubernetes and service-mesh identities, application registrations, OAuth clients, database users, certificate subjects, vault references, CI variables, infrastructure-as-code declarations, deployment manifests, API gateway consumers, and agent registries. Then query runtime and access logs to discover identities that configuration scans missed. Repository secret scanning can identify credential material, but treat it as a lead; it may reveal a leaked key without proving the current principal or owner.
Normalize source identifiers without destroying provenance. Preserve cloud account, tenant, cluster, namespace, directory, issuer, subject, and environment because identical display names do not identify the same principal. Correlate cautiously using platform IDs, issuance records, deployment metadata, secret references, and observed authentication. Store match confidence and conflicting evidence. A wrong merge can assign one team's owner to another team's identity and make retirement dangerous; duplicate candidates are preferable to falsely confident consolidation.
Build the non-human identity inventory data model
| Field group | Required content | Evidence source | Decision enabled |
|---|---|---|---|
| Identity | Canonical ID, type, issuer, subject, tenant, environment | Control-plane API and issuance record | Uniqueness and trust boundary |
| Accountability | Technical owner, business owner, team, contact, approval | Service catalogue and repository ownership | Review and incident routing |
| Purpose | Workload, business process, resources, data, criticality | Deployment and architecture records | Justification and prioritization |
| Access | Direct roles, groups, inherited grants, delegation, conditions | IAM policy and resource policy | Effective privilege reduction |
| Credentials | Type, issuer, location, lifetime, rotation, last use | Vault, CA, STS and authentication logs | Secretless migration and exposure response |
| Lifecycle | Created, reviewed, last used, expiry, dependencies, retirement state | Audit, CI/CD and change systems | Recertification and safe deletion |
Represent relationships explicitly: principal runs as workload; credential authenticates principal; principal assumes role; role grants action on resource; human or team owns principal; deployment creates principal; another service depends on principal; agent acts on behalf of user. A graph model can help, but a relational design with stable keys and relationship tables also works. The critical requirement is answerability: what can this identity do, where is its credential, who approves it, what will break if it is disabled, and when was that evidence last verified?
Assign ownership and a precise purpose
Require a technical owner who can change the workload and a business or service owner who can justify its access. Team aliases alone are insufficient if they are stale, so join repository ownership, service catalogue, deployment metadata, cost tags, and recent committers. For unowned identities, infer candidates but do not silently certify them. Quarantine new privilege, notify likely teams, and set a decision deadline. High-impact unowned identities deserve incident-style handling because nobody can explain whether current use is legitimate.
Purpose should name the workload and action, not say integration or automation. Record target resources, allowed environments, expected schedule or volume, data classification, and whether the principal acts independently or on behalf of a user. Link to approved architecture and change records. Ownership review belongs alongside the wider identity governance lifecycle, but machine identities need deployment and runtime triggers in addition to HR events.
Calculate effective access and credential exposure
Direct role lists understate privilege. Resolve group membership, inherited organization policy, resource-based grants, trust policies, role chaining, permission boundaries, conditional rules, and delegated tokens. Record both potential and observed access; absence of recent use can support reduction but does not prove a grant is safe. Prioritize identities that combine broad privilege, long-lived credentials, external reachability, weak ownership, cross-environment use, or access to identity and secrets infrastructure.
Evaluate credential properties separately: exportability, storage, distribution count, lifetime, rotation, audience, proof of possession, and revocation. Prefer short-lived credentials issued after workload authentication or attestation. The SPIFFE overview describes short-lived SVIDs delivered through a Workload API; this illustrates how an identity record can reference a trust-based issuance mechanism instead of an embedded key. Where secrets remain, link them to every consumer and verify rotation end to end.
Turn inventory findings into lifecycle workflows
| Finding | Immediate action | Durable remediation | Closure evidence |
|---|---|---|---|
| No accountable owner | Restrict new privilege and route investigation | Assign owners or retire identity | Approved record and tested contact |
| Long-lived exported key | Locate copies and assess exposure | Federate or issue short-lived credential | Key revoked and exchange observed |
| Unused identity with dependencies | Disable in staged window | Remove dependency and configuration | No failures; object deleted after hold |
| Shared principal | Identify consumers and increase monitoring | Create distinct workload identities | Per-workload attribution in logs |
| Excessive effective access | Remove clearly unused dangerous grants | Redesign scoped role and conditions | Negative authorization tests |
| Unknown runtime issuer | Block or isolate unexpected trust | Register approved issuer and claims | Validated trust configuration |
Provision identities through reviewed infrastructure or platform APIs so inventory records appear with the workload. Trigger review on privilege change, new credential type, owner-team change, environment promotion, issuer change, unusual inactivity, and service retirement. Decommission in stages: stop new use, rotate or revoke credentials, disable the principal, observe dependent failures, remove grants and trust, then delete after a recovery window. Record rollback without leaving the old identity permanently active.
Measure inventory quality and risk reduction
Track source coverage, reconciliation lag, owner verification, purpose completeness, last-use freshness, unresolved identity matches, orphan count, shared-principal count, long-lived credential count, privilege-remediation age, retirement duration, and reactivation after disablement. Report both counts and risk-weighted exposure. A rising identity count can be healthy if ephemeral workload identities replace shared keys; a shrinking count can conceal undocumented reuse. Measure whether actions reduce blast radius and improve attribution, not whether the database looks tidy.
Join inventory records to security monitoring and incident response. An authentication event should resolve to identity, owner, workload, credential or issuer, expected resources, and current risk flags. Administrative changes need durable evidence described in the audit-log guide. During an exposed-key incident, responders should immediately know every consumer and grant; during an owner departure, reviewers should know which non-human identities remain under that person's informal control.
Govern the inventory as a shared control platform
Define stewardship for the schema, connectors, matching rules, risk scoring, exceptions, and remediation queues. Source teams should attest connector coverage and freshness; identity owners should certify purpose and access; security should challenge high-risk exceptions; platform teams should automate provisioning and retirement. Restrict who can change ownership or mark an identity reviewed, and retain evidence of those decisions. Provide APIs and exports so incident response, cloud security, secrets management, audit, and service catalogues consume one reconciled identity reference. Protect the inventory itself: it reveals privileged principals, credential locations, dependencies, and control gaps, making authorization, monitoring, backup, and recovery essential.
Non-human identity inventory takeaways
- Inventory principals, credentials, issuers, relationships, and runtime evidence separately.
- Discover across control planes, code, secrets systems, deployment metadata, and logs.
- Preserve platform scope and provenance; record uncertainty instead of forcing false matches.
- Require technical and business ownership plus a specific, bounded purpose.
- Calculate effective privilege and credential exposure, not direct roles alone.
- Drive provisioning, recertification, remediation, incident response, and staged retirement from the inventory.
Non-human identity inventory FAQ
Is a secrets vault an identity inventory? No. It can supply credential location and rotation evidence, but it usually does not represent every principal, effective permission, owner, runtime, issuer, dependency, or federated identity.
Should ephemeral identities be inventoried? Inventory their templates, issuers, policies, workloads, and issuance events rather than expecting one permanent row for every short-lived token. The model must support dynamic identity without losing accountability.
Can unused service accounts be deleted immediately? Disablement should be staged when dependency evidence is incomplete. Observe for failures, preserve an authorized rollback window, remove credentials and grants, then delete with closure evidence.
Conclusion
Non-human identity governance starts with a living model of who software is, what it can do, and who answers for it. Reconcile multiple evidence sources, distinguish principals from credentials, calculate effective access, and connect every finding to an operational workflow. The resulting inventory is not another asset list; it is the control surface for replacing shared secrets, reducing privilege, investigating actions, and retiring automation without surprise.