An identity is almost never described by a single source
Across the large information systems we work with, no programme has ever begun with a single repository that perfectly described every person. The programmes that succeed are not the ones that find that source; they are the ones that accept it does not exist.
A request that starts with an admission
A CIO invites us in one morning, folder open in front of him, and asks the question we hear at almost every first meeting. "We want to launch an IGA programme, but our data is not clean enough. We need to sort things out first." The organisation has tens of thousands of identities, several hundred applications, multiple Active Directory forests, an Entra ID tenant in the middle of consolidation, and three HR systems that have coexisted since a merger.
The sponsor's belief is clear. Until the data is perfect, the programme cannot start. We have been hearing that reasoning for fifteen years. It sounds sensible. It is also the first thing we set about undoing.
We never start an identity governance programme with a large-scale data cleanup. We start by understanding how the organisation has chosen to describe its identities. Which populations it distinguishes, which repositories it uses to record them, which implicit rules shape their lifecycle. This step is usually called nothing more glamorous than "workshops", yet this is where the success of the programme is decided.
What we find, every single time, is that the organisation already has everything it needs to govern itself. That knowledge is simply scattered across several teams, several systems, several generations of tooling. It has never been laid out in one place.
Enterprise identity is naturally distributed
In large French and European organisations, populations are not managed in a single repository. This is not an architecture defect. It is a consequence of the company's history, structure and obligations. HR drives employees because payroll and employment law require a dedicated authoritative source. Procurement, or a vendor management tool, usually drives contractors. Partners keep their own repositories, sometimes on their own premises. Temporary staff come from an agency. Technical accounts have no HR source at all. Service accounts are born inside projects and, more often than not, never die.
Some populations are deliberately kept separate to draw a clear line between internal staff and external contributors. That separation answers contractual, governance and audit constraints. We never step into legal analysis — that is not our craft — but we notice that this separation is a common and often deliberate reality.
Enterprise identity is therefore naturally distributed. Trying to consolidate it into a single "source of truth" amounts to asking the organisation to rewrite itself to fit a theoretical model. That is neither realistic nor desirable. An IGA programme must accept that the description of a person is made of several fragments, each held by a different system, each legitimate within its scope.
Four situations, the same mechanism
A handful of scenes taken from recent engagements, in slightly different forms. Each looks like a special case in isolation. Taken together, they describe a pattern.
- 01
One person, two official existences
An employee moves to a subsidiary as part of a reorganisation. The central HR system flags them as leaving; the subsidiary's HR system flags them as arriving. For a few weeks, this person exists twice, with two employee numbers, two managers, two joining dates. Neither system is wrong. Each is telling part of the contractual truth. The identity engine has to be able to represent this double existence without deleting one side to make things look tidy.
- 02
A transition that lasts
A team leader changes role. For several months, she keeps some of the entitlements from her previous position, to ensure the handover, close out a regulatory file, train her successor. On paper, she is no longer in the old role. In practice, she legitimately retains its responsibilities. Governance that bluntly enforces the change of assignment creates an operational incident. Governance that ignores it creates a compliance gap. Neither is acceptable.
- 03
A contractor known to several sources
A consultant works for two departments under two contracts, managed by two different buyers. He appears twice in the vendor management tool, twice in the entitlement records, with two mailboxes created a few weeks apart. It is the same person. No system knows it, because no system was designed to reconcile two commercial contracts with one human being.
- 04
A service account owned by no one
A business application has been using the same technical account for ten years. Its official owner left the company long ago. The account works. Nobody touches it. It does not appear in any HR repository, which is normal, but it does not appear in a non-human identity repository either, which is less so. It simply exists in the directory, as a matter of fact.
None of these situations is a data-entry mistake. Each one reflects normal operation. An IGA programme that refuses to acknowledge them ends up fighting its own client.
How Netwrix Identity Manager models this reality
We regularly use Netwrix Identity Manager, formerly Usercube, on this kind of environment. What we value in the platform is not first and foremost its provisioning engine — many tools can provision. It is its ability to represent an identity as an aggregation of fragments coming from several sources, without forcing the organisation to elect a dominant one.
- Identity Warehouse
- The Identity Warehouse does more than consolidate identities. It retains the origin of every attribute. At any moment we know that the employee number comes from the main HR system, the mail address from Active Directory, the functional manager from a project repository, the contract end date from the vendor tool. That traceability is what makes it possible to model a distributed identity.
- Correlation engine
- The correlation engine reconciles several representations of the same person — an employee recorded twice during a transfer, a contractor known to two departments, a partner with two contracts. We configure those rules with the business, not against it. A correlation that HR or Procurement does not understand is a correlation that will be undone in production sooner or later.
- Policy Engine
- The Policy Engine encodes the rules the organisation has finally agreed to write down. It does not invent governance. It makes it executable. It is also the component that handles overlap periods — an identity inheriting two assignments temporarily, a manager who remains accountable during a transition, an entitlement kept for the duration of a handover.
- Business Roles
- Business Roles describe the organisation as it thinks about itself: by department, by function, by job family. They are not derived from technical groups; they are stated by the business and then confronted with the data. That confrontation is what surfaces the gaps between the official organisation and the real one.
- Technical Roles
- Technical Roles translate Business Roles into application language. That translation remains a human decision, never an automatic mapping. We refuse to create a Technical Role that an application owner has not explicitly validated.
- Recertification campaigns
- Recertification campaigns are not just a compliance instrument. They are a way to raise data quality gradually, one campaign at a time. Each iteration reduces the discrepancies between repositories and sharpens the definition of the roles. Data quality becomes an outcome of the IAM programme, not its prerequisite.
- Dashboards
- Dashboards make discrepancies visible — between repositories, and between repositories and the field. They do not try to hide inconsistencies; they make them readable. That is what allows a governance committee to decide where to focus effort first.
The question we actually ask
We almost never ask "where is your source of truth". We ask "which sources each describe a part of the reality, and which rules allow them to be recomposed". That formulation changes the nature of every workshop that follows.
It relieves the teams of the feeling that everything has to be fixed before anything can start. It recognises that HR is right about what it manages, that Procurement is right about what it manages, that the technical directory is right about what it manages, and that the difficulty is not to arbitrate between them but to write the rules that connect them.
That work of writing the rules — sometimes a sentence, sometimes a table, sometimes a diagram — becomes the real deliverable of the first workshops. Without it, no platform, however powerful, produces sustainable governance. With it, a platform like Netwrix Identity Manager finds its exact place: an engine that executes a shared model, not a tool that replaces it.
Modelling imperfect sources, not chasing a perfect one
The success of an IAM programme does not depend on the existence of a perfect source. It depends on the organisation's ability to understand the rules that connect several imperfect ones. In fifteen years we have never met a company that had a single repository accurately describing each of its identities. We have, on the other hand, met many organisations that eventually accepted that this source did not exist — and whose programme was then finally able to begin.
This is precisely why we use Netwrix Identity Manager as a modelling engine for the organisation before we use it as an automation engine. The platform first serves to represent how the company thinks about itself, contracts with others and assigns responsibility. Automation comes afterwards, and it comes faster than expected once the modelling work has been done seriously.