Blog

midPoint 4.11 and MidPilot: AI proposal, human decision, application onboarded under governance

midPoint 4.11 and MidPilot: What AI-Assisted Application Onboarding Actually Changes

by with No Comment midPoint Tips

Published 6 October 2026, based on the midPoint 4.11 preview and the documentation available at that date. The 4.11 final release is currently planned for 15 October 2026, and details may still change.

midPoint 4.11 is currently scheduled for final release on 15 October 2026. Its June preview already gives a practical look at the MidPilot outcomes planned around 4.11: an AI-assisted connector code generator, recommendation services for mappings and correlation, an integration catalog, and reworked onboarding wizards. We have been testing those capabilities ahead of the final release. What they appear set to change is the effort side of connecting applications: the repetitive integration work that made onboarding slow gets machine assistance. What does not change is just as important: mapping and correlation recommendations require a final user decision by design, results still depend on the quality of your identity data, and generated connectors still need engineering review and testing against real systems. This article covers both halves.

Why application onboarding is the bottleneck

Many IGA programs still have only a subset of the organization’s applications connected to the platform. The reasons are structural. Every application needs integration code for its protocol and quirks, attribute mappings between its data model and the identity model, and correlation rules that match its accounts to real people. Each of those steps takes specialist time, and organizations run hundreds of applications. Integration engineering effort is one of the major contributors to the resulting backlog, alongside missing ownership, absent APIs, weak documentation, and governance ambiguity. The combined effect is the same: the important systems get onboarded, and a long tail of applications waits indefinitely.

That long tail is not a cosmetic gap. Applications outside the IGA platform can also remain outside centralized lifecycle automation, access review, and governance visibility, whatever local processes they may have. Evolveum’s project page frames the motivation the same way, citing weak visibility from slow and incomplete application onboarding as a key identity security issue. Our first two articles this quarter dealt with the same phenomenon from other angles: unmatched accounts that nobody classifies, and identity operations that quietly stop while dashboards stay green.

What MidPilot actually delivers

MidPilot was a fourteen-month Evolveum project, funded by the European Union through the Recovery and Resilience Plan of the Slovak Republic, running from April 2025 to May 2026. Its outcomes reached the public in the midPoint 4.11 preview in June 2026, with production quality planned for the 4.11 final. Four deliverables matter operationally:

A connector code generator service. The service generates integration code using contextual information about both the application being integrated and the connector framework: object and schema detection, identity and access management operations, and help with connector configuration options. It targets cloud services as well as on-premise applications, and object types beyond users: groups, organizational units, memberships.

A recommendation service for mappings and correlation. The mapping side proposes attribute matches, from simple name translations across languages and abbreviations up to transformations, value composition, and scripting logic, including proposals for schema extensions when no matching midPoint attribute exists. The correlation side suggests correlation keys and rules: linking users to accounts, groups to roles, memberships to assignments. Both are explicitly interactive and iterative, and both always require the user’s confirmation. Evolveum designed the human into the loop, not around it.

An integration catalog. A place to browse, share, and reuse not only connectors but also mapping configurations and correlation rules. Reuse is quietly the most economically interesting part: the second organization onboarding the same SaaS application should not start from zero.

Reworked onboarding UI. A new wizard for connector generation, reworked wizards for mapping and correlation configuration, and integration of the same capabilities into midPoint Studio for advanced users and integrators.

Our first-hand impressions from working with the preview: connector generation currently targets SCIM and REST interfaces, built on Evolveum’s SCIMREST framework, which is public in their repositories and which Evolveum still describes as evolving. In the cases we tested with good API documentation, we found the generator genuinely useful: much of the initial integration scaffolding stopped being the main pain point. What stays firmly with you is testing, and plenty of it. On the AI side, one clarification worth making precisely: the MidPilot services require an LLM, with some mapping suggestions also available from built-in heuristics. The enterprise-relevant detail is that the LLM endpoint is OpenAI-compatible, so it can be self-hosted. Organizations that do not want their IGA platform talking to an external AI service can run the model inside their own boundary and point the services at it.

What you actually have to deploy

4.11 does not ship a magic embedded AI engine, and that is worth understanding before anyone plans an upgrade around it. The AI-assisted MidPilot capabilities rely on optional external services that midPoint connects to: the smart resource integration service for mappings and correlation recommendations, and the connector generator service. They require their own configuration and infrastructure, and the connector generation service carries additional dependencies of its own, including a PostgreSQL instance and an LLM endpoint.

The architecture, roughly: midPoint 4.11 talks to the Smart Integration services, which talk to an LLM endpoint. At that last hop you have a real choice: an external AI service, or a self-hosted model behind an OpenAI-compatible endpoint. Which one is right depends on your security and data-governance requirements, because the services work with your schemas, sample identity data and, for connector generation, target API documentation and related integration context. For many European organizations we work with, the self-hosted option is the difference between “interesting feature” and “feature we are allowed to use.” One more architectural detail worth knowing: the services should be treated as trusted internal components and isolated accordingly, because Evolveum’s current reference deployment does not enable authentication on the midPoint-facing microservice endpoints by default, so network and secrets controls around the deployment are part of the design. Plan the deployment question alongside the upgrade question, not after it.

What this changes in practice

The honest framing is that MidPilot attacks the effort side of onboarding, which is one of the main reasons backlogs exist, though not the only one.

More of the long tail can become economically viable to onboard. When a connector plus mappings plus correlation for a routine application takes days of specialist effort, only important systems clear the bar. Machine-assisted generation and recommendations lower the per-application effort, which moves the break-even point down the tail. Where onboarding is blocked by missing ownership or an absent API rather than effort, the AI changes nothing, which is precisely why the preparation section below exists.

Iteration gets faster where it used to be slow. Mapping and correlation design has always been an iterate-and-verify loop: propose, check against real data, adjust. Recommendations that start the loop close to a workable answer, combined with midPoint’s simulations for verifying the post-change state before executing it, compress the loop without removing its checkpoints.

Reuse becomes a first-class mechanism. The integration catalog turns onboarding knowledge into an asset that accumulates. For integrators like us, that changes delivery too: the value shifts further toward the judgment calls, the nonstandard systems, and the governance decisions, and away from retyping boilerplate.

What this does not change

This is the part vendor marketing tends to skip, so it is the part worth writing down.

Human confirmation is the design, not a limitation. Mapping and correlation recommendations require a final user decision by design, while generated connector artifacts still require engineering review, refinement, and testing. That is the correct design for anything that decides how access is granted and matched. The person confirming needs to understand what they are confirming: an AI proposal accepted blindly is just manual misconfiguration at higher speed.

Data quality still decides correlation quality. The recommendation services are built to cope with typos, missing values, and inconsistencies, but coping is not curing. Recommendations operate on the schemas and sample data available to them, so ambiguous or inconsistent source data can still produce ambiguous proposals that a human has to resolve. Everything in our identity data quality article applies before AI-assisted onboarding, not instead of it.

Generated code still needs testing. A generated connector is a starting point that has to be verified against the real application, its real API behavior, its rate limits, and its edge cases, in a proper test environment with test endpoints. The environments discipline from our operations article applies unchanged: production remains the place where nothing happens for the first time.

Governance decisions stay human. Which accounts should exist, who approves access, how roles are structured, what happens on offboarding: none of this is a mapping problem. Faster onboarding gets applications under governance sooner, and then the governance itself still has to be designed and owned.

How to prepare before 4.11 lands

If AI-assisted onboarding lowers the per-application effort, the winners will be organizations whose backlog is ready to be worked through. Concretely:

  1. Inventory the unconnected. List the applications not yet under governance, with an owner per application. If the responsibility map from go-live exists, this is fast; if not, this is the moment to build it.
  2. Prioritize by risk, not convenience. Applications holding sensitive data or privileged access first, regardless of how easy they are to connect.
  3. Clean the identity data. Correlation recommendations work with the identifiers and attributes you have. The stable-identifier and classification work pays off directly here.
  4. Have the test environment ready. Generated connectors and proposed mappings need somewhere safe to be verified.
  5. Plan the AI deployment question. External AI service or self-hosted OpenAI-compatible endpoint, and who signs off on schemas and sample data flowing to it. This is a security decision, and it is faster to make before the upgrade than during it.
  6. Decide your 4.11 position. 4.11 is a feature release, not an LTS. Deployments following feature releases get the Smart Integration outcomes on upgrade. Deployments staying on 4.8 LTS have a strategy decision to make: wait for the next LTS, or move to the feature-release track earlier because the onboarding gains justify it. That is a business decision about backlog size, not a technical default.

Frequently asked questions

When is midPoint 4.11 released?

The 4.11 final release is currently planned for 15 October 2026, following the preview released in June 2026. Evolveum states plainly that planned dates are estimates, so check their roadmap for the current status.

Will the AI build connectors for me automatically?

It generates connector code using context about the application and the connector framework, and it proposes mappings and correlation rules. Mapping and correlation recommendations require a final user decision, while generated connector artifacts still need engineering review, refinement, and testing against the real system before production use. Assistance, not autonomy, and deliberately so.

Does this require sending our data to an external AI service?

The Smart Integration services require an LLM, and the endpoint is OpenAI-compatible, so it can be an external service or a model you host yourself. Some mapping suggestions can also come from built-in heuristics. Organizations with strict data-governance requirements can keep LLM processing inside their own boundary by hosting an OpenAI-compatible inference endpoint. The connector generator may still require controlled outbound access for API-documentation discovery and framework artifacts, depending on how it is deployed.

We run 4.8 LTS. Should we move for this?

Not automatically. 4.8 is supported until October 2028, and the next LTS is the conservative path. The case for moving earlier is a large onboarding backlog whose effort the new capabilities would materially cut. Note the upgrade path too: direct upgrade to 4.11 is supported from 4.10.x. Older versions must first be upgraded to 4.10.3, so moving from 4.8 LTS is a staged upgrade project. Size it honestly before deciding.

Does AI-assisted onboarding replace connector development?

It changes where the effort goes. Routine SCIM and REST integrations need less hand-written boilerplate, and specialist time concentrates on nonstandard systems, complex transformations, correlation edge cases, and verification. For custom and legacy applications with unusual interfaces, engineered connectors remain the path.

Get your backlog ready

The organizations that will benefit most from 4.11 are the ones whose application inventory, identity data, environments, and AI deployment decisions are ready before it arrives. We help with exactly that: onboarding backlog assessment, identity data preparation, connector development for the systems AI will not cover, and the 4.11 upgrade decision itself.

Discuss your application onboarding backlog

Related Resources

Sources

Operating midPoint in production: four monitoring layers with an alert on identity operations

Operating midPoint in Production: Monitoring, HA, Backups, Upgrades, and the Support Chain

by with No Comment midPoint Tips

Operating midPoint in production means owning five things: monitoring that covers all layers of the deployment, backups that have actually been restored at least once, an availability design matched to real business needs, a disciplined upgrade cadence aligned with Evolveum’s release model, and a support chain where responsibilities are named and the escalation path to the vendor actually works. None of these are features you install. They are operational capabilities someone has to build and staff. This article describes what each one involves, based on how Evolveum documents the platform and on what we deliver when we operate midPoint for clients.

The gap between deployed and operated

A midPoint deployment that passed its acceptance tests is not yet an operated service. Acceptance tests prove the configuration works on a good day. Operations is everything that happens on the other days: the sync task that silently stops, the connector that starts timing out after a target system patch, the certificate that expires on a Saturday, the upgrade that has to happen because the version you run is approaching end of support.

The difference matters commercially too. An identity platform sits in the critical path of onboarding, offboarding, and access control. When it stops working, onboarding and offboarding can be delayed, access changes can stop propagating, and audit evidence can stop being produced. Whoever owns operations owns that risk.

The support issues we repeatedly see tend to fall into a few patterns: errors in recurring tasks such as live synchronization, reconciliation, and recomputation; connector failures toward particular target systems; and data or mapping problems triggered by edge cases that were not modeled during implementation. Almost never is the first symptom “midPoint is down.” It is “midPoint is running and something inside it quietly stopped doing its job,” which is exactly why the monitoring section below exists.

Environments: production alone is a choice nobody should make

Before monitoring or upgrades, the structural question: how many environments do you run? Evolveum itself recommends a three-environment model, and our position matches it. At minimum, production should be accompanied by a properly isolated testing environment that mirrors the production architecture, configuration, and data characteristics as closely as practical, while using test endpoints and appropriately anonymized or synthetic data wherever possible. A test instance with three dummy users and no integration endpoints tests nothing but the installer.

The best case is three environments with distinct jobs. Development is where configuration gets built and broken freely, on reduced or dummy data and simulated resources. Test is where changes meet production-representative data at production-like volume, against testing instances of the connected systems. Production is where nothing should ever happen for the first time. Isolation between them is part of the design: a test environment that can accidentally write into production target systems is a hazard, not a safety net.

Simulations make production changes safer, but they do not replace a testing environment. A simulation evaluates what a policy change would do. It does not test a binary upgrade, a Java or PostgreSQL change, a connector library update, a certificate rotation, or the behavior of a patched target application. Those changes still need somewhere to happen for the first time, and that somewhere should not be production.

Monitoring: four layers, not one dashboard

midPoint deployments fail at different layers, so monitoring has to watch all of them. In practice we think in four:

Infrastructure. Hosts, containers, network, storage, certificates. Standard tooling, nothing midPoint-specific, but certificate expiry deserves explicit mention because identity platforms are unusually full of TLS relationships: connectors, LDAP, HR feeds, the GUI itself.

Application and JVM. midPoint is a Java application, so heap usage, garbage collection behavior, and thread health are the early warning system for capacity problems. Sizing problems tend to show up here first, long before users notice.

Repository. For current midPoint versions (4.10 and later), PostgreSQL is the only supported repository database, which makes PostgreSQL health a first-class operational concern: connections, replication health where replicas exist, storage growth, vacuum behavior. Earlier supported branches such as 4.8 may still run the deprecated generic repository on other databases, but native PostgreSQL is the strategic direction, and a legacy repository is itself an upgrade-planning topic.

Identity operations. This is the layer generic monitoring misses. midPoint maintains detailed task statistics: synchronization progress, reconciliation results, errors per task. Operationally, the questions that matter are: is live synchronization keeping up with the source, are reconciliation tasks completing, are connector operations failing, and is anything accumulating in error states. A midPoint instance can look perfectly healthy at the infrastructure layer while provisioning has been failing for days. Alerting on task failures and synchronization lag is what closes that gap.

Our standard monitoring pattern is built on Prometheus and Grafana: node exporters on every host for the infrastructure layer, midPoint’s own actuator health and application metrics, and an external midPoint exporter we deploy that reads operational task state through supported interfaces and exposes it to Prometheus. That last piece is our implementation pattern rather than a native product capability, and it is what makes the identity operations layer visible on the same dashboards as everything else.

High availability: what clustering solves and what it does not

midPoint supports high availability through clustering: several midPoint nodes work as one instance over a shared repository, and a load balancer spreads GUI and REST traffic. Persistent tasks are resilient by default and can resume on surviving nodes after a node failure, although task behavior can be configured differently for cases where automatic restart is undesirable. The clustering setup is documented and works well when configured correctly, including the detail that every node sharing a repository must have clustering enabled, otherwise task scheduling misbehaves. One planning fact that surprises people: Evolveum supports clustering in production only for deployments with a valid subscription identifier from a paid subscription. HA is a subscriber capability, so the availability design and the support relationship get decided together, not separately.

The honest architectural point: clustering protects against node failure, which is only one failure class. In a clustered deployment, the shared repository becomes one of the most critical dependencies, so the availability design has to cover the database, not only the midPoint nodes. A two-node midPoint cluster in front of an unprotected single database has moved the single point of failure, not removed it.

For deployments where repository HA is justified, PostgreSQL should use an active-passive failover design with a connection mechanism supported by the target midPoint version. Evolveum’s current guidance favors PostgreSQL and JDBC-driver-level failover, and explicitly supports direct database connections rather than database proxies or SQL load balancers, which can alter the communication in unsupported ways. The exact topology should be validated against the midPoint version being deployed, not copied from a generic HA cookbook.

The other honest point: not every deployment needs a cluster. HA adds moving parts, and moving parts add operational load. The right question is not “can we cluster midPoint” but “what does the business actually lose per hour of identity platform downtime.” For some organizations the answer justifies full HA with database failover. For others, a well-tested restore procedure with a defined recovery time is the more rational design. Both are legitimate. Choosing without asking the question is not.

Backups: the restore is the deliverable

A complete midPoint backup strategy has four parts, and they are not equally well known.

The repository and audit. Standard PostgreSQL backup practice applies: regular base backups plus continuous archiving where recovery point objectives demand it, with the audit trail included in the scope. This is well-trodden ground for any database team.

Reproducible configuration. midPoint configuration lives as objects in the repository, but treating Git as the source of truth is what makes deployments reproducible: initial objects, resource definitions, role definitions, deployment descriptors. If the configuration exists only inside the running system, rebuilding after a serious failure means archaeology.

midpoint.home and the cryptographic material. The midPoint home directory holds what the repository does not: the initial configuration file, cryptographic keys, schema extensions, custom connectors, custom libraries, and localization. The single scariest file in it is the encryption keystore, by default keystore.jceks. Sensitive values in the repository are encrypted with keys that live in that keystore, not in the database. If the live database is lost but you have a valid repository backup and the required keystore, recovery is possible. If you retain the database backup but lose the encryption keys used by its encrypted values, those values may become unusable. A database backup without the encryption keys needed to decrypt it is not a complete midPoint backup.

The proof. A backup that has never been restored is an assumption, not a capability. Restore testing on a schedule, into a real environment, with the time measured, is the part most organizations skip and the part an auditor or an actual disaster eventually asks about. The measured restore time is also the only honest input for any recovery time commitment anyone makes to the business.

Upgrades: cadence is a decision, not an event

Evolveum currently follows roughly an annual feature-release cycle, a change from the older twice-yearly model that ended around midPoint 4.8. The recent sequence shows it: 4.9 in October 2024, 4.10 in November 2025, 4.11 planned for October 2026. LTS releases serve longer-lived deployments, with a direct upgrade path between LTS versions. That gives a deployment two rational strategies: follow the supported feature releases as they arrive, or stay on an LTS branch and plan the direct jump to the next LTS. midPoint 4.8 LTS is supported until 17 October 2028, and 4.12 is currently planned as the next LTS release, which means every 4.8 deployment already has a dateable upgrade project on its horizon whether it has scheduled one or not.

What a disciplined upgrade actually involves: reading the release notes for schema and behavior changes, verifying platform prerequisites early, checking connector compatibility against the target systems, running the upgrade in the test environment against production-representative data, using the verification tooling Evolveum provides to detect deprecated configuration before it breaks, and simulating policy behavior where simulation applies. The upgrade itself is usually the easy part. The preparation is the work.

Platform prerequisites deserve their own line because they are the most commonly missed class: the supported Java version, the PostgreSQL version, the repository implementation, connector versions, container image and runtime assumptions, and any custom libraries. midPoint 4.8 dropped support for Java 11 and PostgreSQL 13, and 4.10 removed the generic repository entirely. Sometimes the “midPoint upgrade” quietly contains an infrastructure upgrade that has to be planned and staged separately.

The upgrade tooling improved significantly around the 4.8 generation. The enhanced ninja-assisted upgrade procedure was introduced for 4.8 and backported to selected maintenance releases such as 4.4.6 and 4.7.2, and a supported direct LTS path exists from 4.4 to 4.8, provided the 4.4 deployment is first brought to at least 4.4.6. Older deployments therefore need to be assessed from their exact source version, repository implementation, and configuration state rather than classified simply as before or after some version line. Very old deployments can require intermediate upgrades, repository migration, or manual configuration remediation before the current tooling can do most of the work.

The anti-pattern we advise against is drift: skipping releases without choosing the LTS strategy, until the deployment is several versions behind with no tested path forward. At that point every upgrade is a project, and urgent fixes become genuinely painful.

The support chain: name the responsibilities before go-live

This is the part of operations most often left implicit, and Evolveum’s own model makes it explicit. In Evolveum’s support model, level 1 is end-user support, level 2 is solution-level troubleshooting of configuration, integration, and environment, and level 3 is product support: investigation and bugfixing of defects in midPoint itself, provided under subscription. Premium programs add level 4, which covers improvements and new feature development. Evolveum L3 is product support rather than a replacement for operating the deployed solution. Configuration and integration issues are primarily L2 responsibilities, although Evolveum may assist in diagnosis when it is unclear whether the underlying cause is a product defect.

The practical consequence: somebody on the deployment side has to genuinely run L1 and L2. Watching the alerts, diagnosing whether a problem is configuration, integration, data, or product, and when it truly is a product bug, producing the clean reproduction and evidence that makes the L3 escalation effective. A well-diagnosed escalation gets fixed dramatically faster than “midPoint is broken, please help.”

This is where our support offering sits: WeKnowIdentity provides specialist midPoint solution and operational support, corresponding primarily to L2 in Evolveum’s model, under an agreed SLA, typically with 8×5 coverage, with 24×7 coverage available where the business requires it. In practice that means monitoring response, diagnosis, and configuration-level and integration-level fixes, with managed escalation to Evolveum L3 when the root cause is a product defect, where the fix comes through the customer’s Evolveum subscription. We also build internal teams up to run this layer themselves.

The support line is also only one slice of a wider responsibility map, and the map needs names before go-live, not after the first incident. An identity platform touches more teams than any other system in the estate: every connected application needs a named owner who answers for its data and its access model, the HR and other source systems need owners who can fix wrong source data, system administrators own the infrastructure underneath, and IAM personnel own the policies and the platform itself. Who approves a policy change, who resolves a data dispute between HR and a target system, who is called for each class of incident: written down, with names, agreed by the people named. Without this, every incident starts with an ownership negotiation instead of a diagnosis, and the negotiation usually takes longer than the fix.

How to assess where you stand

Five questions, answerable this week, no tooling required:

  1. When was your last restore test, did it include midpoint.home and the keystore, and how long did it take? If the answer is “never” or “unknown,” that is finding number one.
  2. How would you learn that live synchronization stopped? If the answer involves a user complaining, monitoring has a gap at the identity operations layer.
  3. What version are you on, and what is the support end date for it? If nobody can answer from memory, upgrade planning is reactive.
  4. Who gets called when provisioning fails outside business hours, and do they have access and knowledge to act? A name, not a team alias that nobody watches.
  5. Where is your configuration versioned, and could you rebuild the environment from it? If the running system is the only copy, treat that as a risk register entry.

What good looks like

As with data quality, there is no universal standard, but the shape of a well-operated midPoint deployment is recognizable. Treat these as examples to adapt:

  • A properly isolated test environment mirrors production architecture, integration behavior, and data characteristics, using test endpoints and appropriately protected, anonymized, or synthetic data
  • Responsibilities are written down with names: an owner for every connected application, owners for the authoritative sources, system administration, and IAM operations, agreed before go-live
  • Monitoring covers all four layers, and task failures or synchronization lag raise an actionable alert to a human according to the agreed support coverage
  • Restore has been tested on a schedule including midpoint.home and the keystore, and the measured recovery time is documented and accepted by the business
  • The availability design matches a stated business requirement, not a default
  • The deployment runs a supported version, and the path to the next one has an owner and a quarter attached
  • L1 and L2 are explicitly staffed, internally or by a specialist, and the Evolveum escalation process, access, and responsible contacts are documented and validated

Frequently asked questions

Does midPoint support high availability?

Yes. midPoint clusters multiple nodes over a shared repository, distributes tasks across them, and supports load balancing for GUI and REST traffic. Production clustering requires an active Evolveum subscription, and the repository needs its own availability design using supported connection mechanisms, so a serious HA plan covers PostgreSQL failover, not only midPoint nodes.

How often should midPoint be upgraded?

Evolveum currently ships roughly one feature release per year, with sequential upgrade paths and direct paths between LTS releases. The two workable strategies are following supported feature releases as they arrive, or staying on an LTS branch and planning the jump to the next LTS well before support ends. Unplanned drift between versions is the option to avoid.

Can we run midPoint in production without an Evolveum subscription?

For a non-clustered deployment, yes: midPoint is open-source software and can be operated without a subscription. Production clustering, however, requires an active subscription. Without one you also do not have the contractual Evolveum L3 relationship for diagnosis, prioritized bugfixes, and supported backports. For a platform in the critical path of access control, most enterprises conclude the subscription is part of the operating cost.

What should monitoring alert on first?

Failed or suspended tasks, synchronization falling behind the source, connector errors toward target systems, and repository health. These catch the failures that generic infrastructure monitoring misses: the instance looks healthy while identity operations quietly stop.

Do we need Kubernetes to run midPoint properly?

No. Kubernetes standardizes deployment and recovery and pairs well with a GitOps approach, which is how we deploy where it fits, but it adds its own operational overhead and skills requirement. A well-run conventional deployment beats a poorly-run cluster. The deciding factor is your platform team’s existing capability, not fashion.

Talk through your operations

If some of the five assessment questions above have uncomfortable answers, that is normal, and it is fixable. We help enterprises operate midPoint: monitoring design, availability architecture, upgrade planning, and specialist solution and operational support under an agreed SLA, with managed escalation toward Evolveum. We also build internal teams up to run it themselves.

Discuss your midPoint operations

Related Resources

Sources

featured-identity-data-quality-16x9

Identity Data Quality Before Automation: Correlation, Unmatched Accounts, Duplicates, and Drift

by with No Comment Identity GovernancemidPoint Tips

Before enabling IAM automation, four data problems need to be understood and handled: matching accounts to their owners (correlation), classifying accounts that match nobody (unmatched accounts and orphans), resolving people who exist twice (duplicates), and keeping records aligned with reality (drift). Automation does not fail loudly on bad data. It runs, provisions, and deprovisions exactly as instructed, and distributes every data error to the connected systems. This article describes how we evaluate identity data before turning automation on, following the same Connect, Cleanup, Automate progression that Evolveum’s midPoint methodology uses.

Why automation exposes bad data

Manual identity administration tolerates bad data surprisingly well. A helpdesk operator who sees two similar records picks the right one from context. An admin who receives a deprovisioning ticket for the wrong person notices the mistake and asks. Humans apply judgment at every step, which hides the underlying quality problems.

Automation removes the judgment and keeps the data. A typical scenario: HR marks a contractor as departed, the platform disables the linked accounts, and it turns out those accounts belong to a different person whose records were incorrectly merged years earlier. The mistake had existed the whole time. Automation simply executed it.

A pattern we see on nearly every assessment: applications carry technical accounts that accumulated over the years. Each was added for a reason, an integration, a data load, a monitoring tool, and the reason was rarely written down. When correlation flags them, an internal investigation usually starts: who created this account, what does it do, is anything still using it. That investigation is not a failure of the assessment. It is the point of it.

What bad identity data actually means

Identity data quality is the degree to which you can answer four questions with confidence:

  1. Who does this account belong to? Every account in every system should trace to a current person or a documented technical owner.
  2. Is this person represented exactly once? One person, one canonical governed identity, even if that person has multiple employments, contracts, or accounts.
  3. Are the attributes correct? Department, manager, location, employment status. The fields your access policies will run on.
  4. Does reality match the records? The access people actually have should match what your systems say they have.

There is a subtler dimension behind question three that gets missed in most data quality discussions. An attribute can be technically valid and still be unusable for governance. Every employee may have a department value, so completeness looks perfect. But if HR fills that field inconsistently, or if department has no relationship to how access should actually be assigned, the data is still poor for IAM purposes. When we evaluate identity data we look at four levels: completeness (is the field filled), correctness (is the value true), consistency (is it used the same way everywhere), and suitability (can an access policy safely depend on it). Many automation projects stall on the fourth level after passing the first three.

The four problems

Correlation: matching accounts to people

Correlation means determining which account belongs to which person, across every connected system. On paper this is a join operation. On real data it is one of the hardest tasks of the project.

The HR system says Jana Kováčová. Active Directory says jkovacova. The ERP system says KOVACJ01. An old application says jana.kovacova@formercompanyname.com because it was set up before a rebrand. Same person, four representations, no shared identifier.

Start with a stable person-level business identifier where one exists, and verify what it actually identifies: an employee number can represent an employment rather than a person. Then use reliable system-specific identifiers and additional attributes as supporting correlation signals. Email addresses, UPNs, logins, and names can all be useful, but their reliability depends entirely on how the organization manages them. The principle: prefer stable, immutable business identifiers whenever they exist. Human-readable attributes such as names and email addresses are useful signals but poor identity keys. Names change, emails get reissued, and two people named Novák will eventually work in the same department.

midPoint supports this with correlation rules that combine multiple attributes with confidence levels. Matches above a configured confidence link automatically. Ambiguous cases go to a human for resolution. That human step is not a limitation of the tooling, it is the design: an engine that automatically resolves every ambiguous candidate can eventually link two different people, and recovering from a wrong merge costs far more than working a review queue.

The hardest cases in real integrations are rarely the obvious ones. They are identities that are technically valid in every source system but mean something different in each one. HR may model a person. Another source may model employments or contracts. The target system only knows accounts. Before automating anything, those concepts have to be reconciled, and no correlation rule can do that reasoning for you. The data can therefore be correct in every individual system while the identity model created by combining those systems is still wrong.

Unmatched accounts and orphans: classification before cleanup

After correlation runs, some accounts will match nobody. It is tempting to call that remainder the orphan list and schedule it for deletion. That shortcut causes outages.

The unmatched remainder is your investigation queue, not your deletion queue.

Some of those accounts are genuine orphans: a former employee’s account that outlived the offboarding, a vendor account from a finished project. Others are legitimate service accounts, technical identities, pre-created accounts waiting for a hire, protected administrative accounts, or valid users whose attributes are simply too poor to correlate automatically. Evolveum’s methodology makes the same point: unmatched accounts get classified first, and legitimate exceptions get marked and protected before any automated cleanup runs.

The distinction that matters for governance is not orphan versus non-orphan. It is explained versus unexplained. An unexplained account is a governance problem regardless of its origin. An intentionally unmanaged technical account with a documented purpose, owner, protection policy, and review cycle is a different thing entirely, and it can be governed and reviewed differently.

On scale, the problem is well documented. Orchid Security’s Identity Gap 2026 snapshot, based on telemetry from enterprise applications across North America and Europe collected between April 2025 and March 2026, found that 40 percent of accounts across the analyzed applications belonged to users who could no longer be found in the HR system, and were classified as orphan accounts. Earlier, Varonis’s 2021 assessment of 50 manufacturing companies found that 44 percent of them carried more than 1,000 enabled ghost user accounts. Different samples, different years, same direction: unowned access can accumulate when nobody is explicitly responsible for removing it.

This matches what we find in practice. The legitimate exceptions that turn up during classification are mostly non-human identities: integration accounts, service accounts, and other technical identities added to applications over time. They are valid, often still in use, and almost never documented, which is exactly why classification has to come before cleanup.

Duplicates: one person, several identities

Duplicates are the mirror image of orphans: one person, several identity records. Rehires are the classic source. Someone leaves, returns two years later, and HR creates a fresh record because the old one was archived. Each record can accumulate its own accounts, and neither shows the person’s full access.

The consequences are quiet but serious. Access reviews show a reviewer half of someone’s access. Segregation-of-duties checks can miss conflicts when the conflicting permissions sit on two different records. Offboarding disables one identity and leaves the other active.

A good rehire design preserves or rediscovers the original identity rather than creating another one. In midPoint this can be implemented with stable identifiers, correlation rules, and an appropriate lifecycle model, so that a returning person is matched to their existing identity instead of getting a new one. Existing duplicates can be merged, midPoint provides interactive identity merge for exactly this, but merging is corrective surgery. The design goal is preventing the duplicate in the first place, and that depends on decisions about identifiers, retention, and HR process made well before the rehire happens.

Drift: when reality and records diverge

Correlation, classification, and deduplication are project activities. Drift management is permanent. Drift is the gap that opens between what your IAM platform believes and what actually exists in the connected systems.

It accumulates through ordinary work. An admin creates an account directly in an application because a request was urgent. A group membership granted during an incident never gets removed. A SaaS administrator adds a user through the vendor console. None of it passes through the IAM platform, so the platform’s picture of reality degrades quietly.

Reconciliation is the countermeasure: a scheduled comparison between the IAM platform’s state and each connected system, with every discrepancy flagged and either corrected automatically or routed to a human, depending on policy. An account that appears in a target system with no counterpart in the platform is exactly how new orphans are born, and scheduled reconciliation can detect it on the next cycle instead of leaving it undiscovered until an audit or incident.

The sequence: Connect, Cleanup, Automate, Keep It Clean

Evolveum’s midPoint methodology describes iterative cycles of connecting systems, cleaning data, and then automating processes. Our project experience supports the ordering strongly, so we use it as the backbone of the data quality phase.

Connect: see reality before changing it. Connect the HR and other authoritative sources, together with the most important target systems, without writing changes back to those connected systems. Let correlation run and produce the honest picture: match results, the unmatched queue, disputed correlations, evidence of possible duplicates, attribute gaps.

Cleanup: classify and resolve. Classify the unmatched accounts into orphans, exceptions, and data errors. Resolve disputed correlations. Merge confirmed duplicates. Correct the attributes your planned policies depend on, with special attention to consistency and suitability, not just completeness.

Automate: progressively, with simulation. Enable lifecycle automation progressively, starting with the populations and processes whose data and policies are best understood, and expand from there. Movers are often the most complex, because they require decisions about which existing access should be retained, changed, or removed. For changes where simulation is applicable, we treat it as a standard safety step before execution against production data: midPoint’s simulation shows what a policy would do before it does it, and the first cleanup pass is exactly the situation it exists for.

Keep it clean: reconciliation as routine. Schedule reconciliation against every connected system and triage discrepancies as operational work, not annual archaeology. A cleaned environment without reconciliation can start drifting again immediately.

How to assess where you stand

You do not need an IAM platform for a first honest look. You need exports and a few hours.

  1. Map your identity sources and creation paths. Which systems are authoritative for employees, contractors, and other identity populations? Which systems can create accounts independently? If the answer includes “the helpdesk sometimes creates them manually,” write that down.
  2. Measure the match rate on your three most important systems. Export accounts and records from the relevant authoritative source(s), and join them on whatever identifier you have. The percentage that fails to match cleanly is your correlation problem, quantified.
  3. Count accounts with no match in the expected authoritative identity source. That is your investigation queue.
  4. Check the fields your future policies need. Completeness first, then spot-check correctness and consistency. A filled field is not automatically a usable one.
  5. Ask when each system was last compared against its authoritative identity source. If the answer is “at the last audit,” drift is accumulating now.

What acceptance criteria look like

There is no universal correlation percentage at which automation suddenly becomes safe. What matters is that ambiguous and unmatched cases are understood, classified, and handled by policy before destructive automation is enabled. That said, projects need concrete acceptance criteria, so here is the shape they usually take. Treat these as examples to adapt, not industry thresholds:

  • Every account in every connected system is either matched to an owner, classified as a documented exception, or sitting in a triaged investigation queue with a decision pending
  • Automated correlation handles the clear majority of accounts on core systems, and the manual remainder is small enough that a named person actually works it
  • No unexplained duplicates in the identity store
  • The attributes your first wave of policies depends on have been checked for completeness, correctness, consistency, and suitability
  • Reconciliation runs on schedule against every connected system, and discrepancy triage is someone’s defined job

Frequently asked questions

How long does an identity data cleanup take?

It depends less on data volume than on how many cases need a human decision: ambiguous matches, unmatched accounts to classify, duplicates to confirm, and how quickly data owners respond. Connecting systems in read mode early is the fastest way to replace guesses about duration with a real queue you can size.

Can we automate first and clean up as we go?

Automating on unresolved data propagates the errors to every connected system and makes cleanup harder, because you then have to separate legitimate automated changes from amplified mistakes. Progressive automation is the workable middle ground: enable low-risk flows on well-understood populations first, and expand as classification completes.

Is there a match rate that makes automation safe?

No universal number exists, and be skeptical of anyone quoting one. Safety comes from the unmatched and ambiguous cases being classified and policy-handled, not from the matched percentage crossing a threshold. A 99 percent match rate with an ignored 1 percent is riskier than a lower rate with a worked investigation queue.

Are all orphan accounts a security risk?

An unexplained account is always a governance problem. But not every account without a human owner is bad: service accounts, technical identities, and pre-created accounts can be legitimate if they have a documented purpose, a responsible owner, protection policies, and a review cycle. The goal is zero unexplained accounts, not zero exceptions.

Does midPoint require clean data before connecting?

The opposite. Connecting midPoint in read mode is how you measure the problem: its correlation produces the match results, unmatched accounts, disputed correlations, and the evidence needed to investigate possible duplicates. The rule is not clean before connecting. It is clean before automating changes.

Start with the honest picture

Before automating lifecycle processes, we can assess the identity data underneath them. We connect the authoritative and target systems in read mode, evaluate correlation, classify unmatched accounts and duplicates, and turn the findings into a concrete cleanup and automation plan.

Discuss an identity data assessment

Related Resources

Sources

Zero Standing Privileges: Moving from Permanent Access to Just-in-Time with midPoint

by midPoint Tips

99% of cloud identities are over-permissioned. That number comes from Palo Alto Networks’ Unit 42 Cloud Threat research. It means that virtually every identity in your environment holds more access than it needs, and that access persists 24 hours a day, 7 days a week, whether or not anyone is using it.

This is the standing privilege problem. An administrator has permanent production database access even though they touch production once a month. A developer has write access to the deployment pipeline even though they deploy once a quarter. A contractor has VPN access to internal systems even though their active project ended six weeks ago.

Each of these is a dormant attack surface. When credentials are compromised – and the Verizon 2026 DBIR confirms that credential abuse remains present in 39% of breach chains – the attacker inherits whatever standing privileges the credential carries. If the compromised account has permanent admin access to a production system, the attacker has it too. Immediately. Without escalation.

Gartner defined Zero Standing Privileges (ZSP) as “the target state for privileged access in an organization to minimize risk of stolen credentials, privilege abuse, breaches, data loss, and non-compliance.” The core mechanism is Just-in-Time (JIT) access: privileges are granted only when needed, for only as long as needed, with explicit approval, and then automatically revoked.

This is not a theoretical framework. It is a practical architecture that midPoint supports today.

The cost of standing privileges

The breach record makes the case more effectively than any analyst prediction.

Microsoft / Midnight Blizzard, January 2024. A Russian state-sponsored group compromised a legacy test account with standing elevated privileges to Microsoft’s corporate environment. The account had no business need for those privileges. A password spray was sufficient. The attackers accessed senior leadership and cybersecurity team email over a period of weeks.

Snowflake customers, May 2024. Stolen credentials – harvested by infostealer malware months or years earlier – were used to access approximately 165 customer tenants. The accounts had permanent access with no MFA. Standing credentials, standing access, massive breach.

BeyondTrust, December 2024. A compromised API key – a standing credential for a non-human identity – was paired with a command injection vulnerability to gain unauthenticated remote code execution on customer Remote Support SaaS instances.

The pattern repeats: a credential that was granted once and never re-evaluated. Access that persisted long after the legitimate need ended. Revocation that happened only after the breach was discovered.

The numbers reinforce the pattern. IBM’s 2025 Cost of a Data Breach report found that breaches involving compromised credentials cost $4.67 million on average and take 246 days to identify and contain – the longest of any attack vector. Ponemon’s 2025 research found that 45% of incidents involve overprivileged internal users and 34% involve third parties with excessive access.

What Zero Standing Privileges actually means

ZSP does not mean nobody has access. It means nobody has persistent, always-on privileged access that sits idle between uses.

The practical implementation has three components:

Just-in-Time (JIT) access. Privileges are provisioned when explicitly requested, approved, and needed. They expire automatically after a defined time window. Between requests, the identity holds no elevated access.

Just-Enough-Privilege (JEP). When access is granted, it carries only the permissions required for the specific task. An administrator who needs to restart a service does not get full root access to the server. They get the specific capability, scoped to the specific system, for the specific duration.

Continuous verification. Access decisions are re-evaluated based on context: time of day, location, device posture, recent behavior patterns. A request that makes sense at 2 PM from the office may not make sense at 3 AM from an unrecognized device.

Gartner’s April 2025 report “Reduce Risk Through a Just-in-Time Approach to PAM” recommends that IAM leaders implement JIT and JEP strategies starting with low-complexity, high-volume cases and expanding to cover all privileged access. The broader industry trend toward converged IAM/PAM/IGA platforms reflects the reality that JIT access cannot be bolted on as a separate tool – it needs to be embedded in the governance layer.

How midPoint implements Just-in-Time access

midPoint provides the governance and provisioning infrastructure that makes JIT access operational across your environment. Here is how each component works.

Time-bound role assignments

Every role assignment in midPoint can carry validity constraints: a valid-from date, a valid-to date, or both. When a user requests elevated access – production database admin, emergency change authority, audit investigation privileges – the assignment is created with an expiration. When the expiration arrives, midPoint automatically revokes the role and deprovisions the associated entitlements across all connected systems.

This is not a reminder to revoke access. It is automatic enforcement. The access disappears from every target system on schedule, whether or not anyone remembers to act.

Approval workflows

midPoint’s approval engine routes elevated access requests through configurable approval chains. The complexity of the approval process scales with the sensitivity of the access:

  • Low-risk temporary access (read-only access to a test environment) may require single-manager approval.
  • Medium-risk access (write access to staging systems) may require manager plus system owner.
  • High-risk access (production admin, financial system write access) may require manager, system owner, and security team.

Each approval step can include conditions: the approver sees the requested role, the justification, the requested duration, and any policy violations the assignment would trigger. The approver can modify the duration before approving.

Role catalog and self-service requests

Users request elevated access through midPoint’s role catalog – a structured list of available roles with descriptions, risk levels, and approval requirements. The request process works like a controlled shopping cart: the user selects the role they need, provides justification, and specifies the desired duration. midPoint evaluates the request against policies, routes it through the appropriate approval chain, and provisions access only after approval.

This replaces the informal channel – Slack messages, email requests, verbal approvals – that most organizations use for temporary access today. Every request is logged, every approval is recorded, and every grant has an expiration.

Policy-driven enforcement

midPoint’s policy rules engine can enforce constraints that go beyond individual access requests. Because policy rules are expression-based and extensible, organizations can configure constraints such as:

  • Maximum duration limits. A policy rule can specify that production admin access can never be granted for more than 8 hours, regardless of what the requester asks for.
  • Repeated-request controls. Policy rules can be configured to flag or block rapid re-requests of the same elevated role, preventing “permanent JIT” where access is simply re-requested every time it expires.
  • Scoped grant policies. Rules can enforce conditions on how many identities hold a given elevated role or require additional approvals when sensitive roles are concentrated.
  • SoD interaction. Temporary elevated access is evaluated against the same segregation-of-duties rules as permanent access. A temporary grant that would create a toxic combination is blocked or routed to additional approval.

Non-human identity JIT

Standing privileges are not only a human problem. Service accounts, API keys, and automation credentials often hold permanent elevated access because “the system needs it to run.” In many cases, the system needs the access for minutes per day but holds it for months.

midPoint can manage time-bound assignments for non-human identities the same way it does for humans. A CI/CD pipeline that needs production deployment access can receive it through an automated request with a 30-minute expiration, triggered by the deployment event and revoked automatically after completion.

The IGA-PAM convergence

Gartner’s 2025-2026 IAM research increasingly frames JIT access as a convergence point between Identity Governance and Administration (IGA) and Privileged Access Management (PAM). The traditional division – IGA governs who has access, PAM controls how privileged access is used – breaks down when you need both governance (who should be approved, for how long, under what conditions) and enforcement (session recording, credential vaulting, command filtering) in a single workflow.

midPoint operates as the governance layer in this architecture. It decides who gets access, for how long, through what approval process, and with what policy constraints. The PAM tool – CyberArk, BeyondTrust, HashiCorp Vault, or whatever your organization uses – handles the privileged session itself: credential injection, session recording, command filtering.

The integration pattern:

  1. User requests elevated access through midPoint’s role catalog.
  2. midPoint evaluates the request against policies and routes it through approvals.
  3. On approval, midPoint provisions a time-bound entitlement in the PAM tool.
  4. The user accesses the target system through the PAM tool’s session broker.
  5. On expiration, midPoint revokes the entitlement in the PAM tool.

This gives you governance-grade audit trails (who approved what, why, for how long) combined with PAM-grade session controls (what did they actually do during the session). Neither tool alone provides both.

The attack surface reduction

The security argument for ZSP is straightforward: privileges that do not exist cannot be stolen.

BeyondTrust’s 2025 research estimates that JIT access can reduce privileged threat windows by more than 90%. SecHard’s analysis, citing Gartner frameworks, found that JIT combined with just-enough-privilege can shrink the overall attack surface by up to 80% in hardened environments, with up to 94% fewer human errors in access management.

Consider the Microsoft/Midnight Blizzard breach through a ZSP lens. The compromised test account had standing elevated privileges. Under a ZSP model, that account would have had no elevated privileges by default. An attacker who password-sprayed into it would have found an account with baseline access and no path to corporate email. The breach either would not have occurred or would have been contained to an irrelevant test environment.

The same applies to Snowflake. Under a ZSP model, dormant credentials would not carry standing access to customer data stores. Stolen credentials harvested by infostealers months earlier would be useless – the access they once granted would have expired automatically.

Where to start

Moving from permanent access to JIT is not a single project. It is a maturity progression. Gartner recommends starting with low-complexity, high-volume cases and expanding:

Phase 1: Identify standing privileges. Use midPoint’s role analysis and reporting to map which identities hold elevated access, how long they have held it, and how often they use it. The gap between “always has access” and “uses access monthly” identifies your highest-value JIT candidates.

Phase 2: Convert low-risk elevated access. Start with access categories where the blast radius of a mistake is limited: test environments, non-production databases, staging systems. Convert permanent role assignments to request-based, time-bound assignments. Build organizational familiarity with the request-approve-expire cycle.

Phase 3: Expand to production access. Move production system admin access, deployment pipeline credentials, and financial system write access to JIT. Configure appropriate approval chains, maximum durations, and SoD policies.

Phase 4: Cover non-human identities. Extend JIT to service accounts, API keys, and automation credentials. Integrate with your secrets vault for automated credential provisioning and rotation.

Phase 5: Continuous optimization. Monitor request patterns. Identify roles that are requested so frequently they should be birthright (moving them back to permanent reduces friction without increasing risk). Identify roles that are never requested and should be retired. Adjust durations based on actual usage data.

Zero Standing Privileges with WeKnowIdentity

WeKnowIdentity helps organizations design and implement JIT access architectures using midPoint’s governance engine. That includes standing privilege analysis, role catalog design, approval workflow configuration, time-bound assignment policies, PAM integration, and non-human identity JIT. We work with your existing PAM tools and infrastructure – the goal is governance that fits your environment, not a rip-and-replace.

If your administrators have permanent production access they use once a month, your contractors have VPN access that outlives their contracts, and your service accounts have credentials that have not been rotated since they were created – those standing privileges are your largest ungoverned attack surface.

Book a free privilege assessment

Related Resources

Sources

Joiner-Mover-Leaver Automation Done Right: A Practical midPoint Guide

by midPoint TipsTechnical Tutorials

A new employee starts on Monday. By Wednesday, they still cannot access their email, the project management tool, or the shared drive their team uses. The manager opens a helpdesk ticket. IT provisions accounts manually, copying permissions from a colleague who started two years ago and has since accumulated access to three systems they no longer need. The new hire inherits every one of those unnecessary permissions.

This is not a worst-case scenario. This is the default in most organizations. CloudEagle’s 2025 IGA report found that roughly 60% of organizations still handle provisioning and offboarding manually. Gartner’s 2024 research measured new hires losing up to 40% of first-week productivity waiting 3 to 5 days for basic access.

The leaver side is worse. 50% of ex-employees still have access to corporate applications after departure. 42% of organizations take more than a week to fully revoke access after someone leaves.

Joiner-mover-leaver automation is the single most impactful thing an IGA platform can do. It is also the capability most often botched in implementation – not because the technology is hard, but because the edge cases are underestimated. This guide covers what JML automation actually looks like in production with midPoint, including the parts that vendor demos skip.

What JML automation is and is not

JML automation connects your HR system to your IT systems so that identity lifecycle events – someone joins, changes role, or leaves – trigger automatic provisioning and deprovisioning actions across every connected application.

What it is: a policy-driven engine that translates HR data into access decisions, executes them across all target systems, and logs everything for audit.

What it is not: a one-time sync job. A spreadsheet of role mappings. A set of scripts that run on a cron schedule and break when the HR system adds a field.

The difference matters because most failed JML projects fail at the boundary between these definitions. They automate the simple path – new hire gets standard access – and leave everything else to manual process. The result is an automation layer that handles 60% of events and creates confusion for the other 40%.

The three lifecycle events in detail

Joiners

A joiner event begins when a new record appears in the HR system. In midPoint, the HR system is configured as the authoritative source – the single source of truth for identity data. When midPoint detects a new HR record, it triggers a sequence:

1. Identity creation. midPoint creates an identity object with attributes pulled from the HR record: name, employee ID, department, position, manager, start date, location.

2. Account provisioning. Based on the identity’s attributes, midPoint automatically creates accounts on target systems. A new employee in the Engineering department gets an Active Directory account, a GitLab account, and a Jira account. A new employee in Finance gets AD, the ERP system, and the financial reporting platform. These mappings are defined by organizational policies and role assignments, not by copying a colleague’s access.

3. Role assignment. midPoint assigns roles based on organizational rules. Birthright roles – the baseline access everyone in a given position needs – are assigned automatically. These are defined through policy rules that map HR attributes (department, job title, location, cost center) to midPoint roles. Each role carries specific entitlements on specific target systems.

4. Notification. The manager, the new hire, and the helpdesk are notified that provisioning is complete. The new employee has working accounts on day one.

Automated provisioning reduces onboarding time by 73% compared to manual processes. The real value is not speed alone – it is consistency. Every person in the same role gets the same access. No privilege accumulation from copied accounts. No forgotten systems.

Movers

Movers are the most underestimated JML event. A mover is any change in someone’s organizational context: department transfer, promotion, location change, reporting line change, temporary assignment, or restructuring.

The problem with movers in manual environments is privilege creep. When someone moves from Engineering to Product Management, they get new access for their new role. But their old Engineering access – repository write permissions, CI/CD pipeline access, staging environment credentials – stays. Nobody revokes it because nobody remembers to, and the employee does not report it because the access is occasionally convenient.

Over time, long-tenured employees accumulate access across multiple departments. This is one of the largest sources of segregation-of-duties violations in enterprise environments and a primary target for insider threat and lateral movement after credential compromise.

midPoint handles movers through reconciliation. When the HR system updates an employee’s department, position, or manager, midPoint re-evaluates all role assignments. Roles tied to the old organizational context are revoked. Roles tied to the new context are granted. The transition happens automatically, and the employee’s access profile always reflects their current position – not their history.

This re-evaluation runs against policy rules, not static mappings. If a policy says “everyone in Finance with the title Senior Analyst gets access to the consolidation system,” then gaining or losing the Senior Analyst title in Finance automatically grants or revokes that access. No ticket required. No manager approval needed for standard birthright access.

For access that requires explicit approval – sensitive systems, elevated privileges, cross-departmental access – midPoint routes the request through approval workflows. The mover event can trigger both automatic adjustments and approval-gated requests in the same transition.

Leavers

When an employee’s termination date is set in the HR system, midPoint begins the offboarding sequence. The timing is configurable: immediate deactivation, deactivation on the termination date, or a grace period for knowledge transfer.

1. Account deactivation. On the configured trigger date, midPoint disables all accounts across all connected systems. Not deletes – disables. The accounts remain in a suspended state for the retention period required by your compliance framework (GDPR, tax law, internal policy).

2. Access revocation. All role assignments are revoked. All entitlements are removed. The identity retains its audit history but can no longer authenticate to any system.

3. Manager notification. The leaver’s manager is notified of the deactivation and any pending access reviews or knowledge transfer requirements.

4. Delegation and reassignment. midPoint can automatically reassign ownership of resources, shared mailboxes, or service accounts that the leaver was responsible for. This prevents the orphan-account problem where a service account loses its only known owner and becomes ungoverned.

5. Archival or deletion. After the retention period, midPoint can either archive the identity record or delete it, depending on policy.

The industry benchmark for automated deprovisioning is access terminated within 15 minutes of the HR event. Organizations using midPoint achieve this because the provisioning engine executes revocation across all connected systems in a single automated pass. Compare this to the 42% of organizations that take more than a week.

The edge cases that break simple automation

Every JML implementation handles the straight path: new hire, department transfer, termination. The projects that deliver real value are the ones that also handle the cases below. midPoint’s flexible policy engine and lifecycle state model make these tractable rather than exceptional.

Rehires

An employee leaves in March and returns in September. Do they get a new identity or reactivation of the old one? If the old identity is reactivated, which access rights are restored – the ones they had when they left, or the ones appropriate for their new position?

midPoint handles rehires through focal object preservation. The identity record is retained in a suspended lifecycle state. When the HR system creates a new record that matches the old identity (by employee ID, national ID, or correlation rules), midPoint reactivates the existing identity rather than creating a duplicate. Role assignments are re-evaluated based on the new position, not the old one. Audit history is preserved continuously.

Contractors and external users

Contractors do not exist in the HR system. They have no HR joiner event, no department code, and no automatic termination date. They are typically onboarded through a request from the sponsoring manager and have a fixed contract end date.

midPoint manages external identities through separate lifecycle policies. A contractor identity requires a sponsoring owner (a human employee), a defined end date, and periodic recertification. When the contract end date arrives, midPoint deactivates the identity automatically. When the sponsoring owner leaves the organization, midPoint flags the contractor identity for ownership reassignment or deactivation.

Parental leave and long-term absence

An employee on parental leave should not have their identity deleted. But should they retain active access to production systems for twelve months while they are away?

midPoint’s lifecycle state model supports suspension states that deactivate accounts without revoking role assignments. When the employee returns, reactivation restores their previous access profile without requiring a new provisioning cycle. If their role or department changed during the absence (restructuring, for example), the reconciliation engine adjusts automatically.

Multiple simultaneous positions

In universities, hospitals, and research organizations, a single person may hold multiple positions simultaneously: a professor who is also a department head and a research project lead. Each position carries different access requirements.

midPoint supports multiple assignments per identity. Each assignment can carry its own role set, validity period, and organizational context. The identity’s effective access is the union of all active assignments, evaluated against SoD policies to prevent conflicts.

Mergers and organizational restructuring

When two departments merge, or a company acquires another, the organizational structure changes for hundreds or thousands of identities simultaneously. Manual re-provisioning at this scale is not feasible.

midPoint’s policy-driven approach handles restructuring by updating organizational unit mappings. When the org structure changes in the HR system, midPoint re-evaluates every affected identity against the new structure and adjusts role assignments accordingly. The process is audited, reversible, and can be simulated before execution.

The implementation approach that works

Evolveum’s methodology for JML deployment follows a three-phase pattern: Connect, Cleanup, Automate. This sequence matters because automating on top of dirty data produces automated garbage.

Phase 1: Connect (weeks 1–4)

Connect midPoint to the HR system and target systems. Pull identity data. Pull account data. Do not automate anything yet. The goal is visibility: how many identities exist in the HR system, how many accounts exist in each target system, and how do they correlate?

midPoint’s smart correlation engine matches identities across systems even with inconsistent naming, missing fields, or transliteration differences. The output is a map of your actual identity landscape – including orphan accounts, duplicate identities, and accounts with no HR match.

Phase 2: Cleanup (weeks 3–6)

Before automating lifecycle events, clean the data. Assign owners to orphan accounts. Resolve duplicate identities. Remove accounts that belong to people who left years ago. Align role definitions with actual access patterns using midPoint’s role mining capabilities.

This phase is where most of the hard decisions happen. It is also where the most immediate security value is delivered – before any automation is turned on, you have already closed the orphan-account gap.

Phase 3: Automate (weeks 5–12)

With clean data and validated correlation, enable automated provisioning. Start with joiners (lowest risk – new accounts, no existing data to corrupt). Move to leavers (high security value – automated deprovisioning closes the biggest governance gap). Finish with movers (highest complexity – requires validated role models and SoD policies).

Each automation step runs in simulation mode first. midPoint evaluates what the automation would do against production data without executing changes. You review the results, adjust policies, and enable execution only when the simulation matches expectations.

The measurable impact

Organizations that implement JML automation with an IGA platform report consistent improvements across security, efficiency, and compliance metrics:

  • Provisioning time reduced by 73%, from days to hours or minutes
  • Deprovisioning time reduced significantly, from weeks to minutes
  • Identity-related security incidents reduced by over 67%
  • Audit pass rates exceeding 95% for SOC 2 and ISO 27001
  • Helpdesk ticket volume for access requests reduced by 40–60%
  • Privilege creep incidents reduced through automated mover re-evaluation

The ROI is not theoretical. Forrester’s 2025 Total Economic Impact study of enterprise IGA automation (commissioned by Saviynt, but representative of IGA-class automation outcomes) measured 269% ROI with payback under nine months, including 577,000 hours saved on manual provisioning and access reviews. The specific numbers will vary by platform and environment, but the order of magnitude is consistent across IGA implementations.

Start your JML automation project

WeKnowIdentity has delivered 10+ enterprise midPoint deployments managing up to 1,000,000+ identities across telecom, finance, government, healthcare, education, and technology sectors. Our team holds four Evolveum midPoint certifications and has hands-on experience with JML automation projects ranging from single-HR-source deployments to complex multi-source, multi-country environments.

If your onboarding still involves helpdesk tickets, your offboarding still takes more than a day, and your movers still accumulate privileges from every role they have ever held – those are the gaps that JML automation closes first.

Book a free JML assessment

Related Resources

Sources

AI-Powered Identity Attacks: Why Identity Governance Is Your Best Defense

by CompliancemidPoint Tips

AI has not changed what attackers want. They still want credentials, access, and data. What AI has changed is how fast and how convincingly they get them. CrowdStrike’s 2026 Global Threat Report recorded an 89% increase in attacks by AI-enabled adversaries. Deepfake fraud losses hit $1.65 billion in a single year. 82% of CrowdStrike’s 2025 detections were malware-free – attackers logging in, not breaking in.

The security industry has responded with better endpoint detection, smarter email filters, and AI-powered threat intelligence. These are necessary. But none of them address the core problem: once an attacker has valid credentials – stolen, phished, or deepfaked past your verification – your perimeter defenses have already lost.

That is where identity governance picks up. Not as a replacement for detection, but as the control layer that limits what stolen credentials can actually reach.

The numbers behind the shift

The scale of AI-assisted identity attacks in 2025-2026 is not incremental. It is a category change.

Phishing has become AI-native. The FBI’s 2025 IC3 report recorded a 37% rise in AI-assisted business email compromise. Hoxhunt’s Phishing Trends Report found that 40% of BEC emails in Q2 2025 were AI-generated. Vishing – voice phishing – grew 442% between the first and second half of 2024, according to CrowdStrike and Pindrop.

Deepfakes have moved from novelty to operational weapon. Surfshark’s 2026 research tracked $2.19 billion in global deepfake fraud losses from January 2019 to March 2026, with $1.65 billion of that concentrated in 2025 alone. Pindrop recorded a 1,300% year-over-year rise in deepfake fraud attempts in contact centers. 62% of organizations surveyed by Gartner in September 2025 reported experiencing at least one deepfake attack in the prior twelve months.

Credential abuse remains the dominant breach vector. The Verizon 2026 DBIR found credential abuse present in 39% of full breach chains – the single most pervasive technique. IBM’s 2025 Cost of a Data Breach report measured breaches via compromised credentials at $4.67 million average cost, taking 246 days to identify and contain. CrowdStrike’s 2026 Global Threat Report noted an 89% increase in attacks by AI-enabled adversaries.

The speed has changed. CrowdStrike recorded the fastest eCrime breakout time at 27 seconds. Average breakout speed increased 65% year-over-year. When an attacker moves from initial access to lateral movement in under a minute, manual response processes are irrelevant.

Why better authentication is not enough

The instinctive response to credential-based attacks is stronger authentication: phishing-resistant MFA, passkeys, biometric verification. These are necessary. They are not sufficient.

Authentication answers one question: “Is this person who they claim to be at the moment of login?” It does not answer the questions that matter after authentication succeeds:

  • Should this person still have access to this system?
  • Does this access make sense given their current role?
  • Has anyone reviewed whether these privileges are still appropriate?
  • Is this combination of access rights creating a segregation-of-duties violation?
  • Would revoking this access, right now, take minutes or weeks?

These are identity governance questions. And for most organizations, the honest answer to each of them is “we don’t know” or “it depends on someone remembering to check.”

The real incidents tell the same story

The pattern in recent AI-assisted breaches is remarkably consistent. The attacker does not need a zero-day. They need a credential that nobody governs.

Arup, February 2024. A finance worker in Hong Kong joined a video call with colleagues including the company CFO. Every other participant on the call was an AI-generated deepfake. The worker authorized $25 million in transfers before the fraud was discovered.

Microsoft / Midnight Blizzard, January 2024. The Russian state-sponsored group password-sprayed into a legacy test account that had been left with elevated standing privileges to Microsoft’s corporate environment. They accessed email accounts of senior leadership and the cybersecurity team. The test account had no business need for those privileges. Nobody had reviewed it.

Snowflake customers, May 2024. Attackers used credentials stolen by infostealer malware to access approximately 165 customer tenants. No backdoors, no exploits. The accounts lacked MFA and had persistent standing access. Ticketmaster, Santander, and dozens more were affected.

Rakuten Mobile, February 2025. Three teenagers with no coding background used ChatGPT to build an attack tool that hit systems approximately 220,000 times. The barrier to entry for identity-based attacks has collapsed.

In every case, the governance gap was the same: credentials existed with excessive privileges, nobody was reviewing whether the access was still appropriate, and revocation processes were too slow to matter.

What identity governance actually defends

Identity governance does not stop phishing emails from arriving. It does not detect deepfakes. What it does is ensure that when an attacker succeeds in stealing or faking a credential, the damage they can do is constrained, detectable, and reversible.

Least privilege enforcement

The most direct defense against credential compromise is ensuring that every identity – human or machine – has only the access it currently needs. Not the access it needed six months ago. Not the access its predecessor in the role had. The access required by its current job function, right now.

midPoint enforces least privilege through automated role assignment based on HR data. When someone changes departments, their old access is revoked and new access is granted automatically. There is no accumulation of stale privileges, no “just in case” access lingering from a previous project.

Continuous access certification

Periodic access reviews catch the privileges that automated rules miss. midPoint runs access certification campaigns where managers and application owners verify that each identity’s access is still appropriate. Unreviewed items escalate automatically. Rejected access is revoked through automated provisioning, not a ticket queue.

This directly addresses the Snowflake and Microsoft breach patterns. Those dormant accounts with excessive privileges would have been flagged and revoked in the next certification cycle – or immediately, if event-triggered certification was configured for high-risk access.

Segregation of duties enforcement

AI-powered social engineering often targets finance and administrative functions where a single compromised identity can authorize transactions. midPoint’s SoD engine prevents toxic role combinations in real time. A user cannot simultaneously hold “create payment” and “approve payment” entitlements. An identity that acquires both – through any mechanism – triggers an automatic policy violation.

Outlier detection

When an attacker uses compromised credentials to request additional access or move laterally, their behavior creates anomalies in the identity data. midPoint’s outlier detection flags identities whose role assignments deviate from peers in the same organizational unit, job function, or archetype. An account that suddenly holds access to systems outside its normal scope surfaces as an outlier – even if every individual access grant was technically approved.

Rapid deprovisioning

When a breach is detected, the speed of access revocation determines the blast radius. Organizations using midPoint can revoke all access for a compromised identity across every connected system within minutes, not the days or weeks that manual processes require. IBM’s research shows that breaches involving compromised credentials take an average of 246 days to identify and contain. Automated deprovisioning compresses the “contain” portion to near zero.

Non-human identity governance

AI agents, service accounts, and API keys are increasingly targeted because they typically have broader access and weaker governance than human users. midPoint governs non-human identities with the same lifecycle controls as human identities. For a deep dive on this topic, see our article on Non-Human Identity Governance in midPoint.

The governance gap is measurable

IBM’s 2025 Cost of a Data Breach report found that organizations using extensive security AI and automation saved $1.9 million per breach compared to those that did not. But the report also found that 97% of organizations that experienced AI-related security incidents lacked proper AI access controls, and 63% lacked AI governance policies entirely.

The gap is not a technology gap. It is a governance gap. The controls exist. They are not deployed.

Gartner’s 2026 cybersecurity predictions explicitly recommend fortifying identities – both human and machine – with strong lifecycle controls as a top defense priority. Not as a nice-to-have compliance exercise, but as the primary control against credential-based attacks that now dominate the threat landscape.

What this means for your IGA program

If your identity governance program was designed primarily for compliance – annual access reviews, basic role assignments, audit log generation – it is not configured for an AI-powered threat environment. The difference between a compliance-oriented IGA deployment and a security-oriented one is:

Certification frequency. Annual reviews miss too much. High-risk access should be certified quarterly or on every change. midPoint supports both scheduled and event-triggered certification campaigns.

Scope. If your certifications cover human users but not service accounts, API keys, and AI agents, you are certifying the minority of your identity population. midPoint governs all identity types through the same framework.

Automation depth. If access revocation requires a helpdesk ticket, you cannot respond to a breach in the timeframe that matters. midPoint’s provisioning engine executes revocation automatically on certification decisions, policy violations, and lifecycle events.

SoD coverage. If segregation-of-duties checks only run at request time but not continuously, privilege accumulation creates exploitable gaps. midPoint evaluates SoD policies continuously across all role assignments.

Outlier visibility. If you cannot identify which identities hold access that deviates from their peers, you cannot detect lateral movement through compromised credentials. midPoint’s outlier detection makes this visible without manual analysis.

Start closing the governance gap

AI has made credential-based attacks faster, cheaper, and more convincing. The organizations that will weather this shift are not the ones with the best email filters. They are the ones where a stolen credential grants the minimum access required, where that access is reviewed regularly, where anomalies are detected automatically, and where revocation happens in minutes.

WeKnowIdentity helps organizations configure midPoint’s governance engine for security, not just compliance. That includes least-privilege role modeling, continuous certification campaigns, SoD policy design, outlier detection activation, and non-human identity governance. If your IGA program was built for auditors but not for attackers, that is the gap we close.

Book a free governance assessment

Related Resources

Sources

Entra ID Governance vs midPoint: A Practical Comparison

by CompliancemidPoint Tips

Microsoft Entra ID Governance is the default identity governance option for organizations deep in the Microsoft ecosystem. It is cloud-native, tightly integrated with M365 and Azure, and available as an add-on to the Entra ID licenses most enterprises already hold. For pure Microsoft environments, it works.

The question is what happens when your environment is not purely Microsoft.

Most enterprises are not. They run SAP alongside Azure. Oracle databases alongside SharePoint. Custom HR systems alongside Workday. On-premises Active Directory alongside Entra ID. Legacy LDAP directories that predate their cloud migration. And increasingly, Keycloak for application-level authentication and federation that sits outside Microsoft’s reach.

That is where Entra ID Governance’s scope ends and the governance gap begins. This article compares Microsoft Entra ID Governance with Evolveum midPoint – not to declare a winner, but to help you understand which platform governs what, where the gaps are, and how they work together in the hybrid reality most enterprises actually operate in.

DORA Compliance: How midPoint Meets Identity Governance Requirements

by Compliance

The Digital Operational Resilience Act (DORA) has been fully enforceable since January 2025. In 2026, European supervisors moved from readiness checks to active enforcement. If your financial institution still treats identity governance as an IT project rather than a regulatory obligation, the gap between your policies and your evidence is where the examiner will start.

DORA applies to more than 22,000 financial entities across the EU – banks, insurers, investment firms, payment providers, crypto-asset service providers, and their critical ICT third-party providers. Its identity and access requirements are not vague best practices. They are specific, article-level legal obligations with penalties reaching 2% of global annual turnover and up to EUR 1 million in personal fines for senior management.

Here is what DORA actually requires for identity governance, where most organizations are falling short, and how midPoint addresses each requirement.

Non-Human Identity Governance in midPoint: Closing the 109-to-1 Gap

by CompliancemidPoint Tips

Service accounts, API keys, RPA bots, and AI agents now outnumber human users in the average enterprise by 109 to 1. Most IGA programs barely see them. Here is what that gap looks like, why it matters for your 2026 security posture, and how midPoint treats non-human identities (NHIs) as first-class identities you can actually govern.

The numbers most IGA programs would rather not look at

Palo Alto Networks publishes the 2026 Identity Security Landscape Report, which puts the average ratio of machine identities to human identities at 109 to 1. Rubrik Zero Labs measures the ratio at 45 to 1 in traditional enterprises, rising to 82 to 1 in their most recent Identity Crisis study. Some hyper-automated, cloud-native organizations report ratios closer to 500 to 1.

In absolute terms, the average enterprise now manages over 250,000 non-human identities across its cloud and on-premise estate. That includes:

  • Service accounts on Active Directory, Linux, databases, and middleware
  • API keys, OAuth tokens, and personal access tokens
  • Workload identities (containers, serverless functions, virtual machines)
  • CI/CD pipeline credentials
  • RPA bots
  • Machine-to-machine (M2M) certificates
  • AI agents and copilots, the fastest-growing category, projected to grow 85% over the next 12 months

The governance posture, when measured, is uncomfortable:

  • 97% of NHIs carry privileges beyond what their function requires
  • 71% have not been rotated within the recommended timeframe
  • 68% of identity-related security incidents now involve a machine identity
  • Only 15% of organizations report high confidence in their ability to prevent NHI-based attacks

This is the gap, and it is not a future problem.

What recent breaches tell us

The 2024 and 2025 breach record reads like an NHI governance manual written backwards.

  • BeyondTrust (December 2024). A compromised API key was paired with a command-injection bug to gain unauthenticated remote code execution on customer instances of its Remote Support SaaS.
  • Snowflake customers (May 2024). Stolen credentials for non-MFA-protected service accounts gave attackers data from Ticketmaster, Santander, and dozens more.
  • Dropbox Sign (May 2024). A compromised backend service account opened the customer database, exposing emails, API keys, and OAuth tokens.
  • Schneider Electric (November 2024). Exposed Jira credentials let attackers exfiltrate 40 GB of internal project data.
  • AWS “Codefinger” campaign (January 2025). Ransomware operators used compromised AWS keys plus customer-provided-key encryption to lock S3 buckets.
  • DeepSeek (January 2025). Over one million log lines and sensitive secret keys exposed via an unsecured database.

The pattern is consistent. The attacker rarely needed a zero-day. They needed a credential that nobody owned, nobody reviewed, and nobody had rotated. NHIs.

Why traditional IGA misses non-human identities

Most IGA programs were built around employees: hire date, manager, department, role, leaver event. The data model and the workflows assume a human owner and a human lifecycle. That assumption breaks for NHIs in four ways:

1. No HR feed. A service account does not appear in Workday. There is no source of truth and no “joiner” event.

2. No clear owner. A bot created three years ago by a contractor who has since left has no human attached to it. Ownership rots.

3. No leaver. When the application that created the account is decommissioned, the NHI is rarely cleaned up. Orphan accounts accumulate.

4. No certification. Even where access reviews exist, certifiers either skip service accounts (“don’t touch, it’ll break production”) or rubber-stamp them.

The result is a population larger than your workforce, growing faster than your workforce, with weaker governance than your workforce. Gartner’s 2026 IAM track captured the same observation. Many organizations are still in a basic discovery phase for NHIs, inventorying what exists, assigning ownership, and understanding exposure before any meaningful policy work can begin.

How midPoint governs non-human identities

midPoint was designed around a generic identity object model rather than a fixed “user” type. That distinction matters more for NHIs than for any other category. In midPoint, a service account, an RPA bot, and an AI agent are governed using the same primitives as a human identity (roles, archetypes, policies, approvals, certifications, audit, outlier detection), but with object types, lifecycle rules, and ownership models tuned to non-human reality.

Here is what that looks like in practice.

First-class object model with archetypes

midPoint’s archetype mechanism lets you define distinct identity types such as service-account, rpa-bot, ci-cd-credential, and ai-agent. Each archetype carries its own:

  • Required attributes (purpose, system, owner, expiry, risk tier)
  • Lifecycle states and transitions
  • Approval policies for creation and privilege change
  • Certification cadence
  • Default role assignments via inducement

This is what makes governance possible. An ai-agent archetype can require an explicit human owner, a 90-day certification cycle, and an attestation that the agent’s tool list has been reviewed, automatically on every change.

Joiner-Mover-Leaver, adapted for machines

midPoint extends its JML processes to NHIs with a critical addition: human-dependency triggers. When the responsible person for a service account leaves the organization, midPoint can:

  • Re-route ownership to the leaver’s manager
  • Suspend the account if no owner is reassigned within an SLA
  • Trigger an immediate access review
  • Decommission the account when the underlying application is retired

This closes the orphan-account loop that most NHI breaches exploit.

Role-based and policy-based access for machines

Service accounts get the same RBAC discipline as users. Roles can be:

  • Birthright for a given archetype. An ai-agent may always get logging and observability access.
  • Conditional on attributes. Only agents deployed in production get database read access.
  • Approval-gated for anything sensitive. Write access to a financial system requires the data owner’s sign-off.

Segregation-of-duties checks apply equally. A bot cannot simultaneously hold “create payment” and “approve payment” entitlements without raising a policy violation.

Certifications that cover the whole identity population

midPoint’s access certification campaigns can target NHIs as their own scope. The certifier sees the account, the owner, the assigned roles, the last-used timestamp (when fed from the target system), and the risk tier. Decisions such as keep, revoke, or reassign owner flow back as automated provisioning actions, not Jira tickets.

This is where the “97% over-privileged” statistic finally gets addressable.

Outlier detection for the population you cannot eyeball

When you are governing 250,000 identities, the human eye cannot find the bad one. midPoint’s outlier detection flags accounts whose role assignments deviate from peers in the same archetype, owner group, or organizational unit. That surfaces the rogue bot which has accumulated production write access nobody approved.

Integration with secrets vaults and PAM

midPoint is the governance layer, not the secret store. The pattern that works in production is:

  • midPoint owns the lifecycle, ownership, role assignments, certifications, and audit.
  • A vault (HashiCorp Vault, CyberArk Conjur, AWS Secrets Manager, Azure Key Vault) owns the credential material, rotation, and short-lived issuance.
  • ConnId connectors wire midPoint to the vault, so that creating a service account in midPoint provisions both the identity record and the vault entry, and decommissioning cleans both sides.

This separation means rotation, ephemerality, and policy enforcement live where they belong, while governance, ownership, and audit live in midPoint.

AI agents as a governed identity class

The fastest-growing NHI category is also the least governed. midPoint’s archetype model makes AI agents tractable:

  • Each agent gets a human owner and a documented purpose
  • The agent’s tool list and target systems are modeled as role assignments
  • Privilege escalation requires the same approval flow as a human role request
  • Periodic certifications attest that the agent still needs every entitlement it holds
  • Decommissioning the agent’s owning application triggers automatic clean-up

Gartner predicts that by 2028, at least 15% of daily workplace decisions will be made by AI agents. Each of those decisions traces back to an NHI with access to data. Governing that population the same way you govern people is not optional. It is the only model that survives audit.

A reference blueprint: NHIs in midPoint

For a typical enterprise starting from a midPoint baseline, the working blueprint is:

1. Discovery and inventory. Use midPoint’s resource shadows to pull every service account from Active Directory, Linux, databases, cloud IAM, and SaaS admin consoles. Tag each with its source system.

2. Archetype design. Define service-account, rpa-bot, ci-cd-credential, workload-identity, and ai-agent. Set required attributes and risk tiers.

3. Ownership assignment. Bulk-assign owners from application catalogues, CMDB, or where nothing exists, to the department head responsible for the target system. Make ownership mandatory.

4. Role modeling. Define birthright roles per archetype. Move ad-hoc entitlements into named roles. Apply SoD policies.

5. Vault integration. Connect the credential store. Wire creation, rotation, and revocation events both ways.

6. Certifications and outlier detection. Schedule NHI-specific campaigns. Turn on outlier detection. Make remediation automated, not a ticket queue.

7. Decommissioning rules. Build the JML triggers for application retirement and owner departure. Rehearse them.

Most organizations can stand up steps 1 to 4 within a single quarter on top of an existing midPoint instance. Vault integration and certifications follow in the next cycle.

Common mistakes to avoid

  • Treating NHIs as a discovery problem only. Inventory without governance is a spreadsheet that rots.
  • Building a separate “NHI platform.” A parallel system means parallel ownership, parallel audit, and parallel cost. midPoint already has the primitives.
  • Excluding service accounts from certification campaigns. This is the single most common audit finding.
  • Letting application teams self-manage their bots’ privileges without policy. That is how the 97-percent-over-privileged number was earned.
  • Treating AI agents as “just an integration” instead of an identity. They are identities. They have entitlements. They need owners.

The bottom line

Non-human identities are not a niche category any more. They are the majority of your identity population, they are the majority of identity-related incidents, and they are growing faster than your headcount ever will. The NHI access management market itself is forecast to grow from USD 9.45 billion in 2024 to USD 18.71 billion in 2030, at an 11.9% CAGR. That is the market following a problem that already exists, not creating one.

The good news is that midPoint does not require a new product, a new vendor, or a new program to govern this population. It requires the same IGA discipline you already apply to your workforce, extended to the identities that now outnumber them by 109 to 1.

Start your NHI governance journey

WeKnowIdentity helps organizations extend midPoint’s governance model to the full non-human identity population. That includes archetypes, lifecycle automation, certifications, vault integration, and AI-agent onboarding. If your midPoint deployment governs your workforce but not your service accounts, bots, and AI agents, that is the gap where your next incident will land.

Book a free NHI governance assessment

Related Resources

Sources

Microsoft Identity Manager (MIM) End of Support: Your Migration Options

by

Microsoft Identity Manager (MIM) extended support runs until January 2029. If your organization still relies on MIM for identity provisioning, now is the time to plan your next move.

MIM has served enterprises well for over a decade. But Microsoft has made it clear: MIM’s future is limited. The platform receives only security patches, no new features, and its architecture is fundamentally tied to on-premises Active Directory in an era where hybrid and cloud-first identity is the standard.

What happens after MIM?

Microsoft’s own recommendation is Microsoft Entra ID Governance for cloud-native organizations. But for enterprises with complex on-premises infrastructure, hybrid AD environments, and custom provisioning workflows, Entra ID Governance alone may not cover all use cases.

This is where open-source alternatives like Evolveum midPoint become compelling.

Why midPoint is a strong alternative

  • Full lifecycle management: joiner, mover, leaver automation with HR integration, just like MIM but without the deprecated architecture
  • ConnId connector framework: midPoint connects to the same targets MIM does: Active Directory, LDAP, databases, REST APIs, SOAP services, CSV feeds, and SCIM endpoints
  • No per-user licensing: midPoint is open source. You pay for implementation and support, not per-identity fees that scale with your organization
  • Modern deployment: runs natively on Kubernetes with GitOps-based configuration management, Helm charts, and full CI/CD pipeline support
  • Built-in governance: role-based access control, access certification campaigns, segregation of duties, and audit-ready compliance reporting for GDPR, NIS2, and ISO 27001

Planning the migration

A MIM to midPoint migration typically involves these phases:

1. Assessment: Map your current MIM configuration: management agents, sync rules, provisioning workflows, and custom extensions. Identify which connectors and business logic need to be replicated.

2. Architecture design: Define the midPoint deployment model (Kubernetes, Docker, or bare metal), HR source of truth integration, and connector architecture.

3. Connector development: Build midPoint ConnId connectors for each target system. Many standard connectors (AD, LDAP, database, CSV) are available out of the box.

4. Parallel operation: Run MIM and midPoint side by side during the transition period. Validate identity data consistency across both systems.

5. Cutover: Switch production traffic to midPoint with zero downtime. Decommission MIM.

The cost of waiting

January 2029 sounds far away, but enterprise identity migrations are complex projects. A typical migration takes 6 to 12 months depending on the number of connected systems and custom business logic. Starting in 2026 gives you comfortable runway. Starting in 2028 means rushing, cutting corners, and accepting risk.

Our experience with MIM migrations

At WeKnowIdentity, we have delivered 10+ enterprise midPoint deployments managing up to 1,000,000+ identities. Our founder holds four Evolveum midPoint certifications (Professional, Advanced, Deployment, Group Synchronization) and has hands-on experience with MIM migration projects.

We work across telecom, finance, government, healthcare, education, and technology sectors in Slovakia, Switzerland, Germany, Austria, and Poland.

Ready to plan your migration?

Contact us for a free initial assessment. We will evaluate your current MIM setup, map the migration path, and provide a realistic timeline and roadmap to midPoint.

Related Resources

Related: For a comprehensive side-by-side analysis of open source and commercial IGA platforms, read our full guide: midPoint vs Commercial IGA: Which Approach Fits Your Enterprise?