Open source identity governance for financial services

Why open source identity governance for financial services needs audit-ready evidence from day one

A bank or payment institution typically runs several general ledgers, card and payment processing platforms, and core banking applications, and its auditors test access to each of them every cycle. midPoint can run the joiner, mover and leaver, access review and segregation of duties controls on self-hosted infrastructure, provided the records are designed for re-performance from the start. The platform is an identity governance and administration (IGA) system, not an access management or SSO server. Evolveum states that midPoint does not implement the server side of OAuth2, OpenID Connect or SAML, so login for the midPoint user interface and for target applications is handled by a separate SSO product, and the design must show how those two layers hand over to each other.

What sets financial services apart is the combination of obligations that read the same access data. SOX IT general controls, as described in SEC Release 33-8810, cover access to programs and data in systems relevant to internal control over financial reporting. PCI DSS Requirement 7 requires need-to-know access, role-based approvals and periodic review of accounts for any cardholder data environment. DORA, which has applied since 17 January 2025, adds ICT risk rules on identity and access management and a register of contractual ICT arrangements. Before design starts, confirm with your SOX, PCI and DORA owners which systems fall under each regime, because the same midPoint role and certification data will be sampled differently by each. An auditor should be able to pick a user, a role or a review campaign and rebuild the outcome from midPoint's stored assignments, approvals, certification decisions and audit history, without asking the operations team to reconstruct it.

Which financial services access requirements shape the build

This table maps each financial services access requirement to its source and to what it means for a midPoint build. Read each row as a design input: the requirement sets the evidence midPoint must produce, and the build choices follow from it. Confirm the exact applicability of each framework with your compliance lead and assessor before scoping.

Requirement	Source	What it means for the midPoint build
Access to programs and data as an ITGC area	SEC Release 33-8810, SOX Section 404 guidance	Provisioning, removal and access reviews for financially significant applications must be traceable in midPoint, with approvals and changes logged for re-performance by auditors.
Need-to-know access and six-monthly review of accounts	PCI DSS v4.0.1, Requirement 7, applies where cardholder data environment access exists	Scope the midPoint connectors to systems inside the cardholder data environment, and schedule certification campaigns that cover all user and access rights at the required cadence. Confirm with your QSA whether the review evidence will be part of the Report on Compliance or a Self-Assessment Questionnaire.
Validation route for cardholder data scope	PCI SSC scope and FAQs; Report on Compliance or Self-Assessment Questionnaire with Attestation of Compliance	The midPoint scope document should define which identities and systems are in the cardholder data environment, since assessors examine that boundary before testing access controls.
ICT risk management for identity and access, applicable since 17 January 2025	DORA (Regulation (EU) 2022/2554), applies to 20 types of financial entity	Confirm whether your entity type is in scope. The identity management controls then need documented ownership, testing and evidence that supervisors can review.
Register of information on ICT contractual arrangements	DORA Article 28(3)	If an implementation partner or a hosting provider supports midPoint, record that arrangement in the register. Keep the midPoint configuration and runbooks available for that record.
Documented, tested exit strategies for critical or important functions	DORA Article 28(8)	Plan how midPoint configuration, role models, policies and audit history can be exported and moved if the platform or the support provider changes.
Contract terms on location, data processing and data return	DORA Article 30(2)	Any support contract for midPoint should state where administrative access and data processing occur, and how identity data is returned at termination. Ask the partner to confirm these terms in writing.
Multi-factor authentication for any individual accessing an information system	FTC Safeguards Rule, 16 CFR 314.4(c), for non-bank financial institutions under FTC jurisdiction	midPoint does not authenticate users to systems itself. Document which SSO or MFA service enforces MFA, and show that midPoint access requests and approvals depend on that authenticated identity.
Logging and monitoring of authorized user activity	FTC Safeguards Rule, 16 CFR 314.4(c)	Retain midPoint audit records for provisioning, role changes and certification decisions, and confirm with your team how long they must be kept and where they are stored.
Annual independent assessment of Swift CSP controls	Swift Customer Security Controls Framework v2026, 32 controls (26 mandatory, 6 advisory)	Where the controls cover access to Swift infrastructure, midPoint can produce account, role and review records for the assessor, but the independent assessor decides which controls are met.

How SOX access ITGCs translate into midPoint certifications and segregation of duties

Auditors testing SOX access controls look for four things in financially significant systems: approved provisioning, timely removal of leavers, periodic user access reviews and segregation of duties. The SEC's guidance on management's report on internal control (Release 33-8810) names access to programs and data as one of the IT general control areas relevant to Section 404 assessments, and the access controls that sit under it are where most identity governance work lands. Your organization decides how each of these controls is designed, including who approves what, how often reviews run and which conflicting role pairs are blocked. DeployOpen implements the configuration you specify and produces the evidence that the design operates. Independent auditors form the opinion.

In midPoint, the approval is captured in the access request workflow, where the requester, the approver and the requested role or resource are stored with timestamps. A certification campaign records each reviewer decision (keep, revoke or reduce) against a specific account or assignment, along with the reviewer identity and the campaign definition in force at the time. Segregation of duties rules are evaluated against the same assignments, so a request that would create a conflicting combination of roles can be flagged or blocked at the point of approval, and any exception can be traced to a named approver. Confirm with your own IT audit team which fields and reports your auditors expect, and test a sample campaign before it is relied on.

The population is the foundation of the test, so it must be exportable as of a point in time. An auditor who samples reviewed accounts needs the complete list of accounts and entitlements in scope on the campaign start date, not only the ones that were reviewed. Plan for a repeatable export of that population from midPoint, reconciled against the target system, such as the ERP or core banking application, so the count matches what the system itself reports. Ask your implementation partner how the snapshot is taken, how it is stored, and how a re-performance can be run months later. Agree that scope in writing before the first campaign, because a population that cannot be reproduced usually fails the test regardless of how well the reviews were done.

How PCI DSS and DORA change scope, review cadence and contract records

PCI DSS applies to entities that store, process or transmit cardholder data or sensitive authentication data, and to those that could affect the security of the cardholder data environment (CDE). Scope is set by where account data flows, not by the size of the organization, so identity governance should cover every account and group that can reach the CDE, including accounts that only touch systems which connect to it. Assessments are documented either as a Report on Compliance by a Qualified Security Assessor or as a Self-Assessment Questionnaire, each with an Attestation of Compliance, and the payment brands decide which route applies to a given entity.

CDE boundary in midPoint: Tag the directories, applications, databases and cloud projects inside the CDE as resources so that every entitlement there is visible in one place.
Six-monthly review of all user accounts and access: Schedule certification campaigns that cover every account and privilege in the CDE at least every six months, and keep the decisions as evidence.
Application and system accounts: Bring service and system accounts into the same inventory, with named owners, so reviews cover non-human access as well as people.
Need-to-know roles: Map roles to job functions and approval rules so the reviewer can see why each privilege exists.
Validation route: Confirm with the acquirer or payment brand whether a QSA assessment or a Self-Assessment Questionnaire applies, because that choice determines the evidence package.

Confirm the CDE scope, the review interval and the validation route with your QSA or acquirer before you design the campaigns.

Which open source platforms fit a financial services identity stack

A financial services identity stack usually separates the governance layer that decides who should have access from the layers that authenticate users and hold secrets. The cards below cover the core IGA platform, the workforce SSO front end, two alternatives to confirm, and the secrets and licensing checks that shape the design.

midPoint as the IGA core

midPoint is the component that holds joiner, mover and leaver rules, access requests, certification campaigns and segregation of duties policies, which are the records a SOX or PCI DSS assessor will ask to re-perform. It is licensed under EUPL-1.2, and Evolveum states it has no enterprise edition, so the licensing review is about the EUPL terms rather than a feature tier. Check the support path: the 4.8 Curie long-term support release is supported until 17 October 2028, and 4.10 until 26 November 2027. Plan the upgrade path before the 4.11 feature release, which is planned for 21 October 2026.

Keycloak as the SSO and MFA front end

Keycloak handles OpenID Connect, OAuth 2.0 and SAML 2.0 for applications, and it can federate LDAP and Active Directory users. It is the natural place to enforce multi-factor authentication for workforce logins, which the FTC Safeguards Rule requires for any individual accessing an information system unless a written equivalent control is approved. midPoint does not act as the SSO server, so the two must be designed together. Confirm which applications need federation versus direct provisioning, and test the MFA enrollment path for leavers.

authentik as an alternative front end

authentik is licensed under MIT, but its authentik/enterprise directory carries a separate enterprise license, so financial teams should map which features they need against that boundary before committing. It covers SSO and provider federation for workforce applications. Choose it only if your team already operates it and the required features sit in the MIT portion. Confirm with the vendor which capabilities you need, such as MFA policy options and SCIM provisioning to target applications, and test them against your application list.

ZITADEL as a multi-tenant alternative

ZITADEL is licensed under AGPL-3.0 and lists SSO, MFA, passkeys, OpenID Connect certification, SAML 2.0, SCIM and multi-tenancy. It fits institutions that run separate tenants for business units, subsidiaries or regulated entities under one identity service. The AGPL-3.0 network clause needs legal review when the platform is modified and offered to users, and it should be checked against internal policy. Confirm that its SCIM support covers your provisioning targets and that its audit logs meet your retention requirements.

OpenBao for service account secrets

OpenBao manages, stores and distributes secrets, certificates and keys, and it is licensed under MPL-2.0 and hosted under the OpenSSF. Its value in an IGA design is tying the lifecycle of service accounts and machine credentials to the same authoritative records midPoint uses, so a retired application account does not keep a live secret. Confirm how its key custody and audit logging fit your key management policy. HashiCorp Vault 1.15.0 and later uses the Business Source License 1.1 with IBM as licensor, which is not an OSI-approved open source license, so treat it as a commercial dependency in procurement.

Infisical and license boundaries

Infisical is licensed under MIT, but content in its ee directories carries a separate enterprise license. Teams that adopt it for secrets should confirm which features they use sit outside the enterprise directories, and record that boundary in their software inventory. The same review applies to any platform that splits a community and enterprise tier. Ask each vendor in writing which features require a commercial license, because the licensing split, not the headline license, determines what you can run in production without a separate agreement.

Deployment patterns for regulated financial workloads

A financial institution's identity governance platform has to sit inside its own accounts, networks and contracts, and the deployment shape determines how easily auditors can trace access decisions. The patterns below cover hosting, node layout, runtime packaging, network placement and third-party operation, and each one carries checks to settle before go-live.

Primary and recovery in your own estate

Run midPoint in the institution's own cloud account or data center, with a primary and a recovery site decided before build. Confirm where the central database replicates, who can start failover, and whether recovery data stays inside the same jurisdictional boundary as production. Auditors will ask how a provisioning queue is recovered after an outage, so document the recovery point and the steps to re-run pending provisioning and certification tasks. The recovery runbook must be tested before the platform is relied on for leaver removal.

Multi-node midPoint behind a load balancer

A multi-node deployment uses a sticky HTTP load balancer in front of several midPoint nodes that share one central database. Nodes invalidate caches between each other over HTTPS, and Quartz coordinates distributed task scheduling so a reconciliation job runs once rather than once per node. Confirm that the load balancer keeps administrator sessions on one node, that cache traffic is encrypted, and that Quartz tables are backed up with the database. Test a node failure during a certification campaign.

Linux virtual machine or Docker packaging

midPoint runs on Linux in a virtual machine or from Docker images. The choice affects patch cadence, image provenance and how change tickets reference the deployed build. A virtual machine suits teams that already manage hardened Linux baselines, while container images suit teams with an approved registry and signing process. Either way, record the exact midPoint and Java build in the change record, because auditors test whether the production build matches the tested one. Plan the Java runtime upgrade alongside the midPoint version.

Segmenting the cardholder data environment

If identity data or connector credentials reach systems in scope for PCI DSS, place midPoint, its PostgreSQL database and connector hosts in a segment that the assessor can define and test. Limit which hosts can reach directory services, card platform administration consoles and the database. Connector accounts should have the narrowest rights each target needs. Confirm with the QSA whether midPoint itself falls in scope or only the systems it grants access to, because that answer decides how much of the identity estate becomes assessed scope.

Data residency and contract terms for partner operations

When a partner operates the stack, DORA Article 30(2) requires the ICT services contract to state where services are provided and data processed, to give advance notice of changes, and to cover data return on insolvency or termination. Check that the contract names the hosting regions, the sub-processors with access to identity records and the exit assistance for midPoint configuration, role models and audit history. Ask for the exit plan that Article 28(8) requires for services supporting critical or important functions.

How the rollout moves from entitlement inventory to the first certified campaign

The sequence turns an unmapped set of accounts and entitlements into a midPoint-governed estate where each access decision can be re-performed from recorded evidence. Each phase closes with a named artifact that compliance, internal audit and the platform team sign off before the next phase starts.

Scope financially significant systems with compliance and audit
Compliance, internal audit, IT and the system owners agree which applications feed financial reporting, which carry cardholder data, and which fall under DORA ICT services. The team maps each in-scope system to the controls it must evidence, including SOX IT general control areas, PCI DSS Requirement 7 and DORA identity and access rules. The output is a signed control mapping and an in-scope system register that auditors have reviewed. Confirm early whether your auditors expect a specific sampling method, because it changes which logs and populations must be retained.
Discover entitlements and orphaned accounts
Read-only connectors pull accounts, groups, roles and privileged grants from each in-scope system and compare them with the authoritative HR source. The team classifies accounts with no owner, accounts tied to departed staff, shared and service accounts, and entitlements that exceed any documented job function. Owners confirm or reject each finding before anything is removed. The output is a reconciled entitlement inventory with a documented disposition for every orphaned account, which becomes the baseline auditors compare against later.
Build the role model and segregation of duties ruleset
Business owners and application owners group entitlements into roles tied to job functions, then define conflicting combinations that the ruleset must block or route for approval. Financial systems typically need rules such as separating payment initiation from payment approval or journal entry from journal review, and the team records each rule with its owner and rationale. Roles and SoD rules are reviewed by control owners before they are loaded into midPoint. The output is an approved role catalog and SoD policy document with version control.
Build connectors and automate joiner, mover and leaver events
The platform team configures midPoint connectors for each in-scope target system, using the ConnId-based connectors your inventory requires, and connects the HR source as the authoritative feed for joiners, movers and leavers. Test environments run the full lifecycle, including a mover whose role change must remove prior entitlements and a leaver whose access must be disabled on the effective date. Failed provisioning must surface as a tracked exception rather than silent drift. The output is a test record for each lifecycle event and each connector, signed off by the control owner.
Configure access request and approval flows
Access requests for roles and entitlements route through midPoint workflows to the named approver for each system, and any request that would trigger an SoD conflict goes to a designated risk approver. The team tests approval paths, delegation rules and rejection handling, and confirms that every approval records the requester, approver, justification and time. Emergency or break-glass access, if permitted, needs its own approval path and post-event review. The output is a test log of request scenarios showing that approvals and denials are recorded and that provisioning follows the approved decision.
Run the first certification campaign and assemble the evidence pack
The first campaign covers the in-scope population defined in the control mapping, with reviewers assigned by manager or application owner and each review item showing the entitlement, its role and any SoD flag. Reviewers approve, revoke or escalate, and midPoint applies revocations and records each decision. Reviewers who do not respond within the campaign window must be handled by an explicit escalation rule. The evidence pack contains the population extract, reviewer assignments, decisions, revocation tickets, exception approvals and the configuration version in force, so an auditor can re-perform the sample. The output is a closed campaign with a reconciled evidence pack.
Plan run operations and upgrades against the midPoint LTS cycle
Operations owners agree the recurring cadence for periodic reviews, connector monitoring, backup and restore tests, and access rule changes, and they assign owners for each. The platform team sets an upgrade plan that tracks the midPoint long-term support release in use, the feature releases between, and the Java and PostgreSQL versions that each release requires, with the support end dates listed in the release notes. Any upgrade is tested against the role model, SoD rules and connectors before production. The output is a run book, a maintained control calendar and a written upgrade policy that auditors can review.

Evidence an auditor or supervisor can re-perform from midPoint

This table maps each evidence item an assessor can ask for to the control it supports, the midPoint component that produces it, and what your team should confirm before the audit period starts. Read it as a checklist for designing reports, logs and exports, since the strength of each item depends on how the deployment is configured and retained.

Evidence	Control it supports	Component producing it	What to confirm
Population of accounts and entitlements at a date	SOX access controls over financially significant systems, PCI DSS user access review scope	midPoint reports and exports of users, roles and assignments, with connector-sourced account data	Whether reports can be run as of a past date, and that the population matches what target systems show
Approval records for provisioning and access requests	Approved provisioning, DORA access policy enforcement	midPoint workflow cases and the audit log of approvals, including approver identity and timestamp	That every target system is provisioned only through midPoint, so no request bypasses the approval record
Certification campaign definitions, reviewer decisions and remediation tickets	Periodic user access reviews, PCI DSS six-monthly review of all user accounts	Certification campaign objects, reviewer decision history and remediation actions recorded against each item	Campaign scope, reviewer assignment rules, and that revocations are actually applied on the target system and linked to tickets
Leaver removal timestamps against HR termination dates	Timely removal of leavers, DORA access revocation on termination	midPoint audit log of disable and delete actions, compared with the authoritative HR source record	Source feed frequency, handling of late or back-dated HR terminations, and the time zone used in timestamps
SoD rule definitions and violation reports	Segregation of duties in financially significant applications, SOX ITGC access review	Policy rule objects defining conflicting roles or entitlements, plus reports listing current and approved violations	Rule ownership, the approval trail for each accepted exception, and whether rules cover entitlements inside target applications
Connector and configuration change history	Change management over access logic, SOX program change controls	midPoint object history for resources, connectors, roles and policies, and the version control repository for exported configuration	Whether configuration is kept in version control with reviewed merges, and how emergency changes are recorded
Backup and restore tests of the repository	Recovery and availability of access records, retention of audit evidence	Database backups of the PostgreSQL repository and the restore test results documented by the operations team	Restore test frequency, retention period for audit logs, and whether restored data reproduces prior reports

What financial institutions ask before they run midPoint in production

Does midPoint have a license fee, and what does it actually cost to run?

midPoint has no license fee, and Evolveum states that it has no enterprise edition, so every line of its code is published under open source licenses. The cost sits elsewhere: connector and role-modeling work, cleanup of existing account data, infrastructure for the application and its PostgreSQL database, and support. Connector and role work is usually the largest variable because it depends on how many target systems you run and how well their access is documented. Ask any implementation partner to price these components separately in a written, fixed-scope quote, and ask which items recur each year, such as upgrades, support subscriptions and infrastructure.

How long does it take to reach a first access certification campaign?

The timeline depends on four things: how clean the authoritative HR source is, how many target systems need a connector, how much role modeling is required, and how quickly system owners review the entitlements that midPoint pulls in. A first campaign on a small, well-documented estate moves much faster than one that spans legacy applications with undocumented entitlements. Ask for a written plan that separates source data validation, connector build, role design and the first campaign, with a named owner and a sign-off point for each stage. Treat any timeline offered without those dependencies as an estimate to challenge.

What must the institution supply before the engagement starts?

The institution must supply four things: an authoritative HR or workforce feed that identifies joiners, movers and leavers, named system owners for each financially significant application, control owners who define the access policy and segregation of duties rules, and an audit sign-off path that agrees which evidence the external auditor will accept. Without the HR feed, joiner and leaver rules cannot be tested, and without control owners, reviews have no defined approver. Ask the partner to produce a responsibility matrix in the statement of work so each of these gaps is visible before work begins.

Can our internal team run midPoint after the implementation?

Yes, many institutions operate midPoint with internal staff, but the team needs Java and PostgreSQL skills, experience with the ConnId connectors you deploy, and an understanding of identity lifecycle design. midPoint recommends Java 25 for version 4.11 and later and Java 21 for 4.10 and older, so the team must plan upgrades against the release calendar. Decide early which tasks stay in-house, such as routine certification campaigns and role maintenance, and which go to a partner, such as connector development and major upgrades. DeployOpen offers ongoing support, upgrades and documentation as retainers, and its scope for any handover is set out in writing.

Can midPoint replace our single sign-on server?

No. Evolveum states that midPoint is an identity management system, not an access management or SSO server, and that it does not implement the server side of OAuth2, OpenID Connect or SAML. Its own user interface can authenticate against an external SSO service, but authentication for your applications still needs a separate product such as Keycloak, authentik or ZITADEL. In practice, midPoint provisions accounts and governs access, while the SSO server issues tokens and enforces login. Confirm the division of responsibilities in the architecture review so audit evidence for authentication and for entitlement approval comes from the right systems.

What does a midPoint support subscription cover, and what does it not?

Evolveum offers Product Support subscriptions that resolve product bugs, with an 8x5 next-business-day or 24x7 service level, and Platform Subscriptions that add feature development and influence over the roadmap. The Evolveum support page lists no prices, so you need a written quote for the tier you need. A product support subscription does not cover your connector configuration, role model, data cleanup or custom integrations, which are implementation work. Ask which tier matches your audit calendar, how long a critical defect takes to reach a response, and whether the support terms cover the long-term support release you plan to run.

Which midPoint release should a regulated institution run in production?

For a production deployment in a regulated setting, the long-term support release is usually the safer starting point because it receives a longer support window. The midPoint releases page lists midPoint 4.8 (Curie) as a long-term support release supported until 17 October 2028, midPoint 4.10 (Braille) as a feature release supported until 26 November 2027, and midPoint 4.9 with support ending 18 October 2026. Confirm with Evolveum and your partner which release fits your Java and database standards, and plan the upgrade path before your first audit cycle. Ask the partner how they test upgrades in a non-production environment before any change reaches the control evidence.

How do we keep evidence that an auditor can re-perform?

Evidence is re-performable when the population, the sampling basis and the reviewer decisions are all recorded in a way the auditor can reproduce. In midPoint this means keeping the entitlement snapshots used for each certification campaign, the reviewer decisions with timestamps, the approval history for access requests and the records of removals for leavers. Ask the partner to show how these records are exported, how they are protected against change, and how long they are retained under your policy. Confirm the exact evidence format with your external auditor before the first campaign, since they decide what they accept.

Questions to ask an implementation partner before signing

Start with the evidence design, because it determines how much of the project an auditor can re-perform. Ask the partner to show, using a sample campaign, how a midPoint certification record links the reviewer, the reviewed entitlement, the decision, the timestamp and the removal task that followed. Ask who owns the segregation of duties ruleset, how conflicts are defined for each financially significant application, and who approves changes to those rules. A partner who answers that the rules live in a configuration file maintained by the project team has not yet described an ownership model. Ask also how orphaned accounts are found and cleaned before go-live, including which accounts are disabled, which are reassigned and who signs off each decision, since a clean starting population is what a SOX access review depends on.

Ask how connectors for the mainframe and core banking platforms will be scoped. Midpoint reaches these systems through its ConnId connector framework, and the documented connectors include LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID and SCIM2, so ask which target systems need custom or scripted connectors, who builds and tests them, and who maintains them after an application upgrade. For DORA, ask how the partner will produce inputs for the register of information under Article 28(3) and the documented exit strategy under Article 28(8), and whether those inputs will come from the identity platform's own configuration and records or from documents written by hand. Confirm the scope of any contract clauses drafted for Article 30(2), which the financial entity's legal team owns.

Ask how long-term support upgrades will be scheduled, which midPoint release line is proposed, and who tests the upgrade against your connectors. The midPoint releases page lists 4.8 as long-term support until 17 October 2028, so ask what happens when that date approaches. Ask who holds the administrator keys, the database credentials and the backup encryption keys, and how backups are restored and tested. Finally, ask that the statement of work fix scope, deliverables, connectors, exclusions and acceptance criteria in writing before work starts. DeployOpen does not issue audit reports, attestations or certifications, so ask the partner to name the independent auditor or assessor who will review the evidence and to confirm that the evidence package will be prepared for that review.