Introduction
Should you replace your legacy IGA or augment it? In most cases, augment it first, because the IGA governs only what it is connected to.
It was built to govern identities it can tie to a person, and everything outside that was never governed. Replacement ends in a cutover after months of deployment, while augmentation closes the gap as systems connect and keeps the replacement decision open.
Oak, the AI-native identity operating system, is built for that sequence. It lands beside the IGA and identity provider you already run and starts with the part of the estate you have never seen.
Below is when building on what you run is right, when replacement is warranted, and what to measure first.
Key takeaways
- Augment first, and replace only when the platform itself has failed.
- Coverage gaps are what the IGA was never scoped to reach.
- Measure effective access and blast radius before scoring any vendor.
- Oak lets you augment a legacy IGA instead of replacing it.
- Service accounts, contractors, RPA bots, and AI agents all need certifying.
Name the failure you actually have
Two different failures hide behind the same frustration, and they point to opposite decisions.
A coverage failure means the IGA governs only what it is connected to, and only identities it can tie to a person. On-prem systems, homegrown applications, out-of-band entitlements, service accounts, and AI agents sit outside the model.
A platform failure means the product is unsupported, its data model cannot hold what you need, or keeping it alive costs more than it returns.
A quick test separates them. If the IGA handles the identities it can see well, and the complaint is about the ones it cannot see, you have a coverage failure.
Coverage failures are easy to mistake for platform failures. A new platform does not widen reach by itself, because it starts from the same question about what it can connect to.
Oak's ConnectAny exists for that gap. It reaches cloud, SaaS, on-prem, homegrown, and custom systems, and the IGA itself, through pre-built and custom connectors, direct API and database connections, file upload, and an on-prem agent.
Replace versus build on, side by side
DimensionReplacing the legacy IGABuilding on the legacy IGA with OakCoverageWhatever the new platform connects to, rebuilt from scratchExtends to cloud, SaaS, on-prem, homegrown systems, and the IGA itselfIdentity typesDepends on the new platform's modelHuman, machine, and AI agent identities on one data modelTime to first answerAfter migration and months of rebuilding role modelsAs systems connect, with the incumbent still runningReview modelDepends on how campaigns are rebuiltContinuous, risk-driven reviews that weigh access against actual usageRemediationDepends on what the new platform can change at the sourceRisk traced to its root cause and fixed at the sourceProgram riskConcentrated in one cutoverIncremental, with the replacement decision kept open
Program risk is the other row to weigh. A cutover concentrates risk in one event, while an incremental path lets each connected system prove itself first.
Time to first answer is where the two paths separate most sharply. A replacement produces its first defensible answer about who can reach what only after the migration finishes.
Building on the IGA reverses that order. The answer comes first, from a live graph beside the incumbent, and the architecture decision comes once you can see what you are deciding about.
When building on your IGA is the right call
Augmentation is the right choice in four situations, and a fifth note applies if you already run an IGA.
Coverage is the gap, not the workflow. If campaigns, approvals, and ticketing work and the problem is everything outside them, replacing the workflow engine solves nothing.
You cannot say what an identity can actually reach. Nested groups, inherited admin rights, and impersonation chains mean the model in the IGA and the access in the system have drifted apart.
Every identity type needs an owner. Every identity needs certifying, from service accounts and contractors to RPA bots and AI agents, each tied to an accountable human owner.
Credentials are a breach path you cannot leave ungoverned. Verizon's 2026 Data Breach Investigations Report found credential abuse in the attack chain of 39% of breaches.
Already running an IGA? Start where it stops, as Oak does, by keeping the IGA running and governing the service accounts and AI agent identities it was never able to see.
When replacement is warranted
Replacement usually earns its cost in three situations. The platform is unsupported with no upgrade path, its data model cannot represent what you now need to govern, or its run cost exceeds what it returns.
Even then, sequence matters. A role model you have never seen in full is hard to migrate.
If you do replace, keep the graph running beside the new platform, so the cutover can be checked against what the graph shows.
Migration is the hard part, which is what Oak's White Glove team takes on. It maps the environment, integrates from inside your infrastructure, and reads policies and roles out of the incumbent, whether you keep it or retire it.
Four things to measure before you decide
Take these four measurements against your current estate before you score a single vendor.
- Coverage gap. List every system in the estate and every system connected to the IGA, and the difference is your dark footprint.
- Effective access. For a sample of identities, compare what the IGA says they hold against what they can reach once nested groups resolve, by privilege level and resource sensitivity.
- Blast radius extends effective access with what an identity can reach through other identities, weighted by how sensitive those resources are. Score your highest-privilege service accounts and agents first.
- Decision latency is the time from a finding to the access being removed in the target system. If findings die in a ticket queue, remediation is the bottleneck.
Write the results down before any vendor meeting, so every pitch is judged against your numbers rather than its own.
Oak's Identity Risk Visibility & Intelligence resolves the second and third from one graph. It continuously correlates what every identity can access with what it actually uses, then routes risk-prioritized decisions to the right reviewers.
Conclusion
Once you can see the coverage gap, the effective access inside it, and the blast radius it creates, the replace-or-augment question mostly answers itself. You decide with evidence instead of a vendor's roadmap.
Oak closes that exposure beside your IGA and keeps every option open.
Bring your current IGA, your connector gaps, and your service account inventory, and book a demo with Oak to see what one live graph shows beside the stack you already own.
Frequently asked questions
Should we replace our legacy IGA or augment it?
In most cases, augment the legacy IGA before you consider replacing it. Augmentation covers the systems and identities the IGA never reached while the IGA keeps running, so you get answers without a cutover. Oak lands beside the IGA and identity provider you already run. Replace only if the platform is unsupported or its data model cannot hold what you need.
How long does replacing a legacy IGA take compared with augmenting it?
Replacing a legacy IGA means months of deployment before the first answer, because migration and rebuilding role models come first. Augmenting it starts producing answers as each system connects, with the incumbent still running. Raise sequencing with the Oak team on a demo call.
Can Oak work alongside the IGA and identity provider we already run?
Yes, Oak is built to work alongside the IGA and identity provider you already run. It reads the incumbent's policies and roles instead of asking you to rebuild them, and builds one live graph beside it. Augmenting does not commit you to replacing anything, and the incumbent keeps doing the work it already does well.
What should we measure before deciding to replace a legacy IGA or augment it?
Before deciding to replace a legacy IGA or augment it, measure four things: the coverage gap between your estate and what the IGA connects to, effective access against declared entitlements, blast radius across other identities, and the time from finding to removal. Oak resolves effective access and blast radius from one graph.
Does augmenting an IGA cover service accounts and AI agents?
Augmenting an IGA covers service accounts and AI agents when the added layer governs every identity type on one data model. Oak covers human, machine, and AI agent identities together. Every identity needs certifying: service accounts, contractors, RPA bots, and AI agents, each tied to an accountable human owner. AI agents are reviewed continuously on their own risk profile rather than a fixed calendar.
Discover related posts
