Open source identity governance for public sector: why agencies build it differently
midPoint is a candidate identity governance and administration (IGA) platform for a self-hosted public sector deployment, but its fit depends on three things: the connectors your legacy estate needs, the role model you can defend, and the sovereignty rules that decide where the data and the software can run. Most agencies start with HR as the authoritative source, dozens of applications that each hold their own accounts, and auditors asking how account creation, change and removal are approved and evidenced under NIST SP 800-53 control AC-2 or an equivalent catalog. Federal bodies work from the SP 800-53 baselines defined in SP 800-53B, and under FISMA the Inspectors General test the resulting evidence. State and local bodies often answer to a state framework built on similar controls, and EU public bodies face NIS2, where public administration is a sector of high criticality and central government entities are in scope regardless of size.
Sector differences shape the design more than the software does. Federal agencies that place identity data in a cloud service must consider FedRAMP scope under OMB M-24-15, and workloads that touch criminal justice information fall under the FBI CJIS Security Policy, which the California DOJ bulletin describes as version 6.1 effective 26 June 2026. Data residency and EU sovereignty requirements often favor an on-premises or national-cloud deployment, which is where an open source platform helps. The EUPL-1.2 license of midPoint gives EU public bodies access to the source code without a license fee, but licensing does not settle support, upgrade or security obligations. Confirm with your legal and procurement teams which support model you need before choosing a path.
The platform answer is narrower than many teams expect. midPoint is an identity management system, not an access management or SSO server, and Evolveum states that it does not implement the server side of OAuth2, OpenID Connect or SAML. Your workforce single sign-on must come from a separate product, and midPoint can only authenticate its own user interface against an external SSO service. Before scoping, ask the candidate partner to list every target system, the connector each one uses (confirm whether it is a supported, community or experimental connector in the Evolveum connector catalog), and how they will model roles from existing access. Those answers, not the license, will determine the cost and timeline.
Which public sector requirements shape the identity governance build
This table maps the public sector requirements most likely to shape an identity governance build to what each one means for systems in scope, cryptographic modules, hosting location and review cadence. Read each row as a question to answer before design starts, since the applicable set depends on the agency, its data and its contracts.
| Requirement | What it means for the build | Evidence to prepare |
|---|---|---|
| NIST SP 800-53 Rev. 5 AC-2 (account management) | Every account type, creation, change and removal path in the access boundary must be defined, including service and privileged accounts; baseline selection in SP 800-53B (149 low, 287 moderate, 370 high controls and enhancements) sets how many of these apply | Account lifecycle procedures, account inventory mapped to the authorization boundary, and records of approvals and removals |
| FISMA and Inspector General assessment | Agency systems are assessed independently and reported to OMB, so the IGA platform and its connected systems need documented boundaries, owners and tested procedures that an outside reviewer can follow | System boundary diagrams, control implementation statements and test results for the access processes |
| FedRAMP scope under OMB M-24-15 | A cloud-hosted IGA service that stores or processes federal information for an agency falls in scope; a self-hosted midPoint deployment in the agency's own infrastructure avoids that path but still needs an accurate hosting statement | Hosting location record, provider authorization status where a cloud service is used, and data flow diagrams |
| FBI CJIS Security Policy v6.1 | Where identity data touches criminal justice information, encryption must use FIPS 140-3 validated modules or FIPS 197 AES at 256-bit keys in transit and at rest outside secure locations, and vulnerability scanning runs at least monthly | Cryptographic module inventory, scan schedules and results, and records of who can reach CJI through provisioned roles |
| 32 CFR 2002.14(h)(2) and NIST SP 800-171 for CUI | Agencies set NIST SP 800-171 requirements for controlled unclassified information on non-federal systems, so contractor-run identity systems that reach CUI inherit those requirements unless another authority prescribes different safeguards | Contract clauses naming the applicable safeguards, scoping of CUI-bearing roles, and access review records |
| NIS2 coverage of public administration (EU) | Central government entities fall under NIS2 regardless of size, and Member States may extend coverage to local administration; entities in national security, defense, public security or law enforcement are excluded, so confirm the national transposition before scoping | Confirmation of the entity's NIS2 status from the national authority, risk management measures covering access, and incident records |
| WCAG 2.1 Level A and AA for access request portals (ADA Title II) | Self-service access request and approval screens, including those supplied through contracts, must meet WCAG 2.1 A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts (28 CFR 35.200) | Accessibility test results for request and approval screens, remediation log and conformance statement reviewed by the agency |
| Review cadence and approval evidence (agency policy) | Cadence for certifications and privileged reviews is set by the agency's own policy and the baseline controls it adopts, so the build should make cadence configurable rather than fixed in code | Written review schedule, campaign records, reviewer decisions and remediation tickets for removed access |
How HR-driven joiner, mover and leaver rules work across legacy systems
For a public body, the HR system or position register should be the authoritative source for every joiner, mover and leaver event, and midPoint should treat it that way. Accounts follow positions and employment status, not the other way round, so an identity that exists in a target system without a matching HR record is a finding, not a valid account. Before design starts, confirm with HR which field is the system of record for employment status, position number, department and organizational unit, and whether contractors, secondees and volunteers are recorded there at all. Where they are not, the identity owner must be named in writing, because midPoint cannot certify what has no authoritative source.
Mover events in the public sector carry more meaning than a department change. A transfer may come with a new grade or statutory role, a secondment keeps the person employed by one body while placing them in another, and an elected or appointed role can grant time-limited authority that must end on a fixed date. Role rules should therefore separate the base entitlement that follows employment from position-bound and time-limited roles that need an end date and a named approver. Confirm with each body's legal and records teams which roles must be removed on transfer, which may be retained during a secondment, and who signs off the exception. These rules are usually more intricate than private sector templates assume.
Many public bodies still run case management, payroll, benefits and document systems that lack modern provisioning APIs. For these, midPoint's CSV, DatabaseTable, ScriptedSQL and LDAP connectors, described in the Evolveum connectors documentation, are often the practical route, and Active Directory and Microsoft Entra ID are covered by their own connectors. The connector catalog lists support status from supported through community to experimental, so each target system must be confirmed against its exact connector and version before go-live, with a test that creates, changes and removes an account. Before the first certification campaign, reconcile accounts left in prior directories against the HR population, classify orphans as disable, reassign or retain with a named owner, and remove what nobody claims.
Which identity platform pairs with midPoint in each public sector scenario
Many agencies already authenticate staff against Active Directory or an LDAP directory, and that directory usually remains the system of record for logons. In this scenario midPoint sits beside the directory as the governance layer. It reads HR-driven identities, provisions accounts and group memberships through its LDAP and Active Directory connectors, and runs the access requests and certifications that the directory alone does not provide. An SSO server is only needed when web applications must accept directory logins through modern protocols.
- Directory stays authoritative for logon: midPoint does not replace Active Directory or LDAP, so existing Kerberos and Windows logon behavior does not change.
- Keycloak as the broker: Keycloak, licensed under Apache-2.0, can federate LDAP and Active Directory users and issue OpenID Connect or SAML 2.0 tokens to web applications.
- authentik as an alternative: authentik is licensed under MIT, with its enterprise directory under a separate license, and can also front directory sources for applications.
- Connector scope: confirm which attributes, nested groups and service accounts midPoint must manage, since these shape the connector design more than the SSO choice does.
- Lifecycle ownership: agree which system disables an account on departure, the directory or midPoint, so two systems do not conflict.
Check with your directory team whether federation or SCIM patterns are needed, and confirm each SSO server's current capabilities against its documentation during design.
An EU public body that must keep identity inside its own infrastructure often needs a self-hosted SSO server in addition to midPoint, because midPoint is an identity governance system rather than an access management server. midPoint does not implement the server side of OAuth 2.0, OpenID Connect or SAML, so the SSO layer has to be chosen separately. The licensing of each option matters to procurement, since midPoint itself is published under the EUPL-1.2 with Apache 2.0 as a secondary license.
- Keycloak: Apache-2.0, a Cloud Native Computing Foundation incubation project, supporting OpenID Connect, OAuth 2.0, SAML 2.0 and LDAP or Active Directory federation.
- ZITADEL: AGPL-3.0, with SSO, multi-factor authentication, passkeys, OpenID Connect certification, SAML 2.0 and SCIM listed in its README.
- authentik: MIT for the core, with a separate enterprise license for the authentik/enterprise directory.
- Ory Hydra with Ory Kratos: Apache-2.0, which splits the OAuth 2.0 and OpenID Connect server from identity management, so more integration work falls to the implementer.
- SCIM or federation pattern: Keycloak and ZITADEL both support provisioning or federation patterns with midPoint, but the exact pattern must be confirmed in design rather than assumed.
Ask each shortlisted vendor or implementation partner to demonstrate the exact SCIM or federation flow with midPoint and to document the license terms that apply to the features you need.
Some public bodies must authenticate citizens, businesses or external users while keeping staff identities in a separate governed directory. In this scenario midPoint governs workforce and administrative accounts, and a separate customer identity platform handles registration, login and assurance for the public. Mixing the two populations in one store usually complicates retention rules, privacy obligations and the certification campaigns that auditors expect for staff access.
- Workforce identity in midPoint: joiner, mover and leaver rules, role models, access requests and certifications apply only to employees, contractors and administrators.
- Customer identity on a separate platform: ZITADEL, Keycloak or Ory are commonly evaluated for this role, and each has its own license and feature set that must be checked.
- Separate trust boundaries: keep administrative consoles and citizen login on distinct realms or tenants so a staff account cannot be used on the public service.
- Integration seams: define how a staff member who also holds a citizen account is linked or kept apart, and who approves that link.
- Retention and privacy: agree with counsel which data each platform holds, how long it is kept, and how deletion requests are fulfilled.
Confirm with your data protection officer and records team which population each platform covers before selecting an SSO product for the public side.
Why midPoint fits public bodies and what else belongs in the stack
Public bodies usually need an identity governance platform, a single sign-on server and a secrets store, and each carries its own license terms. The cards below cover the components that connect to midPoint and the license questions procurement and legal teams should settle before selecting them.
midPoint under EUPL-1.2
midPoint is the identity governance and administration platform in this stack, and its repository is licensed under the European Union Public License 1.2 or later, with Apache 2.0 as a secondary license. Evolveum states that midPoint has no enterprise edition and that every line of its code is published under open source licenses. Public bodies that modify midPoint and distribute the modified code should have counsel confirm what the EUPL obligates them to publish. Ask the implementation partner which changes are configuration and which are code.
midPoint LTS planning
The 4.8 Curie release is a long-term support release with support until 17 October 2028, which gives a public body a fixed window to plan around. The 4.9 release reaches end of support on 18 October 2026, and 4.10 is a feature release supported until 26 November 2027. Confirm the upgrade path from the current production version to 4.8 before a go-live date is committed. Evolveum's paid support subscriptions cover product bugs, so confirm which tier your body needs.
Keycloak for SSO and federation
midPoint does not implement the server side of OAuth 2.0, OpenID Connect or SAML, so a public body needs a separate SSO server for applications. Keycloak is licensed under Apache-2.0 and supports OpenID Connect, OAuth 2.0, SAML 2.0 and LDAP and Active Directory user federation, which lets it sit against existing directories. Decide early which system is authoritative for passwords, sessions and MFA, and confirm how Keycloak and midPoint will share account state for disabling access when staff leave.
ZITADEL for passkeys and SCIM
ZITADEL is licensed under AGPL-3.0 and lists SSO, MFA, passkeys (FIDO2 and WebAuthn), OpenID Connect certification, SAML 2.0 and SCIM in its README. Those SCIM capabilities are a possible provisioning path alongside midPoint's own SCIM2 connector. The AGPL-3.0 network clause means a public body that offers modified ZITADEL features to users over a network must review its obligations with counsel. Confirm passkey support for each device class your staff use before committing to it.
OpenBao for secrets IGA depends on
Connector accounts that midPoint uses to read and write target systems need credentials, and those credentials should not sit in configuration files. OpenBao is licensed under MPL-2.0 and manages, stores and distributes secrets, certificates and keys, and it is hosted under the OpenSSF. Because it stores the credentials for midPoint's connectors, its own access controls and audit records belong in the same review scope. Confirm how the connector credentials will be rotated and who can read them.
Vault 1.15.0 and the BSL trap
HashiCorp Vault version 1.15.0 and later is licensed under the Business Source License 1.1 with IBM named as licensor, which is not an OSI-approved open source license. A public body that standardizes on Vault for connector credentials may face procurement rules that require OSI-approved licenses. Ask any partner to confirm the license of each component in the secrets path, and check whether earlier Vault versions or OpenBao fit the policy. Document the decision for your open source review board.
How a public sector midPoint rollout moves from source inventory to first certification
The sequence turns scattered HR feeds, legacy accounts and unmodeled entitlements into a governed identity baseline, then proves that baseline with a first access certification campaign that agency owners can sign off. Each phase closes with a written output that the next phase depends on.
Inventory authoritative sources and target systems
The team lists every authoritative HR or personnel source, every target system that holds accounts, and the named business owner for each. DeployOpen typically runs this as a workshop with HR, agency application owners and the security team, and the output is a source and target register with owners, data fields and account types. The step is done when each target system has one accountable owner and each joiner, mover and leaver trigger has a named source of truth. Confirm with your own HR system team which feeds are authoritative and which are copies.
Model roles from existing entitlements
Engineers extract current group memberships, application roles and direct grants from the target systems and cluster them into candidate business roles with the application owners. Roles are drafted in midPoint with clear naming, owners and the entitlements each one grants. The output is an approved role catalog with a documented rule for each role, and the step closes when owners confirm that every high-risk entitlement maps to a named role or is flagged for a decision.
Build and test connectors in a non-production environment
Engineers configure ConnId-based connectors for each target system, such as LDAP, Active Directory, Microsoft Entra ID, SCIM2 or database connectors, in a staging midPoint deployment that mirrors production. They test create, update, disable and delete operations against test accounts and confirm that reconciliation reads what the target actually holds. The output is a test record for each connector, and the step is complete when every connector passes its defined test cases and the agency owners accept the results. Confirm the connector status in the Evolveum catalog before relying on any community or experimental connector.
Clean up orphaned and excess access
Before production synchronization, the team reconciles accounts in each target against the HR source to find orphaned accounts with no matching person, accounts of former staff and entitlements that no role explains. Owners decide whether to disable, retain with a documented reason or migrate each item. The output is a signed cleanup register that records each decision, and the step closes when the remaining unexplained access falls to a level the owners accept in writing. Public sector agencies often find legacy and shared accounts here, so plan time for those reviews.
Sign off joiner, mover and leaver rules
HR and the security team jointly define how a new hire, a transfer and a departure change access. The rules state which events trigger provisioning, which roles are granted by default, how a move removes prior access, and how a leaver is disabled and when access is removed. Rules are written as decisions a reviewer can test, not as informal practice. The output is a signed rule set mapped to midPoint policies, and the step is done when HR and security have each approved it and a test population of sample events produces the expected results.
Configure approval and request workflows
The team configures access request forms, approval chains and escalation paths in midPoint, including who approves privileged or sensitive roles and what happens when an approver is unavailable. Segregation rules for conflicting roles are added where the agency defines them. The output is a documented workflow catalog with approvers named by role, and the step closes when test requests move through each path and each approval is recorded with the requester, approver and decision.
Run the first certification campaign
The team defines the population, reviewers and scope for the first access certification campaign, then routes review items to managers and application owners. Reviewers approve, revoke or flag each entitlement, and midPoint applies the revocations to the connected systems. The output is a completed campaign record with decisions, reviewer identities and timestamps, and the step closes when unresolved items are escalated and the agency accepts the campaign report as the baseline for recurring reviews.
Plan the long-term support upgrade path
Before go-live, the team records the midPoint version, Java runtime, PostgreSQL version and connector versions in use, then sets a plan for applying patches and moving to later releases. The plan is tied to the published support dates for the chosen long-term support release and to any supported subscription terms. The output is a written upgrade runbook with a test environment, rollback steps and an owner, and the step is complete when the team has walked through one upgrade in staging. Confirm current support dates and Java requirements on the Evolveum release pages before you commit.
What auditors and inspectors ask for and which midPoint records produce it
This table maps the records an agency's auditors and inspectors typically request to the midPoint, connector, database and SSO components that hold them. Read each row as a question to answer before the audit: where the record lives, how long it survives, and what the auditor still has to accept.
| Evidence requested | Where it comes from | What the agency must confirm with its auditor |
|---|---|---|
| Account management population (AC-2 account inventory) | midPoint user and account objects, reconciled against each target system through connectors such as LDAP, Active Directory or Entra ID | Whether the auditor accepts the midPoint export as the complete population, or wants a direct extract from each target system for comparison |
| Provisioning and deprovisioning request records | midPoint audit records of change and task execution, plus connector logs showing the outcome in each target system | Which timestamps count as the request time and the completion time, and whether a leaver's removal must be evidenced in every connected system |
| Approval evidence for access requests | midPoint workflow and case records showing the requester, approver, decision and time for each access request | Whether approvals made outside midPoint, by email or ticket, must be linked to records inside midPoint and how they are referenced |
| Periodic certification campaign results | midPoint certification campaign definitions, reviewer decisions, revocations and completion status | The review cadence the auditor expects, who may act as reviewer, and how the auditor will sample decisions and follow up on revoked access |
| Orphaned account reports | midPoint reconciliation results listing accounts in target systems with no matching identity or owner | The remediation deadline the auditor will accept for orphaned accounts and the evidence needed to show each one was closed |
| Access change logs and retention | midPoint audit tables and connector logs stored in PostgreSQL, with SSO sign-in logs from the authentication server | The retention period the agency's records schedule requires, how logs are protected from change, and whether SSO logs are in scope for the same review |
What public bodies ask before engaging an identity governance partner
What drives the cost of open source identity governance for a public body?
Cost comes from the work around the software, not from a midPoint license. The main components are connector work for each target system, role modeling from existing access, cleanup of the accounts and entitlements that already exist, hosting in your own environment, and support. Connector count and the number of legacy systems fed from HR usually move the cost most. Ask a partner to price each component separately in the written scope, and ask which parts are one-time (design, connectors, cleanup, go-live) and which recur (hosting, upgrades, support, certification cycles).
Does midPoint carry a license fee for public sector use?
Evolveum states that midPoint has no enterprise edition and that every line of its code is published under open source licenses, so there is no product license fee to budget. Evolveum does sell support: its Product Support subscriptions cover resolving product bugs with an 8x5 next-business-day or 24x7 SLA, and its Platform Subscriptions add feature development and roadmap influence. Evolveum's support page lists no prices, so request a quote for the tier your agency needs and confirm which release line it covers.
How long does it take to run the first access certification?
No fixed duration applies to every agency, and no figure is given here. The first certification depends on how many source systems feed the campaign, how clean the existing accounts are, whether a role model exists, and how many reviewers a campaign will reach. An agency with a single authoritative HR source and few target systems will move faster than one with several legacy directories and unowned accounts. Ask a partner for a written timeline tied to named milestones, including the data cleanup and reviewer training that often set the pace.
What must agency staff provide before an engagement starts?
Agency staff provide the decisions and the data that no partner can supply. That includes the authoritative HR source and its joiner, mover and leaver events, an inventory of target systems with their owners, named business owners for applications and roles, and the account-management rules your policy already sets. Staff also need access to test environments, a sponsor who can settle role disputes, and reviewers available during the campaign. Confirm these responsibilities in the written scope so that delays are attributable.
Can our agency run midPoint in-house after the engagement?
Yes, a public body can operate midPoint itself, and the software does not restrict who runs it. The skills required are Java application operation, PostgreSQL administration, Linux or Docker hosting, and a working knowledge of the ConnId connectors your targets use. midPoint recommends Java 25 for version 4.11 and later and Java 21 for 4.10 and older, and it uses PostgreSQL as its native repository database, ideally on a separate server. Ask a partner to document the runbook, handover and upgrade plan so in-house staff can take over, and use the long-term support release line where continuity matters.
How does the EUPL affect procurement for EU public bodies?
midPoint's repository is licensed under the European Union Public License (EUPL-1.2) with Apache 2.0 as a secondary license, so the software can be used, modified and redistributed under open terms without a per-user license purchase. Procurement teams should focus on the services contract: implementation, connectors, support subscriptions and hosting. Confirm with your legal team how the EUPL interacts with your own distribution and modification obligations, and ask the partner to state which deliverables, custom connectors and code will be handed over under which license.
How do FedRAMP and NIS2 scope change where identity governance is hosted?
Hosting depends on whether the system falls inside a cloud authorization scope, and that question must be answered before architecture work starts. FedRAMP covers cloud products that create, collect, process, store or maintain federal information on behalf of an agency, while systems used only for a single agency's operations on cloud infrastructure and not offered as a shared service are out of scope. NIS2 covers central government entities regardless of size and lists public administration as a sector of high criticality, with national security, defense and law enforcement excluded. Ask counsel and the agency's security office to confirm the classification, then have the partner design hosting inside that boundary.
Which NIST controls does an identity governance platform support for agencies?
Identity governance mainly supports the account management control in NIST SP 800-53 Rev. 5, AC-2, which covers account creation, modification, review and removal. Under the current Release 5.2.0 of 27 August 2025, SP 800-53B selects 149, 287 and 370 controls and enhancements for the low, moderate and high baselines respectively. Agencies working under FISMA will have inspectors general test these controls, so the partner should map each join, move and leave rule and each review to specific AC-2 expectations. Confirm the baseline with your authorizing official before design begins.
Questions to ask an implementation partner before signing a public sector scope
Start with the role model, because public sector access is rarely clean. Ask the partner how they will derive roles from the access that staff hold today across the directory, the case management system, the finance platform and the shared drives, and who signs off each role definition. Ask for an example of a role catalog they have built for a comparable agency or body, with the reasoning behind each role, and whether the role owners in your organization will approve it before any connector writes to a target system. Then ask which midPoint connectors they have run in production against legacy systems (for example LDAP, Active Directory, CSV, DatabaseTable or SCIM2, as documented in the Evolveum connector catalog) and which ones they would build or script for your estate. A connector listed as community or experimental in the catalog is a scope risk that should appear in the written statement of work.
Next, ask how they will clear orphaned and excess accounts before the first automated run, and what they will not touch until a named owner confirms it. A good answer describes a reconciliation report per system, a decision log for every account that has no authoritative HR record, and a rule for shared service and break-glass accounts. Ask how certification campaigns will be run and evidenced: which reviewers receive which entitlements, how decisions are recorded in midPoint, how revoked access is traced back to a provisioning task, and what export an internal auditor or the Inspector General's team can re-perform. On the SSO side, confirm that the partner understands that midPoint is an identity management system and does not act as the OAuth 2.0, OpenID Connect or SAML server, so the design must name the SSO product (for example Keycloak or authentik) and the attribute flow between them.
Finally, ask about lifecycle and location. Request the partner's plan for the midPoint 4.8 Curie long-term support date of 17 October 2028, including how they will schedule the move to a later LTS or feature release, which Java version (25 for 4.11 and later, 21 for 4.10 and older) they will certify, and who tests the upgrade against your connectors. Confirm where the environment, backups and logs will sit, whether it is in your data center or a cloud account you control, and which jurisdiction holds any copy of personnel data. Ask who in the partner's team can reach production, how that access is approved and logged, whether staff are located in the same country, and how they will support any requirement that treats the environment as a system holding federal or criminal justice information. Ask the partner to put each answer into the written scope.
How DeployOpen scopes and supports public sector identity governance
The sequence below shows how a public body moves from an initial conversation to a written, fixed-scope agreement, a self-hosted midPoint deployment inside its own infrastructure, and an evidence package that its own assessors and auditors can review. Each step ends with a named output the client can check before the next step begins.
Confirm scope and authoritative sources
DeployOpen starts with a discovery conversation covering the bodies in scope, the HR system that will act as the authoritative source for joiners, movers and leavers, the directories in use, and the applications that hold accounts. The agency's security, HR and records owners confirm which systems are in scope and which federal, state or EU obligations apply, such as NIST SP 800-53 control families for the target baseline or NIS2 obligations where the body falls under it. The output is a written list of in-scope systems, owners and assumptions that the client signs off before any quote is issued.
Agree a fixed-scope written statement of work
Once scope is clear, DeployOpen issues a written statement of work that lists deliverables, responsibilities, client-side dependencies such as connector access and test accounts, and the acceptance criteria for each phase. Most engagements are fixed-scope, so changes go through a written change request rather than open-ended hours. Procurement teams should ask for the scope exclusions in writing, including which connectors are built and which are only scoped. The output is a signed statement of work that defines what the client receives.
Assess the estate and clean up accounts
DeployOpen reviews the existing directories and target systems to find orphaned accounts, shared or service accounts without owners, and excess entitlements that would otherwise be imported into midPoint as if they were valid. Findings are agreed with the agency's data owners, who decide which accounts are retired, reassigned or kept with a documented reason. The output is a reconciliation report and an agreed remediation list that becomes the baseline for the first access certification.
Deploy midPoint inside the agency's infrastructure
DeployOpen installs midPoint in the client's own environment, whether a government cloud tenancy, a data center or an air-gapped network, using the supported Java and PostgreSQL versions for the release chosen. For multi-node designs, the build covers a sticky HTTP load balancer, a shared central database and inter-node cache invalidation. The client keeps administrative control of the infrastructure and data. The output is a documented, running environment with build records that the agency's security team can inspect.
Build connectors, role model and approval flows
DeployOpen configures ConnId-based connectors to the HR source and each target system, then models roles and approval flows with the business owners who will operate them. Where a connector is community or experimental in the catalog rather than supported, DeployOpen identifies the gap and agrees the approach in writing before build. Testing covers joiner, mover and leaver scenarios in a non-production environment with recorded results. The output is a tested set of connectors, role definitions and approval rules signed off by the named owners.
Prepare evidence for assessments
DeployOpen configures the reports, certification campaigns and audit records that the agency needs to show how accounts are approved, changed and removed. The work maps these outputs to the control families the agency is assessed against, and it documents what each piece of evidence shows and where it is stored. DeployOpen prepares systems, controls and evidence but does not issue audit reports, attestations or certifications, so the agency's assessors and auditors decide what the evidence supports. The output is an evidence pack and a control mapping that the client's assessors can review.
Hand over, document and move to retainer support
DeployOpen delivers operating runbooks, configuration documentation, backup and restore procedures, and an upgrade plan that accounts for the long-term support and feature release cycle of midPoint. Staff are trained on operating the platform and running the first certification campaign. Ongoing upgrades, support and continuous testing can be covered by a retainer agreed in writing. The output is an accepted handover package and, where chosen, a signed retainer that defines response expectations.
