Access management gaps expose why least privilege still fails

At a glance

What this is: A comprehensive guide argues that access management must control and monitor human and non-human access across modern IT estates, with access gaps and excessive permissions as the core risk.

Why it matters: It matters because IAM teams have to govern service accounts, human users, and privileged access through the same lifecycle controls, or they will miss the weakest access paths.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Zluri's full guide to access management and least privilege

Context

Access management is the set of controls that decides who or what can reach a system, what they can do there, and how that access is monitored over time. In this guide, the core problem is not authentication alone but the gap between assigned access and actual business need, especially as service accounts and SaaS integrations multiply.

For IAM programmes, that gap becomes a governance issue across human identity, NHI, and privileged access. If organisations cannot see who has access, cannot remove what is no longer needed, and cannot enforce least privilege consistently, they will keep turning routine access drift into a breach path.

Key questions

Q: How should security teams reduce access gaps in SaaS and cloud environments?

A: Start by mapping who and what can access each application, then separate active business need from inherited or stale entitlements. Access gaps shrink when provisioning, recertification, and revocation are tied to ownership, not just workflow completion. The key is to treat every access grant as temporary unless the business case is continuously reaffirmed.

Q: Why do excessive permissions keep showing up in IAM programmes?

A: Because access often accumulates through role reuse, exceptions, and incomplete offboarding, not through a single bad decision. Once permissions spread across SaaS, APIs, and service accounts, teams lose a reliable picture of minimum necessary access. That makes least privilege a governance discipline, not just a policy statement.

Q: What is the difference between access management and identity management?

A: Identity management establishes and maintains the identity record, while access management decides what that identity can reach and continuously controls those permissions. In practice, access management is where authentication, authorisation, revocation, and monitoring meet operational risk. If the identity record is accurate but permissions drift, the programme still fails.

Q: How do organisations know if access reviews are actually working?

A: They should measure whether reviews lead to real entitlement changes, especially removals of dormant, excessive, or ownerless access. If review output does not produce revocation evidence, reduced scope, or tighter expiry controls, the process is cosmetic. Effective reviews change the attack surface, not just the spreadsheet.

Technical breakdown

Authentication, authorisation, and access control in modern IAM

Access management is usually described as a three-step flow. Authentication proves the identity, authorisation checks what that identity is allowed to reach, and access control enforces the decision while monitoring activity. In modern environments, those steps stretch across SaaS apps, directories, APIs, and on-prem systems, so the control plane must also handle lifecycle changes, conditional access, and logging. The practical challenge is that a valid identity can still be a risky one if its permissions are stale, excessive, or inherited from a previous role.

Practical implication: Map each access decision to a lifecycle owner and verify that revocation works as reliably as provisioning.

RBAC, ABAC, and policy-based access control

RBAC assigns access through roles, which works well when job functions are stable and easy to group. ABAC and PBAC add more context by using attributes, resource properties, and policy logic to decide access dynamically. That flexibility matters in complex SaaS estates, but it also increases administrative burden because policies and attributes must stay accurate. If the underlying data is stale or inconsistent, the model creates a false sense of precision while still leaving users or workloads with too much access.

Practical implication: Review whether your policy model is precise enough to reduce over-permissioning without creating ungoverned exceptions.

SSO, OAuth, OIDC, and the delegated access problem

SSO simplifies human authentication, while OAuth and OIDC extend identity into delegated and federated access. That delegation is useful, but it also means organisations are trusting tokens, claims, and consent boundaries rather than only passwords. In practice, this becomes an NHI problem when apps, scripts, or integrations use long-lived credentials or poorly scoped tokens. The failure mode is not just login weakness. It is trust that persists long after the business need has changed.

Practical implication: Treat delegated access and token scope as lifecycle controls, not one-time configuration choices.

Threat narrative

Attacker objective: The attacker aims to convert weak access governance into durable, authorised-looking access that supports data theft or system compromise.

1. Entry occurs when attackers exploit access gaps such as over-permissioned accounts, orphaned accounts, exposed tokens, or misconfigured access settings.
2. Escalation follows when legitimate permissions, service accounts, or delegated tokens allow the intruder to move through SaaS, cloud, or internal resources with little friction.
3. Impact is reached when the attacker uses that access to exfiltrate data, modify systems, or sustain unauthorised presence inside the environment.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Access management is now a lifecycle problem, not a login problem. The article correctly frames access as authentication, authorisation, and control, but the governing issue is whether access can be removed, narrowed, and audited at the same speed it is granted. That is why identity programmes that stop at sign-in controls still leave the most dangerous permissions untouched. Practitioners should treat access management as continuous entitlement governance, not as front-door security.

Least privilege fails when entitlement drift is allowed to become normal. The article highlights RBAC and policy-based access, but the real pattern is that roles, exceptions, and inherited permissions accumulate until access no longer matches task need. This is the classic privilege-creep failure mode, and it is especially dangerous in SaaS environments with many integrations and few clean ownership boundaries. Practitioners should focus on entitlement drift as a measurable control failure, not a theoretical risk.

Orphaned accounts are not an edge case, they are a governance signal. When access is not revoked promptly during offboarding or application retirement, the organisation creates accounts that still authenticate but no longer have a valid business owner. That breaks the assumption that every active credential maps to an accountable identity. The implication is straightforward: access reviews are only credible when they can prove revocation, not just document review.

Delegated access needs stronger lifecycle boundaries than human IAM usually assumes. OAuth, OIDC, and similar delegation patterns extend identity beyond the person, but the article treats them as convenience layers rather than lifecycle-critical trust relationships. That is where NHI governance becomes decisive. Tokens, service accounts, and integrations can remain active long after the original user need has changed. Practitioners should see delegated access as a standing trust surface that must be governed like any other non-human identity.

Access governance is converging across human identity and NHI security. The same controls that limit excessive user permissions also determine whether service accounts, API access, and SaaS integrations can be trusted. That convergence is why IAM, IGA, PAM, and NHI teams can no longer operate as separate functions. Practitioners should align controls around entitlement visibility, revocation, and monitoring across all identity types.

From our research:

• 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.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• For the broader lifecycle picture, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding discipline.

What this signals

Entitlement sprawl is the next access-management pressure point: the more SaaS applications and delegated integrations organisations accumulate, the harder it becomes to prove that access still matches business need. That makes ownership, expiry, and revocation the controls that will matter most in the next IAM cycle, especially where OWASP Non-Human Identity Top 10 risks show up in hidden service accounts and long-lived tokens.

The access-management market is increasingly converging with NHI governance because human permissions and machine permissions now fail in the same places: offboarding, privilege creep, and weak visibility. Organisations that still separate those programmes will miss the shared control objective, which is continuous entitlement integrity across all identity types.

Privilege drift debt: access that is technically valid but no longer business-justified becomes accumulated security debt. The organisations best positioned to reduce that debt will be the ones that pair NIST Cybersecurity Framework 2.0 access governance with lifecycle-driven review and revocation, not just authentication hardening.

For practitioners

• Inventory every access path, not just every user Build a complete map of human accounts, service accounts, API tokens, OAuth grants, and SaaS connectors so ownership and revocation responsibility are explicit.
• Review dormant and orphaned access first Prioritise accounts with no active business owner, no recent use, or no documented offboarding path, then revoke or reassign them before broader recertification cycles.
• Treat delegated tokens as governed identities Scope OAuth and OIDC grants tightly, define expiry and reauthorisation rules, and monitor for tokens that outlive the business purpose they were issued for.
• Tie access reviews to revocation evidence Do not count a review as complete unless the system can show access was actually removed, reduced, or time-bounded after the decision was made.

Key takeaways

• Access management fails when organisations treat it as authentication alone rather than continuous entitlement governance.
• The strongest risk signals are excessive permissions, orphaned accounts, and delegated access that outlives the business need.
• Practitioners should measure access by revocation quality, visibility, and lifecycle ownership, not by the existence of a policy.

Key terms

• Access Management: The discipline of deciding who or what can reach systems, data, and applications, then continuously controlling that access over time. It covers authentication, authorisation, monitoring, and revocation, making it a lifecycle function rather than a one-time permission grant.
• Orphaned Account: An account that still exists and may still authenticate, but no longer has a clear business owner or active operational need. Orphaned accounts are dangerous because they often retain access after offboarding, application changes, or ownership loss, creating unauthorised persistence.
• Delegated Access: Access granted through a token, consent, or federation relationship that allows one identity to act on behalf of another. In modern environments this often applies to OAuth and OIDC patterns, where the real risk is not login but how long the delegated trust remains valid.
• Privilege Creep: The gradual accumulation of permissions beyond what an identity needs to perform its current role. It typically happens through promotions, exceptions, inherited access, and weak cleanup processes, and it is one of the main reasons least privilege fails in practice.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, IAM, identity lifecycle, and secrets management. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Zluri: Access Management: A Comprehensive Guide. Read the original.