Non-human identity management is the practice of keeping service accounts, applications, workloads, integrations, and AI agents owned, scoped, and retired on time. It also governs the API keys, tokens, and other credentials those identities use. For employees, an HR feed drives that work. For non-human identities (NHIs), the drivers are the defaults each issuing platform enforces and the signals that say an identity's purpose has ended.
A pipeline creates a service principal in seconds. The first process likely to question it is an access review months later. The controls that close this gap already exist, spread across Google Cloud, AWS, Microsoft Entra, GitHub, and other issuing platforms. Few organizations run them as one program, and that is how identity sprawl across platforms builds up.
An identity team cannot approve each of these identities without becoming a ticket queue. It can set platform defaults, tie each identity to an owner whose lifecycle events carry weight, and let usage evidence decide retirement.
Key Takeaways
- At scale, non-human identity management is mostly configuration and event routing. A team that cannot approve every token can still set the defaults each platform enforces.
- Google Cloud blocks service account key creation by default for organizations created on or after May 3, 2024. Most older organizations have to enforce the constraint themselves.
- An NHI’s lifecycle should follow its owner. A person's mover or leaver event should create a reassignment task for the non-human identities they own.
- Usage evidence is one of the strongest retirement signals available. Investigate identities with no activity in the usage window, then disable and retire those with no remaining owner or purpose.
- AI agents fit the same model with two additions: a sponsor whose authority sets the limit on what the agent can do, and a scope that can change between tasks.
- One framework can cover people and NHIs. NIST CSF 2.0 covers identities and credentials "for authorized users, services, and hardware"; the cadence and the reviewer are what change.
Why Non-Human Identity Management Matters for Security Teams
Non-human identities hold production access, and the processes that retire human access do not reach them. Security teams answer for them anyway.
The population nobody's HR system reports on
For people, the HR system fires the events. A hire, transfer, or termination drives the joiner-mover-leaver process, and the IdP and IGA platform act on it. A new cloud service account, a CI token, or an approved SaaS integration fires nothing the identity team reads.
Each of those identities lives in the platform that issued it, under that platform's idea of an owner. Platforms that record service account ownership at all often default to whoever clicked "create." In Microsoft Entra ID, a user who registers an application is automatically added as its owner. That names a person at one moment and says little about who answers for the identity a year later.
What security teams inherit when nobody manages it
Security teams inherit the tail: working credentials that nobody can vouch for. An attacker who finds one can authenticate as it, and the controls built around human sign-in stay out of the path. The cost also surfaces in incidents. A responder who cannot name an owner cannot tell whether revoking a credential will break production, so the credential stays live while the team asks around.
The Challenges of Managing Non-Human Identities at Scale
Managing non-human identities at scale breaks an assumption under most identity governance: that a central team can review what the organization creates. The population grows wherever engineers work.
More issuing systems than administrators
A mid-sized estate might run cloud organizations, an Entra tenant, a GitHub organization, a CI/CD platform, and dozens of SaaS tenants, most administered by platform and application teams. A model that needs the identity team to touch each creation event assumes staffing nobody has.
Self-service creation is the point
Platforms made identity creation self-service on purpose. A developer who waits days for a service principal may reuse an existing credential instead, which is worse. The workable goal is to constrain self-service: decide which identity types, credential types, and lifetimes are allowed, and let the platform refuse the rest.
Every platform keeps its own evidence
Each platform records creation, last use, and credential age in its own console, and the logs do not reconcile by default. Answering "which identities did this departing engineer create?" takes several queries and a spreadsheet.
Where certification campaigns fall short
The usual fix is to add NHIs to the next round of access certification campaigns. A campaign asks managers to attest to access they can evaluate. Shown hundreds of service principals they cannot map to a system, a reviewer tends to approve, since revoking risks an outage and approving costs nothing. The orphaned accounts that matter most have no owner to route to at all.
Building a Non-Human Identity Lifecycle Management Strategy
A workable plan for non-human identities lifecycle management replaces the missing HR feed with three inputs. Guardrails act where identities are created, ownership follows the owner, and usage evidence decides retirement. The stages, from creation through rotation to retirement, are familiar. At scale, the question is where each transition gets its trigger.
Guardrails at the issuing platform
The provisioning workflow for NHIs should run through the issuing platform's own policy engine. A policy that blocks service account keys stops a class of long-lived credential at creation, with no ticket. A credential the platform refused needs no owner, no review, and no retirement.
That settles the choice between a guardrail and a gate. If the issuing platform can enforce a rule natively, set it there and drop the approval step. Keep human approval for paths the platform cannot constrain, such as classic personal access tokens (PATs) in a GitHub organization that has not restricted them.
Ownership that follows the owner
Each NHI needs a named human owner and a parent service, stored where the inventory can query them. If that owner changes teams, their mover event should open a task to reassign their service accounts and tokens, defaulting to the service's current owner. A leaver event does the same, with a deadline after which unclaimed identities are disabled.
Usage as the retirement signal
Many platforms record when an identity last authenticated or used a permission. That record is the deprovisioning trigger no HR event supplies.
A usage window produces candidates, and some are false positives: quarter-end and annual jobs look dormant most of the year. Investigate first, then disable with monitoring and a rollback plan. Retire the identity once the holding period passes without a reported break. Each lifecycle transition then has a signal source and a default action:
| Lifecycle trigger | Where the signal comes from | Default action |
|---|---|---|
| Identity created outside an approved path | The issuing platform's audit log or creation policy | Block at creation where supported; otherwise queue for an owner |
| Owner moves or leaves | The owner's own joiner-mover-leaver event | Reassign to the named service owner, or retire |
| No activity in the usage window | Platform last-used data, such as unused access findings | Investigate, then disable, hold, and retire if no valid use is found |
| Credential reaches its maximum lifetime | The platform's lifetime policy | Reissue if still needed; otherwise let it lapse |
| Integration or vendor retired | Procurement or service-catalog record | Revoke its tokens, disable its identities, and retain the audit history |
Best Practices for Governing Service Accounts, APIs, and Workloads
Non-human identity management best practices differ by identity type, because each issuing platform exposes its own native controls. The team that already runs each platform can switch them on.
| Platform control area | Native control | Risk it addresses |
|---|---|---|
| Google Cloud service accounts | iam.managed.disableServiceAccountKeyCreation organization policy | Creation of new persistent, downloadable service account keys |
| Entra apps and service principals | App management policies on password addition and lifetime | Creation of new password credentials, including credentials with lifetimes above the tenant’s configured limit |
| GitHub personal access tokens | Organization PAT policy: restrict, approve, cap lifetime | Unapproved or non-expiring tokens reaching organization resources |
| AWS IAM roles and access keys | IAM Access Analyzer unused access findings | Unused roles, access keys, passwords, and permissions going unnoticed; remediation remains manual |
Service accounts
For organizations created on or after May 3, 2024, Google Cloud enforces security baseline constraints by default. Among them, constraints block persistent service account keys and key uploads, and iam.automaticIamGrantsForDefaultServiceAccounts keeps the Editor role off default service accounts. Most older organizations have to enforce these themselves, so checking their status is a sensible first task.
Exceptions should be scoped to a single project, with an owner and an expiry, so the exception list becomes the review population. Workloads outside Google Cloud can often use workload identity federation instead of a stored key.
Application identities and service principals
Microsoft Entra app management policies restrict how a tenant's apps and service principals can be configured. A tenant can block new password secrets, which Microsoft describes as "the most easily compromised form of credential." It can also cap secret lifetimes and reject certificates from untrusted issuers, the point where certificates and cryptographic keys meet app governance.
API keys and access tokens
GitHub organizations accept classic and fine-grained personal access tokens by default. Owners can restrict either token type, and fine-grained tokens need administrator approval by default, except those created by organization owners. Classic tokens skip approval and have no expiration requirement unless the organization sets one, so restricting them is the stronger control.
A maximum lifetime policy, available for both token types, blocks members' non-compliant tokens without revoking them. The fine-grained default of 366 days is a platform setting, not a recommendation.
Many SaaS API keys come with no comparable policy engine. Secrets management keeps them out of code, endpoint scoping belongs to API security, and each key's lifetime should follow what it can reach.
Workload roles
AWS IAM Access Analyzer unused access findings list roles, IAM user access keys and passwords, and permissions with no activity in a specified usage window. The analyzer recommends a fix, such as deleting an unused role or deactivating an unused key, and someone still has to apply it. Route each finding to the role's recorded owner: unused permissions feed right-sizing, and unused roles feed retirement.
Managing AI Agents as the Next Generation of Non-Human Identities
AI agents enter the same model, with an owner, a scope, and a retirement trigger, but two properties change how those fields get filled in.
What changes when the identity plans its own actions
A service account runs code someone wrote and reviewed. An agent picks its next step from a goal, so the permissions it needs can shift between tasks. The distance between what it was approved for and what it attempts is the agent identity governance gap most programs have not closed.
NIST's National Cybersecurity Center of Excellence (NCCoE) raised this in a February 2026 concept paper on agent identity. It asks: "How do we establish 'least privilege' for an agent, especially when its required actions might not be fully predictable when deployed?" The paper poses questions and sets no requirements. For management purposes, three answers matter: who stands behind the agent, where its authority comes from, and when it ends.
Sponsor, scope, and an end date
The paper also asks how to handle "on behalf of" delegation and bind agent identity to human identity. The practical answer is a sponsor: a named human whose authority sets the limit on what the agent can do and whose mover and leaver events reach it. Its identity should also record where its authority comes from: an agent acting through a user's session under delegated identity ends with that session. An agent under its own workload identity needs a policy ceiling and an end date.
Framing the agent as the synthetic employee invites the HR comparison, with sponsor, scope, and end date standing in for manager, role, and contract term. Agent frameworks create credentials faster than a campaign can list them, so the end date belongs on the identity at creation.
Creating a Unified Identity Governance Framework
Governing non-human identities does not need a second framework. Organizations may adopt NIST CSF 2.0 voluntarily or under government policy. Its PR.AA-01 outcome reads "Identities and credentials for authorized users, services, and hardware are managed by the organization" (NIST CSWP 29). PR.AA-05 adds that permissions are "defined in a policy, managed, enforced, and reviewed."
An existing identity governance and administration program already has the policy model and the audit logging reviewers expect. Its entry rule is the decision that matters. Extend the framework to an NHI once an owner can be named. Hold identities without a nameable owner in a separate triage queue until someone claims them or they are disabled.
One framework, several cadences
The cadence and the reviewer differ. A person's access changes with HR events and a manager reviews it. An NHI's access changes with deployments and ownership events, and its owner reviews it. Frequency follows risk, reach, and the control framework the organization reports against.
By the time a certification runs, guardrails have refused the riskiest credentials and usage-based retirement has removed dormant ones. Reviewers see fewer identities, each with an owner who can judge it.
How NewCore Enables Continuous Non-Human Identity Governance
Native guardrails, ownership events, and usage evidence solve different parts of the lifecycle, but each platform stops at its own boundary. A Google Cloud constraint knows nothing about the GitHub token in the same pipeline. NewCore’s view is that an identity created in seconds by a pipeline or agent framework should not wait months for a review to end it. Agents are the sharpest case, each needing its own identity, owner, policy, and audit trail at machine speed.
- Identity Discovery: connects business systems, cloud platforms, infrastructure, and legacy identity systems, and continuously indexes identities, accounts, credentials, and access relationships across connected systems. Risk removed: separate platform inventories that do not reconcile into one list.
- Agentic Governance: classifies each agent by where its authority comes from. On-behalf-of agents last only while the human session is valid, delegated agents carry a delegated owner and bounded scope, and autonomous workloads run under a policy ceiling "from commissioning through retirement." Risk removed: retirement rules that ignore where an agent’s authority came from.
- Ask NewCore: answers "Which agentic identities have no verified owner?" with each identity's environment, permissions, and data reach, then lets a team assign an owner or revoke access. Risk removed: ownership gaps found by spreadsheet.
NewCore works alongside existing guardrails, the IdP, IGA, secrets management, and PAM. It connects HRIS, directories, cloud, SaaS, and AI platforms for discovery across connected systems. It applies a lifecycle by authority source to agents and answers ownership questions in plain language. Each identity those platforms create can then carry an owner and an end.
Non-human identities are created at machine speed. Retire them at the same speed. Request a Demo →
Frequently Asked Questions
Do Google Cloud's default service account key restrictions apply to existing organizations?
Google Cloud enforces them for all organizations created on or after May 3, 2024, and some created between February and April 2024 may also have them. Other organizations keep their existing policies, and administrators there can enforce the same constraints. Before enforcing the key creation block, find the workloads that still create keys, since they will fail once it is on.
Should non-human identities be included in access certification campaigns?
Some should. An identity whose owner can judge its access belongs in review at a frequency its risk justifies. That evidence often maps to the same control objectives as human reviews. Identities nobody can own tend to get rubber-stamped, so hold them out until they have an owner or are disabled, and document that queue.
How is non-human identity management different from privileged access management?
Privileged access management (PAM) vaults, brokers, and records the use of high-privilege credentials, many of them non-human. Non-human identity management covers the whole population and asks who owns each identity, whether it is still used, and what happens when its owner leaves. The two overlap on privileged service accounts, and many programs run both.
What metrics show that a non-human identity program is working?
Useful measures include the share of NHIs with a named owner and the share with an expiry. Add the count unused beyond the usage window and the time from an owner's departure to reassignment. Trend direction says more than any single reading. Targets depend on the estate's starting point and on what its control framework expects.
How long should an API key or access token stay valid?
It depends on what the credential reaches and how hard it is to rotate. A token with write access to production earns a shorter life than a read-only reporting key. Platform defaults, such as GitHub's default 366-day maximum for fine-grained tokens, are starting points. Prefer short-lived credentials issued at run time wherever the platform supports them.
