Non-human identity management needs an operating model

Non-human identity management fails when a company treats it as a secret-scanning project or a vault rollout. A working program has to answer five questions continuously: what identities exist, what each one can reach, who accepts responsibility for it, how its credentials change without an outage, and when the identity should disappear.

That sounds administrative until a production integration outlives its creator, a deployment token gains access to a second environment, or a database password cannot be rotated because nobody knows which binary still uses it. I have seen teams spend more time proving a credential is safe to change than changing it. The program has to make that proof routine.

An identity is not the same as its credential

A non-human identity is a principal that software uses to authenticate and receive authorization without a person acting interactively. Service accounts, cloud roles, application registrations, bots, CI jobs, Kubernetes service accounts, certificates, and AI agents can all qualify. An API key or password is usually a credential held by an identity, not the identity itself. A role binding or database grant is access assigned to that identity.

This distinction decides whether the inventory will support real decisions. If a scanner finds the same API token in a repository, a CI variable, and a container image, that is one credential with three exposures. If two services share that token, the company may have one credential, one vendor account, and two workloads with no independent attribution. Counting every sighting as an identity inflates the queue. Counting only accounts hides the exposed copies.

Model four related records: identity, credential, access grant, and workload. The identity record says what authenticates. The credential record says how proof is presented and where it lives. The grant says what the principal can do. The workload record says which running code uses it. Link them rather than forcing them into one wide spreadsheet row.

Set a clear scope boundary. Include identities created in cloud IAM, SaaS administration, source control, CI/CD, databases, certificate authorities, Kubernetes, automation platforms, observability tools, and AI tooling. Include third-party integrations even when a vendor hosts the principal. Exclude anonymous network endpoints and encryption keys that never authenticate a principal, but link those assets when compromise of an NHI would expose them.

The awkward cases need written rules. A shared technical account used by people is still a human access control failure, not a healthy NHI. A personal access token used by a scheduled job is both: it inherits a person's lifecycle and acts as a machine credential. Put it in the NHI inventory, mark the identity type as person-bound, and prioritize its replacement.

Inventory must join creation, storage, and use

No single discovery source can produce a complete NHI inventory. Identity providers know registered principals but may not know where their credentials were copied. Vaults know stored secrets but not every hardcoded duplicate. Cloud logs show recent use but miss dormant credentials. Code scanners find strings but cannot always prove which account or permission they represent. The inventory has to reconcile several control planes.

Start with authoritative creation sources: cloud IAM APIs, application directories, certificate authorities, database catalogs, SaaS admin APIs, Kubernetes, and CI platforms. Add storage sources such as managed secret stores, CI variables, configuration systems, and password vaults. Then add exposure and use evidence from code scanning, artifact scanning, audit logs, gateway logs, and authentication events.

Each record needs enough context to drive an action. I use these minimum fields:

• Stable identity ID, native source ID, type, environment, and creation source
• Human owner role, owning team, application, business purpose, and lifecycle state
• Credential types, storage locations, issue time, expiry, last rotation, and last observed use
• Effective permissions, reachable resources, cross-account trust, and production access
• Discovery source, confidence, exception status, review date, and retirement condition

A nightly collector can normalize native records into a simple contract. Keep raw source payloads elsewhere for investigation; the program table should remain understandable to an engineering manager.

identity_id: nhi:payments:prod:settlement-worker
source: cloud-iam
source_id: settlement-worker
type: workload-role
environment: production
owner_role: payments-platform-lead
application: settlement
purpose: publish-cleared-batches
credentials:
  mode: federated
  stored_secret: false
access:
  - resource: clearing-queue
    actions: [publish]
last_used_at: 2026-08-08T14:22:17Z
review_due_at: 2026-10-01T00:00:00Z
retire_when: settlement-v2-cutover-complete

The shape matters more than the storage product. It lets you ask a question that separate dashboards cannot answer: which production identities have no accountable owner, have not been observed recently, and still hold write access? In a relational copy of the inventory, the triage query can be this plain:

SELECT identity_id, source, owner_role, last_used_at
FROM nhi_inventory
WHERE environment = 'production'
  AND write_access = true
  AND lifecycle_state = 'active'
  AND (owner_role IS NULL OR last_used_at < CURRENT_DATE - INTERVAL '90 days')
ORDER BY owner_role NULLS FIRST, last_used_at;

Expected output is a review queue with one row per identity, not a count of secret findings. Validate the collector with sampling: select identities from each source, trace them to a running workload, confirm their effective grants, and look for credentials outside the declared store. Coverage without reconciliation gives false confidence.

Ownership belongs to a role with authority

Every active NHI needs one accountable owner who can approve its permissions, fund the work to change it, and accept an outage caused by retirement. The person who created the account is evidence, not necessarily the owner. Creators leave, vendors install integrations, and platform engineers often create identities for application teams they do not operate.

Assign ownership to an organizational role, then resolve that role to a current person through the team directory. For example, payments-platform-lead survives a staffing change better than an email address. Store both the stable role and the current assignee. When the role becomes vacant, route the identity to the role's manager and put a deadline on reassignment.

Ownership should follow the service that benefits from the identity. The platform team can operate issuance and rotation infrastructure, security can set policy and challenge risky exceptions, but the application owner knows whether a credential can be removed. Making security the owner of every NHI creates a queue with responsibility but no operational knowledge.

Use an acceptance workflow for discovered identities. The proposed owner confirms purpose, workload, environment, required access, credential method, and retirement condition. Rejection must name a different owner or trigger escalation; it cannot return the record to an unowned pool. For high-impact identities, require the manager of the service to accept ownership rather than letting a ticket assignee close the task.

Tie ownership to operating events. A service transfer moves its identities. An employee departure searches for person-bound tokens and creator relationships. A vendor offboarding reviews every integration principal before the contract closes. A repository archive checks CI tokens, deploy identities, webhooks, and cloud trusts attached to it.

Measure orphan time, not just orphan count. A count can fall because the inventory changed. The age between discovery and accepted ownership shows whether the process works. Production identities with privileged access should have a much shorter ownership deadline than read-only development automation.

Risk follows reachability and recoverability

A long-lived secret is not automatically the riskiest item, and an expired certificate is not automatically harmless. Prioritize an NHI by what an attacker could reach, how easily they could use the credential, whether defenders would see the use, and how safely the team could revoke it.

Use a small set of factors that engineers can verify:

• Privilege and reachable assets, including indirect role assumption and cross-account trust
• Credential exposure, exportability, storage, lifetime, and number of known copies
• Use context, such as internet origin, production scope, vendor custody, or shared workloads
• Detection quality, attribution, recent behavior, and ability to distinguish instances
• Revocation readiness, rollback path, dependency knowledge, and tested recovery time

Do not collapse those fields into a mysterious risk score. A score helps sort, but the record must state why the item is high risk and what change would lower it. Static credential, write access to production billing, present in two CI systems, no tested revocation is actionable. Risk 92 is not.

Reachability includes chains. A CI identity that can update a deployment manifest may not access customer data directly, but it can change the workload that does. A monitoring agent with permission to read environment variables may collect credentials from other processes. A SaaS integration with directory read access may reveal enough structure to support a later attack. Graph analysis helps here, but a disciplined review of role trusts and control-plane permissions catches many dangerous paths.

Recoverability changes the order of work. A broadly privileged credential with a proven one-command revocation and a tested failover path may deserve action after a narrower credential that nobody can replace without editing an abandoned application. The second identity is operationally stuck, which makes every future incident slower.

Exceptions need an expiry and a compensating control. If a vendor accepts only a static API key, restrict its source where possible, reduce its permissions, monitor its use, store it once, and set a review date. Permanent exception is another name for forgotten design debt.

Rotation is a production migration

Rotation succeeds only when the old credential stops working and every legitimate consumer uses the replacement. Creating a new secret and updating the vault completes issuance, not rotation. The dangerous failures happen between issuance and revocation: an old container image still uses the prior value, a disaster recovery job wakes up monthly, or a vendor retains a copied token.

NIST SP 800-57 Part 1 calls the permitted time for a key's use a cryptoperiod and explains that the period depends on factors such as the key type, use, environment, and consequences of compromise. That is more useful than a universal 90-day slogan. The program should define maximum ages by credential class and risk, then shorten them when automation makes change cheap.

For every rotatable credential, document a state machine: issue, distribute, observe, revoke, verify, and recover. Prefer systems that let old and new credentials overlap briefly. Update a canary consumer first, watch authentication and business metrics, roll the new value to remaining consumers, then revoke the old value. After revocation, search logs for rejected use of the old credential and investigate every caller.

A rotation run should leave evidence with the identity ID, old credential fingerprint, new fingerprint, affected workloads, approver, timestamps, validation checks, revocation response, and rollback decision. Never log the secret value. Fingerprints must identify versions without allowing reconstruction.

Test the failure path before scheduling mass rotation. If the new credential fails, can the team restore the previous version while it remains valid? If revocation has happened, can it issue a third credential quickly? Does the application reload a secret or require a restart? Does the client cache sessions longer than the credential lifetime? Those answers belong in the runbook.

HashiCorp Vault illustrates a different model with dynamic secrets. Its documentation says each dynamic secret has a lease with a duration and may be renewed or revoked; expiry can trigger automatic revocation. This reduces the number of calendar rotations, but it does not remove lifecycle work. Teams still have to protect the broker identity, bound the lease, handle renewal failures, revoke compromised leases, and remove unused roles.

Track rotation completion as verified revocation, not jobs executed. Useful measures include the share of in-scope credentials with automated rotation, revocation failures, consumers seen using an old version after cutover, and time from declared compromise to invalidation. A green scheduler with active old credentials is a failed control.

The best managed secret is the one you remove

Replace static credentials with workload identity, federation, managed identity, or dynamically issued credentials when the target system supports them. Rotation limits exposure time; secretless authentication removes the portable artifact that teams copy, lose, and forget. This is a design program, not a vault migration.

Cloud platforms already provide practical routes. AWS IAM roles issue temporary credentials to workloads, and IAM Roles Anywhere uses trusted X.509 certificates for workloads outside AWS. Microsoft Entra Workload ID covers application and service identities and supports federation scenarios. Google Cloud Workload Identity Federation exchanges credentials from an external identity provider for short-lived access instead of requiring a service account key. Each option still needs narrow claims, permissions, and trust configuration.

SPIFFE makes the separation especially clear. A workload receives a SPIFFE ID and an SVID after the platform attests properties of the workload. The SPIFFE Workload API can deliver short-lived X.509 or JWT identity documents and updated trust bundles without shipping a bootstrap secret inside the application. SPIFFE advises X.509-SVIDs where possible because bearer JWTs can be replayed if stolen.

Short-lived does not mean safe by itself. A token issued every five minutes can still grant administrator access, accept a vague audience, or come from a weakly attested workload. Google Cloud's federation guidance recommends immutable attributes, conditions for multi-tenant issuers, and dedicated service accounts for applications. Those controls prevent a broad trust rule from turning an ephemeral token into an easy privilege path.

Migrate by class, not credential by credential. Pick one pattern such as CI-to-cloud access, Kubernetes-to-database access, or cross-cloud service calls. Define the approved identity exchange, permission boundary, audit fields, and failure behavior. Convert several workloads, write the reusable module, then prohibit new static credentials for that class.

Keep an explicit residual list for systems that cannot federate. Those identities need a vault, automated delivery, shorter age limits, tested rotation, source restrictions, and stronger monitoring. The goal is not to claim zero secrets. It is to make every remaining secret an intentional compatibility decision.

Lifecycle controls must sit in delivery workflows

An NHI program scales when creation, change, review, and retirement happen through paths engineers already use. A quarterly spreadsheet campaign cannot keep pace with deployment pipelines, ephemeral environments, SaaS installations, or AI agents that acquire new tool permissions.

Creation should require purpose, owner role, application, environment, requested access, credential method, and retirement condition. Policy can reject person-bound tokens in production, wildcard permissions, secrets without an approved store, or identities without an owner. Provide reusable infrastructure modules so the compliant path is also the faster path.

Change events matter as much as creation. A new permission, trust relationship, credential type, environment, or owner should trigger review proportional to risk. Record the change against the stable identity ID, because deleting and recreating a cloud principal can otherwise break the history.

Admission control needs an emergency path because production incidents do not wait for a normal review. Let an on-call engineer request a time-limited identity or grant through an approved workflow, require an incident or change record, notify the owner, and expire the access automatically. Review emergency use after the incident. Do not let urgency create a credential whose cleanup depends on somebody remembering a ticket.

For infrastructure as code, evaluate the proposed principal and grants before deployment. A policy check can reject a production role with wildcard actions, a trust policy that accepts an unrestricted external subject, or a credential resource without an owner tag. Save the decision and the tested configuration hash. Runtime discovery still matters because administrators and SaaS installers can create identities outside code, but prevention cuts the queue before it grows.

Define a break-glass rule for the NHI control plane itself. If the broker, vault, or federation service is unavailable, applications should fail according to their business risk, not all in the same way. A payment writer may use a narrowly scoped cached credential for a bounded time, while an administrative automation job should stop. Document who can invoke fallback, what gets logged, and how the temporary path is revoked after recovery.

Access review for machines differs from a human certification campaign. A manager cannot judge a cryptic service account name from a list. Give the reviewer purpose, workload, recent use, effective permissions, reachable production assets, credential posture, and the last deployment that referenced the identity. Ask whether the service still needs the access and whether the current method remains approved.

Retirement needs both disable and delete phases. Disable or revoke access first, watch for failed legitimate calls through a defined observation window, then remove credentials, grants, trusts, vault entries, pipeline variables, and the identity record from source systems. Preserve the historical record and evidence. If deletion happens first, incident responders lose the context needed to explain old logs.

Build control gates around measurable service levels. Track inventory coverage by authoritative source, ownership acceptance time, privileged identities without recent review, static credentials eligible for federation, overdue rotations, verified revocations, and retirement lag. Avoid celebrating the raw number of identities removed; teams can improve that number by merging workloads onto dangerous shared accounts.

Buy control-plane coverage, not a category label

The NHI vendor market combines products with different jobs under similar language. Decide which control plane is missing before comparing feature lists. Most companies need a portfolio, but fewer products are better when one platform can meet the required depth without forcing unsafe migrations.

Cloud-native identity services are the first layer for workloads that live mostly inside one provider. AWS IAM roles, Microsoft managed identities and workload identities, and Google Cloud workload federation can remove static credentials close to the runtime. Their strength is native attestation and authorization. Their limit is cross-cloud, SaaS, legacy, and consolidated governance coverage.

Secrets managers and privileged access products store, issue, lease, rotate, and revoke credentials. HashiCorp Vault is common where teams want programmable brokers and dynamic secrets. CyberArk spans secrets, certificates, workload access, and privileged identity controls. Cloud secret stores reduce operating work inside their own ecosystems. Test connector depth, high availability, root credential handling, client behavior during an outage, and whether rotation reaches the target system rather than only updating stored values.

NHI discovery and posture platforms focus on finding identities and secrets across clouds, SaaS, code, vaults, and identity providers, then relating ownership, privilege, exposure, and use. Current vendors in this group include Entro, Astrix, Oasis Security, and Token Security, though their coverage and emphasis differ. Treat every coverage claim as a hypothesis: give the product a known test set containing an orphaned service account, a dormant vendor token, a duplicated secret, a federated role, and a cross-account trust, then compare what it finds and how it explains the result.

Workload access control products broker service-to-service authentication and policy across mixed environments. Aembit is an example in this area, while SPIRE is an open-source implementation of the SPIFFE standards for attested workload identity. These options solve a runtime identity problem; they do not automatically govern every SaaS token or legacy account. Measure application changes, protocol support, attestation strength, policy granularity, failure mode, and audit attribution.

Secret scanning products cover code, collaboration systems, images, and other exposure locations. GitHub secret scanning, for example, uses patterns and validity checks for supported credential types, and push protection can block some secrets before they enter a repository. This is detection and prevention at an exposure point, not a complete identity inventory. A finding must still map to a principal, owner, permissions, copies, and revocation action.

Certificate lifecycle tools and PKI platforms deserve a separate workstream when certificates dominate the machine identity estate. They discover certificates, automate issuance and renewal, and protect trust chains. Identity governance products may handle service-account certification and ownership workflows well, especially when the company already operates them for people. Neither should receive credit for credential types and runtime paths it cannot observe.

Run a proof against your data and operating events. Score source coverage, relationship accuracy, ownership workflow, permission analysis, rotation safety, revocation evidence, APIs, exportability, and degraded behavior. Include false merges and false splits: a platform that calls five copies five identities or merges five workloads behind one token will distort decisions. Ask how easily you can extract the normalized inventory if the vendor changes direction.

A 90-day program should prove one complete loop

A first program increment should prove discovery through retirement for a bounded estate, not promise company-wide visibility. Choose one production application family with cloud identities, CI credentials, a database account, and at least one SaaS integration. It is broad enough to expose seams but small enough to finish.

During days 1 through 30, define the data model, ownership policy, risk factors, and approved credential patterns. Connect authoritative creation sources and at least one use source. Reconcile the sample manually, assign owner roles, and record unknowns instead of guessing. Baseline person-bound credentials, static production secrets, privileged access, and identities with no recent use.

During days 31 through 60, fix the highest-risk paths and automate one rotation class. Replace one static pattern with federation or dynamic issuance. Exercise issuance, canary deployment, revocation, detection of old use, and recovery. Put the evidence in the same record used for review.

During days 61 through 90, add creation and retirement gates to delivery workflows. Disable a set of unused identities, observe failures, and complete deletion. Run the owner review with useful context, publish the control measures, and decide which discovery, brokering, vault, or governance gap actually warrants a vendor purchase.

Give the program one executive owner and a small working group across security, platform engineering, IAM, and application teams. The executive removes policy conflicts; the working group owns the data contract and paved paths. Application teams remain accountable for their identities. Without that division, security accumulates tickets while developers create new exceptions.

Budget for operational repair, not only licenses. Old applications may need reload support, vendor integrations may need new authentication methods, and shared identities may need to split before attribution works. A Team & AI Audit from oleg.is can expose where engineering ownership and automation capacity are too thin to operate controls like these, while fractional CTO leadership can drive the resulting delivery changes.

The first honest success is not a perfect dashboard. It is one identity whose owner is known, access is justified, credential can change without panic, old proof is verifiably dead, and retirement follows the service lifecycle. Repeat that loop by identity class until creating an unmanaged credential feels as abnormal as deploying an unreviewed binary.