Once a vulnerability gets its own name, it is very obvious that the impact is serious. However, this is perhaps quite an understatement in case of PHP2Shell. PHP2Shell is a set of two vulnerabilities (CVE-2026-109618 and CVE-2026-109619) allowing unauthenticated attackers to remotely execute arbitrary code on servers that use PHP for serving web pages. This is pretty much as bad as it gets. However, it is still not the whole picture of PHP2Shell. As this vulnerability was hidden in PHP codebase for years, pretty much every PHP version currently in use is vulnerable. PHP is an old language, it was proclaimed to be dead several times already. However, it is still very popular. This means that almost every organization connected to the Internet is affected by PHP2Shell in one way or another.

Naturally, Evolveum is affected too. Our company web page is running on PHP as well as several other applications. However, midPoint itself is not affected at all. MidPoint is written primarily in Java, using JavaScript in user interface, and Python which is used for supporting services. There is no PHP in midPoint. Even our PHP applications are not directly involved in midPoint, its development, build and testing. We are sure that midPoint is safe from PHP2Shell.

We have been very busy since the very moment we have learned about PHP2Shell, patching and updating, testing, checking and re-checking. PHP2Shell is such a serious threat that some follow-up work is still ongoing, and will be ongoing for some time. The echoes of PHP2Shell will be reverberating through the Internet for a long time.

This is a painful lesson to all of us, even though it teaches us what we all were supposed to know already: Any software which cannot be readily updated on a very short notice is an unacceptable security risk. It always was, but it just got a lot worse. Make sure all your software is running on supported version, that you have process in place to quickly update it, and that the process works. This is still important if you are using software as a service (SaaS) – perhaps even doubly so in such situation as SaaS providers are prime targets for attackers. Make sure your provider have appropriate mechanisms in place.

PHP2Shell is not an isolated problem. Contemporary software is a huge cauldron of code, libraries, platforms, dependencies, tools, and devices. More severe problems are hiding in the dark corners of the software labyrinth, waiting to be exploited. Brace yourself, and have your incident response process ready. It will be needed. Again and again.

The post MidPoint is Not Vulnerable to PHP2Shell appeared first on Evolveum | Open Source Identity Management & Governance.

And that’s just the beginning. Let’s take a closer look at what’s new in midPoint 4.11.

Rapid Application Onboarding with MidPilot

MidPoint 4.11 introduces new AI-assisted features that help accelerate application onboarding, from developing a connector to configuring the resource.

MidPilot Connector Generator

Every integration starts with a way to connect the application. If you don’t find a suitable connector in our new MidPoint Integration Catalog, you can develop it directly in midPoint using our low-code framework with midPilot’s AI assistance and step-by-step guidance through the user interface. Each step is easy to understand, and midPoint even lets you test the functionality simply by clicking a button.

MidPilot Smart Recommendations

It doesn’t end with the connector. Once you have it installed, you need to configure the resource’s mappings, correlations, and associations. This can be quite time-consuming for users new to midPoint, and we address this concern with midPilot – with a click of a button you can generate suggestions for all those settings.

You remain in control of what information is shared with the LLM. For each suggestion, you can choose which data to provide, including real schemas and portions of actual data when you want more relevant results. You can also connect midPilot to your own in-house LLM. MidPilot provides guidance, but it never changes your configuration without your explicit confirmation.

ITSM Ticketing for Manual Resources

Manual resources rely on tickets to track the progress of provisioning operations that are executed manually by human operators. By default, these were managed internally by midPoint, and system administrators handled them in the midPoint GUI. With midPoint 4.11, we introduce “manual connectors”, allowing the provisioning tickets to be created in your favorite ITSM system and handled there.

MidPoint Integration Catalog

The MidPoint Integration Catalog is the one place where you can find all the information needed to onboard a new application to midPoint. It was designed to be a community-driven hub where you can discover connectors, how-to guides, sample files, configuration snippets, tutorials, and other resources that help you connect applications and configure them in midPoint.

Security Improvements

Safe Scripting Language – MidPoint Expression Language (MEL)

The introduction of the MidPoint Expression Language (MEL) is a major step towards securing midPoint by design. Our vision is to provide a strictly controlled, safe alternative to existing scripting languages. This allows administrators to write necessary expressions while keeping the core system completely isolated from malicious or accidental exploits, significantly minimizing security risks.

TOTP: Two-Factor Authentication for MidPoint Itself

We added a new module for multifactor authentication (MFA) in midPoint 4.11, specifically the Time-based One-Time Password (TOTP) module. This allows administrators to strengthen the protection of midPoint user accounts by requiring an additional authentication factor. As MFA becomes an increasingly important security measure for critical systems, this provides another way to protect access to midPoint itself, even in deployments where MFA is not implemented on the access management level.

MidPoint Studio

With the midPoint 4.11 release, we’re introducing an updated MidPoint Studio plugin for IntelliJ IDEA with AI-assisted workflows. The plugin contains specific actions for object type suggestions, correlation rule suggestions, mapping suggestions, and association suggestions, together with shared infrastructure for launching these workflows through dialogs, wizards, and a dedicated smart-suggestion tool window.

Try MidPoint 4.11 Today

MidPoint 4.11 is available now! Alongside the new features and improvements, the release includes bug fixes, so we recommend upgrading to the latest version.

Try midPoint

And More

MidPoint 4.11 also brings a host of smaller improvements, including:

• • Accessibility improvements – MidPoint is easier to use for everyone, and we are proud to announce our ongoing full compliance with the WCAG 2.2 Level AA.
  • Focus-based policies for task activity – Focus-based policies can now be configured and evaluated per activity. Read more here.
  • Multi-tab browser support – Improves the use of multiple tabs or windows in the web browser while maintaining a consistent experience across all of them.

Ready to explore what’s new?

• Read the full release notes.
• Have questions or need help with an advanced use case? Contact us — we’d love to hear from you.

The post Introducing MidPoint 4.11: AI-Assisted Onboarding, Stronger Security, and More appeared first on Evolveum | Open Source Identity Management & Governance.

About Unicon, Inc.:

Unicon, Inc. is a leading provider of IT consulting, services, and support for education technology and works with institutions and organizations to find solutions to meet business challenges. Unicon specializes in using open source technologies to deliver flexible and cost-effective systems for identity and access management (IAM). The company provides services for open source projects including midPoint, Central Authentication Service (CAS), Shibboleth, Grouper, and SimpleSAMLphp on-prem or in the cloud.

Higher education environments are notoriously complex when it comes to identity governance. The IT landscape must seamlessly accommodate multi-affiliation, multiple source systems, flexible authentication, access grace periods, and immense scalability. In this implementation story written by our partner Unicon Inc., we examine a large public university serving over 80,000 active students, 20,000 staff members, and hundreds of thousands of alumni. The university managed identities across a highly fragmented ecosystem: a primary HR system for faculty and staff, a separate Student Information System (SIS) for enrolled learners, an applicant system, and an independent CRM platform for alumni and continuing education. This is a simpler example as many institutions contain more source-of-truth systems, but the methodology scales.

Challenge: Managing Identity Data Across Multiple Source Systems

The core operational challenge centered on aggregating and harmonizing multiple source systems. While connecting APIs and external systems is straightforward, the business logic required to unify distinct identity silos introduces complications. Several distinct hurdles emerged:

• Attribute duplication and determining the “winner”: A user might exist simultaneously in the HR system (as a researcher) and the SIS (as a graduate student). The university needed a robust strategy to organize attributes for downstream use and determine which system’s data (such as preferred name or contact information) should “win” in the event of a conflict.
• Correlation and deduplication: When a former undergraduate returns years later as an employee or a continuous learner, their records must seamlessly merge. Failing to correlate identities reliably results in duplicate active accounts, fragmented access histories, and licensing bloat in downstream applications.
• Marrying logical identifiers with rules: Many universities historically utilized various scripts, manual processes and other rules to set identifiers and other information. Preserving these rules while planning for inevitable future expansion without breaking existing downstream dependencies is always critical.
• Record consistency and availability: With multiple systems pushing updates at different intervals (nightly HR batches versus real-time SIS event triggers), ensuring record consistency and high availability of the most current identity state is paramount. Underlying this is the need to thoroughly understand the data within the source-of-truth systems themselves. When does it change? Is it possible to have duplicates per physical person or record? What pieces might be missing or unreliable? Essentially, implementers must validate their assumptions about any inbound data, and often it takes time (e.g., semester boundaries).

Building a Unified Identity Hub

To resolve these issues, midPoint was deployed as the authoritative identity hub, leveraging its advanced correlation rules, inbound mappings, and unified schema modeling. The approach required defining clear rules of engagement for how data flowed into the central vault.

Authoritative Sources and Attribute Mappings

Working with business stakeholders, the Unicon team established a strict matrix of authoritative sources and rules based on existing practices. By utilizing midPoint’s inbound mapping parameters, we categorized data feeds by strength (e.g., strong vs. weak mappings) to systematically pick the “winning” attributes.

Note that in many cases in higher education, you cannot always pick a winner solely by the source-of-truth system, although it is a good starting point. MidPoint supports this by easily allowing deployers to bring in all critical attributes via extension attributes (including simplifying via multi-value attributes) on identities. This enables the deployer to choose which attribute “wins” based on their specific logic, circumstances, or even the requirements of the downstream system.

Advanced Correlation Matrix

Most universities have scripts, legacy customizations or even high-effort manual processes to deduplicate identities. With midPoint and its Correlation functionality, we were able to replace rudimentary matching scripts with midPoint’s multi-tiered correlation strategies. The system evaluates incoming records sequentially:

1. Deterministic match: First, midPoint searches for an exact match on a globally unique identifier, such as a National ID or a previously stamped University ID.
2. High-confidence composite match: If a unique ID is absent, midPoint evaluates a composite key (e.g., Legal Name + Date of Birth + Email).
3. Fuzzy match and duplicate handling: If only a partial match is detected, midPoint marks the record, suspends automatic provisioning, and generates a workflow task for manual Identity Management review. This prevents the system from incorrectly merging distinct individuals (e.g., twins with similar names).

Note that this isn’t the only possibility; Unicon has assisted deployers with even more complex needs.

Implementing Identity Correlation and Lifecycle Automation

The technical implementation of marrying rule-based identifiers with midPoint’s native capabilities was challenging but rewarding. The university’s legacy system relied on procedural code to generate usernames (e.g., avoiding collisions by appending sequential numbers). This logic was successfully migrated into midPoint using native Groovy scripting within the user template. MidPoint now evaluates the identity vault dynamically, applies the legacy naming convention, checks for collisions in real time, and assigns the logical identifier without relying on external scripts.

Unicon also tackled record consistency by implementing delta synchronizations and LiveSync where supported. For the legacy HR system that could only export flat files, we scheduled frequent reconciliation tasks. midPoint’s robust caching and unified schema ensured that downstream applications (like Active Directory and Microsoft Entra ID) received highly organized, cleanly formatted attributes regardless of the sync intervals of the disparate upstream sources.

Overall, midPoint allowed them to manage identity data faster than their legacy systems and frameworks, reducing the time from account creation to actual downstream provisioning by days, and in some use cases, weeks.

The Result: Unified Identities and Fewer Duplicate Accounts

By centralizing their identity architecture with midPoint, the university achieved profound operational benefits:

• Unified identity profiles: The help desk now utilizes midPoint as a single pane of glass, viewing a unified focal identity that accurately represents a user’s combined HR, SIS, and CRM personas.
• Massive reduction in duplicate accounts: During the initial reconciliation, midPoint successfully deduplicated 15,000+ legacy records. Downstream systems were cleansed of bloat, significantly reducing licensing costs.
• Automated multi-affiliation lifecycle: When an active student gets hired as an employee, midPoint instantly correlates the new HR record to their existing student profile. It seamlessly updates their primary affiliation, preserving their email inbox while safely layering on new staff entitlements.

Lessons Learned

The most critical lesson from this deployment is that technical correlation rules and attribute rules are only as reliable as the underlying data quality and assumptions made about the source-of-truth systems. During testing, it was discovered that SIS allowed placeholder dates of birth (e.g., 01/01/1900), which severely disrupted correlation logic until remedied. MidPoint allows deployers to handle this in the inbound mapping or condition and to sanitize and ignore these placeholder values before correlation occurs. This is only one of the many “gotchas” that source systems can throw at IAM administrators. We recommend validating data and source system assumptions as early as possible.

Additionally, defining a “winning” attribute is fundamentally a business decision, not an IT/IAM decision. We highly recommend conducting IAM policy and data governance workshops early in the project (including as many relevant stakeholders as possible) to secure official sign-off on the attribute flow matrix and to surface non-documented “tribal” knowledge. The IAM policies, as well as the attribute and identity flows and rules, should be thoroughly documented. These will inevitably change over time, and having a clear picture is essential when making modifications to reduce ramifications. midPoint offers the flexibility to map anything anywhere, but establishing clear business ownership ensures the identity infrastructure remains scalable and maintainable over the long term.

Frequently Asked Questions

The post Taming the Chaos: Managing Multiple Source Systems and Identity Correlation in Higher Education appeared first on Evolveum | Open Source Identity Management & Governance.

As part of our ongoing commitment to the security and long-term development of midPoint, Evolveum has received funding from the EU to assess the current state of the product and our development processes against the CRA requirements. The project will help us identify areas for improvement and define concrete steps towards meeting the regulation’s requirements.

Assessing our readiness for the CRA

The project will begin with a detailed analysis of the CRA requirements and a gap analysis of midPoint and Evolveum’s existing processes. This will help us understand where our current practices already meet the requirements and where further measures may be needed.

We will also perform a cybersecurity risk assessment and identify specific features and process improvements to be considered for implementation in the midPoint 4.12 release. The findings will be brought together in a dedicated CRA action plan, providing a practical roadmap for addressing the identified gaps and preparing for the regulation’s requirements.

Putting midPoint under pressure

Part of our action plan is to conduct a penetration testing of the upcoming midPoint 4.11, including a testing performed by an independent third-party contractor. This will not be a one-and-done exercise – as we have done previously, we are committed to penetration testing subsequent major product versions every year before their release.

The goal is to simulate a cyberattack to identify vulnerabilities and uncover gaps that may not be apparent during the usual testing and development process. The results of the penetration testing will be made publicly available, reflecting our commitment to open standards and transparency. The findings will also feed directly into our ongoing security improvements and help us make each new version of midPoint more resiliant.

Building security into the product lifecycle

The CRA places greater emphasis on cybersecurity throughout the lifecycle of products with digital elements, including secure design and development, vulnerability handling, and ongoing security.

For Evolveum, this project is an opportunity to approach these requirements systematically: understand what the regulation requires, assess our current position, identify risks and gaps, and turn those findings into concrete improvements.
The project is supported through the TestCert-SK project (101127837), funded by the European Commission and Slovakia’s National Security Authority (NBÚ).

Security is not a one-time milestone, it is an ongoing part of developing and maintaining trusted identity governance software. This project is one step in the continuous process of strengthening the security and resilience of midPoint.

---

Posilňovanie bezpečnosti midPointu a príprava na Akt o kybernetickej odolnosti EÚ (CRA)

Akt o kybernetickej odolnosti EÚ (Cyber Resilience Act – CRA) už nadobudol účinnosť a stanovuje požiadavky na kybernetickú bezpečnosť produktov s digitálnymi prvkami. Hoci sa hlavné povinnosti vyplývajúce z CRA začnú uplatňovať od decembra 2027, organizácie, ktoré vyvíjajú a udržiavajú softvérové produkty, by sa na ne mali začať pripravovať s dostatočným predstihom.

V rámci nášho dlhodobého záväzku k bezpečnosti a ďalšiemu rozvoju midPointu získala spoločnosť Evolveum finančnú podporu od EÚ na posúdenie súčasného stavu produktu a našich vývojových procesov z hľadiska požiadaviek CRA. Projekt nám pomôže identifikovať oblasti, v ktorých je priestor na zlepšenie a stanoviť konkrétne kroky smerujúce k splneniu požiadaviek tejto regulácie.

Posúdenie našej pripravenosti na CRA

Projekt sa začne podrobnou analýzou požiadaviek CRA a analýzou rozdielov medzi týmito požiadavkami a existujúcim stavom midPointu a procesov v spoločnosti Evolveum. To nám pomôže zistiť, v ktorých oblastiach naše súčasné postupy požiadavky už spĺňajú a kde bude potrebné prijať ďalšie opatrenia.

Zároveň vykonáme hodnotenie kybernetických rizík a identifikujeme konkrétne funkcie a možnosti zlepšenia procesov, ktoré by bolo vhodné zvážiť na implementáciu v rámci vydania midPointu 4.12. Výsledky spojíme do samostatného akčného plánu pre CRA, ktorý poskytne praktický návrh ďalšieho postupu pri riešení identifikovaných nedostatkov a príprave na požiadavky tejto regulácie.

Bezpečnosť ako súčasť životného cyklu produktu

CRA kladie väčší dôraz na kybernetickú bezpečnosť počas celého životného cyklu produktov s digitálnymi prvkami vrátane bezpečného návrhu a vývoja, riešenia zraniteľností a priebežného zabezpečovania produktu.

Pre spoločnosť Evolveum je tento projekt príležitosťou pristúpiť k týmto požiadavkám systematicky: pochopiť, čo regulácia vyžaduje, posúdiť našu súčasnú situáciu, identifikovať riziká a nedostatky, a následne premeniť tieto zistenia na konkrétne zlepšenia.

Projekt* je podporený v rámci TestCert-SK (101127837), ktorý je financovaný Európskou komisiou a Národným bezpečnostným úradom Slovenskej republiky (NBÚ).

Bezpečnosť nie je jednorazovým míľnikom, ale neoddeliteľnou súčasťou neustáleho vývoja a údržby dôveryhodného softvéru na správu identít. Tento projekt predstavuje ďalší krok v kontinuálnom procese posilňovania bezpečnosti a odolnosti midPointu.

*Projekt financovaný na základe zmluvy o poskytnutí NFP č. 25094/2026 podporuje Národný bezpečnostný úrad. Financované Európskou úniou. Vyjadrené názory a postoje sú názormi a vyhláseniami autora(-ov) a nemusia nevyhnutne odrážať názory a stanoviská Európskej únie alebo Európskeho kompetenčného centra pre kybernetickú bezpečnosť. Európska únia ani Európske kompetenčné centrum pre kybernetickú bezpečnosť za ne nepreberá žiadnu zodpovednosť“.

Výška poskytnutého NFP: 39201,59- EUR

---

Frequently Asked Questions

+ What is the CRA?

The Cyber Resilience Act is an EU regulation that establishes cybersecurity requirements for products with digital elements, including both hardware and software products placed on the EU market.

Its goal is to make products more secure throughout their lifecycle. The regulation puts greater responsibility on manufacturers to address cybersecurity from the design and development stages through to maintenance, vulnerability handling, and support.

+ What are the requirements of the CRA?

The CRA introduces cybersecurity requirements covering the design, development, delivery, and maintenance of products with digital elements.

Among other things, manufacturers need to:

• design and develop products with appropriate cybersecurity in mind
• carry out a cybersecurity risk assessment
• address identified vulnerabilities and security risks
• provide security updates and handle vulnerabilities throughout the required support period
• provide appropriate security information and technical documentation
• carry out the applicable conformity assessment procedure
• report certain actively exploited vulnerabilities and severe security incidents
• provide information about the product’s security and support period

The specific requirements and conformity-assessment procedure depend on the product and its classification under the CRA.

+ What is the CRA timeline?

The CRA is already in force, but its requirements are being introduced in stages:

• 10 December 2024: The Cyber Resilience Act entered into force
• 11 June 2026: Provisions concerning the notification of conformity assessment bodies come into effect
• 11 September 2026: The CRA vulnerability and severe-incident reporting obligations come into effect
• 11 December 2027: The main provisions of the CRA come into effect, including the core cybersecurity requirements for products covered by the regulation

The post Strengthening midPoint security and preparing for the EU Cyber Resilience Act appeared first on Evolveum | Open Source Identity Management & Governance.

]]> https://evolveum.com/midpoint-and-cra/feed/ 0 https://evolveum.com/toxic-combinations-handled-enforcing-sod-with-midpoint/ https://evolveum.com/toxic-combinations-handled-enforcing-sod-with-midpoint/#respond Wed, 23 Sep 2026 06:30:41 +0000 https://evolveum.com/?p=16088 This article was written by our Gold implementation partner, AMI Praha, as part of our MidPoint in Practice series, where partners share real-world implementation stories highlighting how they solve identity governance challenges with midPoint. About AMI Praha: AMI Praha is a system integrator operating in the ICT security segment that specializes in authentication / authorization Read more about Toxic Combinations, Handled: Enforcing Segregation of Duties Across Systems with MidPoint[…]

The post Toxic Combinations, Handled: Enforcing Segregation of Duties Across Systems with MidPoint appeared first on Evolveum | Open Source Identity Management & Governance.

]]> This article was written by our Gold implementation partner, AMI Praha, as part of our MidPoint in Practice series, where partners share real-world implementation stories highlighting how they solve identity governance challenges with midPoint.

About AMI Praha:

AMI Praha is a system integrator operating in the ICT security segment that specializes in authentication / authorization processes and access control to information, regardless of the place of storage. AMI Praha has been integrating midPoint into their customers’ IAM infrastructures since 2015.

What Is Segregation of Duties (SoD)?

Segregation of Duties (SoD) is one of the most important controls in identity governance and administration (IGA). It prevents users from accumulating combinations of permissions that could enable fraud or abuse of power, and it’s a core component of any effective risk management strategy.

Certain powerful capabilities must never rest in the same pair of hands – being able to create a vendor and approve a payment, or to post a journal entry and approve it – these two examples are classic fraud risks. These “toxic combinations” are common audit findings and are addressed directly by compliance frameworks such as ISO/IEC 27001 (Control 5.3).

Many enterprise applications can enforce SoD within their own environment. But today’s organizations run on multiple interconnected systems, and a user may pick up one sensitive entitlement in one application and another in a line-of-business system, creating a risky combination that no single application can detect on its own.

This is where identity governance becomes essential. Because midPoint serves as a central identity governance and administration platform, it has a complete view of a user’s assignments and can enforce cross-system SoD policies before risky access is granted.

In this implementation story, AMI Praha explains how a regulated financial institution in Central Europe used midPoint to move from manual, detective controls to automated, preventive access governance.

The Challenge: Enforcing Segregation of Duties Across Multiple Systems

The organization uses midPoint as its central IGA platform, granting access through a role model (a structure where access rights are bundled into named roles, then assigned to users, rather than granted permission-by-permission) that spans several connected systems – an SAP ABAP back end, Active Directory, an LDAP directory, and a core line-of-business application – all fed from an authoritative HR source.

Although SoD was already being checked within individual systems, most notably inside SAP, the organization faced a common identity governance challenge: no single application had visibility into a user’s complete access profile. As a result, toxic combinations spanning multiple systems could slip through undetected.

At the same time, enforcement relied heavily on manual spreadsheets and periodic audits. Violations were discovered only after access had already been granted, rather than prevented at the point of request – creating real exposure windows, repetitive analyst effort, and audit findings that were expensive to remediate after the fact.

To complicate matters further, years of accumulated role assignments meant SoD conflicts already existed throughout the environment. A “just turn it on” approach wasn’t an option: enabling strict enforcement overnight would have disrupted business operations and generated a flood of errors. The organization needed a solution that strengthened governance and compliance without interrupting day-to-day work.

How MidPoint Enforced Cross-System Segregation of Duties

AMI Praha implemented SoD natively in midPoint using policy rules with exclusion constraints, and, critically, rolled it out gradually. A few properties of midPoint’s model made this approach clean to implement:

• Exclusion is declarative and bi-directional. Administrators state, on one role, that it excludes another via a targetRef. MidPoint treats the exclusion as mutual regardless of which role is assigned first or second, so each conflicting pair is defined once, not twice, which keeps the policy set simpler to maintain long-term.

• The enforcement action is separate from the constraint. The same exclusion can be attached to different policy actions depending on how strict the situation calls for:
  • enforcement – a hard block; the conflicting assignment is rejected with an error.
  • approval – the request is routed to a designated approver, who can grant a documented, auditable exception.
  • record – the conflict is marked but not blocked, so it can be reported without disrupting anyone.

• Metaroles let SoD scale. Instead of wiring together hundreds of individual role pairs, the team expressed “exclusion classes”, for example, all executive roles versus all controlling roles through metaroles (roles that apply their rules to a whole category of other roles at once), so newly added roles inherit the correct exclusions automatically.
• It’s a cross-system by construction. Because midPoint evaluates a user’s complete assignment set, a violation split across SAP and another application is caught just as reliably as one contained entirely inside SAP – something a single-system control cannot do.

A Gradual Rollout That Minimized Risk

The rollout followed midPoint’s gradual-enforcement pattern, which turned out to be the single most important decision in the project:

1. Model the conflicts. Working with business and compliance owners, AMI Praha translated the organization’s SoD matrix into exclusion constraints on the relevant roles, using metaroles for the broad “class versus class” rules.
2. Start in record mode. Every rule went live initially with the record action. Nothing was blocked; conflicts were simply marked.
3. Report and remediate. The team produced a violation report from those marks, surfacing the true state of pre-existing conflicts. The business then worked through the backlog – removing access, splitting duties, or formally accepting a documented exception – until it was clean.
4. Switch to prevention. Only then did the actions change to enforcement for the strict rules and approval for the cases where legitimate, controlled exceptions are a business reality. From that point on, midPoint prevents new violations at the moment of request.

Pairing enforcement and approval per rule was key to making this work: the truly forbidden combinations became simply impossible, while the “normally not allowed, but sometimes justified” combinations generate an approval request that leaves a full audit trail of who requested, who approved, and why.

From Detective Controls to Preventive Identity Governance

The most significant shift was in timing: SoD moved from detective to preventive. Conflicting access is now stopped at the moment of request, closing the exposure window that periodic reviews used to leave open. Instead of discovering a violation weeks or months after the fact, the system simply refuses to create it.

Coverage also became cross-system. Because midPoint evaluates a user’s complete assignment set, it catches combinations that no individual application (SAP included) could have seen on its own, closing the blind spot that motivated the project in the first place.

That shift changed what audit preparation looks like day to day. Rather than assembling evidence after the fact, the organization can now present it directly: the policy rules serve as the documented control, the marks left by earlier record-mode runs serve as historical evidence, and every approved exception carries its own audit trail of who requested it, who approved it, and why. Analyst time that used to go into manually hunting for violations has been redirected toward remediation and ongoing policy refinement instead.

Key Lessons for Implementing Segregation of Duties

Gradual enforcement isn’t optional at scale. Going straight to hard blocking in an established role model breaks legitimate work. The record → report → remediate → enforce sequence is what actually makes SoD deployable in a live environment rather than a theoretical policy that never gets switched on.

It’s also worth defining each conflicting pair only once. Because exclusion in midPoint is bi-directional, mirroring a rule on both roles creates maintenance noise down the line. For the same reason, metaroles are worth adopting early rather than late: pair-by-pair modeling doesn’t scale and tends to rot as new roles are added, while class-level rules keep the policy maintainable over time.

Enforcement and approval should be combined deliberately rather than applied uniformly. Not every conflict is absolute, therefore reserving hard enforcement for the genuinely forbidden combinations, and routing the rest through an approval workflow, keeps the control both strict where it needs to be and workable where legitimate exceptions exist.

Finally, it’s worth remembering that SoD is a business artifact, not a technical one. The exclusion matrix has to be owned and signed off by compliance and the business. MidPoint enforces the policy faithfully, but only the business can decide what the policy actually is.

Frequently Asked Questions

+ What are the benefits of Segregation of Duties?

SoD minimizes operational risk by preventing any single individual from executing high-risk processes unchecked. It dramatically reduces exposure to internal fraud, errors, and privilege abuse across the organization. Additionally, SoD simplifies alignment with major compliance frameworks like ISO/IEC 27001 and SOX.

+ How does midPoint enforce Segregation of Duties?

MidPoint enforces SoD using policy rules defined within role configurations, specifically through role exclusions. A role can declare via a policy constraint that it cannot be assigned alongside another specific role or category. Administrators can utilize metaroles to apply these bidirectional exclusion rules across entire classes of roles simultaneously. Because midPoint evaluates a user’s global assignment set across all connected target systems, it effectively catches cross-system conflicts.

+ What happens when a Segregation of Duties conflict is detected?

When a SoD conflict is detected, midPoint’s response depends entirely on the policy action attached to the exclusion rule. With strict enforcement, the system hard-blocks the request and rejects any conflicting assignment outright. Alternatively, with an approval workflow, the request is automatically routed to a designated authority who can review the context and grant a documented exception. The system can also be configured to simply record or log the conflict for visibility without blocking, which is ideal during initial policy rollouts.

Interested in working with AMI Praha?

Get in touch with AMI Praha to discuss your identity management needs.

Contact AMI Praha

The post Toxic Combinations, Handled: Enforcing Segregation of Duties Across Systems with MidPoint appeared first on Evolveum | Open Source Identity Management & Governance.

]]> https://evolveum.com/toxic-combinations-handled-enforcing-sod-with-midpoint/feed/ 0 https://evolveum.com/ai-agent-governance-how-to-safely-deploy-and-manage-ai-identities/ https://evolveum.com/ai-agent-governance-how-to-safely-deploy-and-manage-ai-identities/#respond Fri, 11 Sep 2026 08:04:52 +0000 https://evolveum.com/?p=15968 AI agents are becoming digital coworkers. So much so that Gartner predicts that by 2028, an average global Fortune 500 enterprise will have over 150,000 agents in use – up from less than 15 just last year. Even if that projection turns out to be way too optimistic and the actual numbers will land somewhere Read more about AI Agent Governance: How to Safely Deploy and Manage AI Identities[…]

The post AI Agent Governance: How to Safely Deploy and Manage AI Identities appeared first on Evolveum | Open Source Identity Management & Governance.

]]> AI agents are becoming digital coworkers. So much so that Gartner predicts that by 2028, an average global Fortune 500 enterprise will have over 150,000 agents in use – up from less than 15 just last year. Even if that projection turns out to be way too optimistic and the actual numbers will land somewhere around 50%, it describes a workforce larger than most of the companies deploying it, assembled in only three years.

Most organizations are somewhere in the early part of this curve right now, and that’s exactly the moment to get governance right. It’s much easier to define the policy framework at the start than to retrofit it later on. Otherwise, organizations risk discovering gaps when scaling, during an audit, or worse, when one becomes a serious security incident.

This guide explores how organizations can deploy AI agents securely and enable innovation without losing control.

 

• What is an AI agent?
• How do AI agents differ from other non-human identities (NHIs)?
• What can go wrong when AI agents aren’t governed?
• Three AI agent governance questions most organizations haven’t answered.
• How to govern AI agents: an 8-step guide.
• How AI agent governance works in midPoint.

 

What is an AI agent?

An AI agent is a software identity powered by a large language model (LLM) that has been given access to credentials and business systems so it can complete tasks autonomously. Unlike a chatbot that simply answers questions, an AI agent can perform work on your behalf. It can call APIs, query databases, read and write files, invoke external services, and even coordinate with other agents to complete more complex workflows.

To do that, an agent authenticates with credentials such as OAuth tokens, service accounts, and workload identities, allowing it to operate as a trusted user inside your environment. Once an AI agent receives credentials and permissions, it becomes another identity that must be governed throughout its lifecycle.

 

How do AI agents differ from other non-human identities (NHIs)?

AI agents are a type of non-human identity but they behave very differently from the static machine identities that IAM teams have managed for years.

Traditional identity governance focuses on granting access and reviewing it periodically. AI agents require continuous oversight because what matters isn’t just who has access, it’s what they’re trying to do right now.

 

What can go wrong when AI agents aren’t governed?

Unlike what we see in sci-fi movies, most governance failures don’t begin with a malicious AI agent. What’s more likely is that they start with an ordinary business problem that slowly snowballs into an identity problem.

Sensitive data exposure

Unlike a human employee reading a customer record on a screen, an AI agent often sends portions of that information into a language model as part of its reasoning process. Governance therefore needs to extend beyond controlling access to databases. Organizations should also consider what information an AI agent can access and process in the first place, and whether personally identifiable information should be masked before it is sent to an LLM for summarization.

Privilege accumulation

As organizations discover new use cases, agents tend to receive additional permissions without much review. What began as read-only CRM access gradually expands into access to multiple systems, while no one periodically asks whether those permissions are still required. Unlike employees, whose access is often reviewed during certification campaigns, AI agents are frequently overlooked because they aren’t seen as traditional identities.

Lack of ownership

AI agents also have a habit of outliving the projects that created them because no one clearly owns them. A developer builds an agent during a pilot, changes teams a few months later, and the agent continues operating because the business depends on it. Over time, the risk of everyone forgetting about these agents compounds.

Shadow AI

Not every AI agent is deployed through an approved IT project. Often, employees are creating agents themselves to solve everyday business problems, often without realizing the security implications. Just as Shadow IT introduced unmanaged applications, Shadow AI introduces unmanaged AI identities. If security teams don’t know an agent exists, they can’t govern its access and monitor its activity.

It’s worth noting that the instinct to clamp down makes this worse. Gartner’s own guidance on agent sprawl is that blocking or restricting AI agents isn’t a long-term solution, because employees who can’t work in sanctioned tools will go around the controls and adopt shadow AI instead — which presents far greater risk than the thing you were trying to prevent.

Compliance: EU AI Act, GDPR, NIS2, DORA, and CRA

As AI agents become part of everyday business processes, governance also becomes a compliance issue. An agent with access to sensitive data and regulated systems is subject to many of the same expectations as human employees.

 

Regulation	Primary focus	Relevance to AI agent governance
GDPR	Protection of personal data	Governs how personal data is processed, including by any model provider in the chain – applies the moment an agent touches customer or employee data, regardless of where the model itself runs.
EU AI Act	Risk-based regulation of AI systems	Categorizes AI by its potential danger to society. Simple tools like internal document summarizers face minimal restrictions, whereas agents that make or heavily influence decisions about people face strict legal obligations. This tiering dictates the exact level of human oversight and transparency required.
NIS2	Cybersecurity risk management for critical entities	Requires access control, logging, and demonstrable accountability across essential and important entities, and makes senior management personally responsible for compliance – including for AI-driven operations.
DORA	Operational resilience for financial entities	Imposes comparable expectations to NIS2 on financial entities, with particular attention to third-party ICT risk – directly relevant wherever an agent or model runs on outsourced infrastructure.
CRA	Cybersecurity of products with digital elements	Introduces mandatory cybersecurity requirements for products with digital elements, including systems that incorporate AI components. Manufacturers must build in secure-by-design principles throughout the product lifecycle before it reaches the market.

 

Three AI agent governance questions most organizations haven’t answered

The risks above are the visible ones, and most organizations will recognize at least one from their own environment. Underneath them sit three harder problems that don’t often come up in discussions and where the genuinely difficult work is. They’re worth settling before you start building.

Whose authority is the agent acting under?

When an agent does something on behalf of a user, does it use its own permissions or theirs?

An agent acting for a user should be limited to the intersection of what the agent may do and what that user may do. In practice this means token exchange and on-behalf-of flows rather than static service accounts. It’s the single most important technical decision in agent identity, and it’s much easier to design in than to retrofit.

What happens when an agent’s instructions come from an attacker?

Your agent has perfectly scoped permissions and a clean audit trail, however, it reads an email containing text crafted to look like an instruction and decides to follow it. This is prompt injection, and the reason it belongs in a governance conversation is what it does to your threat model.

Identity governance unfortunately can’t solve this problem, but it can limit the damage. If the agent’s permissions are scoped to the intersection of its role and the user it’s acting for, an injected instruction can only misuse what’s inside that narrow overlap. That is why enforcement has to exist at the moment of action, not only at the moment of provisioning.

What happens when AI agents call other agents?

Agent A invokes agent B, which calls agent C. Does authority remain the same at each handoff, or does access just keep piling up so the last agent in the chain ends up able to do more than anyone meant for it to? And if something goes wrong six months from now, could you actually trace back and figure out who allowed it and reconstruct the chain? Most organizations can’t answer this yet. If your architecture involves multi-agent orchestration, answer it before you scale.

 

How to govern AI agents: an 8-step guide

Fortunately, none of these questions require reinventing identity governance. They require applying familiar identity principles to a new type of identity, and the following framework is a practical place to start.

1. Find the agents you already have

Every step below assumes you know an agent exists, so start by confirming that. Survey the business, check what’s been connected to your SaaS platforms, look at OAuth grants and API key usage, and ask teams directly what they’ve built. Discovery is uncomfortable and almost always produces surprises. Do it first.

2. Give every agent its own identity

The most common mistake is running agents as extensions of an existing user or application. If you do that, it will be impossible to separate what the person did from what the agent did. Each agent gets its own identity, with a lifecycle that runs from creation through to decommissioning.

3. Authenticate and scope agents like agents, not like users

Avoid shared service accounts and long-lived API keys. Use short-lived credentials and modern standards: NIST identifies SPIFFE/SPIRE as a universal approach to authenticating software workloads, while OAuth 2.0 can provide delegated authorization when an agent needs to act on someone’s behalf. Whatever credentials remain should live in a managed secrets store with automatic rotation, never in a config file or prompt template. Then scope what’s granted to the task – instead of broad access, restrict the agent to exact actions, specific datasets, and precise APIs.

4. Govern the tools, not just the data

An agent’s real capability comes from the tools connected to it. Every integration and MCP server it can reach expands what it can do, and each one (hopefully) arrived through some approval process. Maintain an inventory of what each agent is connected to, who approved it, and what scopes it was granted. This is where most of the risk actually is.

5. Enforce guardrail and human checkpoints where decisions happen

Granting access is only half of the story, as runtime guardrails determine what happens once an agent reaches the data. For high-stakes decisions, keep a human in the loop. Standards like CIBA let the agent pause, request approval through a separate channel, and resume once granted, without anyone watching a screen.

6. Make someone accountable

If we’re treating AI agents as our little work helpers, then every agent needs a designated manager – be it a person or a team – who approves new permissions, responds to access reviews, answers audit questions, and decides when the agent retires. Ownership should be a required field at creation, and it should be reassigned when people move roles. Without it, everything else on this list eventually degrades.

7. Test before you trust

Run new agents in a sandbox with tightly scoped permissions and evaluate how they behave, ideally putting it up against deliberately hostile input. Grant production access when they’ve earned it, and treat every subsequent expansion as a decision requiring a rationale and an approval rather than a configuration change. This prevents permissions from silently piling up over time.

8. Review continuously, monitor at runtime, and know how to stop

Agents belong in the same certification campaigns as employees, with owners confirming entitlements are still justified. Log every significant action and the reasoning behind why it was permitted or denied. And know (before you need it) whether revoking an agent’s credentials kills active sessions immediately or just blocks new ones. When an agent is no longer needed, retire it properly: revoke credentials and tool access, save its logs, and document the shutdown.

 

How AI agent governance works in midPoint

Building a governance program for AI might sound daunting, but if you already use a mature identity governance platform, you likely have most of the foundations in place. You don’t necessarily need a separate, specialized tool to govern AI agents; platforms like midPoint can manage them much like any other non-human identity.

The Service object type exists precisely for this. Services represent non-person identities, and because they carry credentials in much the same way users do, they can represent machine agents and similar things that behave like humans. Services are also abstract roles, so they can grant privileges to other entities.

Archetypes provide the granular typing. An archetype describes what kind of thing an object is, (e.g. “Employee”, “Application”, “AI Agent”) and can be applied to Users, Roles, Orgs, and Services alike. Each archetype can be defined by policies, letting you treat AI agents differently from standard service accounts or human employees without building a parallel governance framework.

MidPoint roles can form hierarchies through inducement relations, and access rights can be assigned and unassigned automatically according to the organizational structure. Roles assigned to an organizational unit can provide access to identities within that unit, while inducements can be used to propagate privileges through a hierarchy.

Approval workflows, access certification, and audits are core platform capabilities available to any identity type. Certification campaigns can automatically revoke access if a reviewer denies it, and comprehensive audit logs make meeting regulatory requirements much easier to manage.

Our partner Inalogy has extended this approach to address the specific requirements of AI agent governance, and a detailed guide can be found in this article. They have extended midPoint with these three attributes:

• Business Roles define who the agent is.
• Application Roles define what it may do, enforcing permissions on every single action rather than just at provisioning.
• Skill Roles define what it knows. This is an agent-specific tier: a skill is a set of instructions, procedures, and guardrails loaded into the agent’s context. Without the role, the agent never sees those instructions at all.

Inducement ties the three together, as assigning a specific business role automatically triggers the corresponding application access and skill sets.

 

See how Midpoint brings human and non-human identities together under one identity governance layer.

Explore midPoint

 

The payoff of getting it right

AI agents are already inside most environments, and building a governance framework now, while the count is on the lower end, will not only be much easier than trying to play catch up later, it’s also the right thing to do.

It won’t stop innovation either – the Larridin State of Enterprise AI Q1 2026 report found that organizations with formalized AI risk and compliance policies are 2.2x more likely to demonstrate ROI than those without. The bottom line is, companies that get AI agent governance right will reap the benefits of deploying AI agents faster, safer, and with more confidence.

 

Frequently Asked Questions

+Is AI agent governance legally required, or is it just best practice?

There isn’t one single AI-specific law that mandates AI agent governance. Regulations such as the EU AI Act, GDPR, and NIS2 can already create obligations around AI, data protection, security, and accountability. Even when there isn’t a specific rule for AI agents, existing requirements may still apply. Good governance is therefore both a compliance consideration and a practical security best practice.

+If an AI agent causes a breach or makes a bad decision, who’s actually liable?

Responsibility sits with the organization that deployed the agent. Exactly who is liable depends on the circumstances and the laws that apply. That’s why it’s important to have comprehensive audit logs of each agent and clear ownership.

+Should IAM own AI agent governance, or does it belong to security or legal?

In practice it tends to split naturally across teams, with IAM handling the identity lifecycle, while security takes on security and monitoring and legal keeps track of interpreting regulations. AI governance is a joint effort throughout the organization and not something that one department can solve on its own.

About Evolveum:
Evolveum is the organization behind midPoint, the leading open source IGA platform recognized as a complete IGA by both Gartner and KuppingerCole. MidPoint bridges the gap between IT and business, making it an ideal choice for organizations seeking digital transformation to enhance security and efficiency.

The post AI Agent Governance: How to Safely Deploy and Manage AI Identities appeared first on Evolveum | Open Source Identity Management & Governance.

]]> https://evolveum.com/ai-agent-governance-how-to-safely-deploy-and-manage-ai-identities/feed/ 0 https://evolveum.com/evolveum-recognized-as-an-innovation-challenger-in-kuppingercoles-2026-iga-leadership-compass/ https://evolveum.com/evolveum-recognized-as-an-innovation-challenger-in-kuppingercoles-2026-iga-leadership-compass/#respond Thu, 06 Aug 2026 15:25:30 +0000 https://evolveum.com/?p=15782 Evolveum has been recognized as an Innovation Challenger in KuppingerCole’s latest Leadership Compass for Identity Governance and Administration (IGA). As an independent European open-source company, being yet again recognized alongside many of the industry’s largest and well-established IGA vendors like Sailpoint, IBM, Microsoft and Okta, is an important milestone for us. We believe this recognition Read more about Evolveum Recognized as an Innovation Challenger in KuppingerCole’s 2026 IGA Leadership Compass[…]

The post Evolveum Recognized as an Innovation Challenger in KuppingerCole’s 2026 IGA Leadership Compass appeared first on Evolveum | Open Source Identity Management & Governance.

]]>

Evolveum has been recognized as an Innovation Challenger in KuppingerCole’s latest Leadership Compass for Identity Governance and Administration (IGA).

As an independent European open-source company, being yet again recognized alongside many of the industry’s largest and well-established IGA vendors like Sailpoint, IBM, Microsoft and Okta, is an important milestone for us. We believe this recognition reflects the strength of midPoint, our Identity Governance and Administration platform, and its ability to address complex, enterprise identity challenges.

What is the KuppingerCole Leadership Compass?

The KuppingerCole Leadership Compass is an independent analyst evaluation designed to help IT and security leaders navigate software markets and identify solutions that best meet their technical and business requirements.

The Leadership Compass evaluates vendors across multiple categories, including Overall, Product, Innovation, and Market Leadership while assessing capabilities such as identity lifecycle management, target system support, self-service and mobile support, audit, reporting and compliance and more.

Where midPoint stood out

The report highlighted several capabilities that distinguish midPoint in the enterprise IGA market:

Simulations for safer deployments

Simulations are midPoint’s key differentiator, as highlighted by KuppingerCole. It enables organizations to analyse the impact of configuration and policy changes before implementing them in production, helping reduce deployment risk and identify potential issues before they go to production.

Flexible deployment options

MidPoint supports a wide range of deployment models, including traditional server installations, containerized environments such as Docker and Kubernetes, and public or private cloud infrastructure. SaaS and managed services are available through a wide range of partners. This flexibility allows organizations to choose the deployment model that best fits their operational and regulatory requirements.

Robust identity lifecycle management

MidPoint provides robust identity lifecycle management, supporting workforce, partner, customer and non-human identities. The platform includes automated provisioning and deprovisioning, real-time synchronisation, schema discovery and extension, and just-in-time (JIT) provisioning to help organisations manage identities of all types throughout their lifecycle.

Comprehensive access governance

MidPoint’s mature access governance capabilities includes centralised role management, hierarchical role models, role discovery and role mining. Smart Roles allow access policies to adapt dynamically based on organisational structure, user attributes or contextual information, helping organisations build scalable and maintainable role-based access control (RBAC) that adapts to organisational structures and user attributes.

Broad integration capabilities

The platform offers an extensive connector ecosystem covering LDAP, Active Directory, relational databases, CSV, and numerous SaaS platforms, including Microsoft Entra ID, AWS, Google Workspace, Jira, Slack, ServiceNow, SAP SuccessFactors, and Microsoft 365. In the next release scheduled for October 2026, we will be releasing midPilot, an AI application onboarding assistant designed to help with integrating new applications more quickly while maintaining strong governance.

Looking ahead

We’re proud to be recognised as an Innovation Challenger and encouraged that the report highlights many of the technical capabilities we’ve invested in over the years.

At the same time, we see this recognition as another step in our journey. The report highlights opportunities for further development, many of which are already reflected in our roadmap. With innovations such as midPilot, we’re excited to continue evolving midPoint and building on this recognition in future Leadership Compass evaluations.

Read the report 

The post Evolveum Recognized as an Innovation Challenger in KuppingerCole’s 2026 IGA Leadership Compass appeared first on Evolveum | Open Source Identity Management & Governance.

Chapters

• The end-of-life of SAP IDM and MIM
• When the obvious choice isn’t always the right one
• The CISO’s strategic migration playbook
• Finding the right replacement for SAP IDM and MIM
• The strategic path forward that shapes the next decade

The end-of-life of SAP IDM and MIM

SAP Identity Management 8.0 mainstream maintenance ends on December 31, 2027, with extended maintenance available until 2030. This date might seem far off, but anyone who’s been through a major identity system migration knows how quickly time flies when you’re dealing with complex integrations, data migrations, and user training. SAP has confirmed it is not developing an on-premises alternative and is heavily encouraging its customers to get rid of custom scripts and embrace a more standardized approach within the cloud.

Microsoft Identity Manager support was extended to January 9, 2029. However, Microsoft stopped actively developing MIM in 2021, focusing instead on Entra ID (formerly Azure AD).  While Service Pack 3 (SP3) was released in May 2026 to support modern operating systems and SQL servers, it only serves as a temporary bridge. On top of that, SharePoint Server 2016 and 2019 reached end of support in July 2026, and any organization relying on them to host their MIM Portal must upgrade to SharePoint Server Subscription Edition (SPSE) or eliminate the portal entirely just to stay compliant. The message is clear: their priority is no longer on-premises identity solutions.

For many organizations, this marks the end of an era – and the beginning of a significant challenge. For those navigating strict data sovereignty requirements or committed to maintaining critical on-prem capabilities, the road ahead may be even more complex. However, there is light at the end of the tunnel. After years of stagnant feature development, most current SAP IDM and MIM environments are outdated, lacking modern identity governance capabilities. Now is the perfect time to rethink your identity infrastructure and modernize your identity security posture.

In the following sections, we will explore practical strategies for legacy identity system migration and outline key options available to ensure a smooth, secure, and future-proof transition.

When the obvious choice isn’t always the right one

When legacy systems reach end-of-life, the natural path often leads to vendor-recommended successors. SAP and Microsoft have developed clear migration guidance toward their cloud-based alternatives: SAP Cloud Identity Services and SAP Cloud Identity Access Governance for identity and access management into SAP products and Microsoft Entra ID.

These solutions offer compelling advantages – modern cloud architecture, reduced infrastructure overhead, and tight integration within existing vendor ecosystems. For organizations heavily invested in Microsoft or SAP technologies, this path provides obvious benefits.

However, neither Entra ID nor SAP Cloud Identity Services represents a direct replacement for their on-premise predecessors. They differ in architecture, features, and how they operate, which means they might not fit every organization’s needs.

Before jumping on the bandwagon, ask yourself:

• Is Microsoft or SAP at the core of your tech stack, and are you planning to stay within a single-vendor architecture? Or are you operating in a more complex, multi-vendor ecosystem?
• Will your architecture remain on-premise, migrate to the cloud, or maintain hybrid operations?
• How complex are your identity governance and administration needs beyond basic user lifecycle management?
• What are your future scalability, security, and compliance needs?

Hybrid achitecture adds complexity

Most large organizations run hybrid environments with a mix of on-premise and cloud systems. Within these environments, managing identity and access consistently can be challenging. Microsoft talks about Entra ID as a hybrid solution, and in many ways it is. But the reality of making it work smoothly across all your systems can be more challenging than initial assessments suggest.

Managing identities in a hybrid IT architecture is not always straightforward. Organizations commonly run into:

• Identity synchronization challenges across forests and domains
• Custom attributes that don’t cleanly map to cloud directories that break in modern policy frameworks
• Firewalls and proxies that impede cloud-to-ground communication in apps not designed for modern protocols

Hybrid identity architecture can add complexity. For many organizations, it offers the necessary balance to maintain compliance and customization without compromising long-term transition potential. The good news is that with identity platforms purpose-built to handle hybrid environments, these complexities can be effectively managed.

Cloud-first isn’t for everyone

Amid the push toward cloud migrations, it’s important not to overlook that many organizations choose to keep their operations on-premises. In such cases, adopting a cloud-native identity platform like Entra ID may not make much sense.

While some vendors are scaling back support for on-prem identity solutions, that doesn’t mean on-prem architecture is obsolete. In fact, many enterprises, including large global ones, continue to rely on it, often due to cost, strict regulatory compliance, and the need for full control over infrastructure and operations. If your organization falls into this category, that’s a valid and strategic choice.

That doesn’t mean your options are limited, though – there are still modern platforms that not only work in the cloud, but also fully support on-prem deployments and are committed to continuing that support.

Integration and customization challenges

This is where many organizations get surprised. If you’ve spent years building custom workflows, approval processes, and business rules in SAP IDM or MIM, you might find that Entra ID doesn’t give you the same level of flexibility.

Microsoft has built a solid platform, but it’s designed to work optimally within a Microsoft environment. If your business processes don’t align with that approach, you’ll need to either change your processes or find workarounds that add complexity and cost.

The true cost of migration

Per-user pricing models appear straightforward during initial evaluations, especially for smaller organizations. But enterprise-scale implementations frequently involve premium features, additional connectors for non-vendor systems, custom development requirements, licensing fees, and subscription costs that significantly impact long-term budgets.

The CISO’s strategic migration playbook

Successfully migrating from legacy platforms requires a comprehensive approach that balances strategic planning with practical, risk-aware execution.

Organizations should begin this process well in advance of sunset dates, as identity system migrations typically require 12-36 months for full implementation in enterprise environments. Simply defining requirements and selecting the right solutions can take several months. Those who delay risk security vulnerabilities, operational disruptions, and compliance issues. That said, with the right tools and approach, you can have a steady stream of initial results from the beginning of the migration process.

Here’s a high-level roadmap to help you navigate this transition successfully:

1. Assess your current identity landscape

Start with a thorough inventory of your existing identity infrastructure. Document not just your systems and integrations, but the actual business processes they support. Often, organizations discover that their identity management has evolved far beyond its original design, with workarounds and customizations that aren’t immediately obvious.

At this stage:

• Review your systems, target directories, and applications, making sure to compare data for inconsistencies.
• Map how your identity systems connect with other applications.
• Understand existing identity lifecycle triggers, provisioning flows, and access policies.
• Audit your data and workflows and look for orphaned and over-permissioned accounts and toxic permission combinations.
• Take an inventory of non-human identities, such as service accounts, API credentials, and AI agents. In modern stacks, NHIs outnumber human accounts by a wide margin.

Also, map your compliance requirements early in the process. Different solutions handle regulatory requirements differently, and understanding these constraints upfront prevents costly discoveries later in the migration.

💡 Best Practice: Take this opportunity to “clean house”. Review your current licenses, identify which tools and capabilities are truly necessary, and pinpoint under-utilized applications. You might find significant savings by removing unused licenses and consolidating your tools.

2. Define your requirements

Engage stakeholders across IT, security, and business units to understand their actual needs and requirements. Focus on business outcomes rather than technical feature translations. This approach often reveals opportunities to streamline processes during the migration.

Consider your organization’s five to ten-year trajectory:

• How complex do you anticipate your identity needs to be?
• How will your identity governance requirements grow?
• Are there any emerging regulations or compliance requirements that will have an impact on your identity processes?
• How will your tech stack grow and what integration capabilities will you need?
• Are you planning to expand internationally?
• What about future mergers or acquisitions?

These factors should guide you in selecting the right solution to support your needs for years to come.

💡 Best Practice: Keep the initial scope focused and achievable. Successful teams often start with a core domain, like workforce identity lifecycle management, and build outward in manageable iterations. This allows for early value delivery and room for lessons learned to inform future phases.

3. Evaluate solutions through a security lens

Evaluation processes should extend well beyond feature comparisons and vendor demos. This includes assessing integration capabilities with existing systems, evaluating performance under realistic load conditions, and understanding true customization flexibility, while prioritizing security controls.

• Authentication and credential security: Assess credential storage encryption, supported authentication methods, passwordless controls and multi-factor authentication enforcement capabilities. Examine password policies and session management.
• Audit and compliance capabilities: Verify detailed logging of access decisions, configuration changes, and administrative actions. Confirm log retention periods and export capabilities. Ensure compliance reporting supports your regulatory requirements.
• Non-Human Identity (NHI) and AI governance: Verify support for managing the full lifecycle of not only human identities but machine and AI identities too.
• Vulnerability management: Evaluate security patch frequency, the vendor security track record, and testing procedures, including penetration testing and code reviews. Request vulnerability disclosure timelines and remediation processes.
• Data protection and privacy: Determine data residency locations, processing controls, and personally identifiable information handling procedures. Verify data export, deletion capabilities, and privacy regulation compliance mechanisms.
• Technical roadmap and sustainability: Understand the vendor’s product development plans and strategic vision. Assess whether the solution is actively maintained and evolving to keep pace with emerging security threats, regulatory changes, and technological advancements.

💡 Best Practice: Favor platforms that allow non-disruptive analysis and prototyping. This ensures you can validate the technical fit, policy alignment, and risk exposure before you commit to full deployment.

4. Build a risk-aware migration plan

Avoid “big bang” migrations. Successful migrations follow phased approaches that balance early insight with controlled execution. While traditional wisdom often suggests starting with non-critical systems, in identity management, it’s often more effective to connect to foundational, business-critical systems early in a non-invasive, simulation-driven way. This approach provides crucial visibility into your most complex and foundational identity flows without introducing immediate risk. Each migration phase should allow time for:

• Integration challenges
• Refining processes
• Validating assumptions before migrating business-critical systems

Pilot phases should focus on complex integration scenarios rather than simple ones, revealing potential issues early in the process.

Don’t forget about resource planning either – these migrations demand significant technical resources and expertise. Resource allocation should account for senior technical staff being significantly engaged with migration activities for extended periods. Assess internal capabilities honestly and plan for external support where needed, including technical implementation support and change management.

Your migration plan should include comprehensive rollback procedures for each phase, strategies for maintaining security during parallel system operations, and clear incident response procedures for migration-related security events.

💡 Best Practice: Connect to core systems like AD early in the process using non-disruptive simulations. This gives you visibility into your identity baseline, reveals gaps or legacy issues, and sets the stage for safer phased implementation, allowing you to “see before you act.”

5. Invest in change management and user adoption

Technical implementation represents only part of your challenge. Successful migrations require comprehensive change management strategies beginning with key stakeholder involvement from IT, security, and business units during solution selection to ensure buy-in and realistic expectation setting.

Training programs should reflect actual user workflows rather than theoretical processes. Organizations should plan for different user groups with varying technical skills and interaction patterns. The communication roll out should address concerns proactively, provide clear feedback and support channels, and maintain transparency about timelines and impact expectations.

💡 Best Practice: Pair each technical delivery phase with targeted stakeholder communication, user training material development, and clear success measurement. Early small wins, achieved through iterative and low-risk deployments, help establish credibility and build momentum for broader adoption.

Finding the right replacement for SAP IDM and MIM

The identity and access management (IAM) market has matured considerably in recent years with numerous established and emerging platforms worth serious consideration. While certain recommended routes offer integration advantages, they’re not the only options:

• Full-featured identity governance platforms: Vendors focused specifically on identity governance and administration often provide deeper governance capabilities and more flexible customization options than general identity management and lightweight IGA solutions. While light IGAs can be handy, often offering out-of-the-box functionality – they frequently lack the robust features required for comprehensive, long-term governance and scalability.
• Hybrid IGA platforms: Designed to support on-prem, hybrid, and cloud deployment needs. For organizations working in a hybrid operational model or those planning a gradual migration to the cloud, these platforms can be an ideal solution.
• Open source software: Modern open-source identity platforms have gained significant enterprise adoption. These solutions now offer enterprise-grade features, professional support options, and active communities that contribute to their ongoing improvement, such as testing, answering community questions, and even developing custom connectors, providing maximum flexibility and customization potential.

Evaluate platforms based on your specific architecture and business needs – consider factors beyond brand recognition. It is worth examining community threads to understand real-world scenarios and engaging with companies with similar challenges. Also, ask for proof-of-concepts where possible.

When it comes to cost, think about the total cost of ownership, including licensing fees, implementation costs, ongoing maintenance, training requirements, and potential needs for external expertise.

Don’t wait until support runs out. Discover how midPoint’s open source IGA platform aligns with your unique needs and environment.

Explore midPoint.

The strategic path forward that shapes the next decade

Thousands of organizations affected by the end-of-life of the SAP IDM and MIM now face pivotal decisions about their identity management future. While vendor-recommended migration paths offer predictable routes, they may not represent optimal solutions for every environment. The key lies in approaching these decisions strategically rather than reactively.

Take time to understand options fully – evaluate solutions based on specific requirements rather than general market positioning, and consider long-term implications. Today’s identity management market offers mature alternatives across different deployment models, architectural approaches, and business models.

Starting evaluation processes early and considering the full spectrum of available solutions will ensure the chosen platforms support long-term organizational objectives. Remember, the decisions made today will impact your identity security operations for the next decade or two.

About Evolveum:
Evolveum is the organization behind midPoint, the leading open source IGA platform recognized as a complete IGA by both Gartner and KuppingerCole. MidPoint bridges the gap between IT and business, making it an ideal choice for organizations seeking digital transformation to enhance security and efficiency.

The post SAP IDM & MIM End-of-Life: How to Plan Your Identity Migration appeared first on Evolveum | Open Source Identity Management & Governance.

Over the course of the midPilot project, we have been exploring how artificial intelligence can assist organizations in simplifying and accelerating system integrations. The goal has always been to reduce the effort required for connector development and application onboarding thanks to artificial intelligence while keeping humans in control of the process. With M4, these ideas are becoming available for hands-on testing and feedback from the midPoint community.

We are proud to announce that the EU-funded portion of the midPilot project has successfully concluded. The research and development conducted during this phase have been instrumental in shaping the future of midPoint. You can read more details of our progress and outcomes in our final report blog post. Building on the success of this phase, the project itself continues at full speed. We have now moved into the productization phase, where our focus shifts from research and experimentation toward refining these new features, ensuring stability, improving performance, and polishing the user experience for the final release.

Because M4 serves as our official preview version, we highly encourage you to download it and experience these latest capabilities firsthand, before the main release. To help you get started, we have adapted our recent MidPoint Community Meetup (MCM) workshops into easy-to-follow tutorials:

• Trying Out the MidPilot Connector Generator
• Try Me (Workshop): AI Assisted Integration of First Systems with MidPoint.

Development continues at a rapid pace as we work toward a production-ready version. You can expect a steady stream of improvements and bug fixes in the coming weeks – in fact, Milestone 5 (M5) is already scheduled for release at the end of July.

Thank you for your ongoing support. Your feedback is more valuable than ever, and we look forward to hearing your thoughts!

---

The post MidPilot Project Try the New AI-Assisted Integrations of MidPoint 4.11-M4 appeared first on Evolveum | Open Source Identity Management & Governance.

The midPilot project was created to change that. Funded by the European Union’s Recovery and Resilience Plan, midPilot explores how artificial intelligence can assist throughout the application onboarding process while ensuring that every important decision remains under human control. With the successful completion of the project’s third milestone in May 2026, we have delivered a functional foundation for AI-assisted application onboarding in midPoint. Rather than building a standalone AI experiment, we integrated intelligent assistant midPilot directly into the midPoint ecosystem through new microservices, connector generation workflows, workflow orchestration, and an integration catalog designed for community collaboration.

Why AI in identity governance and administration requires human oversight

Artificial intelligence can dramatically reduce the effort required to onboard new applications, but identity IGA isn’t a domain where AI can operate without supervision. An incorrect mapping, permission assignment, or provisioning rule doesn’t simply produce an inconvenience – it can create serious security risks, compliance issues, or unintended access to sensitive resources. That is why one design principle guided the entire midPilot project: humans remain in control.

Instead of attempting fully autonomous onboarding, midPilot uses AI to analyze documentation, suggest schemas, generate connector artifacts, draft mappings, and recommend correlations. Expert administrators review every suggestion before it becomes part of a production configuration. This human-in-the-loop model combines AI’s speed with the expertise and judgment of a real human, delivering faster onboarding without sacrificing transparency or trust.

Staying true to Evolveum’s open source DNA, all project deliverables have been implemented in public GitHub repositories. This includes upstream contributions to the main midPoint repository, the integration catalog, the SCIM/REST connector framework, and the dedicated AI microservices. The broader community can immediately access, verify, and benefit from these outcomes.

What we delivered

The true measure of midPilot is the practical value it delivers to identity engineers. By reducing the heavy lifting of documentation analysis, schema preparation, and correlator drafting, we are drastically cutting down manual onboarding effort. To achieve this, we delivered four major technical outcomes.

• A Smart Integration Microservice: Handles schema matching, data mapping, and correlation support while suggesting optimal object and focus types.
• A Connector Generation Microservice: Features session-based discovery, documentation scraping, digestion, and artifact generation.
• Native midPoint Workflow Integration: We built substantial orchestration, validation, persistence, and UI integration directly into midPoint to support smart implementations and connector development.
• The Integration Catalog: A dedicated infrastructure for the publication, discovery, and reuse of integration artifacts. This shifts the ecosystem away from isolated, one-off connector builds toward a collaborative model where configurations can be easily shared and versioned.

How we validated the solution

Building AI features is only valuable if they perform reliably in real onboarding scenarios. Rather than evaluating individual AI models in isolation, we evaluated the complete integration pipeline. Identity engineers ran rigorous end-to-end test scenarios to validate the entire workflow, from providing initial documentation to executing a fully functional connector.

Testing was conducted across diverse, realistic environments, including customer-like proofs-of-concept (PoCs), workshop settings, and Evolveum’s own infrastructure. Using dedicated Docker configurations and SaaS sandboxes, we evaluated the connector generator against both plain REST and SCIM APIs. Tested systems included OpenProject, Codeberg-Forgejo, Nextcloud, Zendesk, and Atlassian, covering full CRUD capabilities for users and groups.

Crucially, these tests proved the effectiveness of our “human-in-the-loop” philosophy. The evaluation mirrored a real-world workflow: engineers provided structured input, reviewed the AI-generated connector artifacts, refined them directly within the midPoint UI, and tested the results. This confirmed that the wizard-based workflow genuinely simplifies and accelerates the authoring process for identity experts.

Looking ahead

With the strong functional baseline established by midPilot, we are shifting our focus from architecture building to consolidation, hardening, and perfecting the user experience. Here is a glimpse into the future of midPoint.

Shifting to a Top-Down, Business-First Approach

Historically, identity integration has been a bottom-up process: administrators configure connectors, map schemas, and handle technical details before ever addressing the business context. We are flipping that script. Engineers will begin by selecting a prepared application from a card-based UI, choosing an integration method, and defining business details (like the application owner and manager) before diving into the technical weeds. If an app isn’t available locally, users will be able to seamlessly recover by browsing the integration catalog.

New Application Dashboards and Setup Assistant

AI is only half the solution; if a user gets lost in the configuration UI, AI suggestions lose their value. To solve this, we are moving away from dense configuration forms and introducing Application and Resource Dashboards. These object-level dashboards will summarize configuration states, integration readiness, and operational signals in one place.

Complementing this is the new Setup Assistant. Adopting a structured two-column layout, the assistant acts as a persistent guide throughout the onboarding journey. It actively bridges the gap between initial app creation and detailed resource configuration, ensuring engineers never have to guess what requires their attention next. (Of course, power users can still configure objects manually whenever they prefer!)

Bringing the Integration Catalog Natively into midPoint

Currently, leveraging the integration catalog involves browsing externally, downloading files, and importing them into midPoint. Soon, we will connect midPoint directly to the catalog. Engineers will be able to browse, download, and deploy community-built integrations natively from the midPoint UI. Furthermore, partners and users will be able to easily upload their own AI-assisted connectors back to the community directly from their environments.

Security by Design: MidPoint Expression Language (MEL)

To guarantee that AI-generated configuration scripts are entirely safe for production environments, we are natively integrating our own strictly controlled MidPoint Expression Language (MEL) into midPilot. This ensures that all AI-generated mapping expressions are secure by design, fundamentally eliminating the risk of unwanted or malicious code injection. You can read more about MEL here.

Updating Our Training and Methodologies

Finally, we want to share everything we’ve learned. We will be updating our midPoint deployment methodologies, certification processes, and training curriculums to include AI-assisted configuration. This will give our users a safe, hands-on tutorial to master AI-assisted connector development and deployment.

Conclusion

The completion of the third midPilot milestone marks an important step toward bringing practical, AI-assisted application onboarding to midPoint. Rather than replacing identity engineers, midPilot is designed to reduce repetitive work by helping analyze documentation, generate connector artifacts, and guide configuration while leaving every critical decision in human hands. As we continue refining the user experience and expanding these capabilities, our goal remains the same: to make onboarding new applications faster, more consistent, and easier to manage without compromising security, transparency, or trust.

Want to explore the project’s architecture, evaluation methodology, and technical findings in more detail? Read the full midPilot report here.

---

The post MidPilot Project: Milestone 3 – Delivering AI-Assisted Application Onboarding for MidPoint appeared first on Evolveum | Open Source Identity Management & Governance.