Non-Human Identity Audit Readiness: The Evidence Auditors Expect

Non-human identity audit readiness means an organization can show an auditor, on demand, that every in-scope machine identity has a validated owner, a documented purpose, justified access, a review history, appropriate credential controls, and a working revocation path. Most organizations can produce that evidence for an employee in an afternoon. HR records establish the person’s status. Access requests document who approved the access. Periodic certifications show who reviewed it. Offboarding records prove that access was removed when the employee left.

Producing the same evidence for a service account that has held production access since 2021 is much harder. The account may never have entered an onboarding workflow. No manager may be responsible for reviewing it. Its original creator may have changed roles or left the company, and the account may never have appeared in an access review. Multiply that governance gap across thousands of service accounts, managed identities, OAuth applications, automation bots, workload identities, and AI agents, and non-human identity sprawl becomes a material weakness in the next SOC 2, ISO/IEC 27001, PCI DSS, or SOX audit.

The terminology matters. A non-human identity is the digital identity used by a workload, application, service, bot, device, or agent. API keys, passwords, certificates, secrets, and tokens are credentials or authenticators associated with those identities. Auditors may ask for evidence about both, but an identity inventory should not treat the credential and the identity as interchangeable.

In this article you will learn why machine identities slip past the review process built for your employees, what an auditor expects for an account no manager can vouch for, and the six categories of evidence that answer those questions. That evidence lines up with the frameworks your auditor already works from, and governing your machines in the same program as your people makes it a byproduct of the work, there before the auditor asks instead of something you assemble at quarter-end.

Why Non-Human Identities Are Where Audits Quietly Fail

Most access-control programs were designed around people.

A manager approves an employee’s request. The HR system identifies when that employee joins, changes roles, or leaves. The identity provider records interactive authentication, and an access review routes the employee’s entitlements to someone who understands the employee’s responsibilities.

A service account created through infrastructure as code does not naturally follow that lifecycle. Nobody necessarily opens a request ticket. No manager is automatically assigned. A human offboarding event does not disable the account, even when the engineer who created it leaves. Unless the IAM program deliberately discovers and governs the identity, it may never enter the certification population or the evidence set provided to an auditor.

The size of the population makes that omission difficult to dismiss. Cloud Security Alliance research cites an average ratio of approximately 45 non-human identities for every human identity in enterprise environments, with even higher ratios reported in cloud-native environments.

That scale changes the audit problem. The population excluded from governance may be substantially larger than the employee population the organization reviews every quarter.

NHI threats commonly begin with one or more ordinary control failures:

• An identity has no accountable owner.
• Its credentials are long-lived or stored insecurely.
• Its permissions exceed the workload’s actual requirements.
• Its activity is not associated with an expected behavioral pattern.
• Its access remains active after the integration, service, or agent is retired.

Machine-to-machine authentication also rarely supports interactive MFA in the way a human login does. That does not make every machine authentication method insecure. It means the organization must rely on controls suited to workloads, including short-lived credentials, workload identity federation, certificate management, strict scope, behavioral monitoring, and tested revocation.

An audit that reviews employees while leaving privileged machine identities outside the control population has not demonstrated complete access governance. It has demonstrated that the organization governs one identity class better than another.

What Auditors Ask When the Account is Not a Person

The evidence changes when the identity is non-human, but the control objectives do not. An auditor still wants to know:

1. What is this identity, and why does it exist?
2. Who is accountable for it?
3. What can it access, and is that access justified?
4. Who approved and reviewed the access?
5. How are its credentials protected?
6. Can the organization disable the identity when its purpose ends?

For a human identity, the answers frequently come from the HR system, a manager, an access request, and an offboarding record. For a non-human identity, the evidence must come from technical ownership signals, workload context, access data, activity logs, credential systems, and governance workflows.

A defensible evidence set generally contains six categories.

1. Inventory and ownership: The identity type, source, associated workload, accountable owner, business purpose, environment, and criticality.
2. Provisioning and authorization: The request, policy, ticket, deployment record, or other decision that explains why the identity received access.
3. Scope justification: The resources and entitlements the identity can reach, the reason it needs them, and evidence that the scope reflects least privilege.
4. Review history: The review date, reviewer, decision, supporting context, changes since the previous review, and resulting remediation.
5. Credential hygiene: The authentication method, storage location, rotation or expiration policy, credential age, and evidence that secrets are not unnecessarily embedded in code or configuration.
6. Revocation and monitoring: A working disablement path, retirement trigger, activity history, anomalous-behavior detection, and confirmation that remediation succeeded.

Ownership is often the control that unlocks the rest. An identity with no accountable person or team cannot be routed to a knowledgeable reviewer. Without a reviewer, the organization cannot produce a credible attestation. Without an attestation, the account becomes an exception that IAM, security, and audit teams must investigate manually.

Ownership should not be based on a single weak signal. Repository activity may identify the last engineer who changed a workload, but that person is not necessarily the current owner. Resource tags may name a team, but the tags may be stale. The strongest process combines multiple signals—such as provisioning history, repository ownership, application ownership, cloud metadata, organizational structure, and recent activity—and then validates the attribution.

Lumos brings human, non-human, and AI identities into a unified access graph and enriches them with entitlement, ownership, sensitivity, and usage context. That context allows IAM teams to identify unowned service accounts, route decisions to the appropriate team, and preserve the resulting evidence in the same governance system used for workforce identities.

How to Map Non-Human Identity Controls to the Frameworks Your Auditor Uses

A defensible non-human identity security strategy begins with control mapping. Before selecting workflows or assembling reports, the organization should identify which systems, data, identities, and control objectives are in scope.

Not every NHI is necessarily relevant to every audit. A development bot with no access to production or regulated data may not belong in the same risk tier as a service account that can write to a financial reporting database. The organization should define the scope, identify every machine identity that can access or affect that scope, and then map the appropriate control requirements.

SOC 2

The SOC 2 logical-access criteria commonly examine whether access is authorized, appropriately restricted, reviewed, and removed. Those objectives can apply to service accounts, application identities, API integrations, and automation identities just as they apply to employees.

A SOC 2 auditor may therefore expect evidence that:

• Privileged machine access was approved.
• Entitlements reflect an authorized business purpose.
• Access was reviewed during the examination period.
• Excessive or inappropriate access was remediated.
• Decommissioned identities were disabled.
• Relevant activity and administrative changes were logged.

The exact evidence depends on the organization’s control descriptions, system boundaries, and auditor-approved design.

ISO/IEC 27001:2022

Several ISO/IEC 27001:2022 controls may be relevant to non-human identities, including A.5.15 for access control, A.5.16 for identity management, A.5.18 for access rights, and A.8.2 for privileged access rights.

Organizations should use their Statement of Applicability and approved control mapping rather than assume that every service account maps to each control in the same way. The evidence should show how the organization’s implemented policies govern the identity throughout its lifecycle.

PCI DSS 4.0.1

PCI DSS 4.0.1 is the active version supported by the PCI Security Standards Council. Requirement 8 includes specific expectations for application and system accounts, which the PCI SSC also refers to as service accounts. Requirements 7 and 8 address the management of account privileges and the secure use of application and system accounts.

For an in-scope application or system account, an assessor may examine:

• Whether interactive use is appropriately controlled.
• Whether access is limited to the function the account performs.
• Whether credentials are protected from misuse.
• Whether password-based credentials are changed according to policy.
• Whether the account remains necessary.
• Whether activity is attributable and reviewable.

An organization that handles payment data should explicitly map its application and system accounts to the relevant PCI DSS requirements rather than assume that controls written for human users provide sufficient coverage.

NIST SP 800-53 and Zero Trust Guidance

NIST SP 800-53 includes AC-2 for account management and AC-6 for least privilege. These controls give organizations a flexible foundation for defining how accounts are created, monitored, reviewed, disabled, and removed. NIST intentionally allows many frequencies and time frames to be organization-defined, which means the organization must document its policy and prove that it follows it.

NIST zero trust guidance also encompasses person and non-person entities, credentials, user access management, resources, and operations. The objective is not to trust a service merely because it is inside the network or owned by the enterprise. The identity and its access should be authenticated, authorized, and evaluated according to policy.

SOX IT General Controls

SOX does not create a separate identity category for service accounts. Machine identities become relevant when they can access or affect financially significant applications, databases, infrastructure, automated controls, or reporting processes.

The organization may need to show that privileged machine access was approved, periodically reviewed, appropriately segregated, monitored, and removed when no longer required. The precise population and evidence should follow the organization’s ITGC design and auditor-approved scope.

The important point is not that every framework uses identical language. It is that none of these programs becomes complete merely because the organization reviewed its employees. The control population must account for the non-human identities capable of accessing or affecting the systems within scope.

The Non-Human Identity Audit Evidence Map

The following map connects common control areas with the evidence an IAM program should be prepared to produce.

‍

Consider a hypothetical service account named svc-billing-reconcile with write access to a production billing database.

The inventory record identifies the platform engineering team as the accountable owner and records the business purpose as nightly billing reconciliation. The provisioning evidence shows the original request and approval. The entitlement record shows that the account can write only to the tables required by the reconciliation process.

The review history identifies the reviewer, date, decision, and any scope changes. The credential record shows the authentication method and recent rotation history. The revocation evidence records a successful disablement test or another verified path for terminating access. Activity data shows that the account runs during its expected schedule and accesses only the resources associated with its documented purpose.

Together, those records tell a coherent story:

• The organization knows the identity exists.
• Someone is accountable for it.
• Its access has a documented reason.
• A qualified reviewer has evaluated it.
• Its credential is governed.
• Its behavior is observable.
• Its access can be removed.

No one should have to reconstruct that story the week before an audit. Each control should produce evidence while the identity is being governed.

That distinction matters because an auditor typically examines a period, not a single moment. A spreadsheet exported on the last day of the quarter can show the account’s current state. It cannot, by itself, prove that the account was properly approved, reviewed, monitored, and remediated throughout the examination period.

Continuous evidence is stronger because it preserves the sequence of events: what was granted, what changed, who reviewed it, what action followed, and whether the action succeeded.

Why Non-Human Access Reviews Collapse at Audit Time and the Change That Fixes Them

A review becomes ineffective when the reviewer receives thousands of machine entitlements without enough context to evaluate them. The problem is not simply the number of rows. It is the absence of meaning. A reviewer may see an entitlement called Billing_Admin_02 without knowing what it permits, whether the account uses it, how sensitive it is, or what changed since the previous certification.

That design encourages rubber-stamping. It records a signature, but it provides little evidence that the reviewer applied informed judgment.

Delta-based access reviews improve the process by emphasizing meaningful changes:

• Newly created identities
• New or elevated entitlements
• Ownership changes
• Newly privileged access
• Unusual activity
• Dormant or unused access
• Policy exceptions
• Changes in workload purpose or environment

The complete in-scope population should remain governed. Delta presentation does not mean that 9,000 unchanged entitlements disappear from the certification. It means stable access can be presented with appropriate policy, usage, and prior-review context while human attention is concentrated on the 200 items that materially changed.

That is a more defensible control than asking a reviewer to reassess every unchanged field without context. It also creates evidence of judgment. When a reviewer sees that a service account gained a new administrative permission and either approves it with a documented reason or revokes it, the resulting record shows what changed, why the decision was made, and what happened next.

Behavioral context is especially useful for machine identities. A service account that suddenly authenticates from an unexpected environment, runs outside its established schedule, accesses a new data set, or begins using a dormant privilege deserves more attention than an identity whose purpose, scope, and behavior remain stable.

Lumos uses delta reviews to direct reviewers toward changes and risks instead of forcing them to reprocess the same access without context. Marqeta reported that its second access-review cycle with Lumos was 40% faster than the first, with delta reviews helping managers focus on what had changed. That result concerns workforce reviews, but the same review design is applicable to governed machine identities.

Sun Country Airlines also reports saving more than 50 hours per quarter by automating access reviews and using delta functionality, while bringing managed service accounts and privileged access into its certification process.

The objective is not to review less access. It is to conduct a more informed review of the entire governed population.

Cut Standing Privilege Before the Auditor Finds It

The easiest access exception to defend is the one the organization already removed. Dormant and overprivileged machine identities expand both the audit population and the attack surface. Each one creates another ownership question, another review decision, another credential to protect, and another revocation path to validate.

Right-sizing begins by comparing granted access with observed use over a risk-appropriate period. The correct lookback depends on the workload. A nightly automation may produce enough activity data in 30 days, while a quarterly process may require a longer window.

The IAM team should evaluate:

• Whether the identity is still active.
• Whether the workload still exists.
• Whether the documented owner remains accountable.
• Which entitlements the identity has used.
• Whether unused access is justified by an exception.
• Whether privileged access can become temporary or task-specific.
• Whether the identity can be disabled safely.

Usage alone should not make the decision. A disaster-recovery account may be intentionally dormant. A month-end integration may use access only periodically. The purpose, workload schedule, dependencies, criticality, and exception policy all belong in the decision.

Once that context is available, the organization can remove unused entitlements, replace standing administrative access with time-bound access where appropriate, rotate exposed credentials, and retire identities that no longer have a valid purpose.

That work is foundational to non-human identity breach prevention. Validated ownership, least privilege, credential hygiene, activity monitoring, and tested revocation reduce the chance that a compromised machine identity can retain unnecessary access or move through the environment unnoticed.

Right-sizing also improves every later certification. When dormant accounts and unused permissions are removed before the review begins, reviewers evaluate a smaller and more relevant population. Faster reviews make it easier to maintain least privilege, and a cleaner access environment makes future reviews faster.

Lumos’s identity analytics can compare granted access with usage and peer context, identify long-standing or unusual privilege, and connect findings to remediation workflows. Code42 reported a 67% reduction in privileged access after implementing time-based access with Lumos. That result was not presented as an NHI-specific benchmark, but it demonstrates the effect of replacing permanent privileged access with governed, temporary access.

The operating principle is simple: discover first, establish ownership, right-size access, and then certify what remains.

Audit Readiness is a Byproduct, Not a Project

Buying technology specifically for non-human identities is not inherently the problem. The problem appears when non-human identity management solutions create a second inventory, a separate ownership model, an isolated review process, and an evidence set that cannot be reconciled with the rest of the identity program.

That architecture reproduces the gap it was meant to solve.

A machine identity still moves through an identity lifecycle:

1. It is created.
2. It receives access.
3. Its purpose or scope changes.
4. Its access is reviewed.
5. Its credentials are renewed or rotated.
6. It is disabled when its purpose ends.

The actor is different from an employee, but the governance disciplines are related. Human and non-human identities should be visible through a shared access model, subject to consistent least-privilege principles, and governed through workflows that reflect the technical differences between the identity types.

That does not mean forcing a service account through an employee workflow. It means operating one identity program with appropriate controls for each identity class.

Lumos combines identity visibility, intelligence, governance, and agentic action in one loop. Its access graph provides context across human, non-human, and AI identities. Identity analytics identifies stale, anomalous, unowned, or overprivileged access. Security Agents can then investigate findings, route decisions, propose remediation, execute permitted actions, verify the outcome, and preserve the evidence trail.

The level of automation remains configurable. An organization can begin with approval required for every action, provide feedback as agents calibrate to its environment, and later automate routine actions while retaining human approval for high-risk changes.

This operating model closes the distance between finding an identity risk and resolving it. Visibility without remediation produces a queue. Governance without complete visibility produces incomplete decisions. Agentic action without controls produces unacceptable risk. The value comes from connecting all three.

When the program operates continuously, the evidence is generated continuously:

• Ownership decisions are recorded when they are made.
• Access approvals are tied to the resulting entitlement.
• Reviews preserve context and reviewer judgment.
• Remediation records show what changed.
• Verification confirms that the change succeeded.
• Reports summarize an existing evidence trail rather than reconstructing one.

ChargePoint reports that Lumos allowed its team to complete twice as many access reviews while replacing spreadsheet- and email-driven coordination with a centralized process. The company also reports saving 20 hours per month on access-request oversight, with audit logs preserving what happened throughout the workflow.

That is the difference between preparing for an audit and operating an auditable identity program.

An audit-ready program does not depend on someone assembling a binder at the end of the quarter. It can answer who and what has access, why the access exists, who approved it, how it was reviewed, what changed, and whether remediation succeeded because those questions are part of daily governance.

Stop Governing Non-Human Identities by Hand

An audit isn't really a test of your documentation. It's a test of whether your governance is real, and whether it was real all along or only the week you assembled the binder. Manual, siloed governance fails that test for machines, because you can't hand-build a quarter of history the night before it's due.

You already automated the pipelines, the infrastructure, and the deployments the auditor is asking about, and the machine identities running all of it are the one population you still govern by hand. They outnumber your people dozens to one, and they hold the shortest paths to the data you're being audited on.

Bring those machines into the same program that governs your people, and the audit evidence becomes a control that already ran, ready the day the auditor asks: every access review, every rotation, every deprovisioning recorded as it happens. That's how you walk into the audit with the answers already in hand instead of assembling them the night before. See Lumos do the same against your own environment in a demo, and make your next audit the one you don't have to prepare for.