Identity governance looks deceptively simple when viewed at small scale.

An employee joins the organization. An account is created. Access is assigned. When the employee changes roles, access changes. When the employee leaves, access is removed.

The basic lifecycle does not change when an organization grows from 10,000 identities to 100,000.

Almost everything around that lifecycle does.

At 100,000 identities, organizations begin to discover that identity governance is no longer primarily about managing accounts and approving access requests. It becomes a problem of data quality, ownership, automation, policy consistency, exception management, and operational scale.

The challenge is not simply having more identities.

It is having more identities, applications, permissions, exceptions, identity sources, organizational changes, and decisions that all interact with one another.

And that is where many IAM programs begin to struggle.

The 100,000-Identity Threshold Is Not a Magic Number

There is nothing inherently special about exactly 100,000 identities.

For one organization, the operational complexity may appear at 30,000 identities. For another, it may not become significant until several hundred thousand.

The more useful way to think about scale is through the number of relationships an IAM program must continuously understand.

Consider a simplified environment:

100,000 workforce identities
5,000 applications
500,000 application accounts
Millions of entitlements
Thousands of groups and roles
Multiple identity sources
Privileged accounts
Service accounts
Contractors and external identities
Temporary access
Exceptions and emergency access

The organization is no longer managing a list of people.

It is managing a large and constantly changing identity graph.

Every identity can have relationships with applications, groups, roles, permissions, devices, managers, departments, locations, projects, and business processes.

The governance challenge grows with those relationships.

1. Identity Data Becomes a Governance Problem

At smaller scale, IAM teams can often compensate for imperfect data through manual knowledge.

Someone knows that an old application is owned by Finance.

Someone remembers that a particular service account belongs to an integration team.

Someone knows that a contractor’s account is temporary.

At 100,000 identities, institutional memory stops scaling.

The IAM platform may contain identity attributes, but those attributes do not necessarily tell the complete story.

For example:

User: John Smith
Department: Engineering
Manager: Jane Smith
Application: Customer Database
Access: Production Read/Write

The system may know that John has access.

It may not know why John has access.

That distinction becomes increasingly important.

Effective governance requires answers to questions such as:

Who owns this application?
Why does this person need access?
Which business process requires it?
Who approved it?
Is the access still being used?
Is the permission excessive?
What happens if the person changes roles?
Who is accountable for reviewing it?

At scale, identity data without contextual data is not enough.

2. Ownership Becomes a First-Class Control

One of the most underestimated problems in large IAM environments is ownership.

Organizations often have reasonably good records of:

Who has access?

But much weaker records of:

Who is responsible for that access?

Those are different questions.

An application may have thousands of users but no clearly accountable business owner.

A group may have hundreds of members but no active owner.

A service account may still exist even though nobody knows which application depends on it.

An entitlement may be technically valid but impossible to review intelligently because there is no accountable decision-maker.

This creates a governance deadlock.

The IAM team can identify the access.

The system can launch a certification.

But the organization cannot make a high-confidence decision because nobody clearly owns the underlying business risk.

At scale, ownership therefore becomes part of the security architecture.

3. Access Reviews Stop Being Simple Approval Exercises

Access certification is often presented as a straightforward process:

Send reviewer a list.
Reviewer approves or revokes access.
Record the decision.
Repeat periodically.

That model becomes increasingly difficult as identity populations grow.

Imagine a manager receiving hundreds or thousands of access decisions.

The question becomes:

How can a reviewer make a meaningful decision about access they may not understand?

A reviewer might recognize an employee’s name.

They may not recognize:

the application,
the entitlement,
the permission,
the business purpose,
the last-used date,
the risk associated with the access.

This creates the rubber-stamp problem.

A review can be technically completed while providing limited security value.

At scale, governance needs to move from:

“Approve this access.”

toward:

“Here is the context you need to determine whether this access remains appropriate.”

That means reviews increasingly need contextual information such as:

access history
last activity
privilege level
peer comparisons
employment status
organizational changes
application criticality
entitlement sensitivity
previous review decisions
segregation-of-duties conflicts

The objective is not to eliminate human decisions.

It is to make human decisions meaningful.

4. Automation Becomes Mandatory

At smaller scale, manual processes can appear manageable.

At 100,000 identities, manual IAM operations become a structural risk.

Consider a simple lifecycle event.

An employee changes departments.

That single event may require:

removing previous application access
adding new access
changing group membership
modifying privileged access
updating application-specific roles
triggering approvals
adjusting data access
changing device or authentication requirements

Now multiply that by thousands of organizational changes every month.

The question is no longer:

Can the IAM team perform this task?

It becomes:

Can the IAM team perform it consistently, quickly, and reliably every time?

Automation becomes necessary not merely for efficiency, but for control consistency.

The goal should be to automate predictable decisions while escalating ambiguous or high-risk situations to humans.

5. Exceptions Multiply Faster Than Policies

Large organizations rarely operate entirely according to the standard process.

There are exceptions.

A senior engineer needs temporary production access.

A contractor requires access beyond the normal role.

A business acquisition introduces a new identity source.

A legacy application cannot integrate with the organization’s standard provisioning system.

An executive requires unusual access.

A project requires temporary privileges.

One exception does not create a problem.

Thousands of exceptions create another governance system.

Over time, organizations can end up with:

Policy + exceptions + exceptions to exceptions.

This creates what might be called governance drift.

The documented IAM policy says one thing.

The effective access environment behaves differently.

A mature IAM program therefore needs to govern exceptions explicitly:

Why does the exception exist?
Who approved it?
When does it expire?
What compensating controls exist?
Is it still necessary?
How many similar exceptions exist?
Could the underlying policy or role be redesigned?

An exception should be treated as a managed condition, not as a permanent configuration.

6. Role Explosion Becomes a Real Operational Problem

Role-based access control is powerful.

But large organizations can discover that simply adding more roles does not necessarily produce better governance.

A role can begin as:

Finance Analyst

Then organizations discover differences based on:

country
business unit
seniority
application
project
environment
data sensitivity

The number of roles can grow rapidly.

Eventually, the organization has hundreds or thousands of roles that nobody fully understands.

This is commonly referred to as role explosion.

The problem is not that roles are inherently bad.

The problem is treating roles as static representations of an organization that is actually dynamic.

At scale, organizations increasingly need a combination of:

roles
attributes
policies
contextual signals
time-bound access
risk-based controls

The architecture should reflect how access decisions actually work rather than forcing every decision into a predefined role.

7. Machine and Non-Human Identities Change the Equation

One of the biggest changes in modern IAM is that workforce identities are only part of the problem.

Large environments may contain:

service accounts
API identities
application identities
workload identities
cloud identities
automation accounts
bots
certificates
tokens
secrets
increasingly, AI agents

These identities may not have a traditional manager.

They may not appear in the HR system.

They may not participate in conventional access reviews.

Yet they can have extremely powerful permissions.

This creates a fundamental governance question:

Who is accountable for an identity that is not a person?

The answer cannot simply be:

“The IAM system knows about it.”

Technical existence is not accountability.

A mature governance model needs to establish relationships between non-human identities and accountable owners, applications, workloads, environments, and business purposes.

This becomes particularly important as autonomous software begins performing actions that previously required humans.

8. Identity Governance Becomes an Integration Problem

At scale, IAM cannot operate in isolation.

Important identity information is distributed across systems such as:

HR platforms
directories
identity providers
applications
cloud platforms
IT service management systems
privileged access systems
endpoint platforms
security tools
data platforms

The IAM system may be the central control plane, but it is rarely the complete source of truth.

This creates another major challenge:

data synchronization.

An identity may be terminated in HR but remain active in an application.

An employee may change departments but retain their old permissions.

An application may contain accounts that were never connected to the central identity platform.

A service account may exist entirely outside the normal lifecycle process.

At scale, governance therefore depends heavily on visibility across the identity ecosystem.

9. The IAM Team’s Operating Model Must Change

Perhaps the biggest change after reaching large identity populations is organizational.

A small IAM team can sometimes operate through individual expertise.

Large environments require defined operating processes.

That includes clear responsibility for:

identity lifecycle
access requests
provisioning
deprovisioning
access reviews
privileged access
application onboarding
role engineering
policy management
exception management
identity data quality
audit evidence
non-human identities

The IAM team also needs to distinguish between:

What should be automated?

and

What requires human judgment?

Automation should handle predictable lifecycle events.

Humans should focus on ambiguous, exceptional, and high-risk decisions.

That division becomes increasingly important as identity populations grow.

10. Metrics Have to Move Beyond Completion Rates

A large IAM program can produce impressive numbers.

For example:

99.8% of access reviews completed.

That sounds excellent.

But it does not necessarily answer whether the organization is actually safer.

Better questions include:

How much inappropriate access was removed?
How long does it take to remove access after termination?
How many identities have no accountable owner?
How many applications lack a defined owner?
How many privileged accounts are inactive?
How much access is never used?
How many exceptions are past their expiration date?
How many identities exist outside the standard lifecycle?
How much provisioning is automated?
How quickly can high-risk access be revoked?

The important shift is from measuring activity to measuring control effectiveness.

11. Scale Changes the Meaning of “Visibility”

IAM teams often say:

“We have visibility into our identities.”

But visibility can mean several different things.

You might know:

Who exists.

But not:

What they can access.

You might know:

What they can access.

But not:

Why they have it.

You might know:

Why they have it.

But not:

Whether they still need it.

You might know:

Whether they still need it.

But not:

Whether they are actually using it.

True governance requires progressively richer visibility.

A useful mental model is:

Identity → Access → Purpose → Usage → Risk → Ownership

The further an organization moves along that chain, the more meaningful its governance decisions become.

12. What a Mature Large-Scale IAM Program Looks Like

There is no single architecture that works for every enterprise.

But mature programs tend to share several characteristics.

1. Reliable identity sources

The organization understands where identity information originates and which system is authoritative for each attribute.

2. Defined ownership

Applications, entitlements, roles, and non-human identities have accountable owners.

3. Automated lifecycle

Joiner, mover and leaver processes are increasingly automated.

4. Contextual access reviews

Reviewers receive enough information to make meaningful decisions.

5. Managed exceptions

Exceptions have owners, justification and expiration.

6. Risk-based governance

Not every access decision receives identical treatment.

7. Non-human identity governance

Service accounts, workloads, applications and other machine identities are governed alongside workforce identities.

8. Measurable control effectiveness

IAM metrics demonstrate reduction of risk rather than merely completion of workflow.

9. Continuous improvement

The organization regularly examines where manual processes, exceptions and poor data are creating recurring problems.

The Real Scaling Problem

When an organization reaches 100,000 identities, the biggest mistake is to think:

“We need a bigger IAM system.”

Sometimes additional technology is necessary.

But technology alone does not solve the underlying problem.

The real challenge is that identity governance becomes a systems problem.

More identities create more relationships.

More relationships create more decisions.

More decisions create more exceptions.

More exceptions create more operational complexity.

And that complexity eventually exposes weaknesses in ownership, data quality, automation and accountability.

The organizations that scale successfully are not necessarily those with the largest IAM platforms.

They are the ones that build a governance model capable of answering five fundamental questions consistently:

Who is this identity?

What can it access?

Why does it have that access?

Who is accountable for it?

What should happen when circumstances change?

At 10,000 identities, those questions can sometimes be answered manually.

At 100,000, they have to be answered systematically.

And beyond that, they increasingly need to be answered continuously.

That is the real transition from identity management to identity governance at scale.