The frustration that drives people to bootstrap their own identity governance tooling is almost always the same: SailPoint and Saviynt solve the right problems, but at a scale, cost, and implementation complexity that makes them unusable for teams under a few hundred employees. The lightweight alternative — a collection of spreadsheets, manual offboarding checklists, and SSO logs parsed by hand — stops working around the time the company hits 50 people and has 80 SaaS apps, half of which IT does not know about.

The Reddit thread this article draws from is a practitioner who built their own solution out of that exact frustration. What they ended up building — and the mistakes they made along the way — maps almost perfectly onto what modern mid-market IGA platforms are designed to do. Here is the full picture: the four problems that mid-market identity governance actually needs to solve, and how each one works in practice.

The Mid-Market Identity Problem That Enterprise IGA Doesn't Solve

Enterprise IGA platforms were designed for organizations with thousands of users, complex on-prem infrastructure, dedicated identity engineering teams, and compliance programs that require deep connector-based architecture and highly customized workflow logic. The implementation cycles run 12 to 18 months. The ongoing maintenance requires specialized expertise. The licensing and professional services costs reflect all of that.

For a 50 to 500 person company with a primarily SaaS stack, none of those trade-offs make sense. The problems are real — shadow IT, manual offboarding, sprawling access that no one has reviewed in two years, ex-employee accounts that are still active in applications that don't connect to the IdP — but the solution complexity dramatically exceeds the problem complexity.

What the practitioner in this thread recognized after an early attempt at building enterprise-feature-parity: the mid-market needs radical simplicity, not feature depth. The four things that actually matter are app discovery, HR-driven lifecycle automation, delegated access reviews, and proactive alerts for the risks that matter most. Everything else is overhead that slows down deployment and adds maintenance burden without proportional security value.

Auto-Discovery: Finding the Apps IT Doesn't Know About

Over 60% of enterprise applications operate outside of formal IT oversight. At mid-market scale, the ratio is often worse — a 200-person company that has grown quickly will typically have dozens of tools purchased by individual teams or employees that never went through IT. SaaS sprawl is not a sign of poor governance; it is a natural consequence of how modern teams work. The governance problem is that IT cannot manage access to applications it does not know exist.

Auto-discovery that actually works at this scale pulls from multiple sources simultaneously:

SSO logs identify every application employees are authenticating to through the identity provider. This covers the formally sanctioned stack but misses anything that does not federate to SSO — which is typically where the shadow IT lives.

Financial transaction data — expense reports, corporate card transactions, AP records — surfaces subscription SaaS tools that employees or teams are paying for directly. A tool purchased with a personal card and expensed monthly will never appear in SSO logs. It will appear in finance data.

Browser extension and desktop agent data captures application usage directly from the endpoint, including web apps that require no installation and leave no IdP footprint.

Combining these three sources gives a complete picture of the actual application environment, not just the portion IT formally manages. The first time most mid-market IT teams run comprehensive discovery, they find 30 to 50% more applications than they expected — and a meaningful number of those are tools with access that has never been formally reviewed or governed.

The shadow AI category is worth flagging specifically: generative AI tools adopted by employees for productivity reasons frequently process company data and often have no formal procurement or security review. Discovery that surfaces these tools before they become a data handling issue is materially different from discovery that finds them during an incident investigation.

HR Integration: Making Lifecycle Events the Trigger for Everything

The foundational principle of JML automation — Joiner, Mover, Leaver — is that identity events should be driven by HR system events, not by IT tickets or manual processes. When the HR system records a new hire, that event should trigger provisioning. When it records a departure, that event should trigger deprovisioning. When it records a role change, that event should trigger both.

The reason this matters more than it sounds: manual lifecycle processes do not fail occasionally. They fail consistently at the margins — the employee who left on a Friday afternoon when IT was short-staffed, the contractor whose access was never formally revoked because nobody owned the offboarding step for contractors, the role change that added new access three months ago without removing the previous role's permissions. Each individual failure is small. Across an organization over time, they accumulate into the access sprawl that makes access reviews such painful work.

Automating the full JML cycle against HR events eliminates the category of failure, not just individual instances. New hires get birthright access — the standard applications their role requires — on day one, without waiting for an IT ticket. Role changes trigger both new provisioning and revocation of outdated access in the same workflow. Departures trigger systematic offboarding across every connected application, not just the ones on a checklist that someone remembered to update.

The coverage gap that comes up most often in mid-market environments: applications that do not support SCIM or do not connect to the IdP. Offboarding through SSO deactivation reaches the federated apps cleanly. The non-SSO tools — the 20 or 30 applications that employees access directly with separate credentials — require explicit offboarding actions. A discovery layer that surfaces those applications is the prerequisite for offboarding automation that actually covers the full stack.

Delegated Access Reviews: Getting the Right People Making the Decision

Traditional access reviews fail in mid-market environments for a predictable reason: they make IT responsible for decisions that IT does not have the business context to make well. Whether a specific user should still have access to a specific application or entitlement is a business question, not an IT question. The person who can answer it accurately is the application owner or the user's manager, not an IT administrator reviewing a spreadsheet.

Delegated access reviews route the decision to the person with the right context. Application owners review access to their applications. Managers review their direct reports' access. IT retains visibility and can escalate or override, but the primary review burden sits with the people who actually know whether the access is still needed.

The operational difference is significant. An IT-driven access review for 200 users across 80 applications requires IT to somehow evaluate 16,000 access combinations, most of which they have no context for. A delegated review requires each application owner to review a manageable list of users who have access to their application and confirm whether each one still needs it. The same governance outcome, with dramatically better decision quality and lower IT overhead.

For mid-market compliance programs, the audit trail matters as much as the review itself. Each review decision — approved, revoked, escalated — should be logged with the reviewer identity, the timestamp, and the access in question. When an auditor asks for evidence that access reviews were conducted, the response should be a structured report, not a collection of email threads.

Proactive Alerts: The Risks That Warrant Immediate Attention

Access reviews are periodic by definition. The risks that matter most are not always periodic — they surface between review cycles, and waiting for the next scheduled review to address them is how small exposures become significant ones.

The alert categories that mid-market security teams consistently flag as highest priority:

Dormant admin accounts. A user with administrative access who has not logged in for 30 days or more is either a former employee whose offboarding missed an account, or an active employee who no longer needs admin access. Either way, the account represents unnecessary privileged exposure. Automated flagging of dormant admin accounts surfaces this without waiting for a review cycle.

Active accounts linked to inactive users. When an employee is marked inactive in the HR system but their accounts remain active in connected applications, that is an offboarding gap. These accounts are the practical residue of manual or incomplete deprovisioning — they show up in discovery but not in any formal access review because the user no longer exists in the HR system.

Login attempts from ex-employees. An authentication attempt from a credential associated with a departed employee is a signal worth immediate investigation, regardless of whether the attempt succeeded. In most cases it is a former employee who did not realize their access was revoked, or a credential reuse attempt. In some cases it is something that warrants escalation.

These alerts do not replace access reviews — they supplement them with real-time signal that does not wait for a quarterly cycle.

The Offboarding Gap That Everything Else Depends On

The practitioner who built their own tool noted that offboarding automation was the single biggest game-changer for early users. That is consistent with how mid-market IT teams prioritize their IGA problems: offboarding failure is visible, has obvious consequences, and is the gap that every compliance framework will eventually ask about.

The hard part of mid-market offboarding is not the applications that connect to SSO. Those deprovision cleanly when the IdP account is disabled. The hard part is everything else: the SaaS tools without SCIM support, the applications that employees access with credentials separate from their corporate identity, the tools that were never formally provisioned through IT in the first place.

For those applications, offboarding requires either native integration, browser-based automation that can execute deprovisioning actions in the application UI the way a human administrator would, or a manual task workflow that assigns the deprovisioning action to the right person and tracks it to completion. The combination of all three is how full offboarding coverage works in practice — API-connected apps through native integrations, non-API apps through UI automation, and anything that requires a human step through assigned and tracked manual tasks.

The early mistake the practitioner in the thread described — feature creep, building for imagined enterprise requirements rather than real mid-market pain — is the trap that most IGA vendors also fall into when serving this segment. The four things described above are what mid-market teams actually need. The rest is overhead.

FAQ

What is lightweight IGA and who is it for?

Lightweight IGA refers to identity governance platforms designed for mid-market organizations — typically 50 to 500 employees — that need lifecycle automation, app discovery, access reviews, and offboarding coverage without the implementation complexity and cost of enterprise platforms like SailPoint or Saviynt. The focus is on faster time-to-value and lower ongoing maintenance burden.

How does SaaS app auto-discovery work for identity governance?

Comprehensive discovery pulls from SSO logs, financial transaction data, and endpoint agents to surface every application employees are using — including shadow IT that never went through formal IT procurement. Combining multiple data sources is necessary because any single source misses a significant portion of actual SaaS usage.

Why is HR system integration important for IGA lifecycle automation?

HR system events — new hires, role changes, departures — are the authoritative trigger for identity lifecycle actions. Connecting IGA automation to HR events eliminates the manual handoff between HR and IT that causes offboarding delays and orphaned accounts. When the HR system records a departure, deprovisioning starts automatically rather than waiting for an IT ticket.

What is the difference between IT-driven and delegated access reviews?

IT-driven access reviews ask IT administrators to evaluate whether users should have access to applications, which IT typically lacks the business context to assess accurately. Delegated access reviews route those decisions to application owners and managers who have the context to evaluate whether specific users still need specific access. Delegated reviews produce better decisions at lower IT overhead.