An IGA platform doesn't fail loudly when its underlying data is bad. It fails quietly: reviewers certify access that was never accurate to begin with, SoD checks miss violations in applications the platform never fully saw, and an auditor asks where a number came from and nobody can answer. The platform keeps running. The governance it's producing just isn't real.
IGA vendors sell workflows: automated reviews, provisioning, segregation of duties, audit reporting. Almost none of them talk about what those workflows actually run on: a continuous stream of identity and access data pulled from dozens of systems that disagree with each other, go stale at different rates, and were never designed to be reconciled into one trustworthy picture.
That data layer is invisible until it isn't:
- A "completed" access review can still leave an organization exposed.
- SoD monitoring can run cleanly for years while a real violation sits untouched in an unmonitored app.
- Audit prep can turn into a scramble to reconstruct evidence nobody saved properly the first time.
This article covers where that failure actually happens inside IGA specifically, and how we've built Zluri to close it.
(This piece assumes the general framework from how Zluri solves the data hygiene problem: data hygiene has seven separate properties, accuracy, completeness, traceability, timeliness, consistency, validity, and integrity, not one. Here we're applying that framework specifically to where IGA workflows break when the data underneath them fails.)
The seven properties in IGA, at a glance
The sections below cover each of these in depth, first where they break, then how we've built around them.
Why IGA is more exposed to bad data than almost any other identity workflow
Authentication tools fail loudly. If SSO breaks, nobody can log in, and the problem announces itself in minutes.
IGA workflows fail silently, because they consume data and produce a decision, and the decision looks legitimate whether or not the data behind it was right:
- A reviewer certifies access based on a status field.
- An SoD engine clears a user based on the entitlements it can see.
- An audit report states a fact based on whatever the platform recorded.
None of these processes have a built-in mechanism for noticing that their input was wrong. They just produce confident, wrong output, and that output becomes the compliance record.
This is what makes data hygiene an IGA-specific problem, not just a generic data quality concern. The four core IGA workflows each have a distinct failure mode when the underlying data breaks.
Where data hygiene actually breaks inside IGA workflows
Access reviews: certifying a snapshot that was never accurate
Access reviews run on whatever status the platform has on file at review time: active, inactive, last login, usage frequency. If that status is wrong, the review doesn't catch it, it inherits it.
The most common version of this failure: an account shows Active because an identity provider reported a login or an active token, when the real story is that nobody has used the application in weeks. A reviewer sees "Active, last login 3 days ago" and certifies it without a second thought, because nothing about the interface signals that the underlying number might be an inference rather than a fact.
The consequence compounds over time. Each review cycle certifies the same inaccurate baseline, and each certification becomes evidence, on record, timestamped, attributed to a reviewer, that the access was checked and confirmed appropriate. The organization isn't just carrying stale access. It's manufacturing audit trail that says the stale access was reviewed and approved.
Segregation of duties: monitoring the apps you can see, blind to the ones you can't
SoD engines detect toxic entitlement combinations, but only within the applications and identity data the platform actually has visibility into.
This creates a specific, dangerous gap: an SoD program can run cleanly, zero violations flagged, for years, not because the organization has no toxic combinations, but because the platform's coverage stops at the identity provider's federated app list, and the real violation lives in a finance tool, a homegrown system, or a departmental app that was never connected.
A clean SoD dashboard and an SoD-free organization are not the same thing. The dashboard only reflects what the platform was able to see, and most platforms (by design) can't see the 60 to 70 percent of an environment that sits outside the SSO federation.
Provisioning and deprovisioning: acting correctly on the wrong picture
Lifecycle automation is only as good as the identity and application data it acts on. Two specific failures recur:
- Duplicate or fragmented identity records. The same person exists as two records because of a name formatting mismatch or a source that reported them slightly differently, and an offboarding workflow correctly revokes the access tied to one record while the other, with real standing access attached, is never touched. The automation executed flawlessly. It just executed against half the person.
- Incomplete entitlement data at deprovisioning. If the platform never captured what a user's actual in-app permissions were, because the integration never supplied granular entitlement data, deprovisioning can disable the account while leaving delegated permissions, shared credentials, or downstream access untouched, because the platform never knew those existed to revoke.
Audit evidence: numbers with no defensible origin
This is where data hygiene failures become financially and legally expensive, not just operationally messy. An auditor doesn't ask "does the dashboard show green." They ask specific questions:
- Why does this figure say this?
- Where did this status come from?
- Who approved this access, and when?
If the platform can't answer with a specific, reconstructable origin, traceable to a source, a timestamp, an actor, the evidence doesn't hold up, regardless of how complete or accurate the underlying data actually was.
A finding here is worse than a finding of bad access. Bad access is a remediation item. Unreconstructable evidence is a finding about whether the entire governance program can be trusted, which puts every other control in scope for re-examination.
Four more ways data hygiene breaks inside IGA, and why they matter just as much
Accuracy, completeness, and traceability get most of the attention because their failures are the most visible. Four quieter properties break just as often, and just as expensively, inside the same four workflows.
Timeliness: reviewing access that changed since the snapshot was taken
A review or SoD check that runs against a data pull from three days ago isn't wrong, exactly, it's describing a version of the environment that may no longer exist. A role change processed on Tuesday but not reflected in the platform until Friday's sync means every review or SoD check run in between is evaluating access that's already stale, and nobody reviewing it has any way to know that.
This is a distinct failure from accuracy. The data can be a perfectly correct record of Tuesday's reality while being a badly wrong record of Friday's. In IGA specifically, where the entire point is certifying access as of right now, that gap is the difference between a review that means something and one that's a formality.
Consistency: the same entitlement, described differently by different modules
SoD engines detect toxic combinations by matching entitlement names and definitions across applications. If the access management module records a permission as "Finance-Admin" and the SoD engine's policy references "Finance Administrator," a genuine toxic combination can sail through undetected, not because the platform lacks the rule, but because the two records of the same fact don't match each other.
This failure is invisible from the outside. The SoD dashboard shows clean because nothing actually triggered the rule, not because there was nothing to trigger it.
Validity: policies and entitlement records missing what remediation actually depends on
A review policy published without a defined remediation path, or an entitlement record with a permission type that doesn't match any category the SoD engine recognizes, isn't inaccurate, it's incomplete in a way that breaks the workflow depending on it:
- Remediation can't execute against an undefined path.
- An SoD rule can't evaluate a permission type it doesn't recognize.
Validity failures in IGA don't produce wrong answers. They produce workflows that silently can't run at all, which is often harder to catch than a wrong number, because nothing necessarily errors, it just doesn't do anything.
Integrity: ownership and assignments that silently orphan when identities change
Access review campaigns, policy ownership, and SoD exemptions all reference specific people: an assigned reviewer, a policy owner, an approver of record. When two identity records merge, get renamed, or an account is consolidated after an offboarding cleanup, anything still pointing at the old record references something that no longer functions: an access review with a reviewer who's technically gone, a policy with an owner nobody can reach.
This is how governance accountability quietly evaporates. The record still shows a name in the owner field. The actual person behind that name may not be who's responsible anymore, and nothing about the interface signals that the relationship has broken.
How Zluri addresses each of these, specifically
The fixes here aren't generic data quality practices. They're the same seven mechanisms covered in our data hygiene deep dive, applied directly to where each IGA workflow above breaks.
Fixing access review accuracy: source priority, not whichever source answered first
Zluri resolves conflicting status signals through a defined source priority hierarchy:
- Manual entry or Workflow
- Direct Integration
- SSO
- Indirect Integration
- Browser or Desktop Agents
A direct integration reporting genuine usage data outranks an SSO reporting a login event, specifically because login-based status is the single most common cause of a reviewer certifying access that looks active but isn't.
What this means for a review in practice: the status a reviewer sees is the highest-confidence answer available, not whichever source happened to report first, and where a direct integration exists, "Active" reflects actual use rather than an inferred token state.
Fixing SoD completeness: eight discovery methods instead of an IdP-bounded scope
SoD monitoring is only as complete as the application inventory feeding it. Zluri's discovery layer pulls from eight distinct sources:
- SSOs
- Direct integrations
- Manual entry
- Transactions
- Agents
- MDMs
- CASBs
- Plugins
This closes the exact gap described above: the finance tool or homegrown app that a federation-only platform never sees is exactly the kind of application these additional discovery methods are built to catch, which means a toxic combination sitting in an unfederated system gets flagged instead of sitting invisible behind a clean dashboard.
Fixing provisioning accuracy: preventing the fragmentation that lets access survive offboarding
Two mechanisms directly address the duplicate-record failure described above:
- Name normalization prevents the same application or identity from splitting into multiple records over a formatting inconsistency in the first place.
- User and Application Merge is the correction mechanism when fragmentation has already happened, consolidating what should have been one record into one, with protections against the merge silently overwriting correct data with incorrect data from the record being absorbed.
On the entitlement side, Custom Permissions close the gap where an integration doesn't natively supply granular permission data, so deprovisioning isn't working from an entitlement picture that's silently incomplete.
Fixing audit defensibility: traceability by default, not by request
Every identity attribute in Zluri traces to a specific, visible primary source. Every application shows its full Sources column and an actual Discovery Date. Three mechanics matter specifically for audit defense:
- Dated groups preserve the full history of license and access quantity changes over time, rather than overwriting a number and losing how it got there.
- Version History captures a complete configuration snapshot, not just a diff, at every policy publish: author, timestamp, and the full Basics, Scope, Rules, and Remediation state as it stood at that moment.
- Run Logs and Audit Logs tie every provisioning event, policy enforcement, and exemption grant back to a specific trigger, actor, and timestamp.
Together, these mean an auditor's "why does this say this" question has an answer built into the record, rather than requiring a reconstruction project after the question is asked.
Fixing review timeliness: continuous discovery instead of a stale snapshot
Zluri's discovery model runs continuously across source types rather than depending on a single infrequent sync, and usage-based thresholds are calculated against defined rolling windows rather than a fixed point in the past.
What this means for a review specifically: the access a reviewer certifies reflects the environment close to real time, not whatever it looked like at last week's sync, which shrinks the window where a role change or termination can slip through uncaptured.
Fixing SoD consistency: one classification method, normalized entitlement names
Name normalization strips formatting inconsistencies before matching runs, and Account Type classification is limited to one method per integration rather than letting two rules potentially classify the same identity differently.
Applied to SoD specifically: an entitlement recorded through one integration and referenced in a policy defined through another has a materially better chance of actually matching, which is what lets the toxic-combination rule catch what it was built to catch instead of silently missing it over a naming mismatch.
Fixing policy validity: required fields enforced at creation, not cleanup
Zluri enforces requirements at the point a record is created rather than leaving them as a data-quality cleanup task for later:
- Ownership fields are required.
- Vendor associations are required.
- Permission types are constrained to defined categories rather than open text.
Applied to IGA specifically: a review or remediation policy can't exist without the fields a workflow will actually need to execute against it, and entitlement records carry permission types SoD rules can reliably evaluate, rather than free text a matching engine has to guess at.
Fixing integrity: ownership and assignments that transfer automatically
When identity or application records merge, ownership fields, including policy ownership and review assignment, transfer automatically to the surviving record rather than continuing to reference one that's been consolidated away.
Applied to governance accountability specifically: a review or SoD exemption doesn't quietly end up owned by a reference that no longer resolves to an actual, reachable person, because the platform updates the relationship at the moment the underlying record changes, not whenever someone happens to notice.
The deeper distinction: active correction, not passive display
Underneath all eight fixes above is one underlying difference worth naming directly. Most IGA platforms, once they've pulled a data point from a connected source, treat their job as finished: display it, trust it, hand it to the next workflow.
If two sources disagree, a record has quietly fragmented into duplicates, or a relationship silently points at something that no longer exists, nothing in a passive architecture is actually watching for that, because nothing was built to.
Zluri's data layer is built to actively catch and correct these failures, not just surface whatever a source last reported:
- Conflicting signals get resolved through a defined source priority hierarchy rather than accepted from whichever source answered first.
- Fragmented identity and application records get caught and merged through a dedicated mechanism, not left to quietly accumulate as duplicates.
- Manual corrections are protected by explicit rules governing when they're allowed to hold.
- Ownership relationships transfer automatically instead of silently dangling when the record they point to changes.
This is the difference that actually separates a platform that runs its workflows correctly on bad data from one that runs them on data it's actively verifying. A passive platform will certify a stale access review, clear an SoD check against an incomplete inventory, deprovision against a fragmented record, or leave a policy owned by someone who's no longer reachable, all while behaving exactly as designed, because nothing in its architecture was built to notice the input was wrong.
An active model treats correctness as something the platform is responsible for producing, not something the customer is left to catch after a number looks wrong.
The pattern underneath all eight fixes
None of the mechanisms above are add-on features bolted onto an existing platform. They're answers to the same question, applied eight times across four workflows: when this specific IGA workflow needs to trust a piece of data, where does the platform's confidence actually come from.
- For reviews: confidence comes from a defined source hierarchy and continuous discovery, so certified access reflects real usage close to real time.
- For SoD: it comes from discovery that isn't bounded by federation and entitlement data that matches consistently across modules.
- For provisioning: it comes from preventing and correcting the fragmentation that lets access survive its own revocation, and from ownership that transfers instead of orphaning.
- For audit evidence: it comes from traceability captured at the moment of the event and policies that can't be published missing the fields remediation depends on.
Data hygiene isn't a separate initiative from IGA. It's the precondition for IGA actually doing what it claims to do.A platform can run every workflow correctly and still produce governance that doesn't hold up, if the data underneath was never accurate, complete, traceable, timely, consistent, valid, and structurally intact to begin with.
Frequently Asked Questions
Can an IGA program pass its access reviews and still be non-compliant?
Yes, and this is one of the more common gaps in practice. A review can be completed on schedule, with every item certified, while the underlying status data was stale or inferred incorrectly. The review process ran correctly; the data it ran on was wrong. Passing a review is not the same as the access actually being appropriate.
How would we know if our SoD monitoring has a coverage gap?
A coverage gap looks identical to a clean SoD program from the dashboard, zero violations flagged either way. The way to check: compare your SoD platform's application inventory against your actual application footprint (finance and expense records are a good cross-check), not against your identity provider's federated app list, since that's the exact boundary most coverage gaps hide behind.
Why does an offboarded employee sometimes retain access after deprovisioning ran successfully?
Most commonly because the deprovisioning workflow acted correctly on an incomplete or fragmented identity record, either a duplicate account the workflow never touched, or entitlement data the platform never captured because the integration didn't supply it. The automation isn't broken; the record it executed against was.
What should we ask an IGA vendor about data hygiene during evaluation?
Six questions cut through most vendor claims, one per property:
- Accuracy: How do you resolve conflicting data from different sources for the same user or application?
- Completeness: How many discovery methods feed your inventory beyond the identity provider?
- Traceability: Can you show me the origin, source, and timestamp behind this specific figure, right now, not in general?
- Timeliness: How current is the data behind a review at the moment I run it?
- Consistency: Does an entitlement get recorded and named the same way across your review and SoD modules?
- Integrity: What happens to policy ownership and review assignments when the identities behind them merge or change?
Vague answers to any of the six are a signal.
Can a review or SoD check technically run correctly and still be wrong?
Yes, and it's a distinct failure from the data simply being inaccurate:
- A review can certify access based on a real, correctly-recorded status that's several days out of date, a timeliness failure, not an accuracy one.
- An SoD check can fail to flag a genuine violation because the same entitlement is named or classified differently across the modules comparing it, a consistency failure, not a completeness one.
Both produce a workflow that executed exactly as designed on data that wasn't fit for the moment it was asked to evaluate.
What happens to an access review or policy when the identity or account behind it changes?
It depends entirely on whether the platform treats relationships as something to maintain or something to leave alone. If a reviewer's account gets merged or consolidated and the platform doesn't update review assignments and policy ownership automatically, those records keep pointing at a reference that no longer functions, an integrity failure: the field still shows a name, but the accountability behind it has quietly broken.
.svg)
