Look at whether new applications, schema changes, and integrations can be absorbed without repeated connector fixes or reimplementation. If every environmental change triggers manual repair, the platform is not scaling governance so much as scaling dependency.
How to tell whether an IGA platform scales cleanly
An IGA platform scales when it can absorb change without turning every new application, attribute, or integration into a custom services exercise. The real test is operational friction: if onboarding, schema drift, or connector maintenance keeps needing bespoke repair, the platform is scaling dependency, not governance. That distinction matters because services-heavy delivery masks product limits.
Look for whether the platform preserves a stable governance model as the environment changes. A strong platform keeps identity data, entitlement logic, and workflow rules adaptable enough that new systems fit into the pattern rather than forcing the pattern to be rewritten. That is the difference between a platform with elasticity and one that merely has a professional services team attached.
The most useful evaluation question is not whether the vendor can make one integration work, but whether they can repeat the outcome across many applications with different schemas, owners, and entitlement models. In practice, scaling depends on how much of the change is handled by configuration, model extension, and reusable patterns, versus one-off connector code and manual remediation.
What failure looks like in practice
When IGA cannot scale, the symptoms are usually visible long before the rollout fails completely. New systems require connector rewrites, schema mapping breaks every time an application changes, and service teams are pulled back in for what should have been routine lifecycle work. That creates hidden backlog, slower onboarding, and a growing gap between the governance intent and what the platform actually enforces.
Another warning sign is brittle integration design. If each connector is tightly coupled to a single app version or data shape, even small upstream changes can trigger rework. A scalable platform tolerates change at the edges while keeping core governance controls intact. A fragile one makes every environmental change a mini implementation project.
Reimplementation risk also shows up in the operating model. If the vendor or integrator has to keep re-coding rules, transforming data by hand, or inventing application-specific exceptions, then the platform is not generalising governance. It is accumulating technical debt in the identity layer.
How to evaluate scalability without buying a services dependency
Judging scale is mostly about evidence. Ask whether the platform can onboard a genuinely different application class without custom engineering, then repeat that test with a second or third system. A platform that claims flexibility should demonstrate that new schemas, entitlement structures, and lifecycle events can be absorbed through configuration and metadata, not just through project labour.
It also helps to separate functional breadth from delivery depth. Some platforms look complete in a demo but rely on implementation work to keep policies, connectors, and review flows aligned once reality changes. For procurement teams, IGA buyer evaluation should therefore include proof that integrations survive change, not only that they work on day one.
Governance scale also depends on lifecycle discipline. If access review, provisioning, deprovisioning, and role maintenance all depend on repeated manual intervention, the platform will struggle as volume grows. The more the system can reuse standard lifecycle patterns, the less likely it is to turn each new application into a special case. NHIMG’s IAM and IGA Basics is a useful reference point for separating core governance functions from implementation noise.
Vendor claims about automation should be tested against connector resilience. Ask what happens when a source system adds an attribute, renames a field, or changes its provisioning logic. If the answer is “we open a services ticket,” the platform may still be useful, but it is not operationally scalable in the way buyers usually mean. The Joiner-Mover-Leaver Guide is a good lens for checking whether lifecycle handling remains repeatable as the environment changes.
Where organisations need deeper control over access design and governance operating rhythm, role design and access review maturity also matter, because poor underlying models make every integration look harder than it should be. Good platforms reduce that burden by making governance patterns reusable across applications rather than bespoke per connector.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | IGA scaling hinges on repeatable account and entitlement lifecycle control. |
| Recommendation — Standardise account lifecycle handling so new integrations do not require custom services work. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Connector and lifecycle scalability depends on managing credentials and related identity material cleanly. |
| AC-2 — Account Management | IGA platforms must scale account provisioning, modification, and removal across applications. | |
| AC-6 — Least Privilege | Role and entitlement scale depend on keeping access models manageable as systems multiply. | |
| Recommendation — Automate credential and authenticator lifecycle handling to reduce connector-specific rework. Use account management controls to keep provisioning and deprovisioning repeatable across systems. Design access models so privilege growth does not force bespoke remediation per application. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | IGA is fundamentally about governing identities and their lifecycle at scale. |
| A.5.18 — Access rights | Scaling IGA requires repeatable access granting, review, and removal processes. | |
| Recommendation — Define identity lifecycle ownership and operating rules before expanding integrations. Make access-right changes configurable so each new application does not need a new process. | ||
Practitioner Guidance
What to verify: Ask for a live demonstration of onboarding at least one application with a different schema and entitlement structure from the vendor’s preferred example. Then require a second change scenario, such as an added attribute or a revised API field, to see whether the connector absorbs it through configuration or breaks into custom work.
What to prioritise: Prioritise repeatability over feature count. A platform that covers many governance functions but needs constant reimplementation is a weaker operational choice than a simpler platform that can be maintained with low-touch change.
Common mistake: Treating the first successful integration as evidence of scale. The real question is whether the platform can keep working as applications evolve, owners change, and entitlement models drift.
Practitioner takeaway: A scalable IGA platform should reduce the marginal cost of each additional application; if marginal cost keeps rising because every change needs services intervention, the platform is not scaling governance, it is scaling dependency.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities at scale?
- How do security teams judge whether an authorization platform is flexible enough?
- How can teams judge whether an identity platform will scale operationally?
- How should security teams implement IGA for IT operations in a way that reduces manual work without losing control?