They should test whether the programme can sustain the core governance workflows, not just configure them once. If joiner-mover-leaver handling, access reviews, and offboarding require a level of manual effort the team cannot maintain, the platform is too heavy for the operating model, even if it looks complete on paper.
How to judge “too heavy” in practice
A mid-market IGA platform is too heavy when the operating model cannot keep pace with the control model. The real test is not feature breadth, but whether the team can run the platform every week without turning standard governance work into a backlog. If it only works during a clean implementation, it is overbuilt for the team that has to live with it.
That means judging the platform against the organisation’s actual volume, staffing, and tolerance for process overhead. A tool that promises full lifecycle governance can still be the wrong fit if it depends on constant tuning, specialist administration, or repeated manual intervention just to keep core workflows moving.
The most useful way to think about it is as an operating burden question. If joiner-mover-leaver work, access reviews, and offboarding all need more effort than the team can reliably sustain, the platform is too heavy even when the product looks mature on paper.
What signals show the operating model is breaking?
The strongest warning sign is when routine governance becomes exception handling. If teams need ad hoc scripting, spreadsheet reconciliation, or repeated vendor support to complete normal reviews or deprovisioning, the platform is no longer supporting the process, the process is supporting the platform.
Another signal is low automation with high coordination cost. If every access request or certification campaign requires too many owners, too many reminders, or too much cleanup, then the system is creating friction that will accumulate as access sprawl and review fatigue. That is especially visible when teams start delaying recertification because the effort is disproportionate to the risk being managed.
Mid-market teams should also watch for a gap between entitlement depth and operational reach. Rich role models, workflow branching, and extensive connector libraries are only useful if the organisation can keep data current, maintain owners, and absorb the administrative load. Otherwise, the platform becomes a partial control surface rather than a dependable governance layer.
What matters most before buying or keeping the platform?
Focus on whether the platform can be owned by the team you actually have, not the team the vendor assumes. A smaller identity team can usually sustain simpler policy logic, fewer exception paths, and tighter scope far better than a broad design that demands continuous expert attention.
Test the core flows under realistic conditions: a normal onboarding, a move with entitlements changing across systems, a leaver who has multiple access paths, and a certification campaign with messy ownership data. If those scenarios require heavy manual rescue, the platform will age badly in production even if the initial rollout was successful.
The underlying decision is whether the tool reduces governance work or merely relocates it. Mid-market teams should look for IAM and IGA Basics when they need to separate what the platform should automate from what still needs human judgment, and they should compare that with Joiner-Mover-Leaver (JML) Guide and Access Reviews and Certification Guide to see whether the core lifecycle and review motions are sustainable at their scale.
Risk and Threat Considerations
When an IGA platform is too heavy, teams often compensate by shortening review cycles, accepting stale access, or delaying offboarding. That creates governance drift, and in practice it means excessive access can persist long enough to become an exposure rather than a theoretical weakness.
Failure mechanism: Operational burden leads to skipped reviews, incomplete deprovisioning, and inconsistent ownership, which weakens the governance controls the platform was meant to enforce.
Impact: Access creep, delayed revocation, and poor evidence quality can increase the likelihood of unauthorized access, audit findings, and preventable privilege retention.
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 addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | IGA heavy-fits are about whether lifecycle access control can be operated sustainably. |
| AC-6 — Least Privilege | Overheavy IGA often fails by leaving excessive access in place too long. | |
| IA-5 — Authenticator Management | IGA burden often includes ongoing credential and secret lifecycle handling. | |
| Recommendation — Limit account lifecycle scope to changes your team can sustain and review reliably. Use least privilege to reduce entitlement volume and review burden. Tie credential lifecycle work to automated renewal and revocation controls. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity governance determines whether lifecycle controls can be run at mid-market scale. |
| A.5.18 — Access rights | Access review and removal are central to deciding whether the platform is too heavy. | |
| Recommendation — Define identity ownership and lifecycle responsibilities that fit the team’s capacity. Set access review and removal processes that can be completed on schedule. | ||
| CIS Controls v8 | CIS-5 — Account Management | Practical account lifecycle management is the operational test for platform heaviness. |
| Recommendation — Standardise account lifecycle handling so it remains manageable at current staffing levels. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | The question is about whether access governance can be sustained, not just designed. |
| Recommendation — Align identity and access workflows with the operating capacity to run them continuously. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Offboarding burden is a core signal of whether governance is too heavy to sustain. |
| NHI-07 — Long-Lived Secrets | Heavy governance often correlates with secrets that outlive practical operational control. | |
| Recommendation — Prioritise reliable offboarding paths that remove access without manual rescue. Shorten secret lifetime so lifecycle obligations stay manageable. | ||
Practitioner Guidance
What to verify: Ask whether a small internal team can complete the three core motions, JML, access review, and offboarding, without relying on specialist intervention for every cycle. If not, the platform is likely oversized for the operating model.
Decision rule: If the platform needs frequent manual correction to keep entitlements accurate, prefer a narrower deployment scope or a simpler control set over adding more workflow sophistication. A lighter system that is consistently used is usually better than a fuller system that is only partially operated.
Practitioner takeaway: The right question is not whether the IGA tool can do more, it is whether your team can keep the minimum governance loop running reliably after the implementation team leaves.
Related resources from NHI Mgmt Group
- How can security teams judge whether an IGA platform will scale without heavy services work?
- How should security teams decide whether Light IGA is enough?
- How do zero trust teams decide whether their trust anchor is too cluster-bound?
- How do IAM and platform teams decide whether an agent should use GraphQL at all?