How to build a non-human identity governance program

Non-human identity governance programs fail when organizations treat machine credentials like human accounts — creating them through individual requests, assigning ownership after the fact, and discovering scope through audit rather than design. The program must establish five components that operate continuously, not as periodic reviews: inventory closure, ownership assignment, lifecycle enforcement, scope controls, and complete revocation.

Non-human identities outnumber human users in enterprise cloud environments by ratios that often exceed 10:1. These credentials are created through multiple paths: cloud consoles, infrastructure-as-code, CI/CD pipelines, application deployment, and developer automation. The governance gap creates operational risk when credentials persist beyond their intended context, accumulate excessive permissions, or become orphaned when services are decommissioned.

Program components

A non-human identity governance program requires five components that address the fundamental differences between machine and human credential lifecycles. Each component must define what it controls, what fails without it, and who owns its operation.

The inventory component addresses the discovery gap between registered credentials and the full credential population. Many organizations operate with partial inventories — credentials registered through official channels — while unknown credentials accumulate through developer automation, emergency provisioning, and service deployment outside governance systems.

Inventory must cover service accounts in directories and cloud platforms, API keys in secrets managers and code repositories, workload credentials assigned through cloud identity services, agent tokens in OAuth authorization servers, and certificates in certificate authorities and deployed infrastructure. Discovery must include static credential scanning in code repositories, secrets detection in environment configurations, and cloud CIEM queries for unregistered workload identities.

The ownership component creates accountability that survives personnel changes. Individual ownership fails when the owner leaves; team ownership with explicit succession paths provides more durability. Ownership must be recorded before credential issuance — not assigned retroactively from orphaned credential audits.

The lifecycle component creates artificial lifecycle events for credentials that have no natural expiry. All long-lived credentials must have explicit maximum lifetimes — no permanent credentials by default. Rotation schedules must execute before expiry, not only on compromise. Decommission processes must include mandatory credential revocation gates.

The scope enforcement component addresses scope drift — the condition where a credential's permission set grows beyond its documented purpose. Scope must be documented at issuance with specific resources, APIs, and actions defined. Periodic scope reviews must verify that credentials still require their assigned permissions.

The revocation component ensures complete invalidation of primary credentials and all derivative tokens, session grants, and secondary credentials created using the primary credential. Revocation must be immediate for confirmed compromise, complete across all derivative credentials, and evidenced with timestamps for detection, decision, and completion.

Mechanism consequence

Each program component operates through specific mechanisms that produce different failure modes when absent or incomplete.

Inventory discovery
Credential discovery operates through multiple detection paths because machine credentials are created outside central provisioning systems. Static analysis scanning identifies hardcoded credentials in code repositories. Secrets detection tools find credentials in environment variables, configuration files, and container images. Cloud CIEM queries identify service accounts, managed identities, and workload credentials not registered through official channels.

# Logic pattern / pseudocode — validate for your platform
# AWS unregistered service account discovery
aws iam list-roles --query 'Roles[?!contains(Tags[?Key==`OwnerTeam`].Value, `registered`)]'

# Azure unregistered managed identity discovery 
az identity list --query '[?!tags.OwnerTeam]'

# GCP service account ownership gap
gcloud iam service-accounts list --filter='NOT labels.owner:*'

Discovery gaps create governance blind spots where credentials operate without oversight. The program must reconcile registered credential inventories against platform queries and secrets scans to identify the governance gap size.

Ownership assignment mechanisms
Ownership assignment requires three mechanisms: pre-issuance approval workflows, ownership transfer processes triggered by personnel changes, and escalation paths for orphaned credential discovery. Team ownership models must include succession plans that do not depend on individual knowledge.

Ownership failures create credentials that outlive their operational context. When the original creator leaves or changes roles, no remaining team member can answer whether the credential is still needed, what its scope should be, or when it should be revoked.

Lifecycle enforcement mechanisms
Lifecycle controls operate through automated expiry enforcement, scheduled rotation triggers, and decommission process gates. Credentials exceeding 30-day lifetimes require rotation schedules. Service decommission workflows must include credential revocation as a mandatory gate, not an optional cleanup step.

Without lifecycle enforcement, credentials persist indefinitely. Rotation happens reactively in response to compromise incidents rather than proactively on schedule. Decommissioned services leave active credentials that provide unauthorized access to resources the service no longer needs.

Scope drift detection
Scope enforcement requires documentation at issuance, periodic entitlement reviews, and automated detection of permission expansion. Scope documentation must specify which resources, APIs, and actions the credential requires for its stated function.

# Logic pattern / pseudocode — validate for your platform
# AWS IAM policy expansion detection
aws iam list-attached-role-policies --role-name [service-role]
aws iam get-role-policy --role-name [service-role] --policy-name [inline-policy]
# Compare against documented scope at issuance

# Azure role assignment growth
az role assignment list --assignee [managed-identity-id] --query '[].roleDefinitionName'
# Compare against baseline permissions

Scope drift occurs when credentials accumulate permissions beyond their documented purpose. This happens through permission inheritance, role assignment expansion, and emergency access grants that are not reverted.

Complete revocation mechanisms
Revocation requires inventory of derivative credentials: OAuth grants, session tokens, API keys generated by the primary credential, and trust relationships established using that credential. Platform-specific revocation mechanisms vary by provider and token type.

Incomplete revocation leaves active session tokens and derivative credentials that can continue operating after the primary credential is disabled. OAuth grants made by a service account, for example, can survive service account deletion unless explicitly revoked.

Implementation guidance

Program implementation follows three phases: inventory establishment, lifecycle control deployment, and scope enforcement activation. Each phase builds on the previous phase's outputs.

The logic patterns and platform queries throughout this article are suitable for direct use or as inputs to AI-assisted tooling. Teams implementing this program at scale will find the structured, repeatable nature of each component — discovery queries, ownership workflows, rotation triggers, revocation checks — well-suited to automation under human direction.

Phase 1: Inventory establishment

Begin with credential discovery across all creation paths. NHI discovery must cover console creation, infrastructure-as-code deployment, CI/CD pipeline automation, and developer tools. Run discovery tools in parallel: static scanning for hardcoded secrets, secrets detection in runtime environments, and cloud platform queries for unregistered identities.

# Logic pattern / pseudocode — validate for your platform
# Multi-path credential discovery approach
1. Static analysis: truffleHog, git-secrets, or similar on all repositories
2. Runtime scanning: secrets detection on container images and environments 
3. Cloud queries: CIEM tools or native platform APIs for service accounts
4. Certificate discovery: scan certificate stores and expiry tracking

Establish ownership records for discovered credentials. Every credential must have a named owner — either an individual with team backup or a team with succession plans. Credentials without clear ownership get flagged for assignment or revocation.

Reconcile registered inventories against discovery results to quantify the governance gap. The gap between known and total credentials indicates program maturity and risk exposure.

Phase 2: Lifecycle control deployment

Establish maximum lifetime policies for all credential types. No permanent credentials — all long-lived credentials require defined expiry dates. Temporary credentials for CI/CD and application deployment should expire within hours; service account credentials for long-running services require rotation schedules.

Deploy automated rotation for credentials with lifetimes exceeding 30 days. Rotation must happen on schedule, before expiry, not only when compromise is detected. Test rotation procedures in non-production before applying to production credentials.

Create decommission process gates that require credential revocation. Service shutdown workflows must include credential inventory review and revocation confirmation. Decommission cannot complete while active credentials remain.

Implement ownership transfer processes for personnel offboarding. All credentials owned by departing personnel must transfer to team ownership or be revoked. Ownership transfer must complete before access removal.

Phase 3: Scope and revocation controls

Document credential scope at issuance. New credential requests must specify required resources, API access, and operational boundaries. Scope documentation becomes the baseline for future entitlement reviews.

Schedule periodic scope reviews for all active credentials. Review frequency depends on credential privilege level and operational context. High-privilege credentials require more frequent review than read-only access.

Test complete revocation procedures that cover primary credentials and all derivatives. Revocation testing must verify that OAuth grants, session tokens, and trust relationships are invalidated alongside the primary credential. Platform-specific revocation behavior varies — test each credential type separately.

Establish revocation evidence collection that logs discovery timestamps, revocation decisions, and completion confirmation. Evidence must demonstrate that no active sessions remain after revocation.

Implementation checklist

Phase 1 — Inventory (4 items)
- [ ] NHI discovery covers all credential creation paths (console, IaC, CI/CD, developer automation)
- [ ] Registered credential inventory reconciled against cloud platform CIEM queries and secrets detection scans
- [ ] Every discovered credential has ownership record or is flagged for assignment
- [ ] Credential population includes service accounts, API keys, workload credentials, agent tokens, and certificates

Phase 2 — Lifecycle controls (5 items)
- [ ] No permanent credentials — all long-lived credentials have defined maximum lifetime
- [ ] Rotation schedule defined and automated for all credentials exceeding 30 days lifetime
- [ ] Decommission process includes mandatory credential revocation gate
- [ ] New credential issuance requires stated purpose, defined scope, and named owner
- [ ] Ownership transfer process triggered on personnel offboarding for all NHI owned by that individual

Phase 3 — Scope and revocation (4 items)
- [ ] Credential scope documented at issuance
- [ ] Periodic scope review scheduled for all active credentials
- [ ] Revocation covers primary credential plus all derivative tokens, grants, and session credentials
- [ ] Revocation evidence logged with timestamps for discovery, decision, and completion

Sources

https://owasp.org/www-project-application-security-verification-standard/