How Companies Are Preventing Non-Human Identity Breaches in 2026

Nobody got phished. No malware ran. No MFA prompt appeared because the workload did not use an interactive sign-in. A token authorized eighteen months earlier for a marketing integration read an entire CRM, and every log entry looked like the integration doing its job.

That is the shape of a modern non-human identity breach. Preventing one is not primarily a detection problem. Non-human identity security starts with controlling what machine identities can reach, how they authenticate, how long their credentials remain valid, and how quickly their access can be revoked.

Detection still matters, but a valid credential operating within its granted scope may produce no failed authentication or other obvious sign of compromise. The critical question is how far the credential can reach if it is misused.

The distinction matters because each layer fails differently and each requires a different control. Rotating a credential does not reduce an entitlement, and disabling a principal does not revoke a token that a third party still holds. In this article you will learn how NHI breaches unfold across five stages, why workforce identity controls do not map cleanly to machine identities, the seven preventive controls that constrain each stage, the metrics that show whether those controls are working, and a 90-day sequence team should start following now.

The Five Stages of a Non-Human Identity Breach

Many significant NHI breaches follow the same five-stage pattern. Once IAM and security teams can name each stage, they can identify the controls that constrain it.

Stage one: The upstream compromise

The attacker often starts with a vendor, integration partner, development tool, or application that someone authorized to access production data.

The exposure comes from where the credential lives. It sits outside your environment, under another organization's security program, monitoring, and rotation schedule. Your attack surface therefore includes every external organization that holds a credential or delegated authorization pointed at your environment.

The problem is not limited to whether you trust the vendor. You also need to know:

• What access the vendor holds
• Which identity or integration uses that access
• Whether the access is still required
• Who inside your company owns the relationship
• How quickly the grant can be revoked

Stage two: The credential is harvested

The credential artifacts associated with compromised NHIs are usually unremarkable: a service account key stored in an environment variable, an OAuth refresh token in a vendor database, an API key committed to a repository, or a cloud access key exposed through instance metadata.

The attacker may not need a zero-day vulnerability. They may only need to read a configuration file, repository, log, or database on a system they have already compromised.

This stage is where secret discovery, secure storage, workload identity federation, managed identities, and short credential lifetimes matter. A credential that does not exist as a persistent secret cannot be harvested in the same way as a static key.

Stage three: The credential authenticates successfully

The attacker presents the credential, and the target system accepts it.

There may be no failed login, MFA failure, or impossible-travel alert because the workload is authenticating through a noninteractive flow. Successful authentication does not make the activity legitimate, but it removes several of the signals that security teams use to detect compromised workforce accounts.

From August 8 through August 18, 2025, a threat actor used OAuth credentials associated with the Salesloft Drift integration to exfiltrate data from customer Salesforce instances. The incident illustrates how compromised OAuth credentials can provide direct access to customer environments without requiring an attacker to defeat an interactive authentication challenge.

Responders may still find evidence in source IP addresses, user-agent strings, authentication logs, query patterns, access volume, and the specific records the identity requests. The challenge is that the authentication event itself may appear valid.

Stage four: The attacker inherits the identity’s reach

A compromised identity comes with permissions, OAuth scopes, resource assignments, and trust relationships.

An integration granted broader access than its original purpose requires may reach connected applications, production data, administrative APIs, or cloud resources. The attacker inherits the scope that the organization granted, including permissions the legitimate workload rarely or never uses.

OWASP identifies vulnerable third-party NHIs and overprivileged NHIs as separate risks because the combination is particularly dangerous. A third-party compromise can become an enterprise breach when the affected NHI holds excessive permissions or can assume additional roles.

Scope reduction limits this stage. Even when the credential is compromised, the attacker should not be able to reach resources that the workload does not need.

Stage five: Data is accessed or exfiltrated

Investigators may find no malicious binary, persistence mechanism, or conventional malware payload. Instead, they may find a valid identity reading records that it was authorized to access.

The activity may still produce detectable changes in volume, timing, source infrastructure, query composition, or resource selection. However, those signals can be subtle when the attacker stays close to the integration’s normal behavior.

Non-human identity threats often present as valid use of excessive or outdated access. That is why organizations need to control the identity, the credential, the entitlement, and the underlying trust relationship.

Why Human-Centric Identity Controls Are Insufficient for NHIs

MFA, Conditional Access, session controls, and HR-driven offboarding are essential parts of a workforce identity program. They do not map cleanly to every non-human identity or machine-to-machine authentication flow.

NHIs require controls designed around workload authentication, credential type, token issuance, entitlement scope, network context, ownership, and service lifecycle events.

MFA assumes an interactive authentication flow

MFA works by interrupting an interactive login and asking a person to prove possession of an additional factor.

A workload calling an API may have no person to challenge. It may authenticate with a client secret, private key, certificate, managed identity, signed assertion, or federated workload token.

The objective is not to force a human MFA experience onto every workload. It is to replace weak, persistent credentials with stronger noninteractive authentication methods, such as:

• Managed identities
• Workload identity federation
• Short-lived tokens
• Certificate-based client authentication
• Signed client assertions
• Sender-constrained tokens
• Mutual TLS

Conditional Access needs workload-specific signals

Traditional Conditional Access policies frequently evaluate workforce signals such as device compliance, sign-in risk, location, and authentication strength. Workload identities may not generate those same signals.

Some identity platforms support Conditional Access policies for service principals or other workload identities, but coverage varies. Enforcement often differs from workforce policies and may not extend to every managed identity or application scenario, so the value of the control depends on which identity types your platform supports and how the policies are scoped.

Workload-focused policies may instead evaluate factors such as:

• Expected network location
• Service-principal risk
• Token issuer and audience
• Source workload
• Environment
• Resource sensitivity
• Federation claims
• Permitted authentication method

Conditional Access can therefore contribute to NHI security, but only when the platform supports the identity type and the organization configures workload-specific policies.

Credential and token lifetimes vary

Interactive workforce sessions, access tokens, refresh tokens, certificates, and API keys do not share one expiration model.

Access tokens may be short-lived, while refresh tokens can be used to obtain new access tokens. Refresh-token expiration, replacement, rotation, and revocation behavior depends on the authorization server and client configuration. Static API keys may remain active until they are manually rotated or revoked.

Current OAuth security guidance recommends sender-constrained refresh tokens or refresh-token rotation for public clients. Organizations should evaluate the actual lifecycle and replay protections of each credential type rather than treating every stolen token as a universally permanent session.

HR-driven offboarding does not cover service lifecycles

Workforce deprovisioning normally begins with an HRIS event. No HRIS automatically knows that:

• A migration finished
• A proof of concept ended
• A vendor contract expired
• An application was retired
• A CI/CD pipeline was replaced
• An AI agent was decommissioned
• A service no longer needs production access

Without service lifecycle signals, an NHI can outlive the project, application, vendor relationship, or engineer that created it.

Every NHI therefore needs an owner, a documented purpose, an expected lifetime, and a decommissioning trigger.

Seven Preventive Controls That Reduce NHI Breach Risk

Seven preventive controls can constrain different stages of the attack chain. Behavioral monitoring remains essential, but it is a detective control rather than a substitute for governance.

‍

Continuous discovery

You cannot govern or revoke an identity that is missing from your inventory.

Non-human identity sprawl commonly occurs outside the primary identity provider. Examples include:

• A standalone cloud IAM user created during an incident
• A personal access token stored in a CI/CD configuration
• A local administrator account inside a SaaS application
• A service principal created through infrastructure as code
• An OAuth application authorized by an employee
• A database credential stored in a secrets manager
• An AI agent using inherited employee access
• A certificate associated with an abandoned application

Discovery needs to reach identity providers, cloud accounts, SaaS applications, on-premises systems, code repositories, secrets stores, CI/CD platforms, and local application directories.

The inventory should distinguish the principal from its credentials and entitlements. A single service principal may have multiple secrets, certificates, role assignments, and application grants, each with a different owner, lifetime, or risk level.

Ownership attribution

Every NHI needs a named human who is accountable for its purpose and access.

The owner does not need to be the person who originally created the identity. They need to understand the business or technical dependency well enough to answer questions such as:

• Is this identity still required?
• What service depends on it?
• What should it be allowed to access?
• Can its credential be rotated?
• What happens if the identity is disabled?
• Who should approve an exception?
• When should the identity be decommissioned?

Ownership can be inferred from existing signals, including the identity’s creation source, connected application, repository activity, usage behavior, deployment environment, cost center, team membership, and the people who administer the dependent service.

Lumos discovers service accounts, API keys, tokens, and workload identities across connected identity providers, cloud platforms, SaaS applications, and supported on-premises systems. Our NHI governance capabilities associate those identities with responsible humans and provide the context needed to make access decisions.

ChargePoint connected more than 100 applications to Lumos in under three months, creating broader visibility across its identity estate and moving access reviews toward automated, evidence-backed workflows.

Scope reduction

Compare the entitlements an NHI holds with the access its function requires and the permissions it actually uses.

Many machine identities accumulate access through broad default roles, copied policies, testing permissions, vendor recommendations, and one-time project requirements. The unused remainder increases the impact of a compromise.

Scope reduction should consider:

• Resource-level access
• OAuth scopes
• Cloud IAM roles
• Application permissions
• Database privileges
• Group assignments
• Role-assumption relationships
• Cross-environment access
• Administrative APIs
• Write and delete permissions

Observed usage is useful evidence, but it should not be the only basis for removal. Some permissions support infrequent but legitimate recovery, failover, or maintenance processes. Owners should validate those dependencies before access is revoked.

Credential rotation and short-lived authentication

Prefer authentication models that do not require a long-lived secret.

Managed identities, workload identity federation, OIDC-based credential exchange, and short-lived tokens reduce the amount of persistent credential material an attacker can steal.

Where static credentials remain necessary, use a staged process:

1. Discover every known copy of the credential.
2. Identify the workloads and environments that use it.
3. Create or issue the replacement credential.
4. Update dependent services.
5. Validate that the replacement works.
6. Revoke the old credential.
7. Monitor for failures or attempted reuse.
8. Remove stale copies from repositories, configuration files, and secrets stores.

A 90-day maximum age can be a useful starting policy for long-lived cloud access keys, but it is not a universal requirement for every NHI credential. Unit 42 recommended rotating cloud service-provider access keys every 90 days in its 2021 analysis of IAM misconfigurations. Organizations should set credential-specific limits based on privilege, exposure, provider capabilities, and operational risk.

Third-party grant review

Treat each OAuth authorization and external trust relationship as an entitlement with:

• A named owner
• A documented business purpose
• An approved scope
• A known data path
• A review date
• A revocation procedure
• An expiration or recertification requirement

An employee clicking Accept should not create an authorization that remains active indefinitely without further review.

Stage one begins outside your environment, which means grants pointing into your applications and data deserve the same scrutiny as internally assigned roles. OWASP ranks vulnerable third-party NHIs among its top NHI risks and specifically identifies compromised third-party integrations as a route to credential theft and permission misuse.

Prioritize grants that hold:

• Administrative access
• Write or delete scope
• Access to production data
• Offline access
• Broad user impersonation rights
• Cross-tenant permissions
• Access to source code or deployment systems
• Access to customer, financial, or regulated data

Entitlement-level reviews for machines

Include human and non-human identities in the same governance model, but do not assume that every identity needs the same review interval.

Set the cadence according to:

• Privilege level
• Data sensitivity
• Credential lifetime
• Environment
• Third-party involvement
• Usage changes
• Ownership status
• Separation-of-duties risk
• The identity’s ability to create or modify other identities

A privileged production workload may require continuous evaluation or a review triggered by an entitlement change. A low-risk read-only integration may fit a quarterly or semiannual schedule.

The important principle is unified governance, not an identical calendar. Reviewers should be able to see the identity, owner, purpose, credential type, entitlement, recent usage, and risk context in one place.

These reviews also produce non-human identity compliance evidence. Instead of showing an auditor only that a campaign was completed, the organization can demonstrate:

• Who owns the NHI
• Why its access is required
• What permissions it holds
• When those permissions were last reviewed
• Who approved the decision
• What evidence supported the approval
• Whether remediation was completed

Fast containment and revocation

When an NHI’s purpose ends or its credential is suspected of compromise, use the correct action for each object.

An identity or principal may be disabled, suspended, or quarantined. A key, secret, certificate, or token may need to be revoked, rotated, deactivated, or deleted.

A safe decommissioning workflow should:

1. Identify the principal and all associated credentials.
2. Confirm the owner and dependent services.
3. Quarantine or disable the principal where supported.
4. Revoke or rotate active credentials.
5. Monitor for failed dependencies and attempted reuse.
6. Preserve the evidence required for investigation or audit.
7. Delete the identity after the validation period.
8. Remove residual secrets, grants, policies, and trust relationships.

Reversible containment reduces the fear of breaking production without leaving a high-risk identity active indefinitely.

Why behavioral monitoring is not listed as a preventive control

Behavioral monitoring is still required. It can identify suspicious activity and shorten attacker dwell time.

However, monitoring does not reduce the amount of access a compromised identity holds. It detects potential misuse after an identity authenticates or begins acting.

That is why monitoring should complement discovery, ownership, least privilege, short-lived authentication, access reviews, and revocation rather than replace them.

Prevention Starts with Governance; Detection Limits Dwell Time

A compromised integration token reading records within its authorized scope may be difficult to distinguish from legitimate activity. Difficult does not mean impossible.

Monitoring can identify changes in:

• Source IP address
• Hosting provider or autonomous system
• User-agent string
• Request volume
• Query composition
• Access timing
• Resources requested
• Data-export behavior
• Token issuer or audience
• Geographic source
• Error patterns
• Role-assumption behavior

Threat intelligence and incident-specific indicators can also expose misuse that a generic behavioral baseline misses.

The Salesloft Drift incident, for example, produced information that organizations could use to investigate authentication activity and connected-application behavior. The fact that the OAuth credentials were accepted did not eliminate every opportunity for detection. It eliminated the failed-authentication signal that many identity programs rely on first.

Governance and monitoring therefore solve different parts of the problem:

Governance limits what the identity can do. Monitoring helps identify when the identity may be doing it for the wrong reason.

A mature NHI security program needs both.

In practice, governing the entitlement layer requires four foundations:

1. A unified inventory covering human identities, NHIs, AI agents, credentials, entitlements, and external grants
2. Visibility at the individual entitlement level rather than only at the group or account level
3. Time-bound access as the default for privileged identities
4. Risk-based review cycles that include machine access and its human owners

Lumos represents employees, contractors, service accounts, and AI agents within a unified Identity Access Graph. Each identity can be mapped to the entitlements it holds, the systems it reaches, and the human responsible for it.

Delta access reviews make recurring governance manageable by showing reviewers what changed since the previous cycle rather than requiring them to reapprove thousands of unchanged grants. Pluralsight increased its access-review coverage from 20 applications over two months per quarter to 200 applications in under two weeks.

As AI agents and automated workloads expand, the number of access relationships will grow faster than a human team’s ability to review every permission manually. The governance model needs to support that volume before the identities are deployed, not after the first incident.

What Mature NHI Security Programs Do Differently

Organizations that reduce NHI risk do more than purchase another scanner. They change how identities are governed throughout their lifecycle.

A practical non-human identity security strategy usually includes three operating practices.

They govern machines and people in one program

Machine identities belong in the same governance model, access graph, policy framework, and evidence system as workforce identities.

That does not mean every identity follows the same authentication method or review interval. It means the organization can answer one question consistently:

Who or what can access this resource, why do they have that access, and who is accountable for it?

A unified program avoids producing one report for employees and another for machine accounts that nobody can reconcile. It also prevents non-human identity management from becoming a second identity silo with separate owners, policies, and audit evidence.

They treat standing privilege as a failure state

Mature teams assume that a permanently held privileged credential may eventually appear in an incident report.

They reduce standing privilege by:

• Granting elevated access only when it is needed
• Setting explicit expiration times
• Requiring stronger authentication for privileged workloads
• Removing unused permissions
• Rotating or replacing long-lived secrets
• Monitoring dormant privileged identities
• Requiring an approved exception for permanent administrative access

Lumos’s Access Request Agent grants access for the required period and revokes it automatically. Its NHI Owner Hunter Agent monitors service accounts, keys, and tokens and identifies dormant or overscoped access for remediation.

Code42 reduced privileged access by 67% while decreasing average access-request resolution time from hours to four minutes with Lumos.

They make ownership a provisioning requirement

A new service account, application integration, workload identity, or AI agent should receive a named human owner before it receives access.

Provisioning should require:

• An accountable owner
• A responsible team
• A documented purpose
• A target environment
• Requested entitlements
• An expected lifetime
• A credential type
• A review interval
• A decommissioning trigger

This sequencing prevents the orphaned-identity backlog from continuing to grow while IAM teams work through existing accounts.

Compare that approach with the legacy pattern: a year-long governance deployment built around human joiner, mover, and leaver events with no complete representation of workloads, API keys, service principals, or AI agents.

Six Metrics That Show NHI Controls Are Improving

Posture statements are difficult to defend in an executive or board discussion without measurable outcomes.

Baseline these six indicators at the beginning of the program and report their trend at least quarterly.

‍

These metrics require a sufficiently complete inventory and consistent definitions.

Organizations may be able to calculate an initial baseline from existing identity-provider, cloud, SaaS, secrets-management, and ticketing data. However, manual measurement becomes difficult to sustain as the NHI population grows.

The trend over multiple quarters shows whether the program is reducing exposure or merely documenting it.

Where to Start in the First 90 Days

Three sequenced phases can establish practical control faster than a multiyear program that attempts to model every possible identity relationship before producing an outcome.

Days 1–30: Build the inventory and establish definitions

Create a unified inventory across identity providers, cloud accounts, SaaS applications, on-premises systems, CI/CD platforms, repositories, and secrets stores.

Distinguish among:

• Principals
• Credentials
• Entitlements
• OAuth grants
• Trust relationships
• Owners
• Dependent services

Baseline the six metrics above.

Avoid broad cleanup until ownership and dependencies are understood, but do not delay containment of confirmed critical exposures. Immediately address publicly exposed secrets, known compromised credentials, and unauthorized administrative access.

Days 31–60: Assign owners and contain clear risks

Assign a named human owner and documented purpose to every privileged NHI.

Prioritize identities that are:

• Privileged
• Dormant
• Unowned
• Externally controlled
• Using static credentials
• Connected to production
• Able to create or modify other identities
• Holding write or administrative OAuth scopes

Use reversible containment for dormant or unclaimed identities. Disable or quarantine the principal where supported, validate dependencies, revoke or rotate the associated credentials, and monitor for failures before permanent deletion.

Do not assume that an unowned credential has no production dependency. Lack of ownership is a risk signal, not proof that removal is harmless.

Days 61–90: Reduce third-party grants and long-lived credentials

Review every third-party OAuth grant with write, delete, administrative, offline, or broad impersonation access.

Revoke unused grants, reduce excessive scopes, and assign an owner to each approved integration.

Begin replacing the oldest and highest-risk static credentials with managed identities, workload federation, or short-lived tokens. Where replacement is not yet possible, use staged rotation and document the exception.

Introduce change-based reviews for machine entitlements so reviewers can focus on new grants, privilege increases, ownership changes, unusual usage, and other material changes.

By the end of the quarter, the organization should have moved from an unknown population to a classified, prioritized, and substantially owned one. The program will not be complete, but its exposure, decisions, and progress will be measurable.

Reduce the Reach of the Next Compromised Credential

Every stage of this attack chain can run on access that someone originally granted for a legitimate purpose.

The vendor integration was authorized. The service account was provisioned. The credential was valid. The application had permission to reach the data.

That leaves several variables an organization can control:

• How the identity authenticates
• How long its credentials remain valid
• What resources it can reach
• What actions it can perform
• Which systems trust it
• Who owns it
• How often its access is reviewed
• How quickly it can be contained
• What activity is monitored

Non-human identities now outnumber human users by as much as 50:1 in many environments, and the ratio climbs with every cloud migration, SaaS integration, and automation project. That is a population no team can govern through disconnected spreadsheets and quarterly campaigns that reviewers do not finish.

Lumos is designed to govern that population across connected identity providers, cloud platforms, SaaS applications, and supported on-premises systems. It discovers service accounts, API keys, tokens, workload identities, and AI agents; maps them to human owners; and brings their entitlements into the same access graph and policy model used for workforce identities.

Time-bound access reduces standing privilege. The NHI Owner Hunter Agent identifies dormant and overscoped access. Delta reviews keep recurring certification work focused on meaningful changes. Lumos customers have reduced standing overprivileged access by as much as 80%.

The goal is not to assume that every NHI compromise can be prevented or instantly detected. The goal is to ensure that a compromised identity cannot reach more than its function requires and cannot remain active longer than the organization can tolerate.

Book a demo to see what a unified inventory of human identities, non-human identities, credentials, entitlements, and AI agents reveals in your environment.

‍