Non-Human Identity Management Best Practices: IT Playbook

Non-human identity management best practices start with an inventory, a named human owner and access that expires when its workload does. The strongest programs also replace persistent secrets with workload identities, review permissions against actual use and preserve evidence of every change and retirement.

A service account can be technically healthy and still be a governance failure. The credential works, but nobody can explain who approved it, what application depends on it or how you'd shut it down without an outage. That's the gap where IT operations, security engineering and application owners need a shared process.

What counts as a non-human identity?

A non-human identity (NHI) is a credentialed identity used by software, infrastructure, devices or automation rather than an individual signing in. The inventory needs to include both the identity that receives permissions and the credential or trust relationship used to authenticate it.

Microsoft Entra describes workload identities as applications, service principals and managed identities. Google Cloud service accounts represent non-human users. AWS IAM roles can supply workloads with temporary credentials. These platforms use different labels, but the governance questions don't change much: what can act, on whose authority and for how long.

Identity type	Typical use	Governance question	Preferred evidence
Directory service account	Legacy scheduler or Windows service	Which system breaks if the account is disabled?	Service configuration and owner sign-off
Cloud workload role	Application accessing storage or a queue	Which resources and actions are permitted?	Role policy, trust policy and activity record
App registration or service principal	Application-to-API access	Who granted consent and what scopes remain?	Permission grant and owner attestation
API key or integration token	SaaS-to-SaaS connection	Who can revoke it and what depends on it?	Key inventory and rotation record
Certificate-backed machine identity	Service authentication	Who renews it and what uses the private key?	Certificate inventory and renewal test
CI/CD deployment identity	Pipeline deploying infrastructure	Which repository, branch and environment can assume it?	Federation trust and deployment logs
AI agent identity	Tool or service access initiated by an agent	What actions can the agent delegate or approve?	Tool permissions, sponsor and execution trail

An API key isn't always a separate principal. It may authenticate as an application or account that holds the actual permissions. Record both objects, or a revoked key can appear to close a risk while another key still authenticates as the same principal.

Which non-human identity management practices matter most?

The essential practices are continuous discovery, ownership, secure provisioning, least privilege, credential lifecycle management, monitoring and decommissioning. Each practice needs a named operator, an acceptance test and a record that an auditor or incident responder can retrieve.

1. Discover and classify

   Export identities from directories, cloud IAM, SaaS integrations, CI/CD platforms and certificate stores. Reconcile the results with deployed workloads and secret scans; mark unknown owners as open findings.

   IAM and platform teams

2. Assign accountable owners

   Require a human business or application owner, a technical custodian, a backup and an explicit workload dependency. Reject owner fields that contain only a team mailbox.

   Application owner and IT operations

3. Replace or constrain credentials

   Choose managed identity, federation or temporary roles first. Where persistent credentials remain, put them under controlled storage, access and rotation with an exception owner.

   Platform engineering and security

4. Review permissions and behavior

   Compare granted rights with documented purpose and observed use. Investigate privilege escalation, unexpected token use and cross-environment access before attesting.

   Security and resource owners

5. Retire and prove closure

   Identify dependent systems, remove access in a safe sequence and preserve disablement, revocation and validation evidence. Keep a recovery plan until the retirement's confirmed.

   Service owner and change manager

Discover identities that never entered the ticketing process

Discovery can't rely only on approved provisioning requests. Engineers create roles in cloud consoles, applications mint tokens, vendors request OAuth consent and pipelines receive credentials during deployment. A ticket-only register won't see those paths.

Start with platform-native exports. Pull service accounts and privileged groups from directories, service principals and credential metadata from Entra, IAM roles and access keys from AWS, service accounts and user-managed keys from Google Cloud, and integration identities from business SaaS systems. Add code and configuration secret scanning to find credentials that aren't represented in the expected vault.

Reconcile by stable identity ID rather than display name. Store the source platform, tenant or account, environment and first-seen timestamp. Keep the inventory synchronized with source systems; a spreadsheet can support an initial review, but it shouldn't pretend to discover identities automatically.

Make a person accountable for each identity

An owner approves why the identity exists and whether its permissions are still justified. That's a judgment call, not a clerical step. A technical custodian knows how to rotate or disable it. The two roles can be held by one person in a small team, but the responsibilities shouldn't be confused.

For an orphaned service account, don't immediately delete the credential because the owner is missing. Treat it as an exception: identify execution hosts, scheduled jobs, resource logs and recent changes. Assign an interim custodian, document a proposed owner and escalate high-privilege cases. What you're aiming for is either a confirmed owner or a controlled retirement.

Prefer identity federation over long-lived secrets

AWS recommends temporary credentials through IAM roles for workloads. Microsoft's guidance favors managed identities for supported Azure services and workload identity federation when external workloads can exchange trusted tokens. Google Cloud advises avoiding user-managed service account keys where another authentication method is available.

For GitHub Actions deployments, OpenID Connect can exchange a workflow identity for a short-lived cloud token. The cloud trust policy still matters: constrain which repository, environment and workflow context may request access. A temporary token attached to an overly broad role isn't least privilege.

Where a vendor requires a static API key, record the exception, put the key in a managed secret store and restrict who can read it. Rotate with a dual-credential or staged cutover when supported, validate the consumer and only then revoke the old key. Rotation without a dependency check can turn a security improvement into a production incident, and you'll own that outage.

Enforce least privilege at the resource and trust layers

Least privilege covers more than a role name. Inspect the actions allowed, the resources in scope, the identity allowed to assume the role and the conditions under which access is granted. Separate read-only reporting jobs from deployment identities and separate production from test workloads.

AWS IAM Access Analyzer can identify unused roles and permissions. Google Cloud recommends dedicated service accounts rather than sharing broad default accounts across applications. Use these signals as review inputs. They aren't automatic deletion orders. An infrequent disaster-recovery job may be legitimate even if its last-used timestamp is old.

Monitor machine behavior, not employee login patterns

Machine identities often operate continuously, so a midnight login isn't necessarily suspicious. Better alerts don't watch the clock. They look for an identity accessing a new resource, acquiring new permissions, creating another credential, assuming a different role or authenticating from an unexpected workload context.

Correlate identity events with deployment, change and application logs. Route an alert to the technical custodian and security team, and make sure they've got a way to identify affected workloads. The response should tell a compromised credential apart from a legitimate deployment that's changed its access pattern.

Offboard identities with dependency-aware revocation

An unused credential and an unused identity aren't the same thing. An identity can have several credentials, trust paths or delegated permissions, and they won't all show up in one console. A service retirement isn't complete until its reachable access paths are closed and dependent applications have been checked.

The OWASP Non-Human Identities Top 10 for 2025 places improper offboarding first. It also calls out secret leakage, overprivileged identities, long-lived secrets and identity reuse. Use those risks to prioritize the backlog. They're not proof that every stale account has been exploited.

How should IT teams inventory and assign ownership?

IT teams should keep an NHI register that connects each principal to its workload, human owner, technical custodian, credential method, permissions, last-use evidence and retirement plan. The template below is a usable starter register, with fictional example rows and an acceptance checklist.

Template

Non-human identity register template

Copy the register into your tracker or download it. The three rows are fictional examples with no real credentials; replace them with your own identities.

Identity register

Identity ID	Platform	Workload	Human owner	Custodian	Authentication	Access scope	Last-use evidence	Next review	Retirement trigger
svc-invoice-export	Directory, production	Invoice export scheduler	Finance systems lead	Windows operations	Vaulted password	Read billing export folder	Scheduler log	Next quarterly review	Scheduler replaced
role-order-worker	AWS, production	Order event processor	Commerce engineering lead	Cloud platform	Temporary IAM role	Specific queue and bucket	Cloud activity record	Next quarterly review	Service decommissioned
app-partner-sync	Entra, production	Partner data sync	Integration lead	Identity engineering	Federated workload identity	Approved API permissions	Service principal sign-in log	Next quarterly review	Integration contract ends

Acceptance checklist before an identity counts as governed

• Stable principal ID, platform, tenant and environment recorded
• Human owner and technical custodian confirmed
• Purpose and dependent workload documented
• Authentication method and credential storage identified
• Permission scope and trust conditions reviewed
• Last-use signal and known scheduled use documented
• Rotation or federation decision recorded
• Disablement, revocation and rollback path documented
• Next review date and retirement trigger assigned
• Approval and evidence links retained

DOCXDownload Word (.docx)XLSXDownload Excel (.xlsx)Free, no sign-up. Store references to secrets, never the secret values.

Don't place secret values, private keys or token bodies in the register. Store only a reference to the secret manager or credential metadata. It's an accountability system, not a second secrets repository.

The acceptance checklist inside the template is the gate between discovered and governed. The review should be able to answer every line without an engineer reconstructing the application from memory.

For a deeper ownership worksheet, see the service account ownership matrix. For evidence collection, use the service account audit checklist.

Who should approve, operate and review machine identities?

Application owners should approve business purpose and continued need, while IAM and platform teams implement access and security teams challenge exceptions. Audit teams need evidence, but they shouldn't become the default operational owner of every credential.

Activity	Accountable owner	Operator	Independent check	Evidence
Create a new NHI	Application owner	IAM or platform team	Security for elevated scope	Approved request and policy diff
Grant privileged access	Resource owner	IAM administrator	Security reviewer	Scope justification and approval
Rotate a persistent secret	Application owner	Platform or service custodian	Change reviewer	Cutover and validation record
Review existing permissions	Application owner	IAM analyst	Security for exceptions	Attestation and remediation ticket
Disable a retired identity	Service owner	IAM or platform team	Change or incident lead	Revocation proof and dependency check

A practical separation-of-duties rule is that the person who can expand an identity's access shouldn't be its sole reviewer. Small teams can use a second approver outside the platform group rather than building a complex committee.

Which authentication pattern fits each workload?

Choose authentication based on where code runs, whether the resource supports federation and how easily the identity can be revoked. The goal isn't to force every legacy service into the same mechanism. It's to make exceptions explicit and progressively remove persistent credentials.

Workload context	Preferred pattern	What to verify	Common fallback risk
AWS-hosted application	IAM role with temporary credentials	Role trust and resource policy	Embedded long-term access key
Azure-hosted service	Managed identity where supported	Resource assignments and sign-in evidence	Client secret stored in configuration
Google Cloud workload	Attached service account or federation	Dedicated account and narrow roles	Downloaded user-managed key
GitHub Actions deployment	OIDC federation to a cloud role	Repository, environment and subject conditions	Shared deployment secret
Legacy on-premises service	Controlled service account with vault	Dependencies, rotation test and operator access	Shared password with no owner
Third-party SaaS integration	Scoped OAuth grant or vendor-supported identity	Consent, scopes, expiry and revocation	Broad API key shared by integrations

Microsoft's Conditional Access for workload identities applies to certain service principals, not every kind of machine identity. Its documentation says managed identities aren't covered by that policy and that appropriate Workload Identities Premium licensing is required to create or modify scoped policies. Don't describe that control as a universal machine-identity firewall.

A security architecture review should also ask whether an agent or integration can mint additional credentials. Restricting the initial token won't contain an incident if the identity can create new privileged principals or delegate authority without review.

How can teams run an evidence-backed access review?

An evidence-backed NHI review pairs a human attestation with actual permission and activity data. A checkbox that says approved isn't enough when nobody has examined what the account can access or how the workload authenticates.

1. Freeze the review population

   Export the identities in scope and preserve the timestamp and source. Flag missing owners, shared identities and identities with elevated access.

   IAM analyst

2. Attach the evidence

   Link current role grants, trust relationships, credential metadata, last-use data and known dependency records. Don't attach plaintext secrets.

   Platform team

3. Request an explicit decision

   Ask the accountable owner to retain, reduce, replace, investigate or retire the identity. Require a reason for privileged exceptions.

   Application owner

4. Execute and verify remediation

   Create a tracked change, verify the resulting permission state and check dependent workload health. Preserve the before-and-after evidence.

   IAM operator

5. Close the attestation

   Record reviewer, decision date, evidence references and unresolved exceptions. Schedule the next review based on risk and change frequency.

   Review coordinator

For example, an application owner may approve an invoice export account because the job still runs. The IAM analyst then finds that the account's also able to modify unrelated production databases. The correct decision is retain with remediation, not an unqualified approval. Don't sign off just because the job runs. The ticket should identify the excess permission, responsible operator, deadline and post-change evidence.

Keep a separate exception queue for identities whose owners can't be found, credentials that can't rotate and workloads whose access can't yet be reduced. Each exception needs a sponsor, compensating control and expiration or review date. An exception without a next action is just an undocumented permanent privilege.

What should an auditor be able to trace?

An auditor should be able to trace a sampled identity from creation approval to current owner, privilege review, credential changes and retirement. The evidence trail should identify the source system and the person who made each decision.

NIST SP 800-53 Revision 5 is a catalog of security and privacy controls, not a blanket legal requirement for every private company. Map the program's account management, least privilege, identifier management and service authentication controls to your applicable framework and contract requirements. Don't label an internal review cadence as a NIST-mandated interval without a specific obligation.

What metrics show whether NHI governance is working?

Useful NHI metrics measure coverage, accountability, risky authentication and completed remediation. A falling count of identities can be misleading if discovery coverage is shrinking, so pair every trend with the population and collection method.

Metric	Calculation	Interpretation
Owner coverage	Identities with confirmed human owner / discovered identities	Accountability, not security by itself
Evidence coverage	Identities with recent permissions and activity evidence / identities reviewed	Whether attestations have substance
Persistent-secret exposure	Active identities using static secrets / discovered identities	Migration backlog, segmented by risk
Overprivilege backlog	Open excessive-permission findings by severity and age	Whether access reduction is progressing
Retirement completion	Retired workloads with verified access revocation / retired workloads sampled	Whether offboarding closes access paths
Review closure	Decisions completed with evidence / decisions due	Process execution and exceptions

For each metric, define the denominator. A team that discovered new identities this month may show worse owner coverage even though discovery improved. That's a useful signal, and it's no reason to hide the new identities.

How should a team roll out these practices in 30 days?

A 30-day NHI improvement sprint should establish a reliable inventory, accountable owners, a small high-risk remediation queue and a repeatable review. Treat it as an example sprint, not a compliance deadline or a promise of complete coverage.

Period	Deliverable	Exit criterion
Days 1 to 7	Inventory source map and first export	Major identity stores named and export owners assigned
Days 8 to 14	Owner and dependency enrichment	Critical identities have accountable owners or tracked exceptions
Days 15 to 21	Privilege and credential remediation	Highest-risk cases have approved changes or time-bound exceptions
Days 22 to 30	Access review and retirement rehearsal	Decisions, evidence and rollback tests recorded

Start with a representative production application and one automation pipeline. Follow their credentials end to end, including who can create them and who can revoke them. If the process works on that sample, you can automate source collection and expand to more platforms. If it doesn't, fix the process before adding volume.

What should happen when a machine credential is exposed?

When a machine credential is exposed, containment has to cover the identity and its downstream access. A password change alone won't do it. Identify the principal, credentials, granted roles, reachable resources and dependent jobs before choosing the safest containment sequence.

For a confirmed leak, revoke or disable affected credentials according to incident severity, investigate logs for unauthorized use and rotate any downstream secrets the identity could read. Preserve the timeline, cloud audit events and change evidence. Recovery should verify that legitimate jobs use replacement credentials and that the compromised path doesn't work anymore.

Microsoft's guidance for risky workload identities includes examining assigned credentials, replacing compromised credentials and remediating secrets the principal could access. The OWASP risk list also highlights leaked secrets and reused identities. Both point to the same operational lesson: one credential can open more than one access path, so don't stop at the first revoked key.

An emergency runbook should say who can approve immediate disablement, who's able to contact application owners and who validates service recovery. Don't make the incident commander search a wiki for the sole engineer who knows the secret's consumer.

How should SaaS integrations and AI agents be governed?

SaaS integrations and AI agents need the same owner, permission and retirement controls as traditional service accounts. Their extra risk is delegated authority, and it's easy to miss: an integration or agent may call another service, retain a token or create work on behalf of a person without that person's direct involvement.

For an OAuth integration, record the application publisher, tenant, consent grant, approved scopes, resource owner and method for revoking the grant. Separate the integration's technical administrator from the business owner who requested the data flow. They're different jobs. Revisit consent after vendor changes, new scopes or a terminated business relationship. A vendor account that's still active after contract expiry shouldn't silently retain access to production data.

An AI agent adds an action boundary. Document which tools it can call, which resources each tool can reach and which actions require a human approval. The agent's sponsor should approve its business purpose, while the platform custodian maintains authentication and logs. Neither role's optional. Don't give an agent an administrator token merely because a human administrator initiated the workflow.

If an agent delegates a task to another agent or integration, retain the initiating request, delegated identity, granted scope and resulting action in the execution record. That chain makes an investigation possible when the downstream action looks legitimate in isolation. Where the platform can't preserve the chain, constrain the agent to low-risk actions until a stronger audit mechanism is available.

The practical review isn't whether an agent has an owner field. It's whether the owner can show a current list of tools, permissions and approval boundaries, then stop the agent's access without searching through several unrelated services.

How do third-party grants get retired?

Third-party grants should be retired as part of vendor offboarding. Don't leave them to the next generic account review. Start with the contract owner and the application administrator, identify every tenant where the integration was approved and list its tokens, certificates and service principals.

Revoke grants in the relevant provider, then check that dependent automations either have a replacement integration or are stopped on purpose. Save the revocation record and confirm that later access attempts fail. Don't assume they do. If the integration created secondary credentials, those need their own closure evidence.

How do legacy service accounts fit into the program?

Legacy service accounts need a controlled path to better authentication, not an overnight rule that every password must disappear. A Windows service, batch scheduler or older vendor application may support only a username and password. The first improvement is knowing where the credential's used and who can change it safely.

Inventory service configuration, scheduled tasks, hostnames, vault references and the identity's group memberships. Find interactive sign-in rights and administrative privileges the job doesn't need. Separate a service's run identity from the account engineers use for maintenance.

When a platform supports a managed service identity or another passwordless mechanism, test migration in a representative environment. Preserve a rollback plan, monitor the next scheduled execution and have the application owner approve the cutover. A technically successful password rotation isn't enough if a rarely used month-end job fails later, so check the calendar before you declare victory.

If migration isn't feasible, document why and set compensating controls: restricted logon locations, limited privileges, a managed secret, monitored use and a rehearsed recovery procedure. Assign an exception review date. Don't declare the legacy identity permanently exempt.

Which exceptions deserve the fastest attention?

Prioritize exceptions by the access they expose and how much you trust your evidence. An ownerless identity with production write access and an unknown credential location is more urgent than a documented read-only batch account whose owner has a tested rotation procedure.

Exception signal	Initial response	Evidence to close it
Owner unknown, privileged access	Assign interim custodian and investigate dependencies	Confirmed owner or approved retirement
Credential exposed in source control	Treat as suspected compromise and contain	Replacement credential, investigation and revocation proof
Production identity shared with test	Separate trust and permissions by environment	Distinct principals and verified policy scopes
Long-lived key with no rotation method	Assess federation or managed secret storage	Migration record or time-bound exception
Unused identity with unclear job schedule	Confirm execution calendar before disablement	Dependency check and controlled retirement

An exception register shouldn't be a bare list. Include the risk, sponsor, owner, compensating control, next action and review date. Don't mark a finding resolved because it's been moved into a spreadsheet. Resolution means the exposure's changed or a responsible decision-maker explicitly accepted the remaining risk for a defined period.

Where does a service account ownership review tool fit?

A service account ownership review tool fits after discovery and before access remediation. It helps collect nominations, decisions and evidence, but it doesn't replace the identity provider, secrets manager or enforcement platform.

The IT Lead's service account ownership workflow focuses on CSV import, owner nomination, attestations and an audit trail. It isn't a password rotation engine, account scanner or live directory synchronization service, so you'll still need your platform tools for enforcement. That narrower role can help teams close an accountability gap while platform tools continue to control actual permissions.

Frequently asked questions about non-human identity management

Non-human identity management questions usually concern ownership, rotation, review cadence, privileged access and safe retirement. The answers depend on the workload and the controls available in each platform.

• OwnershipService Account Ownership Matrix
• AuditService Account Audit Checklist