Bringing Identity Governance to Scale Across 100,000+ Identities

Organization: Large multinational enterprise
Industry: Financial Services
Environment: Hybrid infrastructure, multiple identity sources, 5,000+ applications
Identity population: 100,000+ workforce and external identities

Executive Summary

A multinational financial services organization had built a mature identity environment over many years, but its growth had created a governance problem.

The organization had more than 100,000 identities spread across multiple regions, thousands of applications, several identity sources, and a mixture of modern and legacy systems.

From a distance, the IAM program appeared healthy.

Identity provisioning was established. Access reviews were performed regularly. Security policies existed. Major applications were integrated with central identity infrastructure.

But as the environment grew, a different problem emerged:

The organization could manage identities, but it was becoming increasingly difficult to govern the relationships between identities, applications, permissions, ownership and business purpose.

Access reviews generated large volumes of decisions without always providing sufficient context. Application ownership was inconsistent. Service accounts were difficult to track. Employee movements created access accumulation. Manual processes remained common around applications that could not participate in standard lifecycle workflows.

The organization therefore shifted its objective.

Instead of asking:

“How do we process more IAM transactions?”

it began asking:

“How do we establish reliable governance across a continuously changing identity environment?”

The resulting program focused on visibility, ownership, lifecycle automation, risk-based governance and measurable control effectiveness.

The Environment

The organization had grown substantially through geographic expansion, new business lines and several acquisitions.

Its identity environment reflected that history.

The environment included:

• More than 100,000 workforce and external identities
• Multiple authoritative identity sources
• Thousands of enterprise applications
• Cloud and on-premises infrastructure
• Multiple directories
• Privileged identities
• Service and integration accounts
• Application-specific accounts
• Legacy applications
• Multiple access-control models

The central identity platform provided important capabilities, but it was not a complete representation of the organization’s identity environment.

Some applications had modern provisioning.

Others relied on manual processes.

Some access was role-based.

Other applications used application-specific permissions.

Several older systems maintained their own accounts.

The organization therefore had a common IAM platform but a distributed identity reality.

The Challenge

The organization initially viewed its primary challenge as one of scale.

More identities meant more:

• provisioning events
• access requests
• certifications
• application integrations
• support tickets
• lifecycle changes

But deeper analysis showed that scale was exposing a more fundamental issue.

The organization could frequently answer:

Who has access?

It had more difficulty answering:

Why do they have it?

And in some cases:

Who is accountable for deciding whether they should continue to have it?

This distinction became increasingly important.

Access Reviews Were Growing, but Context Was Limited

The organization conducted periodic access certifications across important applications.

Completion rates were high.

However, reviewers were often presented with large lists of users and entitlements.

A typical review might tell a manager:

Employee X has access to Application Y.

It did not always provide enough context to determine:

• whether the employee still used the application
• when the access was last used
• how sensitive the entitlement was
• whether the employee had recently changed roles
• whether similar employees had the same access
• whether the access was temporary or permanent

As the number of identities and entitlements increased, the organization became concerned that review completion was becoming a better measure of workflow participation than governance effectiveness.

Ownership Was Inconsistent

The organization also discovered that ownership information was incomplete.

Some critical applications had clearly identified business owners.

Others had technical owners but no clearly accountable business decision-maker.

Some groups had administrators but no defined business owner.

Service accounts presented an even greater challenge.

An account could be technically active and associated with an application, while the organization could not confidently identify the person or team responsible for its continued existence.

This created a simple but important governance problem:

Visibility without accountability.

Knowing that access exists is not enough.

Someone must be responsible for deciding whether that access remains appropriate.

Employee Movement Created Access Accumulation

The organization had relatively mature joiner and leaver processes.

The mover process was less consistent.

Employees frequently changed:

• departments
• managers
• business functions
• locations
• responsibilities

When employees moved, new access was generally provisioned.

Removing previous access was more complicated.

In some applications, historical access remained because the organization could not confidently determine whether it was still required.

Over time, employees could accumulate access associated with multiple roles.

This created a gradual expansion of the organization’s access footprint.

It was not necessarily caused by a single control failure.

It was the result of thousands of small lifecycle decisions.

The Strategic Shift

The organization decided that simply processing more access requests or increasing review frequency would not solve the underlying problem.

It established five priorities:

1. Improve identity and access visibility

Create a more complete picture of identities, accounts, applications and entitlements.

2. Establish ownership

Identify accountable owners for critical applications, access structures and non-human identities.

3. Improve lifecycle governance

Strengthen joiner, mover and leaver processes, particularly around role changes.

4. Make access reviews more meaningful

Provide reviewers with additional context and prioritize higher-risk decisions.

5. Measure outcomes

Move IAM reporting beyond workflow completion toward risk reduction and control effectiveness.

The Approach

Step 1: Establish the Identity Baseline

The organization first created an inventory of its identity environment.

Rather than focusing exclusively on workforce identities, the baseline included:

• human identities
• application accounts
• service accounts
• privileged accounts
• groups
• roles
• applications
• entitlements

The objective was not to immediately clean everything.

It was to understand the environment first.

This distinction proved important.

Attempting to remove unknown or apparently unused objects without understanding their dependencies could create operational disruption.

The first objective was therefore:

Know what exists before deciding what should change.

Step 2: Classify Applications and Access

Not every application represented the same level of risk.

The organization introduced a classification model based on factors such as:

• business criticality
• data sensitivity
• privilege level
• regulatory importance
• number of users
• access type
• authentication architecture

This allowed governance effort to be prioritized.

A low-risk internal application did not need the same governance treatment as a system containing highly sensitive financial information.

The principle was straightforward:

Governance intensity should reflect risk.

Step 3: Establish Ownership

The organization then focused on accountability.

Critical applications were assigned business owners.

Where possible, ownership was also established for:

• privileged groups
• sensitive entitlements
• service accounts
• application identities
• major access roles

Ownership was treated as more than an administrative field.

The organization defined what owners were actually responsible for.

For example, an application owner could be accountable for determining:

• which access categories were appropriate
• which entitlements were sensitive
• who should review access
• which exceptions were acceptable
• when access should be removed

This changed ownership from documentation into a governance control.

Step 4: Improve the Mover Process

The organization redesigned role-change governance around access deltas.

Instead of treating a mover as simply another provisioning event, the process examined:

Previous access

versus

New required access

The difference became the object of governance.

This made it easier to identify access that should be removed as part of a role change.

It also reduced the tendency to treat access accumulation as an inevitable consequence of employee mobility.

Step 5: Add Context to Access Reviews

The organization retained periodic certification where appropriate.

But the review experience was changed.

Where available, reviewers were provided with additional information such as:

• identity attributes
• application criticality
• entitlement sensitivity
• recent organizational changes
• access history
• privilege information
• ownership
• previous decisions

The purpose was not to eliminate human judgment.

It was to improve it.

A reviewer should not have to decide whether access is appropriate based solely on a name and an application.

Step 6: Treat Exceptions as Temporary Conditions

The organization also introduced stronger controls around exceptions.

Exceptions required:

• business justification
• accountable owner
• approval
• defined duration
• periodic reassessment

Long-lived exceptions were specifically identified for review.

This helped distinguish between:

A temporary deviation from policy

and

A permanent access model that was never formally designed.

Step 7: Automate Predictable Lifecycle Events

The organization then prioritized automation.

The objective was not to automate every IAM decision.

Instead, predictable events were targeted first.

Examples included:

• standard onboarding
• standard termination
• routine group changes
• predefined role transitions
• access removal following authoritative lifecycle events

Human review remained important for:

• unusual access
• sensitive permissions
• exceptions
• privileged access
• ambiguous situations

This created a practical division:

Automation for repeatable execution.

Human judgment for risk-sensitive decisions.

Measuring the Change

The organization deliberately avoided using access-review completion as its primary measure of success.

Instead, the program introduced a broader measurement framework.

Metrics included:

• time to revoke access after termination
• percentage of critical applications with accountable owners
• percentage of privileged identities with owners
• percentage of mover events resulting in appropriate access changes
• number of long-lived exceptions
• percentage of lifecycle events automated
• volume of dormant or potentially unnecessary access
• percentage of identities covered by defined governance processes
• remediation time for access-review decisions

This created a more complete picture of the IAM environment.

What Changed

The most important change was not a single technology deployment.

It was a change in the organization’s mental model.

IAM moved from being viewed primarily as:

A system for managing accounts and access requests

toward:

A governance capability for managing identity-related risk.

The organization gained a clearer understanding of:

• where identity data originated
• which applications were critical
• who was accountable for access
• where lifecycle processes were weak
• where manual processes created risk
• which exceptions required attention
• where access accumulated
• which governance controls were actually effective

The program also created a foundation for continuous improvement.

Instead of waiting for an audit finding or a major transformation project to expose identity problems, the organization could identify areas of increasing identity debt earlier.

Lessons Learned

1. Scale Exposes Governance Weaknesses

Large identity populations do not necessarily create new IAM problems.

They expose problems that were already present.

Manual processes, unclear ownership and inconsistent lifecycle controls become much harder to hide as the environment grows.

2. Visibility Must Be Connected to Accountability

Knowing that access exists is only the first step.

Effective governance requires someone who can make an informed decision about that access.

3. Access Reviews Are a Control, Not the Goal

A completed review does not automatically mean that access was appropriately governed.

The quality of the decision matters more than the percentage of boxes checked.

4. Employee Movement Deserves More Attention

Organizations often invest heavily in onboarding and termination while underestimating the governance implications of internal movement.

A role change can be an access-risk event just as much as a new hire.

5. Non-Human Identities Cannot Remain Outside the Governance Model

Service accounts and other machine identities may not have managers in the traditional sense.

They still need accountable ownership, purpose, lifecycle controls and appropriate access.

6. Automation Should Follow Understanding

Automating an unclear process can simply make an ineffective process run faster.

The organization therefore focused first on understanding the identity environment and then automating repeatable processes.

The Broader Takeaway

At 100,000 identities, identity governance becomes less about managing individual accounts and more about managing relationships.

Relationships between:

• identities and applications
• users and permissions
• employees and organizational roles
• applications and owners
• service accounts and business processes
• access and business purpose

The larger the environment becomes, the less sustainable it is to rely on individual knowledge, manual processes and periodic cleanup.

The organizations that govern identity effectively at scale tend to build around a few fundamental principles:

Know what exists.

Know who owns it.

Understand why access exists.

Automate predictable lifecycle changes.

Prioritize risk.

Treat exceptions as temporary.

Measure outcomes rather than activity.

Most importantly, identity governance should not be viewed as a project with a finish line.

Identity environments continuously change.

People change roles.

Applications are introduced and retired.

Businesses merge.

Cloud workloads appear.

Machine identities multiply.

Permissions evolve.

The governance model therefore has to evolve with them.

At scale, the objective is not to achieve a perfectly clean identity environment once.

It is to build an environment in which identity risk can be continuously understood, governed and reduced.