By NHI Mgmt Group Editorial TeamDomain: Governance & RiskSource: Oleria SecurityPublished March 2, 2026

TL;DR: Identity attacks now dominate, with 88% of web application breaches involving stolen credentials and 95% of enterprise permissions going unused, according to Oleria Security. Basic IAM cannot keep up with fragmented identity data, usage blind spots, and expanding non-human identities, so usage-aware governance has become the real control requirement.


At a glance

What this is: This is an analysis of why identity security has expanded beyond traditional IAM, with the central finding that authentication alone no longer reveals real access risk.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes now have to govern actual access use across humans, service accounts, bots, and AI agents, not just provisioned entitlements.

By the numbers:

👉 Read Oleria Security's analysis of why identity security goes beyond IAM


Context

Identity security is the layer that checks what identities actually do after authentication, while IAM focuses on granting access in the first place. The article argues that this shift is necessary because permission data, usage data, and risk signals now live in separate systems, leaving security teams with incomplete identity pictures across human users, contractors, service accounts, bots, and AI agents.

That problem is now central to identity security programmes because attackers increasingly exploit existing access rather than brute-force entry. For IAM, IGA, PAM, and NHI teams, the issue is no longer only whether access was approved, but whether the access is still justified, actively used, and behaving within expected boundaries.

The article’s starting position is typical: most enterprises have fragmented identity data, dormant accounts, and machine identities that outgrow manual governance. The practical challenge is to move from point-in-time access records to continuous visibility and lifecycle control.


Key questions

Q: How should security teams govern access when permissions and usage do not match?

A: Treat the mismatch as a risk signal, not a reporting issue. If an identity has access it never uses, or uses in ways that do not match the role or workflow, review the business justification, reduce standing privilege, and add monitoring for reactivation. The point is to govern actual behaviour, not preserve theoretical entitlement.

Q: Why do non-human identities create more blind spots than human users?

A: Because they are created for systems, not people, so they often bypass the controls that rely on human login patterns, review cycles, and manual ownership checks. Service accounts, API keys, and bots can keep working long after the original use case changed, which makes stale access harder to notice and harder to revoke.

Q: What breaks when identity reviews focus only on entitlements?

A: You lose sight of whether access is dormant, excessive, or actively abused. A permission list can look acceptable while the actual account is unused, over-scoped, or behaving suspiciously. That creates false confidence, which is exactly what attackers need when they try to operate through valid credentials.

Q: Who should own remediation when identity controls fail compliance checks?

A: Ownership should sit with the control owner, not the auditor. Audit teams can identify the gap, but remediation needs a responsible business or technical owner who can revoke access, close exceptions, and prove the defect will not recur. Without that ownership, the same failure reappears in the next review cycle.


Technical breakdown

Why permissions data is not enough

Traditional IAM tells you who can authenticate and what entitlements were assigned. Identity security adds the missing layer: what the identity actually did with that access, when it did it, and whether the behaviour fit the expected pattern. That distinction matters because entitlements can remain valid long after the business need has disappeared. In practice, the architecture requires correlating directory data, cloud activity, SaaS logs, HR changes, and resource-level events into one identity view. Without that correlation, dormant accounts, stale contractor access, and over-provisioned machine identities stay hidden until they are abused.

Practical implication: treat permissions as a starting point, then validate every high-risk identity against real usage and resource activity.

How lifecycle governance changes when identities are non-human

Service accounts, API keys, bots, and AI agents do not follow the same lifecycle as employees, but they still require joiner-mover-leaver discipline. The main difference is that non-human identities are often created for technical workflows, passed between systems, and forgotten after the original use case ends. That creates persistent access with weak ownership. Identity security therefore has to track issuance, purpose, rotation, renewal, and offboarding as lifecycle events, not just as secret-management tasks. When this is absent, the organisation ends up with valid credentials that no one can confidently justify or revoke.

Practical implication: put every non-human identity on an ownership, expiry, and offboarding path with clear accountability.

Usage-aware access intelligence and continuous remediation

Usage-aware access intelligence is the difference between seeing a permission and seeing a risk. It combines authentication, activity, and contextual signals so teams can identify dormant access, unusual resource use, and privilege that is never exercised. That matters because access reviews built on static permission lists tend to turn into box-ticking exercises. Continuous remediation closes the loop by making revocation and adjustment part of the monitoring workflow rather than a separate manual project. The architecture only works if the platform can move from detection to action quickly enough to matter.

Practical implication: require continuous monitoring that can trigger revocation, not just alerting, for high-risk identity events.


Threat narrative

Attacker objective: The attacker wants to convert legitimate-looking identity access into data theft, privilege abuse, and broader environment control without triggering obvious intrusion alerts.

  1. Entry occurs when attackers obtain valid credentials instead of forcing a perimeter breach, which aligns with the article’s emphasis on stolen credentials as the dominant access path.
  2. Escalation happens when over-permissioned identities, dormant accounts, or exposed service credentials provide more access than the attacker should have received.
  3. Impact follows when the attacker moves laterally, reaches sensitive resources, and uses authenticated access to avoid traditional perimeter-based detection.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Usage-aware identity governance is now the dividing line between control and guesswork. IAM can answer who authenticated and what was provisioned, but it cannot prove whether access was actually used in a way that matches business intent. That gap is exactly where dormant accounts, stale contractor access, and over-permissioned service identities become exploitable. The implication is that governance programmes need to shift from entitlements to evidence of use.

Non-human identities are no longer a side category of IAM. Service accounts, API keys, bots, and AI agents now represent a material share of enterprise access and often sit outside human-oriented review cycles. Their credentials can persist longer than the business process that created them, which means traditional certification cadences miss the risk window. Practitioners should treat NHI lifecycle governance as a core identity discipline, not a niche control.

Visibility without revocation is only half a control. Security teams can discover dormant accounts and unusual activity, but if they cannot shorten access duration or remove exposure quickly, the programme remains observational rather than preventive. That is why real identity security must connect detection, approval context, and remediation in the same operating model. The practitioner conclusion is that monitoring alone does not reduce blast radius.

Identity security is becoming the operational layer that binds IAM, IGA, and PAM together. The article is right that point-in-time access administration is not enough when permissions, usage, and risk are changing continuously. The broader market signal is that practitioners now need a single view of identity state across humans and machines, with enough context to support both governance and response. Identity programmes that stay siloed will continue to miss the same class of exposure.

From our research:

  • 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
  • Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
  • For a broader breach lens, see 52 NHI Breaches Analysis for recurring failure patterns across exposed credentials and unmanaged access.

What this signals

Identity security is moving from review-heavy governance to evidence-driven control. As organisations add more machine identities and AI-assisted workflows, entitlement lists will matter less than proof of real usage and rapid revocation. Teams that still rely on periodic access review will struggle to keep pace with identity change across cloud, SaaS, and automation layers.

Non-human identity lifecycle discipline is becoming a board-level risk topic. When service accounts, tokens, and API keys outlive the process that created them, the programme inherits hidden access debt. That is why lifecycle ownership, expiry, and offboarding must be treated as operational controls, not administrative housekeeping.

The practical signal for practitioners is simple: if you cannot answer who owns each identity, when it was last used, and how quickly it can be removed, the programme is already behind. That makes continuous visibility and context-aware remediation the next rational step, especially for privileged and third-party access.


For practitioners

  • Unify identity sources into one operational view Correlate IdP, cloud, SaaS, HR, and resource activity data so you can see permission, usage, and ownership in the same record. Prioritise high-risk identities first, especially contractors, privileged users, service accounts, and any account with no clear business owner.
  • Review access based on usage, not entitlement alone Use recent login patterns, resource access history, and business context to challenge dormant or never-used privileges. Make quarterly certifications a fallback, not the primary signal, and require evidence when reviewers keep access in place.
  • Put non-human identities on a lifecycle register Track creation date, purpose, owner, credential type, rotation expectation, and offboarding trigger for every service account, token, certificate, bot, and AI agent. Revoke or reissue credentials when the underlying workflow, vendor, or project changes.
  • Automate response for high-risk identity anomalies Build runbooks that can suspend access, force reauthentication, or revoke credentials when dormant accounts activate, when an identity touches sensitive resources outside its normal pattern, or when a machine identity exceeds its intended scope.

Key takeaways

  • Identity security fills the gap between authentication and real-world access use, which is where most modern identity risk now sits.
  • Non-human identities and dormant permissions create persistent exposure that traditional IAM and quarterly reviews routinely miss.
  • Practitioners should shift toward usage-aware visibility, lifecycle ownership, and fast remediation if they want to reduce identity-driven attack paths.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03The article centers on unmanaged secrets, stale access, and poor NHI lifecycle visibility.
NIST CSF 2.0PR.AC-4Identity permissions and least-privilege enforcement are central to the article's governance model.
NIST SP 800-53 Rev 5IA-5Secrets, tokens, and authenticator management are directly implicated in the article's access risks.
NIST Zero Trust (SP 800-207)The article argues for continuous identity verification rather than perimeter trust.
CIS Controls v8CIS-5 , Account ManagementAccount ownership, dormant access, and offboarding are recurring themes throughout the article.

Align identity decisions with Zero Trust by validating context continuously instead of relying on one-time authentication.


Key terms

  • Identity Security: Identity security is the discipline of governing who and what can access systems, data, and tools, then proving those decisions are enforced. In practice it spans human users, service accounts, tokens, certificates, and AI agents across the full access lifecycle.
  • Identity-Aware Visibility: Identity-aware visibility is the ability to see not just that an AI tool exists, but which identity is using it, what it can reach, and which data it touches. In NHI governance, this turns discovery into actionable control because access can be attributed, reviewed, and revoked.
  • Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
  • NHI Lifecycle Management: The end-to-end governance of a non-human identity from creation and onboarding through active management, monitoring, credential rotation, and secure decommissioning.

What's in the full article

Oleria Security's full article covers the operational detail this post intentionally leaves for the source:

  • Side-by-side explanation of IAM, IGA, and identity security operating models for teams planning a programme redesign.
  • Product-specific examples of usage-aware access intelligence across human and non-human identities.
  • Implementation guidance for automated lifecycle management, access reviews, and continuous remediation workflows.
  • Resource-level visibility examples that show how activity data supports investigations and compliance evidence.

👉 Oleria Security's full post covers the identity security model, lifecycle controls, and usage-based visibility in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 14, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org