How Many Identities in Your Business Should No Longer Exist?

Most organizations can tell you how many employees they have. They can inventory laptops, servers, and cloud resources with reasonable confidence. But if you ask the security team how many identities exist across the business, however, the answer becomes much less straightforward.

The identity landscape now extends far beyond employees. It includes contractors, external users, administrator accounts, service accounts, cloud identities, SaaS accounts, and increasingly AI agents.

But the harder question is not how many identities exist.

It is:

How many of them should still exist — and how much access should they still have?

A former employee may have an active account in a third-party SaaS application. Someone may still hold elevated privileges granted for a project three years ago. A privileged account may not be fully protected by MFA. A service account may remain active even though nobody can identify its owner.

None of these situations necessarily began as a security incident. More often, they are the residue of normal business activity accumulating over time. As identities and permissions multiply faster than ownership, access policies, and security controls can keep up, identity itself becomes part of the enterprise attack surface.

That is the real issue behind identity sprawl.

Identity Sprawl Is Not Really About Having Too Many Accounts

It is tempting to define identity sprawl as an account-count problem. The real issue is whether the organization can still determine which accounts, permissions, and access relationships remain justified.

Consider a normal employee lifecycle. Someone joins the business and receives an initial set of permissions. They change roles, join projects, and gain additional access. Some of the old access is never removed. Over time, privilege creep sets in.

Identity sprawl is what the environment looks like after these small gaps accumulate across hundreds or thousands of users and applications.

A former employee’s main account may be disabled while an account in a third-party SaaS platform remains active. An administrator account may not have been used in months but still retains privileged access. An application may technically require MFA while an alternative login path bypasses the intended SSO or authentication policy. Individually, each issue may look manageable. Together, they expand the organization’s identity attack surface.

The most common risks include unused accounts, partially offboarded users, excessive permissions, MFA coverage gaps, and identities that no longer have a clear owner.

Okta Identity Security Posture Management (ISPM) is designed to surface these kinds of issues across connected identity, SaaS, and cloud environments, including unused accounts, partially offboarded users, and missing MFA controls.

The most dangerous identity is not always one the company does not know about. Sometimes it is the identity everyone can see, but nobody can explain why it still needs to exist.

If You Already Have IAM, Why Do You Need Identity Security Posture Management?

This is a natural question for organizations that already use Okta, Microsoft Entra ID, or another mature IAM platform.

If SSO, MFA, provisioning, and lifecycle management are already in place, what does ISPM add?

The answer is that they solve different problems.

IAM establishes authentication and access controls. It helps determine who a user is, which applications they can access, and how accounts should be provisioned or deprovisioned as their relationship with the business changes. But enterprise identity rarely lives in one system. The same person may have a primary identity in Okta, an account in Microsoft 365, an AWS role, repository access in GitHub, and a completely different set of permissions in Salesforce.

Each system can appear correctly configured when viewed on its own. The risk becomes visible when the relationships are viewed together. A user, for example, may simultaneously hold privileged access, retain permissions that have not been used for months, and have an authentication path that is not adequately protected by MFA.

What security teams really need to understand is:

What does this identity have access to across the enterprise, and how is that identity authenticating?

That is the gap ISPM is designed to address.

Okta ISPM connects to identity providers, SaaS applications, and cloud infrastructure to provide continuous visibility into identities, permissions, and authentication relationships across otherwise fragmented environments.

A useful way to distinguish the two is:

IAM tells the business who can sign in and what access can be granted.

ISPM asks the next question:

Does the identity and access posture that exists today still look secure?

How Okta ISPM Turns Identity Findings Into Security Priorities

Most security teams are not suffering from a lack of findings. They are suffering from too many.

A dashboard that reports 3,000 identity security issues does not necessarily make the environment easier to secure.

The question that matters is: Which one should we fix first?

Imagine two accounts that are not adequately protected by MFA.

One is a low-privilege test account. The other is a privileged administrator with access to a critical application. Both can technically be labelled “No MFA.” Their business impact is completely different.

Okta ISPM is designed to use context and severity to help security teams prioritize those differences. An unprotected privileged user, a critical application without appropriate MFA coverage, or an authentication route that bypasses established SSO and MFA controls should naturally rise above a low-impact configuration issue.

That changes the conversation from finding issues to managing risk.

The first step is to see the identity landscape: users, accounts, applications, permissions, and authentication relationships.

The second is to understand which combinations create meaningful exposure, such as excessive privileges, stale access, missing MFA, or risky administrative identities.

The third is to remediate them.

An unused account can be disabled. Excessive access can be reduced. An MFA policy gap can be corrected. A partially offboarded employee can be fully deprovisioned. An application or workload that has not been used for an extended period can be reviewed and removed if it no longer serves a business purpose.

Okta ISPM also provides visibility into stale applications and long-unused workloads, helping organizations identify access points that may no longer be necessary. The real value of ISPM is therefore not that it finds more problems. It is that it helps the organization decide which identity risks deserve attention first.

Identity Security Should Start Before an Account Is Compromised

Security programs naturally invest heavily in what happens during an attack: detect suspicious activity, generate an alert, investigate the incident, and respond.

But identity security has another stage that begins much earlier: Remove unnecessary attack surface before an attacker has the opportunity to use it.

If a former employee’s account should no longer exist, the best control is not to wait for suspicious activity on that account. It is to remove the account first. If an administrator does not need permanent privileged access, the strongest control is not simply to detect misuse later. It is to reduce the privilege beforehand. If an authentication path is missing MFA, the best time to fix it is before an attacker discovers it.

Okta positions ISPM in this pre-attack stage of Identity Security: continuously identifying identity risks, misconfigurations, excessive permissions, and authentication gaps so the organization can reduce its attack surface before those weaknesses are exploited.

This also clarifies how ISPM complements the rest of an identity program.

Lifecycle Management helps prevent unnecessary access from accumulating as people join, move within, and leave the business.

Identity Governance helps determine whether access is still justified.

ISPM looks across the environment and asks: What identity risk has already accumulated here?

Once those risks can be continuously identified, prioritized, and remediated, Identity Security becomes more than a one-time access configuration exercise. It becomes an ongoing security posture.

A Smaller Identity Attack Surface Gives Attackers Fewer Opportunities

Identity sprawl grows through normal business change: new employees, job moves, departures, new SaaS platforms, more cloud services, additional service accounts, and now new AI and non-human identities.

The goal is not to prevent the number of identities from ever increasing. It is to maintain confidence in five basic questions:

Which identities still exist?

Who owns them?

What do they have access to?

How do they authenticate?

Is that access still justified?

When those answers become unclear, identity begins to shift from a business requirement into a security exposure.

Okta ISPM gives security teams a way to rebuild that visibility across fragmented identity data, identify unnecessary accounts, excessive access, MFA gaps, and other identity misconfigurations, and focus limited security resources on the risks with the greatest potential impact.

Identity Security should not only ask, “Who is attacking us?” It should first ask, “How many identities have we left behind for an attacker to use?”

If your organization cannot confidently explain how many accounts exist, which users hold privileged access, or which permissions have gone unused for months, the issue may extend beyond IAM. It may be time to examine your overall Identity Security Posture.

Contact the advisory team at Master Concept to assess your Identity Security Posture and uncover potential gaps caused by identity sprawl, stale accounts, excessive access, and weak authentication coverage.

FAQ

What is identity sprawl?

Identity sprawl occurs when accounts, permissions, and human or non-human identities are spread across multiple SaaS, cloud, and identity systems, making it difficult to see who has access to what.

Why is identity sprawl a security risk?

It can leave behind stale accounts, excessive permissions, MFA gaps, and unowned identities that unnecessarily expand the identity attack surface.

What is ISPM?

Identity Security Posture Management continuously identifies, assesses, and prioritizes identity risks and security configuration gaps across the enterprise.

What is the difference between IAM and ISPM?

IAM manages authentication and access. ISPM evaluates whether the identities, permissions, and authentication controls already in place are creating security exposure.

What can Okta ISPM identify?

Okta ISPM can help surface unused accounts, partially offboarded users, MFA gaps, excessive access, and other identity security misconfigurations.