Field notes — Netwrix Identity Manager

An IGA programme does notstart with a connector

The point is not to provision accounts. It is to decide which access is legitimate, then keep that decision true over time, while people, organisations and applications keep changing.

Netwrix Identity Manager — formerly Usercube — industrialises the governance of identities, roles and entitlements. We use it to turn real IAM processes into an operable system: HR sources, lifecycles, roles, provisioning, reconciliation, certifications, audit evidence, migration and run.

A technical and methodological page. Not a product sheet: the capabilities described are the ones the vendor documents; the method is ours.

IGA does not start with the tool

Process before tooling. Identity before account. Data quality as the foundation. Standard before custom. Controlled automation, progressive architecture, systematic documentation, embedded training, proactive run. These principles drive the configuration, not the other way around.

A bad process, automated, is still a bad process. It just runs faster.

What we establish before configuring anything

Before the first rule, we work through a set of questions whose answers govern everything else. When they are missing, configuration only relocates the problem.

  • Which populations actually exist: employees, contractors, interns, temporary staff, service accounts, non-human identities?
  • Which sources are authoritative for which data, and what happens when they disagree?
  • Which events trigger a lifecycle, and who emits them?
  • Who owns each application, and who approves its entitlements?
  • Which rights are structural, which are business-driven, which are exceptions?
  • Which systems can be written to automatically, and which must stay read-only?
  • Which access must be reviewed, how often, and by whom?
  • What evidence must the organisation be able to produce?
  • Which discrepancies are acceptable, and which are not?

Scope is prioritised

Applications do not join the platform at the same time. We sequence by risk, request volume and the availability of a real business owner.

Data is qualified before it is governed

An incomplete HR repository produces wrong identities, therefore wrong entitlements. We measure data quality before making it the source of automated provisioning.

Standard first

Every customisation is paid for twice: at build time, then at every upgrade. We only develop when standard configuration cannot cover the need.

The objects of an IGA system

What Netwrix Identity Manager lets you structure

These are not features to tick off, they are the objects the programme has to define. The platform industrialises them; it does not invent them for you.

  1. 01

    Identities

    The platform consolidates information from several sources into an identity repository. The vendor documents coverage of human and non-human identities: employees, contractors, service accounts and other populations depending on context.

    • Employees, contractors, temporary populations
    • Service accounts and non-human identities
    • Duplicate reconciliation across sources
    • Structuring attributes: organisation, job, site, contract

    An identity is not an account. One person can hold several accounts, report to several organisations, combine responsibilities, change job or go through a temporary situation. The identity model must reflect business reality before it drives access.

  2. 02

    The lifecycle

    Joining, moving, changing organisation or position, suspension, leaving, returning, intermediate HR corrections. The goal is to turn an authoritative event into consistent decisions.

    • Identity, accounts, roles, groups, entitlements
    • Notifications to the right people
    • Residual manual actions, owned and traced
    • Rule-driven workflows and provisioning

    Lifecycle design is functional work before it is technical work. Joining is never the hard part: movers are, because the previous scope must disappear exactly when the new one appears.

  3. 03

    Roles and entitlements

    Business roles, technical roles, composition where relevant, direct rights and exceptions. The vendor documents a role model, RBAC, assisted role mining, excessive access and SoD conflict detection.

    • Business roles derived from the real organisation
    • Technical roles per application
    • Exceptions isolated and time-bound
    • Gap analysis and progressive optimisation

    The goal is not to create five thousand roles to “do RBAC”. A good model is understandable, reflects the business, stays maintainable, reduces exceptions and can evolve. Role mining helps you see; it does not decide for the owners.

  4. 04

    Access requests

    Part of the access must be automatic because it follows from the job. The rest must be requestable, justifiable and revocable.

    • Automatic assignment through roles
    • Manual request where it is justified
    • Approval routes owned by application owners
    • Temporary rights and exceptions with an expiry date

    The point is to stop every access from becoming a ticket or an email. Predictable access should never require a human decision.

  5. 05

    Provisioning

    Writing to target systems: automatic, manual or hybrid. The vendor documents the ability to review provisioning orders before they execute.

    • Provisioning orders reviewed before execution where needed
    • Error recovery and non-destructive replay
    • End-to-end traceability
    • Manual actions routed to ITSM when writing is not possible

    Not everything that can be automated should be automated immediately. In sensitive contexts we start read-only, simulate, get validation, and only then enable writes.

The capabilities listed reflect what the vendor documents for Netwrix Identity Manager. Their exact availability depends on the version and the chosen architecture: we verify it during scoping rather than promising it by default.

Simulate before writing: a deployment method, not a precaution

On sensitive scopes we do not grant a new rule the right to act straight away. We first ask it to show what it intends to do. Depending on context this takes the form of simulation, a blocked mode, a duplicated job without the write step, or a technical account with no modification rights.

  1. 1

    Connect source and target

  2. 2

    Read what exists, change nothing

  3. 3

    Compute the expected decisions

  4. 4

    Simulate the changes and count the operations

  5. 5

    Check impacts object by object

  6. 6

    Have the rules validated by the owners

  7. 7

    Enable writes, scope by scope

  • Limit regressions on production systems
  • Catch mapping errors before they become incidents
  • Validate the role model against real data
  • Reassure application teams, who keep control of their scope
  • Measure volumes before any real change
An IGA platform does not earn the trust of the IT estate by writing everywhere on day one.

Reconciling theory with reality

An IGA that only computes what “should” exist governs nothing. It must also read back what the systems actually contain, then compare. The vendor documents detection of non-conforming assignments, unauthorized accounts, orphaned or unused accounts, along with role and property reconciliation.

What the platform computes

  • Identities from authoritative sources
  • Roles assigned by rules
  • Expected entitlements per application
  • Accounts that should exist

What the systems contain

  • Accounts actually present in the directory
  • Effective groups and entitlements
  • Rights granted directly in the target
  • Accounts with no recent usage

The gaps to handle

  • Non-conforming assignments
  • Unauthorized accounts
  • Orphaned or dormant accounts
  • Provisioning that never completed
  • Diverging attributes
Governing means comparing the rule with reality — then deciding what to do with the gap.

Certifying access without turning managers into IAM auditors

Netwrix Identity Manager can schedule certification campaigns on targeted scopes, have entitlements reviewed, remove inappropriate access and produce the associated reporting. The hard part is not launching a campaign: it is getting a usable outcome from it.

A badly designed campaign produces blind approvals. The reviewer approves everything, the organisation collects formal evidence with no value, and the risk stays exactly where it was.

What makes a campaign useless

  • Too many lines presented at once
  • Technical labels nobody can read
  • Too many false positives, so no attention left
  • The wrong reviewer
  • No consequence given to the decisions

What we work on

  • Identify the right reviewer for each entitlement
  • Translate entitlements into business language
  • Limit and sequence the scope
  • Add context: since when, why, who else
  • Actually execute the removals that were decided
  • Measure results and improve the next campaign
A useful certification does not ask “approve 850 entitlements?”. It helps the owner understand what they are approving.

Separation of duties and sensitive combinations

The vendor documents detection of separation-of-duties conflicts and excessive access. The subject is not regulatory in itself: it consists of identifying which combinations of rights your organisation considers incompatible, then making them visible and governable.

We do not promise generic compliance. We help write the rules, translate them into the platform and own the exceptions that remain.

  • Define incompatible combinations with the business areas involved
  • Translate the rules into the platform
  • Govern exceptions: who approves, and for how long
  • Recurring controls rather than a one-off check
  • Traceability that holds up in an audit

An SoD rule without a business owner does not survive its first exception.

Connectors: where the programme meets the real IT estate

Our environments span very heterogeneous systems. Some come with a standard integration; others are handled through APIs, scripts, generic processing, specific development, or stay deliberately manual through ITSM.

  • HRIS and HR sources
  • Active Directory
  • Microsoft Entra ID
  • LDAP
  • Exchange
  • SharePoint
  • EasyVista / ITSM
  • SAP
  • WebMethods
  • REST APIs
  • SCIM
  • Databases
  • Internal applications
  • SaaS
  • Legacy systems

Standard integration

The target is covered by an integration the platform provides. The work is about mappings, filters and write conditions.

Configurable or API-based integration

The target exposes an API, SCIM, a database or files. We build the exchange contract, the allowed operations and error handling.

Specific or manual handling

Some applications cannot be written to from the outside. The decision stays governed by the platform; execution goes through an order tracked in ITSM.

  • Understand the operations the target really supports
  • Define mappings attribute by attribute
  • Decide what is read and what is written
  • Handle errors and partial cases
  • Secure technical accounts and their privileges
  • Document the connector for the people who will operate it
  • Monitor it and plan for maintenance over time
A connector count is not an integration strategy.

SaaS or on-premises

Netwrix Identity Manager exists in SaaS and on-premises, and the vendor currently documents the ability to move between the two without a full re-implementation. We work with both. The choice follows the context, not a preference.

SaaS can answer

  • Simpler operations
  • A faster start
  • Less infrastructure to maintain
  • A standardisation objective

On-premises can be required by

  • Hosting or sovereignty constraints
  • Network architecture and specific interconnections
  • Internal security policies
  • A need for full operational control
The deployment model should be a consequence of the context, not a religion.

Build. Migrate. Take over.

We do more than greenfield deployments. Three very different situations come up, and they call for neither the same team nor the same method.

Build

Build a new identity governance foundation.

  • Scoping of populations and sources
  • Identity model and role model
  • Lifecycle and workflows
  • First connectors, then progressive extension

Migrate

Migrate an existing environment, notably from SaaS to on-premises.

  • Flow and dependency analysis
  • Preservation of the processes in place
  • Qualification of customisations, connector review
  • Controlled cutover, tests, documentation, service continuity

Take over

Take over a platform already in production, sometimes unstable or under-used.

  • Understand and document what exists
  • Analyse recurring incidents
  • Deal with fragile connectors
  • Restore governance, rebuild a backlog, stabilise then improve

Building, migrating, taking over: three crafts, one requirement — continuity.

How we run the programme

The same frame serves build, migration and take-over. Only the entry point changes.

  1. 1

    Assess

    Understand the ground before proposing a target.

    • Populations
    • Sources
    • Applications
    • Processes
    • Pain points
    • Risks
    • Architecture
  2. 2

    Design

    Decide the model, and only then the configuration.

    • Identity model
    • Lifecycle
    • Role model
    • Workflows
    • Mappings
    • Architecture
    • Governance
  3. 3

    Build

    Build with a bias for standard.

    • Configuration
    • Connectors
    • Rules
    • Workflows
    • Reporting
  4. 4

    Simulate

    Measure impact before writing.

    • Synchronisation
    • Computation
    • Impact analysis
    • Blocked mode where relevant
  5. 5

    Validate

    Prove the system does what was decided.

    • Unit tests
    • Integration
    • UAT
    • Data quality
    • Regression
    • Acceptance criteria
  6. 6

    Deploy

    Cut over without losing the service.

    • Cutover
    • Production
    • Hypercare
    • Documentation
  7. 7

    Operate

    Hold the platform over time.

    • Support
    • Incidents
    • Maintenance
    • Upgrades
    • Connectors
    • Campaigns
  8. 8

    Improve

    Extend coverage and quality.

    • New applications
    • New populations
    • Role mining
    • Data quality
    • Automation
    • Optimisation

The phases overlap: one scope can be in run while another is still being simulated.

What the client receives

An IGA programme is not delivered in man-days. It is delivered as artefacts that must stay understandable once the project team is gone.

Design

  • Architecture document
  • Identity model
  • Role model
  • Business rules
  • Mapping matrices
  • Connector specifications
  • Workflow descriptions

Build and validation

  • Configurations
  • Scripts and packages where needed
  • Test strategy
  • UAT book
  • Test results
  • Data quality report

Operations

  • Installation documentation
  • Administration documentation
  • Operations documentation
  • Support procedures
  • Release procedures
  • Training kit
  • Backlog and run reporting
An operable platform must stay understandable once the project is over.

The team around the programme

An IGA programme does not rest on a single “product consultant”. It rests on complementary roles, and on coordination that reaches well beyond the IAM team.

The roles involved

  • Project manager
  • IAM architect
  • Netwrix Identity Manager expert
  • Functional consultant
  • Integrator
  • Connector specialist
  • L2 / L3 support
  • Trainer

What has to be coordinated

  • Business
  • HR
  • Security
  • Architecture
  • Infrastructure
  • Applications
  • Support
  • Compliance

Most delays we see do not come from the platform, but from business decisions with no identified owner.

The client must not stay dependent

Skills transfer is part of the programme, not an optional phase at the end. We train as we build, on the client's real configuration rather than on a demo environment.

The goal is for the internal team to be autonomous on normal operations, while we remain available for complex changes and for the run if the organisation wants it.

  • Platform administrator training
  • Onboarding for support teams
  • Coaching for application owners on approvals and campaigns
  • Design workshops rather than presentations
  • Documentation written during the project, not after
Our goal is not for the client to call us for every role change.

The programme does not stop at go-live

An IAM system degrades if it does not evolve with the IT estate, the business, HR, roles, applications and organisations. Run is therefore not about “keeping the server green”: it contributes to keeping governance accurate.

We operate Netwrix Identity Manager platforms in SaaS and on-premises, with service commitments and a continuous improvement path.

  • Functional and technical support, L2 / L3
  • Incidents and corrective maintenance
  • Changes and upgrades
  • Connector maintenance
  • Monitoring of jobs and discrepancies
  • Execution and improvement of certification campaigns
  • Backlog, reporting, service reviews
A run that never produces change is a run that lets governance go stale.

Three real contexts, anonymised

Sectors and orders of magnitude only. These three situations cover build, migration and take-over.

Build · SaaS

Financial services / banking

≈ 700 identities

  • Architecture and three SaaS environments
  • HR data, Active Directory, Entra ID
  • SharePoint, Exchange, EasyVista
  • Workflows and role model optimisation
  • Preparation of the SAP integration
  • Team training

A SaaS foundation built with a role model that holds and real integrations.

Migrate · SaaS → on-premises

Local public sector

≈ 2,000 identities

  • HR and Active Directory synchronisation
  • Joiner / Mover / Leaver
  • Exchange, WebMethods
  • Connector redesign
  • Mailbox automation
  • Maintenance, upgrades, support
  • Around 40 changes delivered over time

Migration to on-premises with no service interruption, then committed long-term maintenance.

Take over · stabilisation

Software vendor / HR services

≈ 15,000 identities

  • Analysis and stabilisation of an existing platform
  • Active Directory, Entra ID, HR interfaces, ITSM
  • Workflows and entitlements
  • HR changes, incidents, support, maintenance
  • Role mining preparation
  • Onboarding of new applications

Take-over of a live platform, stabilisation then continuous improvement.

We name no client on this page. Published references are shared with their agreement.

External proof, secondary to delivery

Ariovis received the Netwrix Partnership Excellence Award 2026. It says something about the relationship with the vendor; it does not replace what the teams deliver on production platforms.

Netwrix Partnership Excellence Award 2026
Ariovis team receiving the Netwrix Partnership Excellence Award 2026

You may not need Identity Manager

We remain able to advise vendor-agnostically. A full IGA platform is not the right first step in every context.

The signals

  • Joiner, mover and leaver processes are not defined
  • HR sources are inconsistent or incomplete
  • No application has an identified owner
  • No role model exists, even on paper
  • Scope has not been prioritised
  • The organisation lacks the resources to operate the platform afterwards

Better first steps

  • A scoping exercise
  • An audit
  • A map of applications and sources
  • A roadmap
  • A pilot foundation on a narrow scope

In those situations, installing a platform solves nothing: it just makes unresolved disorder visible faster.

Ariovis mini product

Not ready for a full IGA programme? Start by proving the value.

The IAM ROI mini product is an Ariovis offering, independent of any vendor. It quantifies the return on investment of an IAM programme across three scenarios and returns the study as a PDF.

  • Start on a targeted scope
  • Make the expected benefits objective
  • Structure the priorities
  • Build a roadmap, then decide whether to industrialise

It is neither a lightweight version of Netwrix Identity Manager, nor a Netwrix product, nor a replacement for an IGA.

Frequently asked questions

What is Netwrix Identity Manager?

It is an Identity Governance & Administration (IGA) platform, formerly known as Usercube. It consolidates an identity repository, automates lifecycles, manages a role model, provisions target systems, reconciles the real state, detects excessive access and runs certification campaigns.

What is the difference between IAM and IGA?

IAM is the whole domain: identities, authentication, access, privileges, authorization. IGA is its governance and administration part: who should have what, why, for how long, and how to prove it. An IGA replaces neither access management, nor PAM, nor runtime authorization.

Does Netwrix Identity Manager run in SaaS and on-premises?

Yes, the vendor documents both architectures. The choice depends on hosting and sovereignty constraints, interconnections and operating capacity. We work with both models.

Can you migrate from SaaS to on-premises?

The vendor currently states that you can move between models without a full re-implementation. In practice a migration is still a project: flow analysis, connector and customisation review, testing, cutover and service continuity. We have run that type of migration.

Which systems can be connected?

Our environments span HRIS, Active Directory, Entra ID, LDAP, Exchange, SharePoint, ITSM tools such as EasyVista, SAP, WebMethods, REST APIs, SCIM, databases, internal applications, SaaS and legacy systems. Not all of them have a native integration: some targets are handled through APIs, scripts, generic processing, or stay deliberately manual through ITSM.

How does Joiner / Mover / Leaver work?

An authoritative event, usually from the HR system, triggers the computation of decisions: identity creation or update, accounts, roles, groups, entitlements, notifications and any residual manual actions. The hardest part is the mover case, where old rights must disappear exactly when new ones appear.

What is a role model in an IGA?

It is the structured translation of the organisation into entitlements: business roles derived from jobs and entities, technical roles per application, and owned exceptions. A good model is understandable and maintainable; the number of roles is not a quality indicator.

What is the difference between provisioning and reconciliation?

Provisioning applies a decision in a target system. Reconciliation reads back what that system actually contains and compares it with the expected state. Provisioning tells you what was requested; reconciliation tells you what exists.

What are certification campaigns for?

To have access periodically re-examined by the accountable people, remove what is no longer justified and produce evidence. Their value depends entirely on the quality of the information shown to the reviewer.

Does Netwrix Identity Manager handle non-human identities?

The vendor documents coverage of human and non-human identities, including service accounts. The exact scope depends on the identity model defined during the project and on the systems actually connected.

Can Ariovis take over an existing platform?

Yes. Part of our activity is taking over platforms already in production, sometimes poorly documented or unstable: analysis of the existing setup, documentation catch-up, fragile connectors, backlog rebuild, stabilisation then improvement.

Does Ariovis run the platform after the project?

Yes, if the organisation wants it: L2/L3 support, incidents, maintenance, upgrades, connectors, monitoring, campaigns, backlog and service reviews. We also train internal teams so they stay autonomous on day-to-day operations.

Do you have to start with Netwrix Identity Manager?

No. If processes, sources and application ownership are not established, an IGA platform will only accelerate the disorder. A scoping exercise, a mapping, or the IAM ROI mini product is often a better first step.

Let's talk about your platform, not ours

New foundation, migration or take-over of an existing environment: the first useful conversation is about your processes, your sources and your pain points.