Identity Governance at Scale: Why Identity Volume Is the Wrong Measure

For CISOs, IAM leaders and compliance teams in complex enterprises, identity scale is often measured by the wrong number.

A platform may be able to process millions of accounts and still leave critical applications, entitlements and non-human identities outside effective governance. Headcount is rarely the real constraint. Complexity is.

Every acquisition, cloud application, legal entity and AI agent introduces another place where access can be granted, changed or overlooked. The question is therefore not simply whether an identity platform can accommodate more users. It is whether the organisation can bring every material identity and application under consistent, auditable policy—without rebuilding its governance model each time the business changes.

That is the difference between scaling identity administration and scaling identity governance. This makes time to governance coverage a more meaningful measure of scale than the number of identities stored in a platform.

The argument in brief

Identity governance operates at scale when an organisation can:

• See entitlement-level access across critical applications, not merely accounts and role names.
• Apply consistent policy to human and non-human identities.
• Evaluate risk across applications, entities and organisational boundaries.
• Bring newly acquired and previously unmanaged systems into scope without a multi-year replacement programme.
• Produce evidence showing what was approved, why it was approved and which policy was applied.

If scale only means processing more identities inside the applications already connected, the organisation has increased capacity, not coverage.

Why identity risk grows with scale

Many centralised IGA programmes work well for the applications they have fully onboarded. The problem appears when extending that model to multiple ERP instances, acquired applications, legacy systems and locally managed SaaS platforms requires separate integrations, entitlement models and governance processes.

Four dimensions of identity scale

Identity scale has four dimensions, and headcount is only one of them.

• Application scale. Each ERP, SaaS platform and legacy application has its own access model. An identity platform may know that a user has a role without showing the privileges, data access or sensitive actions contained within it.
• Organisational scale. Access that is appropriate in one ledger, legal entity, operating unit or geography may be inappropriate in another. Governance therefore needs business context, not simply a global list of role assignments.
• Identity scale. Employees now sit alongside contractors, service accounts, integration users, bots and AI agents. These identities have different owners and lifecycles, but they can reach the same sensitive data and business processes.
• Change scale. Acquisitions, reorganisations and application changes continually alter the environment. If governance coverage takes months or years to catch up, risk accumulates in the gap.

The decisive metric is not how many identities a platform stores. It is how much of the organisation’s material access it can govern—and how quickly that coverage can expand.

None of these problems are obvious in a single-entity rollout. They appear specifically at scale, which is why a platform that looked adequate for one region fails once it is asked to cover ten.

What “at scale” actually means

Five questions that reveal whether governance really scales

Buyers should look beyond connector counts and identity volumes.

• Coverage: What proportion of material applications and entitlements is actually governed today?
• Depth: Can reviewers see the privileges and data access beneath a role name?
• Context: Can policy distinguish between legal entities, operating units, ledgers, locations and other business boundaries?
• Consistency: Can the same policy evaluate access across ERP, SaaS, legacy and identity platforms?
• Time to coverage: How long does it take to bring an acquired or previously unmanaged application under governance?

A platform that performs well on identity volume but poorly on these measures is scaling administration, not governance.

How to govern all identity types

AI agents, APIs and service accounts are changing governance faster than employee growth. In many large enterprises, non-human identities already outnumber employees. Service accounts, integration users, API credentials, bots and AI agents are also being created and changed at machine speed, often without the ownership and lifecycle processes applied to employees.

Governing all identity types under one model means:

• Every identity type — human or non-human — has a named owner responsible for its access and behaviour.
• Segregation of Duties and critical-access policies evaluate the risk created by an identity’s effective access, whether that identity is an employee, a service account or an AI agent. Ownership, approval and monitoring may differ by identity type, but the underlying business risk does not disappear.
• Access reviews and certifications cover service accounts, integration users, bots, API keys and AI agents, not just employees and contractors.
• Lifecycle events — creation, activation, change, retirement — are defined for non-human identities the same way they are for people, including short-lived cloud and AI workloads that exist for minutes or hours.

Leaving any identity type outside this model does not remove the risk. It just pushes it into the blind spots where auditors, CISOs and CFOs usually find it later.

For a deeper look at this, SafePaaS has a dedicated perspective on non‑human identities and their governance model.

Explore a federated model for governing non-human identities, including service accounts, integration users, bots and AI agents.

How continuous monitoring actually helps

Point-in-time reviews were built for smaller, slower environments. At scale, with more systems, entities, identities and change, continuous monitoring is what keeps governance close to reality. With SafePaaS, continuous monitoring is not just alerts and dashboards. It is supported by a policy-based access model that evaluates identity, resource, organisational and risk context when access changes.

Continuous governance in SafePaaS:

• Re-evaluates SoD and sensitive-access risk when roles, privileges or organisational context change, including conflicts created across connected applications.
• Identifies access that no longer aligns with current organisational context and routes the exception through review, mitigation or remediation workflows.
• Identifies new or changed machine identities as they appear in Oracle, SAP, Workday, SaaS and AI platforms, linking them to owners, policies and evidence.
• Keeps the evidence trail continuously current, so SOX and ITGC requests pull normalised, ready-to-use proof rather than triggering a reconstruction exercise.

SafePaaS describes this model in more detail in its policy-based access control content, where policy becomes the core abstraction for scale and compliance rather than roles alone.

At small scale, the gap between periodic reviews and continuous governance is tolerable. At multi-entity, multi-ERP, AI-heavy scale, that gap is exactly where most unaddressed risk and audit findings accumulate.

What a control plane should unify

What distinguishes federated governance from another centralised IGA layer

A central dashboard is not the same as a governance control plane. Reporting can aggregate data while the policies, decisions and evidence beneath it remain fragmented.

A federated identity governance model connects governance across the systems an organisation already uses. It does not require every application to surrender its identity data, workflow and provisioning to a new central platform before it can be governed.

SafePaaS is designed around that distinction:

• Entitlement-level access reviews: Reviewers see the privileges behind roles, giving them enough information to make and defend access decisions.
• Context-aware segregation of duties: SafePaaS evaluates legal entity, business unit, operating unit, geography and other organisational boundaries to distinguish material conflicts from low-value exceptions.
• Cross-system governance: Policies can identify combinations of access that become risky across applications, not merely conflicts contained within one system.
• Coexistence with existing investments: SafePaaS can work alongside platforms such as SailPoint, Okta and ERP-native tools rather than requiring a replacement.
• Coverage for difficult applications: API connections, data transformation and file-based ingestion provide practical routes for governing SaaS, on-premises and legacy applications.
• Auditor-verifiable evidence: Requests, approvals, policy evaluations, mitigating actions and access changes are retained as part of the governance record.
• Modular adoption: Organisations can begin with the highest-risk coverage gap and expand without committing to an all-or-nothing IGA transformation.

The result is not simply a more complete identity inventory. It is a consistent decision and evidence layer across a heterogeneous enterprise.

SafePaaS defines this architecture as federated identity governance — a central control plane layered above IAM and below ERP/SaaS so policies, reviews and controls can operate continuously across the estate.

A platform that needs a different configuration, rule set or reporting process for each entity is not unifying governance; it is centralising dashboards while the control model stays fragmented underneath.

Business enablement: why scale governance instead of just scale security

When governance does not scale:

• Close cycles slow down because access issues, late reviews and unresolved SoD conflicts hold up sign-off.
• Audit fees and internal effort increase because evidence has to be manually assembled from multiple systems and spreadsheets.
• Finance leaders carry more misstatement and fraud risk because money-moving roles and machine identities cannot be consistently governed across ERP and SaaS.

Scaling governance with a federated control plane does the opposite:

• Financial close and control sign-off are less exposed to late access exceptions when evidence and unresolved SoD risks are visible before period-end.
• Audit preparation requires less reconstruction when approvals, policy evaluations and remediation evidence are retained in a consistent record.
• CFOs and CISOs gain a clearer view of where identities can move money or change critical data, human or non-human, and what controls sit around those actions.

This is ultimately a board-level issue: leaders may be signing off on financial information produced by applications that remain only partially governed. Explore the board’s role in addressing identity governance gaps.

Compliance: SOX, ITGC, AI and non-human identities

For SOX-regulated ERP environments, identity at scale is now a compliance problem as much as a security one. As non-human identities gain access to financially significant systems, audit and control owners need to determine whether existing ITGC and application-control procedures cover the actions those identities can perform. That includes:

• Identifying which human and non-human identities can execute sensitive activities.
• Demonstrating how access was requested, approved and reviewed.
• Evaluating SoD and sensitive-access risk across connected systems.
• Retaining evidence of exceptions, mitigating controls and remediation.

For organisations that need to extend this model beyond access, SafePaaS also supports continuous ITGC and ITAC monitoring  across high-impact access changes, configurations and transactions.

Continuous monitoring can strengthen this evidence and surface changes between periodic certifications. It complements formal access reviews; it does not eliminate the need for them.

SafePaaS addresses this by acting as a federated governance layer above IAM and below ERP/SaaS, turning fragmented identity, access and transaction data into a single compliance and control model. Instead of extending legacy IGA one integration at a time, you add a control plane that can orchestrate policy, user access reviews, SoD and AI-related controls across the full risk surface.

What broader governance coverage can deliver

A Fortune 500 animal-health company used SafePaaS alongside SailPoint and SAP GRC to extend governance beyond its core ERP environment. In nine months, it:

• Increased high-impact applications under governance from 8 to 22.
• Reduced quarterly access-review effort by 55%.
• Cut median fulfilment time in selected non-ERP applications from three business days to less than one.
• Completed its next annual audit with no critical access findings related to non-ERP applications.

Read the enterprise-wide identity coverage case study

A Fortune 500 financial-services company used SafePaaS with SailPoint, Okta, Workday and Oracle ERP. It reduced Oracle ERP access fulfilment from two to three days down to a few hours and freed approximately 110 hours each month across business and IT teams.

See the customer results

FAQ

Why do legacy IGA tools struggle specifically at scale, even if they work for a single entity?

The difficulty is usually not raw platform capacity. It is extending deep governance to every material application. Each new system may require integration, entitlement modelling, policy mapping and local business context. When that work is slow or uneconomic, central IGA covers part of the estate while spreadsheets, tickets and local administration persist elsewhere.

Does scaling governance require replacing the existing IGA platform?

Not necessarily. A federated approach can preserve existing identity administration, authentication and ERP investments while adding consistent policy, cross-system risk analysis and audit evidence around them. This gives organisations a way to close priority coverage gaps incrementally rather than beginning another enterprise-wide replacement programme.

Does “identity at scale” mainly mean more employees?

No. Employee count is the smallest part of it. The harder scaling factors are the number of systems, entities and identity types, including contractors, service accounts and AI agents, that all need to be governed under one consistent policy.

How does continuous monitoring differ from more frequent reviews?

More frequent reviews are still point-in-time snapshots. Continuous monitoring evaluates access as changes happen, so new conflicts or inconsistencies are flagged near the moment they are created and driven back into ERP, SaaS or IAM for remediation.

What happens to governance after a merger or acquisition if there is no unified control plane?

The acquired company’s systems and identities typically keep running under their own access standards until someone manually brings them into the parent’s governance process, which can take months. During that time, that access sits outside real controls and increases audit and misstatement risk.

Where SafePaaS fits

The next question is not “How many identities can we manage?” It is: how much of our material access is governed, and how quickly can we close what remains outside the model?

SafePaaS helps organisations answer that question across human and non-human identities, ERP, SaaS, cloud and legacy applications. Its federated architecture connects existing identity and business systems to a common policy, risk and evidence layer, allowing organisations to extend governance without discarding investments that already work.

The practical starting point is a coverage assessment: identify the applications, entitlements and identity types that can affect financial reporting, sensitive data or critical operations, then measure how consistently they are governed today.

Book time with SafePaaS to talk through governing identity at scale.