Non-Human Identity Access Reviews: The Next IGA Challenge

Enterprises no longer have an access-review problem limited to employees. They have a governance problem that increasingly spans service accounts, bots, automation accounts, API identities, cloud workloads, machine identities, and other identities that operate without a human logging in every morning.

If you are a CISO or IAM leader, the question is no longer simply whether employees are being certified every quarter. The question is whether every identity capable of accessing enterprise resources has an accountable owner, a legitimate purpose, appropriate entitlements, and a mechanism for periodically proving that its access is still required.

That is the practical purpose of non-human identity access reviews. They extend access certification beyond the workforce and into an identity population that frequently sits outside HR-driven lifecycle processes.

Non-human identities need certification for the same reason humans do

Human access reviews exist because circumstances change.

An employee changes departments. A project ends. A temporary entitlement is no longer required. An administrator changes responsibilities.

Exactly the same thing happens to non-human identities.

A service account may originally be created to integrate two applications. The integration is later replaced, but the account survives.

An automation account may receive temporary production access during a migration. The migration finishes, but the entitlement remains.

A CI/CD identity may accumulate permissions as additional deployment requirements are added over several years.

The difference is that there may be no human user associated with the account whose lifecycle naturally triggers a review.

This is why non-human identity governance cannot stop at discovery and inventory.

SailPoint, for example, now explicitly supports machine-account certification for NHIs such as service accounts, bots, RPAs, and other machine accounts, with the objective of validating whether those accounts still have a legitimate purpose and appropriate permissions. SailPoint

The governance question remains familiar:

Does this identity still need this access?

But answering it for a non-human identity requires very different context.

The first challenge is determining what is actually being reviewed

For an employee, the governance model is relatively intuitive:

Person → Account → Entitlement → Resource

For a non-human identity, the relationship can be more complicated:

Business Process → Service Account → Credential → Entitlement → Application

or:

Workload → Cloud Identity → Role → Cloud Resource

or:

Automation → API Identity → Token/Secret → Scope → API

This distinction matters.

A secret is not necessarily the identity. A certificate is not necessarily the identity. An API key is not necessarily the identity.

They may be credentials used by an identity to authenticate.

A useful governance model therefore separates:

Identity → Credential → Entitlement → Resource

Consider a payment-processing service account.

The organization might discover:

Identity: svc-payment-prod
Credential: Secret stored in a vault
Entitlement: Database Write
Resource: Production Payment Database

Rotating the secret does not answer whether the service account should still have database-write permission.

Similarly, certifying that the service account still exists does not answer whether every entitlement assigned to it remains necessary.

A meaningful NHI access review needs to understand the complete relationship.

Ownership becomes the foundation of NHI certification

Human identities usually have natural governance context.

They have managers, departments, job titles, employment status, and HR records.

A service account does not.

This makes ownership one of the most important attributes in non-human identity governance.

SailPoint's current NHI model similarly emphasizes assigning human owners to service accounts, bots, and AI agents so there is accountability for access decisions, reviews, and lifecycle actions. SailPoint

Every NHI should therefore answer:

• Who is the accountable business owner?
• Who is the technical owner?
• What application or process depends on it?
• What is its purpose?
• What environment does it operate in?
• What resources should it access?
• What permissions should it have?
• How does it authenticate?
• When should its access next be reviewed?
• What happens when its owner leaves?

This is why governing service accounts, machine identities, and AI agents together requires more than simply placing them into an inventory. Ownership has to become part of the lifecycle. Astranova Labs

Without an accountable owner, there is nobody qualified to answer the most important certification question:

Does the business still need this identity and its access?

Who should certify a non-human identity?

This is where traditional access-review models begin to break down.

For an employee, certification may be assigned to the employee's manager.

Who is the manager of svc-payment-prod?

There isn't one.

The certifier should instead be selected based on accountability and technical context.

NHI Type	Potential Certifier
Application service account	Application owner
Database service account	Application or database owner
Cloud workload	Cloud/resource owner
CI/CD identity	DevOps/platform owner
API identity	API/application owner
RPA bot	Process/business owner
Shared technical account	Account/resource owner
Machine identity	Infrastructure/application owner

This creates an important governance principle:

Do not ask who manages the identity. Ask who understands why it exists and what would happen if its access were removed.

In some cases, that may require more than one certifier.

A business owner may validate that the process is still required, while a technical owner validates whether the specific permissions remain necessary.

That creates a potential certification path such as:

Business Owner → Technical/Application Owner → Security for high-risk access

The objective is not to make every NHI review multi-level. It is to ensure that higher-risk access receives appropriate scrutiny.

The reviewer needs machine context, not employee context

A human access review might present:

User: Rahul Sharma
Department: Finance
Role: Finance Analyst
Entitlement: Payment Reporting
Last Login: 12 days ago

Those attributes make sense for a person.

They are largely meaningless for a service account.

A useful NHI certification might instead present:

Identity: svc-payment-prod
Type: Service Account
Owner: Payments Platform Team
Environment: Production
Purpose: Payment reconciliation
Entitlement: Production DB Write
Last Used: 3 hours ago
Credential Age: 173 days
Created: 4 years ago
Risk: High
Review Decision: Approve / Modify / Revoke

The reviewer may additionally need:

• dependent applications
• calling workloads
• effective permissions
• credential type
• credential age
• last authentication
• source and destination
• environment
• ownership history
• privilege level
• SoD conflicts
• expiry or review date

This is the difference between putting an NHI into a human certification workflow and actually designing certification for non-human identities.

Dormancy means something different for non-human identities

Dormancy is an especially useful NHI governance signal.

Suppose a production service account has not authenticated for 180 days.

That raises an obvious question:

If nothing has used this account for six months, why does it still have production access?

The account may belong to an application that has been retired.

It may be a legacy integration nobody remembers.

It may be a disaster-recovery identity intentionally kept dormant.

Or it may still be necessary but used only during a particular business process.

The correct action is therefore not necessarily:

Dormant → Delete

It is:

Dormant → Investigate → Establish dependency → Review → Retain, Restrict, or Retire

This is particularly important because blindly disabling service accounts can cause production outages.

A mature review should therefore combine inactivity with ownership, dependencies, privilege, environment, and business purpose.

For example:

Dormant + No Owner + Production Write Access = Critical Review

while:

Dormant + Named Owner + Documented DR Purpose + Restricted Access = Potentially Acceptable

Risk comes from context, not from a single attribute.

Orphaned NHIs should be a certification priority

An orphaned employee account is concerning.

An orphaned service account with privileged production access can be considerably harder to investigate because nobody may understand what depends on it.

This is one of the reasons NHI governance should explicitly identify accounts where:

Owner = Unknown

or where the recorded owner has left the organization.

SailPoint's current NHI approach similarly emphasizes discovery, classification, ownership, lifecycle governance, and reduction of orphaned or excessive access. SailPoint

A practical risk hierarchy might look like this:

NHI Condition	Review Priority
Active + Owner + Least privilege	Normal
Active + Excessive privilege	High
Dormant + Valid owner	Review
Dormant + No owner	High
Privileged + No owner	Critical
Credential never rotated + privileged	High
Purpose unknown	High
Owner left organization	Immediate review
Application retired	Review for decommissioning

This is where NHI certification becomes a powerful remediation mechanism rather than merely an audit exercise.

NHI access reviews should evaluate permissions, not just accounts

Suppose a service account is still legitimately required.

The easiest certification decision is:

Approve

But that may be the wrong question.

The identity may still be required while some of its access is not.

For example:

svc-payment-prod
Production Payment DB — Read
Production Payment DB — Write
Customer Analytics DB — Read
Legacy Reporting DB — Admin

The service account itself may remain essential.

But why does it still have administrator access to a legacy reporting database?

The stronger certification model therefore asks:

Which entitlements should this identity continue to hold?

SailPoint's machine-account certification model similarly allows reviewers to examine the access items associated with machine identities and approve or revoke individual entitlements. SailPoint Documentation

This distinction matters because deleting unnecessary identities and removing unnecessary permissions are two different governance outcomes.

Credential governance should inform the access-review decision

Non-human identities also introduce another dimension that human certification campaigns typically do not emphasize: credentials.

A service account may authenticate through:

• password
• API key
• OAuth client secret
• certificate
• cloud access key
• token
• vault-issued credential
• workload federation

Suppose two service accounts have identical production access.

Service Account A uses short-lived workload credentials.

Service Account B uses a static secret that has not been rotated for three years.

Their entitlement risk may appear identical.

Their overall identity risk is not.

This is why access certification should increasingly incorporate credential context.

A reviewer may need to know:

Who owns the identity? → What can it access? → What credential does it use? → How old is that credential? → Where is it used? → When was it last rotated?

This creates a natural relationship between NHI governance and secrets governance.

But the two should not be confused.

Access review asks:
Should this identity retain this permission?

Secret review asks:
Should this credential still exist, who or what uses it, and is its lifecycle appropriate?

Both contribute to the same governance decision.

Periodic certification alone is not enough for NHIs

A quarterly employee review may be reasonable because workforce changes often originate in HR systems.

NHI changes can happen much faster.

A new service account can be created during a deployment.

A cloud role can gain another permission through an infrastructure change.

A credential can become stale.

An application can be decommissioned.

An owner can leave.

A workload can stop using an identity.

Waiting three months to notice these changes creates unnecessary exposure.

A stronger NHI governance model therefore combines scheduled certification with event-driven reviews.

Useful triggers include:

• owner leaves or changes role
• NHI becomes ownerless
• new privileged entitlement assigned
• application is retired
• workload stops using the identity
• credential exceeds rotation policy
• identity becomes dormant
• new SoD conflict appears
• environment changes
• privilege increases
• unusual authentication behavior appears

The principle is simple:

If something changes that weakens the original justification for access, the previous certification should be challenged.

That is the same principle behind a mature non-human identity governance program. Astranova Labs

Revoking an NHI is more complicated than revoking an employee

If an employee loses access to a reporting application, the business impact is usually visible quickly.

Disabling a service account can stop an application.

Revoking a cloud workload identity can break production.

Removing an API permission can interrupt a customer transaction.

NHI remediation therefore needs dependency awareness.

Before removing access, the governance process may need to determine:

What uses this identity? → What does it access? → What credential does it use? → What will break if access is removed?

The resulting workflow may be:

Review → Revoke decision → Dependency validation → Change window → Remediation → Verification → Evidence

rather than:

Review → Revoke → Done

This is also why an NHI's owner and actioner may be different.

The application owner may certify that an entitlement is no longer required.

A cloud, infrastructure, or DevOps team may need to implement the actual change.

Governance needs to preserve both responsibilities.

NHI certification should eventually become risk-driven

Not every service account needs the same review frequency.

A read-only automation account used daily with a clear owner and narrow scope does not present the same risk as an ownerless service account with administrator access to production.

A risk-driven model could look like this:

NHI condition	Possible governance response
Owned + active + low privilege	Periodic certification
Privileged NHI	More frequent certification
Ownerless NHI	Immediate ownership review
Dormant NHI	Targeted certification
Static credential + high privilege	High-priority review
Owner departure	Event-driven review
Application retired	Decommissioning review
New privileged entitlement	Targeted review
SoD conflict	Immediate review
Unknown purpose	Investigate and certify

The objective is not to review machines more often simply because they are machines.

It is to direct human attention toward the identities where ownership, purpose, privilege, usage, or credential posture indicates higher risk.

Audit evidence for NHIs needs to answer different questions

For human access, an auditor may ask:

Why did Rahul have access to the Finance application?

For an NHI, the question may become:

Why did svc-payment-prod have write access to the production database, who owned that decision, what workload used it, and when was that access last reviewed?

A defensible NHI certification record should therefore preserve:

• identity name and type
• owner and technical owner
• business purpose
• application or workload
• environment
• entitlements
• credential type
• usage information
• risk level
• reviewer
• certification decision
• comments and justification
• reassignment history
• remediation action
• completion status
• timestamps
• retirement evidence

This is what turns discovery into governance.

An inventory tells you:

We have 4,500 non-human identities.

Governance tells you:

We know why they exist, who owns them, what they can access, whether that access is still required, and what happened when it was challenged.

NHI access reviews are the bridge to AI agent governance

Service-account certification also prepares organizations for a much larger governance challenge.

AI agents are non-human actors, but they introduce additional dimensions.

An AI agent may have:

Identity → Credential → Tools → MCP Servers → Applications → Data → Actions

It may also operate autonomously or on behalf of a human.

Traditional service-account certification therefore provides the governance foundation — ownership, purpose, entitlement, lifecycle, review, remediation, and evidence — but it does not solve the entire agent problem.

The next step is asking:

Who should certify what an AI agent is allowed to do?

That question becomes increasingly important as organizations extend identity governance across human, machine, and agent identities. Citadel Identity360, for example, positions its IGA platform around governance of both human and non-human identities across hybrid environments. Astranova Labs

AI-agent access reviews deserve their own governance model, which we will cover separately in this series.

What good NHI access governance should change operationally

The goal is not to add thousands of service accounts to the same quarterly campaign used for employees.

It is to make every meaningful non-human identity discoverable, attributable, reviewable, and removable.

Organizations should expect to:

• discover and classify non-human accounts
• distinguish identities from their credentials
• assign accountable human owners
• document purpose and dependencies
• correlate identities with effective entitlements
• provide NHI-specific context to certifiers
• identify ownerless and dormant identities
• incorporate credential posture into risk
• review entitlements rather than simply approving entire accounts
• trigger reviews when ownership, usage, privilege, or risk changes
• validate dependencies before revocation
• track remediation through completion
• retire identities when their business purpose ends
• preserve evidence throughout the lifecycle

The measure of maturity is therefore not:

How many service accounts did we discover?

It is:

How many non-human identities can we actually explain, govern, certify, and safely retire?

FAQ

What is a non-human identity access review?

It is a certification process that determines whether a service account, machine account, bot, workload, API identity, or other non-human identity should continue to have its existing access.

Who should certify a service account?

Usually the person accountable for the application, process, or resource that the service account supports. Depending on the risk, this could involve a business owner, application owner, technical owner, or multiple levels of certification.

Should service accounts be included in employee access-review campaigns?

Not necessarily. They can operate within the same governance platform, but the reviewer, context, risk signals, and remediation process are different enough that NHI-specific campaigns or review policies can be more effective.

Is reviewing a secret the same as reviewing a non-human identity?

No. A secret is typically a credential used by an identity. NHI access review asks whether the identity should retain its permissions. Secret governance asks whether the credential should exist, how it is used, who owns it, and whether its lifecycle and rotation are appropriate.

Should dormant service accounts automatically be deleted?

No. Dormancy is a strong review signal, but deletion without dependency analysis can disrupt applications or production workloads. Ownership and dependencies should be established before disablement or removal.

How frequently should NHI access be reviewed?

Frequency should depend on risk. Privileged, ownerless, dormant, or high-impact identities may require more frequent or event-driven reviews, while low-risk, well-owned identities may remain on periodic certification cycles.

What should happen when the owner of an NHI leaves?

The identity should be flagged for ownership reassignment and review. The organization should establish whether the underlying business purpose still exists and whether the existing access remains appropriate.

Non-human identity access reviews ultimately need to answer more than:

Does this service account still exist?

They should establish:

What is this identity for, who is accountable for it, what can it access, what credential does it use, is that access still necessary, and can we safely remove it when its purpose ends?

That is the standard modern non-human identity certification should meet.