Fragmented identity data is breaking IAM programmes at scale

At a glance

What this is: Hydden argues that fragmented identity data, manual IAM workflows and services-heavy implementations are leaving large enterprises with programmes that cannot operationalise governance at scale.

Why it matters: IAM, IGA and PAM teams need a single view of identity data because fragmented sources and spreadsheet-driven processes prevent reliable certification, provisioning and control validation across human, NHI and emerging autonomous identities.

Context

Identity data fragmentation is a governance problem, not just a data-integration issue. When identity attributes live across HRIS, directories, cloud platforms, SaaS apps, mainframes and custom systems, no team can confidently treat any one source as the authoritative record for access decisions.

The article ties that fragmentation to manual certification, provisioning and control-validation work that persists even in heavily funded IAM programmes. For IAM, IGA and PAM leads, the operational consequence is familiar: incomplete governance, slow remediation and expensive dependency on services teams to keep the environment semi-functional.

Key questions

Q: What breaks when external identity data is spread across multiple systems?

A: When external identity data is fragmented, teams lose a reliable view of who has access, who approved it, and whether the relationship is still active. That creates duplicate identities, certification gaps, and delayed offboarding. A central system of record reduces those failures by giving IAM, GRC, and sponsors one place to work from.

Q: Why do manual IAM processes persist even after platform investment?

A: Manual work persists when the data foundation is unreliable enough that automation cannot be trusted to close the loop. If identity records disagree across systems, teams fall back to spreadsheets, email and contractor-driven chase work because those are the only ways to reconcile exceptions. The process survives because the records do not.

Q: What are the signs that an IAM programme is becoming services dependent?

A: Look for deployments that need consultants to keep running, roadmap changes that require external configuration help and recurring project work just to preserve basic functionality. Those are signs the programme has shifted from operating a control system to renting expertise to maintain fragility.

Q: Should IAM teams prioritise data unification before more tooling?

A: Yes, when the operating problem is inconsistent identity truth rather than missing functionality. More tools do not fix conflicting records, delayed updates or duplicated sources of truth. Teams get better assurance by reducing identity-data fragmentation first, then automating workflows that can actually trust the underlying inputs.

Technical breakdown

Why fragmented identity data breaks governance

Identity governance depends on consistent attributes, stable relationships and a defensible source of truth. In large enterprises, those inputs are split across systems that update on different schedules and use different schemas, so entitlement decisions, attestations and ownership records never line up cleanly. The result is not merely inconvenience. Control evidence becomes hard to trust, recertification becomes slow, and policy enforcement starts lagging behind operational reality. When the data foundation is fractured, even well-funded IAM platforms inherit ambiguity instead of resolving it.

Practical implication: treat identity data quality as a control dependency and map where authoritative attributes actually originate before automating decisions.

Why manual certification survives modern IAM tooling

Manual work persists because automation cannot compensate for incomplete or inconsistent identity records. If access reviews are exported to spreadsheets, provisioning is routed through email and application owners still have to be chased by contractors, the programme is running governance as a labor process rather than a control system. That is why more platform spend does not automatically reduce operational burden. The bottleneck is often not the review workflow itself, but the inability to trust the underlying identity data enough to let the workflow close the loop.

Practical implication: redesign certification and provisioning around verified identity data first, then automate only the steps that no longer require manual reconciliation.

How services dependency becomes a structural IAM risk

When deployment, integration and ongoing configuration depend on armies of consultants, the programme becomes expensive to change and difficult to mature. The vendor ecosystem then rewards complexity because services revenue offsets product friction, while enterprises absorb the operational drag. This creates lock-in at the governance layer: even when teams know a platform is underperforming, they hesitate to replace it because the implementation burden feels riskier than staying put. That is a programme design failure, not just a procurement problem.

Practical implication: measure IAM success by how much governance can be operated without external services dependency, not by license count or platform footprint alone.

NHI Mgmt Group analysis

Identity-data fragmentation is now the primary governance bottleneck in mature IAM programmes: the limiting factor is no longer whether enterprises own enough tools, but whether those tools can operate against a coherent identity record. When identity state is split across directories, HR systems, cloud platforms and SaaS apps, control decisions become reconciliation exercises. Practitioners should recognise fragmentation as the point where governance stops being deterministic and becomes approximate.

Manual certification at scale is a sign that identity governance has collapsed into labour substitution: organisations are paying people to compensate for data and process defects that should be enforced by the programme itself. That is why access reviews, onboarding and control validation keep surviving inside sophisticated stacks. The lesson for IAM and IGA leaders is that automation cannot be layered on top of bad records and expected to produce reliable assurance.

Professional-services dependence is a structural risk signal, not just a budgeting concern: when a programme requires continuous external expertise to remain operational, the governance model is too fragile to absorb change. This also explains why many enterprises become stuck with partially implemented PAM and IGA estates. The market now rewards integration rhetoric, but practitioners should measure whether identity governance can actually be run without permanent services scaffolding.

Identity blast radius grows when the authoritative record is fragmented: every disconnected source of truth expands the chance that access, ownership and certification decisions diverge. That divergence is what lets stale permissions, duplicate records and partial implementations persist. For practitioners, the operational conclusion is straightforward: reduce the number of places where identity truth can disagree.

What this signals

Identity data sprawl is becoming an architectural limit, not a housekeeping issue: IAM programmes that cannot establish one defensible source of truth will keep converting governance into reconciliation work. The operational signal is simple: if review, provisioning and attestation all depend on exports and manual matching, the programme is already spending control time on data cleanup instead of risk reduction.

Agentic systems will intensify the cost of weak identity foundations: as autonomous workflows and machine identities proliferate, identity state will change faster than human-led governance cycles can observe. That means the control point moves toward continuous discovery and issuance-time decisions, not slower periodic review alone.

Hydden’s core signal is that the next IAM maturity step is not more platform breadth but tighter identity-data governance: programmes need fewer places where identity truth can diverge, fewer manual exception paths and less dependence on external services to maintain basic operability. In practice, that means treating identity data as infrastructure rather than as admin overhead.

For practitioners

• Map the authoritative identity sources Inventory where identity attributes, entitlement records and ownership data actually originate across HRIS, directories, cloud platforms, SaaS and custom systems. Document which system is authoritative for each data element before attempting further automation.
• Remove spreadsheet-driven certification loops Identify every access review, data attestation and control-validation process still exported to Excel or .CSV. Replace the manual handoff points with governed workflows only after the underlying identity records are reconciled.
• Measure services dependency as a governance metric Track how much of day-to-day IAM operation still depends on consultants or system integrators to keep platforms usable. Treat high services reliance as evidence that the programme is not yet self-sustaining.
• Rationalise overlapping tools and disconnected implementations Review whether multiple products from the same vendor or acquired stack are duplicating functions without a shared data model. Consolidate where tool overlap is creating process drift, duplicate administration and budget leakage.

Key takeaways

• Fragmented identity data turns IAM, IGA and PAM into reconciliation exercises instead of enforceable control systems.
• Manual access reviews and provisioning survive when the underlying records are too inconsistent to trust, even in well-funded programmes.
• The limiting factor is now programme operability, so teams should reduce identity-data fragmentation and services dependency before adding more tooling.

Key terms

• Identity Data Fragmentation: Identity data fragmentation is the condition where authoritative identity information is split across many systems that do not agree with one another. It weakens governance because reviews, dashboards, and audit evidence can no longer be trusted as a single source of truth.
• Services Dependency: Services dependency is the condition where an identity control can only be deployed, tuned, or recovered with continuous outside assistance. It signals that the organisation owns software licences but not the operating capability. In practice, it weakens resilience because control sustainability depends on specialist availability rather than internal competence.
• Manual Certification: Manual certification is the practice of reviewing access by exporting data, chasing owners and recording decisions outside the system of control. It is a symptom of weak identity data quality because the process exists to compensate for records that are too inconsistent or incomplete to automate safely.
• Identity Source of Truth: An identity source of truth is the system that owns a particular attribute and is treated as the authoritative record for that field. In practice, different attributes may have different owners. Clear ownership reduces conflicts, supports auditability, and makes downstream access decisions easier to explain.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.