Integration cost is driven by application complexity, not just count. Two environments with the same number of apps can differ sharply if one uses standard SaaS and directories while the other depends on legacy systems, file feeds, custom APIs, or acquired platforms. The harder the integration pattern, the more implementation effort, maintenance, and specialist support the programme usually requires.
Why Integration Complexity Drives IGA Cost
IGA programmes rarely scale in a straight line with application count alone. The real cost driver is how each system exposes identities, entitlements, approvals, and lifecycle events. A clean SaaS app with standard directory connectors is usually quick to onboard, while a legacy platform, file-based feed, or custom API can require mapping, testing, exception handling, and ongoing support. The same application count can therefore produce very different delivery effort and run cost.
That difference also matters because integration work is not just a one-time project task. Every non-standard connection tends to create more failure points in provisioning, deprovisioning, access review, and audit evidence. In practice, a smaller estate full of awkward integrations can cost more than a larger one built on a predictable pattern. The cost curve is driven by interface complexity, not by app inventory alone.
For identity-heavy programmes, this is also where operational debt accumulates fastest, because each unusual integration often needs a tailored control path rather than a reusable onboarding template.
How It Works in Practice
Integration cost usually reflects the number of distinct patterns you must support, not just the number of target systems. A standard connector to a modern SaaS platform may give you provisioning, deprovisioning, and entitlement sync with limited engineering effort. By contrast, a mainframe, home-grown application, or acquired platform may expose only partial metadata, delayed feeds, or custom business logic that must be translated before IGA can do anything useful.
That creates direct implementation overhead in several places:
Data mapping, when application roles do not match enterprise access models.
Lifecycle orchestration, when joiner, mover, and leaver events need custom handling.
Entitlement reconciliation, when the system cannot reliably return authoritative access state.
Exception management, when manual approvals or human workarounds are needed for edge cases.
Maintenance, when each upstream change breaks a bespoke integration path.
This is why two portfolios with identical app counts can land at very different cost bands. One may consist mostly of modern systems with mature APIs and directory integration, while the other may contain older or heavily customised applications that require scripting, middleware, or recurring remediation. The second portfolio needs more design time, more testing, and more support after go-live. When the integration method is brittle, the programme also spends more effort proving that the control still works after every change.
Industry guidance increasingly treats identity sprawl and weak lifecycle control as systemic exposure, and NHIMG’s Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, which is a useful reminder that lifecycle gaps become costly when integrations are hard to standardise.
These controls tend to break down when acquired applications, custom feeds, and undocumented entitlement logic must all be supported through the same IGA operating model.
Common Variations and Edge Cases
Tighter integration standards often reduce long-term operating cost, but they can increase upfront delivery effort, which forces organisations to balance speed of onboarding against durable control. That trade-off is especially visible in mixed estates where some systems are easy to automate and others are not.
Three edge cases matter most. First, a small estate of legacy systems can be more expensive than a larger cloud-first estate because each legacy connection needs bespoke engineering and more manual reconciliation. Second, an acquired business may temporarily distort costs because its identity model, role design, and reporting structure do not match the parent organisation. Third, systems with weak APIs may still appear “simple” on paper but behave like complex integrations once real provisioning, revocation, and audit requirements are added.
Another common mistake is pricing IGA only on user population or app count and ignoring the hidden cost of entitlement quality. Poor role hygiene, duplicated permissions, and inconsistent ownership all increase the effort required to make integration outcomes trustworthy. The practical lesson is that integration cost should be estimated by connector type, data quality, lifecycle automation depth, and exception volume, not by the number of icons in the application map.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC — Supply Chain Risk Management | IGA integrations depend on third-party and inherited application trust. |
| Recommendation — Assess integration dependencies and control ownership across connected systems. | ||
| CIS Controls v8 | 6 — Access Control Management | IGA cost is driven by provisioning, revocation, and entitlement complexity. |
| Recommendation — Standardize account and entitlement workflows to reduce bespoke integration effort. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Secrets and Credential Management | Hard integrations often hide costly credential, token, and lifecycle handling. |
| NHI-04 — Lifecycle Management | IGA integrations must support joiner-mover-leaver events across varied systems. | |
| Recommendation — Inventory and rotate integration credentials to reduce manual maintenance overhead. Design lifecycle automation for the hardest application paths first. | ||
Practitioner Guidance
What to prioritise: Classify each target application by integration pattern before you estimate cost. Standard connector, file feed, custom API, manual attestation, and hybrid workflows should be treated as different cost classes because they drive different implementation and support burdens.
What to verify: Confirm whether the system can return authoritative entitlement data and support automated revoke actions. If it cannot, the integration is not just “less mature”, it is likely to create manual follow-up work, longer audit cycles, and higher exception handling cost.
Decision rule: If two portfolios have the same number of applications, assume the one with more custom, legacy, or acquired systems will cost more until proven otherwise. Application count is a rough sizing input; integration complexity is the cost determinant.
Practitioner takeaway: The best estimate is the one that prices the hardest ten applications honestly, because those systems usually define the programme’s real delivery and maintenance burden.
Related resources from NHI Mgmt Group
- What do teams get wrong about governing disconnected applications in IGA?
- How should security teams prioritize applications for IGA onboarding?
- How should organisations evaluate the total cost of ownership for an IGA platform before buying it?
- What do teams get wrong about IGA cost after implementation goes live?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
