How to Prepare an Identity Management Project (2026 Update)

Are you facing a decision on how to prepare an Identity Management (IdM) project and need advice? This article describes how to prepare an Identity Management project. The motivation behind it is clarity and simplicity, not a detailed analysis of one particular deployment. That’s what our other articles are for. The article also includes a practical example of the data you should prepare on the side of the connected systems.

This article was substantially updated in 2026. The biggest changes since the original version: AI-assisted implementation, security requirements driven by NIS2, the IdM + PAM combination, multi-company deployments, and hybrid Active Directory + Entra ID environments.

What are the project’s objectives?

Identify the goals of the project, specifically, clearly and measurably. What is the pain? What do you want the IdM project to solve? Well-defined goals are critical to the success of the project. Always focus on them with the client when creating the brief.

Examples of good goals:

• speed of setting up accounts for new employees (onboarding in hours, not days),
• delegation of access decisions to data and application owners,
• security — eliminating orphaned and dormant accounts,
• user self-service — password resets, access requests,
• compliance — being able to prove to an auditor who has access to what and why, typically driven by NIS2 or the national cybersecurity act.

Different organizations, different goals. Avoid the expectation that “IdM is a magic tool that will solve everything for us.” IdM is a powerful tool, but it needs to be aimed at concrete problems.

How AI changes an IdM project

The biggest shift since we first published this article is AI. Let’s get one thing straight first: AI must not decide who gets access. Assigning accounts and permissions has to remain governed by people and by deterministic, auditable rules — a manager or a role guarantor approves, a policy assigns, and every decision leaves a trail. No regulator, and frankly no security team, will accept “the model decided” as an answer.

Where AI genuinely shines is getting the system into production quickly. The prerequisite is quality product documentation, ideally available online. From good documentation you can build a quality Skill — a knowledge package that an AI assistant loads and works with. From that point on, AI serves you as a consultant:

• it helps connect systems. Proposes attribute mappings and writes transformation scripts,
• it drafts user guides and admin handbooks tailored to your configuration,
• it prepares test scenarios and helps debug synchronizations,
• it answers “how do I…” questions that would otherwise be a ticket to the vendor.

The practical consequence: the project gets cheaper, because you are far less dependent on the implementer. Your own administrators can handle a much larger share of the configuration, and the vendor’s consultants focus on the genuinely hard parts.

What to prepare in project management?

Above all, be clear about the assignment. It sounds obvious, but we very often encounter vague briefs.

Avoid a fixed brief for large projects, history shows it leads to failure. We have yet to meet an IdM project without change management. Identity Management projects are integration projects, and it is extremely difficult to impossible to analyze and design everything in advance. The bigger the project and the longer the implementation, the more changes in systems, in the organization and in the project itself will arise. Make room for change. Even in public-sector tenders, it can be done.

The agile way of developing and implementing software is the way to go. Organizations today change rapidly, and the project needs space to react. Agile project management is significantly preferable.

Every project must define:

1. Scope — at least the first product (a prototype or MVP). The brief must be based on the problems the project is supposed to solve. Which systems should Identity Management manage? List them in the brief as indicative, so they can be changed without amending the contract. We have seen many cases where a company tendered the management of specific systems and then needed to replace one of them mid-project. Give the project team the contractual power to adjust the brief.
2. Budget — how much in total do you want to invest? Set the budget as a ceiling to be drawn from in an agile way.

Next, set up:

1. the project committee — who will work on the project. Yes, customer representatives are needed too: a project manager, an IdM administrator or product owner, and optionally the administrators of connected systems,
2. regular project meetings — weekly or biweekly,
3. a risk log,
4. a schedule.

Map your systems, then pick the first two or three

In the past, the standard advice was simply “choose 2–3 systems to connect first.” That still holds for the first phase, but today we recommend starting one step earlier: map all the systems in your organization. Build an inventory and classify it:

• which systems hold personal accounts (tied to a specific person) and which hold technical and service accounts (belonging to applications, scripts and integrations),
• which of them contain privileged access — admin accounts, infrastructure, databases,
• who owns each system and its data.

Then make sure your project plan covers all types of systems over its phases — not just the visible personal-account systems, while forgotten service accounts with high privileges live on unmanaged. In the first phase, connect 2–3 essential systems. The rest will gradually crystallize into follow-up phases.

Don’t be pushed into connecting as many systems as possible at once in a single project. A large assignment dramatically increases the risk of failure. Connect and automate what really makes sense. Expect to gradually teach yourself — and your organization — what IdM is and how to use it best. This is what allows you to stay agile; a fixed assignment complicates the situation, above all for you.

Define which systems you want to manage (integrate) directly and which indirectly (we call it virtually). Direct integration costs effort, so it makes sense where accounts and permissions change frequently. If you create an account in a system twice a year, an indirect connection through a virtual system is enough — it can be set up within a minute and serves as a record-keeping tool (who has which account on the system) and for assigning responsible admins.

Don’t over-invest in studying connectors upfront

One thing you can worry about much less than a few years ago: connectors. IGA products today are mature and ship with connectors for practically every interface you will meet — REST and SOAP web services, JDBC databases, LDAP, PowerShell, Microsoft Graph API and more. In most cases an existing connector can be used as-is or adapted to the specific system.

And AI helps here too: if the vendor builds on a standardized connector framework such as ConnID, AI can adapt an existing REST connector to your system’s API — or write a new one — in a fraction of the time custom connector development used to take.

What data to manage on the systems?

Do you just want to create accounts, or also manage permissions in detail? Define what data you want to manage in each system. This is purely the customer’s job — the vendor can ask good questions, but they don’t know your data.

What is the source of employee data? Usually HR. Beware: there may be different sources for different identity populations. For non-employees, the source is typically a contractor register — or they are created directly in the IdStory web interface, for example via self-registration with approval.

Security capabilities: the new selection criterion

Here is a shift in emphasis we consider essential. More important today than the length of a vendor’s connector list — or the perfect upfront preparation of synchronized attributes — is whether the system offers functions matching modern security requirements, above all those stemming from NIS2 and the national legislation implementing it.

When selecting an IdM/IGA system, check that it can handle:

• Management of technical and service accounts — the accounts that belong to applications, scripts and integrations, not people. These are the accounts most often forgotten, typically highly privileged, with passwords that never change. Each must have a responsible guarantor, a validity period and an audit trail.
• Privileged accounts — an inventory of who holds elevated access, with the ability to hand privileged accounts over to a PAM system for vaulting and session control.
• Periodic recertification of access — campaigns in which managers and role guarantors regularly confirm or reject assigned permissions, with automatic removal of what is not confirmed and a complete record for the auditor.
• Audit reporting — ready-made answers to “who has access to what,” “what changed and when,” exportable for auditors without a developer writing SQL.
• Data retention and GDPR — automatic anonymization or archiving of leavers’ personal data according to your retention policy, while preserving the audit trail.

 

If the system you are selecting cannot do these things, you will hit a wall within a few years — regulation is only moving in one direction. Put simply: the system must support these capabilities to guarantee the long-term sustainability of your investment. (IdStory IdM covers all of the above with dedicated modules — technical account management, recertification, reports, PAM integration and GDPR — so this list doubles as our own checklist.)

IdM and PAM: which comes first?

The most common IGA combination deployed today is IdM + PAM (Privileged Access Management). The two solve different layers of the same problem: IdM governs the processes around identities and accounts. Who should have which account and role, approvals, lifecycle, evidence. PAM controls privileged accounts at a low level like password vaulting and rotation, session brokering and recording.

Pay attention to the compatibility of your IdM with your PAM (or the one you plan to buy). And if you are planning to deploy PAM before IdM, consider reversing the order. IdM puts order into accounts first (every account gets an owner, a purpose and a lifecycle) and thereby prepares the ground for PAM, which then takes over low-level control of the privileged ones. Deploying PAM onto an unmapped, unowned account landscape means doing the inventory work twice. In IdStory IdM, this handover is direct: technical accounts flagged as privileged are passed to the PAM system (e.g. CyberArk) for vaulted, audited access.

Multi-company organizations: plan for multitenancy

If your organization is a group composed of several companies, plan the onboarding of companies gradually, company by company, not all at once.

The selected IdM solution must support a multitenant approach: it must separate data and administrative access between organizations, while at the same time handling the situation where one person holds contracts in several companies of the group. In practice this means the IdM must manage contracts from different companies rigorously and assign permissions strictly per contract. A role obtained through a contract in company A must not silently leak to the person’s contract in company B.

Secure a pairing identifier in advance. An attribute that lets you merge multiple records of the same person from different HR sources into a single identity in IdM. Ideally this is a personal number that is unique across the whole group. If none exists (or it is not unique), an anonymized derivative of the national birth number works well, for example its hash. The IdM then never stores the sensitive value itself, yet can still reliably match one person across several companies.

Hybrid Active Directory + Entra ID

Most organizations today run a hybrid Microsoft environment, so plan the integration in phases:

1. Phase one: manage the on-premises Active Directory and let Entra ID Connect synchronize identities to the cloud. Your IdM should support this setup out of the box — it manages AD, and the cloud follows.
2. Later phases: connect Entra ID directly via the Microsoft Graph API. This is what enables management of cloud-only objects that never exist in the on-prem AD — cloud-only groups, Guest accounts, license assignments.

 

One boundary worth keeping clear: single sign-on and multi-factor authentication are the domain of access management (Entra ID, CAS and similar). IdM/IGA governs who has which account and role and feeds the access management layer with clean, current data. The two complement each other; neither replaces the other.

Example of connecting systems to IdM

The following is probably the simplest case: connecting an HR system and Microsoft Active Directory to IdM. If you prepare the data in this way, the systems can be connected to IdM without any further modification on the IdM side.

The HR system as the authoritative source of employees

Let’s take an HR system that holds its data in a SQL database or can export it to CSV files. Column names can be arbitrary. The structure of the database view or CSV corresponds to the Identity, Contract and Organization objects described below.

1/ Persons

The person table serves as the primary source of information for establishing a user’s identity in IdStory.

attribute	unique	required	note
id	*	*	often a personal number; ideally a time-invariant identifier that is never “recycled” after the relationship with the person ends
login	*		minimum length 2 characters; if not available, the identity manager generates the login
first name
surname
title before name			academic degrees
title after name
email			by default used to deliver the initial password
mobile phone			if the identity manager is connected to an SMS gateway, the password can be sent by SMS
timestamp			timestamp of the last change, ideally a Unix timestamp

2/ Contracts (employment relations)

A contract can be a full-time or part-time employment, a temporary or casual work agreement (in some countries known as a zero-hours contract), an external supplier’s contract, an internship in a department, enrollment at a faculty, participation in an unpaid project, and so on. The most important attribute of a contract is its owner; if automatic onboarding and offboarding processes are to run, the validity dates (from/to) matter just as much.

An identity can normally have multiple contracts recorded in the identity manager, and contracts can be synchronized from an external source just like identities. If your organization doesn’t work with contracts, this synchronization isn’t necessary — the identity manager creates a default contract by itself and links all functionality to it.

attribute	unique	required	note
id	*	*	processing key
job title			e.g. “Head Nurse”; optional
owner		*	reference to the person’s id
valid from			SQL timestamp — start of contract validity
valid to			SQL timestamp — end of contract validity
excluded from headcount			boolean; the person is temporarily excluded from active employment (e.g. parental leave)
main contract			boolean flag of the person’s main contract; if not provided, automatic calculation is used
supervisor			reference to a person’s id; can be used without an organizational structure
organizational unit			reference to an id from the organizational structure
timestamp			timestamp of the last change, ideally a Unix timestamp

3/ Organizational structure

If the organizational structure is to be synchronized into IdM, the following data structure must be followed. Contracts can then be assigned to the synchronized structure. IdM supports multiple organizational structures — multiple synchronizations are possible. When an element is deleted from the data source, the corresponding part of the structure in the identity manager is deleted only if it is empty.

attribute	unique	required	note
id	*	*	immutable processing key
name	*	*	unique name of the organizational unit or position
parent			reference to the id of the parent element of the structure

Examples of managed systems

• Microsoft Active Directory — one domain, provisioning of identities and their group memberships,
• Entra ID — in a hybrid setup via AD + Entra ID Connect, or directly via the Graph API (including cloud-only groups and Guest accounts),
• LDAPv3 — provisioning of identities and their roles,
• databases via JDBC — e.g. one table of users.

Microsoft Active Directory (MS AD)

An example assignment:

• installation and configuration of IdM,
• connecting the MS AD domain to manage user accounts and their group memberships,
• loading groups from MS AD and automatically creating the corresponding roles in the identity manager,
• managing users’ home directories,
• managing email accounts on MS Exchange,
• managing the lifecycle of certificates issued to external users via a certificate authority.

 

An example of managed data — the connector can manage anything the directory exposes:

attribute	required	note
DN	*	distinguished name
sAMAccountName		user login
cn		common name — often used as the RDN
displayName		display name, shown in applications that use AD
description
password
sn		surname
givenName		first name
mail		user’s email
userPrincipalName		login + domain

Processes

Identity Management is a process tool. Data is read from the source system, transformed, approved and written to the target systems. We recommend using the standard processes shipped with the selected identity manager — heavy customization makes every future upgrade more expensive.

The main types of processes:

• Identity lifecycle management (joiner–mover–leaver):
  • synchronization of persons and their contracts,
  • the standard password handover process — the initial password is emailed (or sent by SMS) to the user when the AD/LDAP/DB account is created,
  • standard lifecycle processes: onboarding (joiner), change of position or organizational assignment (mover), contract termination (leaver), exclusion from headcount,
  • automatic assignment and removal of permissions according to the person’s place in the organizational structure.
• Synchronization of the organizational structure and other objects — e.g. certificates or attributes such as card numbers.
• The approval process for access requests — changes to assigned roles. Configure the standard approval flow: completion of the request by the helpdesk, approval by the user’s manager and/or the role guarantor, optionally a final security approval.
• Manual processes — performed by users and administrators in the IdM GUI: requesting an access change, approving it, password resets, bulk actions, working with roles, starting synchronizations, and so on.

Questions to answer about processes

1. What processes do you want to automate? Which systems do you want to synchronize data from, and what data?
2. What is the lifecycle of the accounts of employees, contractors, customers and technical accounts? Write it down at least in outline — creation, changes, termination.
3. What is the lifecycle of the organizational structure and its units? Beware — this tends to be a hidden chore. We recommend managing the organizational structure in HR; IdM synchronizes it and propagates changes to the connected systems.
4. What does the lifecycle of roles, AD groups and certificates look like — creation, changes, termination? This too can grow into a task worthy of a separate project.
5. How do you need approvals to work? Keep the approval process simple — three steps at most. If approval is complex, dissatisfaction with the length of the approval round grows over time. Move approvals to managers and data owners, away from administrators.

Permissions in the identity manager

Who will work with the IdM, and how? These are the usual permission roles:

• Super administrator — at least one user on the customer’s side with the highest permissions in the identity manager,
• Helpdesk — changes passwords, accesses audit information and sent notifications,
• Regular user — changes their own password, reads their profile, submits access requests,
• Manager — everything a regular user can do, plus visibility of their subordinates and the ability to request access changes for them,
• Role guarantor / data owner — approves access to the system or role they are responsible for,
• and others — e.g. a read-only auditor role.

Which accounts to manage?

IdM can manage all accounts, with different processes for each account type. Which accounts make sense to manage? Integration and automation cost some investment even with IdM — it probably doesn’t pay off to automate a process applied twice a year to a handful of accounts; an administrator can do that more cheaply. Typical account groups:

• Employees — the identity is created at the start of the contract, loaded into IdM from HR.
• Externals — suppliers, customers, students. They often access systems via VPN, frequently using certificates. Their identities can be created in the IdM web interface, or through self-registration with approval by a responsible person.
• Technical and service accounts — application and integration accounts. These must not be deactivated when their human owner leaves; they follow their own lifecycle. Every technical account should have a responsible guarantor, a validity period and an audit trail, and IdM can also handle the password handover agenda. Flag the privileged ones for handover to PAM.
• Privileged accounts — administrator accounts across infrastructure and applications. Keep an inventory with guarantors and manage them in cooperation with your PAM system.

What objects does IdM process?

Identities, accounts, roles, groups, organizational structures, contracts, certificates, photos, the role catalog, software licenses and assets, VPN accesses… and the actions users need to perform on them in the GUI.

HW/SW requirements for IdM

An IdM typically consists of a Java application running on an application server and a database storing the metadata — deployed on a virtual machine, in containers, or as a pre-packaged appliance. In most deployments the workload is modest and low hardware requirements suffice; only systems that systematically synchronize large volumes of data from many sources need more power. Either way, hardware today is cheap relative to everything else in the project — its acquisition usually costs less than a week of a consulting team’s work.

Customer cooperation

What should you prepare as a customer? A good supplier will get the right information by asking good questions in meetings. In any case, it is the customer who specifies what problems they want to solve, which systems to manage, which processes and which data.

The following tasks are expected on the customer’s side:

• server preparation (hardware or a virtual server),
• operating system installation, firewall configuration, etc.,
• access to the mail server — the identity manager needs an SMTP server for notifications,
• configuring the SSL connection to Active Directory (if passwords are to be managed),
• remote access for the technicians performing the implementation,
• preparation of the data source in the format described above, made available on the network,
• participation in the initial data import, data cleansing and process debugging,
• participation in training and the handover of the environment,
• and one new item: make the documentation of your systems available. It speeds up the consultants — and it is the raw material for the AI Skills described above.

Conclusion

Identity Management projects tend to be large and complex integration projects, and good preparation is essential. Start with a minimal brief, build a minimal product, and go to production with it as soon as possible; then iteratively improve and extend the solution. This prevents the project from dragging on and stops you from implementing features that look important on paper but end up unused.

Two closing recommendations from the 2026 perspective. First, choose a system by its security capabilities — management of technical and privileged accounts, recertification, audit reporting — because that is what regulation will ask of you, and that is what guarantees the long-term sustainability of the investment. Second, use AI: with good documentation and a well-built Skill, it makes the implementation faster and cheaper and leaves you far less dependent on the implementer. Just remember the one thing AI must never do — decide who gets access. That decision stays with your people and your rules.