Why HR-driven provisioning changes the identity build in regulated firms
For a regulated finance team running self-hosted HR and payroll, the HR record should drive joiners, movers and leavers, with midPoint handling identity governance and provisioning and Keycloak handling login and token issuance. The HR record is the authoritative employment event: a hire, transfer, pay change or termination in Frappe HR or OrangeHRM is what should create, change or disable accounts, rather than a ticket raised by a manager. midPoint, an identity governance and administration platform written in Java by Evolveum, reads that employment data, decides what access follows from it and pushes accounts to target systems through its connector framework. It is not an SSO server. Keycloak, an open source identity and access management server, is where users authenticate and where OpenID Connect or SAML tokens are issued to applications.
The separation matters for audit. midPoint keeps the record of who was granted what and why, and Keycloak reflects the resulting accounts, roles and sessions. Before design starts, confirm which HR fields are reliable enough to act on: employee ID, legal and org unit, manager, employment status, effective dates and contract type. Confirm also whether the HR system emits change events or whether midPoint must poll it, and who approves exceptions such as rehires or contractors who have no HR record. Those answers determine how much of the flow is automated and which joiner, mover and leaver rules you must write and test.
The scope of the build depends on the HR data model. A firm with one legal entity and clean job codes needs a simple mapping, while a firm with multiple entities, matrixed reporting lines or payroll-only staff needs more rules, more reconciliation and more test cases. Ask your implementation partner to show the attribute mapping from your HR schema to midPoint, a list of the applications that will receive accounts, and the process for correcting HR data that disagrees with directory records. Platform versions also matter: midPoint release support windows and Keycloak upgrade practice should be checked against your change management policy before you commit to a design.
What the requirements mean for the provisioning build
This table maps the FTC Safeguards Rule controls, the testing cadence in 16 CFR 314.4(d)(2), and SEC Rule 17a-4(b) to specific provisioning build decisions. Read each row as a design question: what the joiner, mover and leaver flow must do, and what evidence your team should be able to produce on request.
| Requirement | What it means for the provisioning build | Evidence to keep |
|---|---|---|
| Multi-factor authentication for any individual accessing a system (16 CFR 314.4) | Accounts created from HR records must enforce MFA at the Keycloak realm or client level from the first login, and provisioning should not grant a role that bypasses it. Confirm which accounts, including service and break-glass accounts, are exempted and why. | Keycloak realm and client authentication settings, export of required-action configuration, list of exempted accounts with approvals |
| Timely deprovisioning of leavers (16 CFR 314.4 access controls) | A leaver event in the HR system should disable Keycloak sessions and connected accounts in midPoint-managed targets without waiting for a manual ticket. Define the trigger, the expected processing path and who is alerted when a task fails. | midPoint task history for leaver events, failed-task alerts, reconciliation reports showing disabled accounts |
| Access reviews for movers (16 CFR 314.4 access controls) | A transfer changes the employee's HR attributes, so midPoint must recompute role assignments rather than only add new ones. Build a periodic review of retained access against the new job, and confirm that old entitlements are removed or re-certified. | Role assignment history per identity, certification campaign results, exceptions list with owner and date |
| Change management on attribute mappings and roles (16 CFR 314.4 change management) | Mappings from HR fields to midPoint roles and Keycloak groups are controlled configuration. Each change to a mapping, role definition or connector should go through a documented review and be applied from version-controlled configuration. | Versioned mapping files, change tickets with approvals, deployment logs for each midPoint and Keycloak configuration change |
| Logging of provisioning actions by authorized users and processes (16 CFR 314.4 logging) | Every create, modify, disable and delete action taken by midPoint against Keycloak or other targets should be logged with the source HR record, the actor and the outcome. Confirm that logs are forwarded to a central store with retention set by your policy. | Provisioning audit log samples, log forwarding configuration, retention settings, access list for log readers |
| Encryption of customer information in transit and at rest (16 CFR 314.4) | HR-to-midPoint, midPoint-to-Keycloak and connector traffic should use TLS, and the midPoint and Keycloak databases should be encrypted at rest. Confirm which data elements in the feed are in scope for the Safeguards Rule and minimize the rest. | TLS configuration for each connection, database encryption settings, data flow diagram with field list |
| Penetration testing and vulnerability assessments (16 CFR 314.4(d)(2)) | Where continuous monitoring is not in effect, the rule calls for annual penetration testing and vulnerability assessments at least every six months. Include the HR connector, midPoint, Keycloak and their hosts in that cadence, and retest after significant provisioning changes. | Test scope statements, dated reports, remediation tracking for each finding |
| Retention of broker-dealer business records (SEC Rule 17a-4(b)) | Where HR-driven accounts also control access to broker-dealer records, provisioning logs and access history may support the retention of those records. Confirm with counsel which records must be kept for three years, with the first two easily accessible, and align log retention accordingly. | Retention schedule mapped to log and record types, documented access path to retained logs, restore test results |
Which HR and identity platforms fit this pattern
HR-driven provisioning needs one system that records employment events and one that turns those events into accounts, groups and access. The platforms below cover both roles, and the connections between them determine whether joiners, movers and leavers are handled correctly. Check each HR product's export and connector options before committing to a design.
Frappe HR as the HR source
Frappe HR runs on the Frappe framework and is part of the ERPNext family, which is licensed under GPL-3.0. It records employees, departments, designations and leave, so its employee and status fields can act as the trigger for provisioning. Confirm that the Frappe HR version you deploy exposes employee status changes through its API or webhooks, and decide whether joiners and leavers are pushed on save or pulled on a schedule. Map which fields drive account creation, such as employee ID, department and reporting line.
OrangeHRM as an HR source
OrangeHRM holds the core employee record, job history and leave data that identity processes depend on. Because connector support for OrangeHRM is not a standard part of midPoint's documented catalog, the integration usually runs through the OrangeHRM API, a scheduled export or a database view feeding midPoint's CSV, DatabaseTable or SCIM connectors. Confirm the API endpoints, the event model for terminations and the mechanism for rehires before you design the flow.
Odoo as an HR and ERP source
Odoo is published under LGPL-3.0 and its Community core is the open source base for the Odoo platform. Where the same system also runs payroll, purchasing or project time, one employee master record can feed both finance and identity processes. Confirm which Odoo edition holds the HR and payroll modules you need, because Enterprise adds features such as Studio and hosting. Check whether the HR apps you use expose contract and departure dates through the API for downstream connectors.
midPoint for identity governance
midPoint is the identity governance and administration layer that compares the HR feed with existing accounts and applies joiner, mover and leaver rules. Its repository is under EUPL-1.2 with Apache 2.0 as a secondary license, and Evolveum states there is no enterprise edition. It connects to targets through ConnId connectors including LDAP, Active Directory, SCIM2 and Microsoft Entra ID. Confirm that the connector you need for each target is supported, not community or experimental, and check which midPoint release you will run, since support windows differ.
Keycloak for authentication and SSO
Keycloak is an Apache 2.0 identity and access management server that supports OpenID Connect, OAuth 2.0 and SAML 2.0, along with single sign-on and user federation. Provisioned identities reach applications through Keycloak, while midPoint does not act as the SSO server. The current release is 26.8.1, published October 13, 2026. Confirm which applications need protocol support, whether accounts should be created in Keycloak directly or federated from a directory, and how disabled users are treated in active sessions.
Red Hat build of Keycloak
Red Hat build of Keycloak is Red Hat's supported distribution based on the open source Keycloak project and replaces Red Hat Single Sign-On. It suits organizations that need a vendor support agreement for the identity layer that holds HR-driven accounts. Confirm the supported version against your required Keycloak features, because Red Hat's product page showed 26.6 as its latest version and that may differ from the upstream release. Ask whether the support terms cover the database and operator components you plan to deploy.
How a hire becomes an account: the HR to midPoint to Keycloak chain
The chain starts in the HR system, not in midPoint or Keycloak. When a joiner, mover or leaver event is recorded in Frappe HR or OrangeHRM, midPoint needs to see it through a source resource: either a scheduled export or an API pull into a staging table or file that midPoint reads through a connector such as CSV or DatabaseTable. midPoint then runs mapping and correlation to match each HR record to a midPoint user, usually on a stable employee identifier rather than on name or email, which change. Role assignment follows through midPoint policies (assignment rules driven by department, job position or employment type), and midPoint pushes the resulting accounts and attributes to target systems through ConnId connectors such as LDAP, Active Directory, Microsoft Entra ID or SCIM2. Keycloak sits beside this path as the login and federation layer. Depending on the design, Keycloak reads users through user federation from a directory that midPoint maintains, or receives synchronized accounts, so applications authenticate against Keycloak. midPoint does not act as the SSO server and does not implement the server side of OpenID Connect, OAuth 2.0 or SAML.
Three HR fields carry most of the design risk, and each needs a written decision before any connector is configured. The first is the employment status field, which must distinguish active, on leave, terminated and future-dated hires, because a status that is only ever overwritten makes leaver processing unreliable. The second is effective dates: every movement, such as a transfer or a contract change, needs an effective start and end, so midPoint can schedule access changes for the date the change takes effect rather than the date someone typed it in. The third is the correlation key, which should be an immutable employee ID exported from the HR system and never reused after exit. Confirm with your HR team how rehires are keyed, and test a rehire in a non-production environment.
Mover and leaver logic must be defined before code is written. For movers, decide which attributes trigger role removal and which only add access, and whether old access is removed on the effective date or after a manager confirms the change. For leavers, decide the timing for disabling Keycloak sessions and directory accounts, how long access is kept for handover, and who owns exceptions such as contractors whose records sit outside the HR system. Ask your implementation partner to write these rules as a table signed off by HR, security and application owners, and to confirm which midPoint connectors and Keycloak features your target applications require. Validate the chain with test records that cover a hire, a transfer, a leave and a termination before any production data flows.
Deployment patterns for the identity layer
A single-site pattern runs one midPoint instance that reads employment changes from the HR system and provisions accounts into one Keycloak cluster in the same data center or cloud region. It is the simplest layout to operate and test, and it suits organizations whose HR system, directories and applications all sit in one location. midPoint runs on Linux in a virtual machine or from Docker images, and its native repository is PostgreSQL, ideally on a separate database server from the application.
- midPoint host: Run midPoint on Java 21 for version 4.10 and older, or Java 25 for 4.11 and later, since Java 21 remains supported for the newer line.
- Database server: Place the midPoint repository on a dedicated PostgreSQL server, separate from the midPoint host, so backups and patching can be scheduled independently.
- Keycloak database: Use one of the production databases Keycloak supports, such as PostgreSQL 14 to 18, and keep the development file database out of production.
- Single cluster: Keycloak can run as one cluster, optionally spread across availability zones, which still requires a synchronously replicated database for high availability.
- Connectors: Confirm which ConnId connectors (for example LDAP, Active Directory or Microsoft Entra ID) the target directories need before the build starts.
Confirm the midPoint release line and its support end date against the release page before you choose a Java version, and ask your partner how the single PostgreSQL server will be backed up and restored.
A multi-node pattern runs several midPoint nodes behind a sticky HTTP load balancer, all reading and writing one shared central database. This removes a single point of failure in the provisioning engine and spreads the work of reconciliation across nodes. Because nodes share state, the design must also handle cache invalidation and the scheduling of periodic tasks so that a joiner, mover or leaver event is processed once.
- Sticky load balancing: Configure the load balancer for session stickiness, since midPoint nodes expect a user session to stay with one node.
- Shared database: All nodes use one central PostgreSQL database. Treat that database as the highest-value component in the design and plan its replication and failover before go-live.
- Cache invalidation: Nodes invalidate caches between each other over HTTPS, so network rules between nodes must allow that traffic.
- Quartz scheduling: midPoint uses Quartz for distributed task scheduling, which coordinates which node runs a given reconciliation or synchronization task.
- Java version: Standardize every node on the same Java version (21 or 25, depending on the midPoint release) so that nodes behave the same during rolling upgrades.
Ask your partner to document the load balancer settings, the node sizing assumptions and the rolling upgrade order, and to test a node failure during an active reconciliation run.
A Kubernetes pattern deploys Keycloak through its Operator, which manages the Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient custom resources. The Operator is installed through Operator Lifecycle Manager, which is the recommended method, or with kubectl, or with an experimental Helm chart. This pattern fits organizations that already run a platform team and want realms and clients managed as code.
- Operator installation: Install the Operator through Operator Lifecycle Manager where possible, since that is the documented recommended method.
- Manual approval mode: Set operator updates to manual approval. The Keycloak Operator documentation strongly recommends this to avoid unintended automatic upgrades of the identity service.
- Schema migration: Keycloak migrates its database schema automatically at startup by default. For large deployments, the upgrading guide suggests manual migration, where administrators apply the SQL themselves during a planned change window.
- High availability database: Both supported multi-site designs need a synchronously replicated database, so confirm that your managed or self-run PostgreSQL offers synchronous replication before selecting the architecture.
- Release cadence: Keycloak plans four minor releases a year, and breaking changes in a minor release are opt-in, so plan a test cycle for each upgrade.
Ask your partner which Keycloak version will be pinned, who approves each operator update and how the realm and client definitions will be versioned and promoted between environments.
Rollout phases and the output of each
The sequence moves HR-driven provisioning from a data review to a supported production service, with a signed artifact or evidence record at each gate. Each phase narrows the risk that a wrong joiner, mover or leaver event reaches a live directory or application.
Map the HR data model and employment events
The implementation partner and the HR, IT and security owners walk through the Frappe HR or OrangeHRM data model and list every employment event that should change access: hire, transfer, role change, leave of absence, termination and rehire. Each event is traced to the HR fields that trigger it, such as employment status, department, manager, cost center and end date. The step closes with a draft mapping specification that names the source field, the target attribute in midPoint and the Keycloak group or role it controls. Confirm with the HR system owner which fields are authoritative and which are copied from elsewhere.
Clean data and fix the correlation key
Before any account is created, the team checks employee records for duplicates, missing manager links, inconsistent department names and rehires that reuse an identifier. A stable correlation key, such as an employee number that is never reissued, is chosen and enforced in the HR system. The output is a data quality report listing each defect, its owner and its resolution, plus a signed sign-off from HR that the key rules are final. Ask the HR team to confirm how contractors and non-employees are recorded, because they often sit outside the HR source.
Build midPoint and Keycloak in non-production
The team deploys midPoint and Keycloak in a non-production environment that mirrors the target network, database and directory layout. Connectors for the HR source, Active Directory or LDAP, and the target applications are configured and tested against non-production data, with each mapping and synchronization rule recorded in version control. Keycloak is set up with the realm, clients and role mappings that receive provisioned identities. The output is test evidence: a log of test cases for joiner, mover and leaver events, expected results, actual results and defects, all linked to the mapping specification.
Sign off mover and leaver policy
Security, HR, application owners and legal or privacy reviewers agree the rules that decide what happens on each event. Typical decisions include when access is removed on termination, whether a transfer removes old group memberships immediately, how leave of absence is handled and who approves exceptions. The policy is written down with the event, the action and the approver for each case. The step is complete when the policy document is approved by named owners, and the approved version is the baseline the test evidence is measured against.
Run parallel reconciliation before cutover
The provisioning chain runs alongside the existing account process for a defined observation period agreed in the project plan. Each night or sync cycle, the team compares what midPoint would have done with what the current directory and applications actually hold, and records every difference. The reconciliation report lists unmatched accounts, orphaned accounts, wrong group memberships and any leaver whose access would remain active. The step is complete when the open differences are resolved or accepted in writing by the control owner.
Cut over with a documented rollback plan
The team switches account authority to midPoint in a controlled change window, following the change management procedure the organization already uses. A rollback plan states how to return control to the previous process, which database snapshots are taken, who can authorize the reversal and how Keycloak sessions are handled. The output is a change record with pre and post checks, including a leaver test with a non-production account and a review of the first live sync results. Confirm that the rollback has been rehearsed in non-production.
Hand over operations with an upgrade runbook
Operations staff receive a runbook covering daily sync checks, failed task handling, connector and certificate renewal, database backup and restore, and the reconciliation routine. Upgrade procedures are written for midPoint and Keycloak, including the release support windows that apply to the version in use, the test cycle before each upgrade and the approval path for production changes. The step closes when the operations team has run one routine reconciliation and one restore test without the implementation team present. The runbook and the signed handover record become the operating baseline.
Evidence auditors ask for and which component produces it
This table maps each item an assessor is likely to request for HR-driven provisioning to the component that generates it and the setting you must confirm. Read it as a checklist for evidence collection before fieldwork begins, not as a list of what an auditor will accept. DeployOpen prepares the systems, controls and evidence for assessment, but independent auditors issue any opinion or attestation.
| Evidence item | Produced by | What to confirm before the assessment |
|---|---|---|
| Provisioning and deprovisioning logs | midPoint task and audit records for each joiner, mover and leaver event, written to the central repository | Retention period for midPoint audit and task data, and that every HR-triggered change maps to a traceable HR record ID |
| Keycloak admin and login event logs | Keycloak admin events and user login events, forwarded to a central log store | That admin and login event storage is enabled, retention is set outside the default, and events reach the SIEM without gaps |
| Access review exports | Identity governance campaign reports from midPoint, plus role and group membership exports from Keycloak | Reviewer assignments, decision timestamps and evidence that revocations were carried out in the target systems |
| Change records for mappings and connectors | Version control history for midPoint object mappings, connector configuration and Keycloak realm exports | An approval trail for each mapping change, linked to a change ticket and a named approver |
| Reconciliation reports between HR and directories | midPoint reconciliation tasks comparing the HR source with Keycloak and connected directories | Frequency of reconciliation runs, handling of orphaned and uncorrelated accounts, and who reviews exceptions |
| Penetration test and vulnerability assessment reports | DeployOpen security testing outputs for the identity stack, plus scan results from your own tooling | Scope covers midPoint, Keycloak, the HR system and connectors, and the cadence meets your regulatory baseline |
| Retention settings for logs and records | Configuration of the log store, database backups and midPoint and Keycloak event retention | Retention periods agreed with legal and HR, and that the settings are documented and shown to be in force |
How long, what it costs and what the team must provide
What drives the effort of HR-driven provisioning?
The main drivers are the number of HR events you need to automate, the number of target systems, the amount of custom attribute mapping, and whether you run several sites or identity sources. Each joiner, mover and leaver event type (new hire, transfer, contract change, termination, rehire) needs its own rule set in midPoint, and each target such as Active Directory, Microsoft Entra ID or a Keycloak realm needs a connector configuration, test cases and a rollback path. Multi-site employers and organizations with contractors in a second directory usually add more reconciliation work than the core flow. No duration is fixed here: ask any partner to break the estimate down by event type, target system and mapping complexity, and to list what is excluded from the written scope.
Can an internal team build HR-driven provisioning alone?
A team with Java, LDAP or directory administration, PostgreSQL and identity experience can build it in-house, and midPoint is developed as open source with no enterprise edition, so the software itself carries no license fee. The harder part is the design work: agreeing which HR field is authoritative for each attribute, handling edge cases such as rehires and retroactive changes, and testing leaver logic against live directories without locking out staff. Many teams bring in an implementation partner for the first build and keep operations in-house afterward. Whichever route you take, the decision should rest on the skills you can staff for the life of the system, not on the first sprint.
What must the client supply before provisioning work starts?
The client must supply four things before design begins:
- An HR data dictionary that defines each field used for provisioning, its format and who maintains it in Frappe HR, OrangeHRM or Odoo.
- Named policy owners who decide joiner, mover and leaver rules, including access removal timing and exceptions for contractors.
- Administrators for each target system (directories, Keycloak, applications) who can grant test accounts and approve change windows.
- A staging environment that mirrors production HR data shape, with test employees.
Ask any partner to confirm these inputs in writing as part of the scope, because missing owners are the most common reason for schedule slippage.
How do midPoint and Keycloak upgrades affect the provisioning chain?
Each component has its own release clock, so the chain needs a planned upgrade path. midPoint 4.8 is a long-term support release supported until 17 October 2028, midPoint 4.10 is supported until 26 November 2027, and midPoint 4.9 support ends 18 October 2026. Keycloak plans four minor releases a year and says breaking changes in minor releases will be opt-in, but you should still test each upgrade against your realm configuration and custom providers. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates. Ask the partner to state which midPoint line and Java version they will support, how they will test each upgrade, and who approves production changes.
What recurring work follows go-live?
Provisioning does not end at go-live. Recurring work includes monitoring reconciliation jobs and failed provisioning tasks, reviewing new HR fields and org changes, updating connector configurations when directories change, applying security patches and planned upgrades, and reviewing role and entitlement mappings during audits. Some of this work is carried by your own administrators, and some can be covered by a retainer for ongoing support, upgrades and testing. Ask any partner to separate one-time build costs from recurring operations in the quote, and to name the people who will be paid for each part.
Do Evolveum support subscriptions have to be purchased?
No. midPoint is published under open source licenses and Evolveum states that it has no enterprise edition, so the software can be deployed without a subscription. Evolveum offers Product Support subscriptions, with an 8x5 next-business-day or 24x7 SLA, for resolving product bugs, and Platform Subscriptions that add feature development and roadmap influence. The support page lists no prices, so request current terms from Evolveum. Whether to buy support depends on your internal depth, your tolerance for vendor-dependent bug fixes, and how critical provisioning is to joiner access on day one.
What cost components should a quote separate?
A useful quote separates the one-time work from the recurring work. One-time items usually include discovery of HR data and policies, mapping design, midPoint and Keycloak installation in your environment, connector build, testing, cutover and training. Recurring items include hosting and database operations, support subscriptions if chosen, upgrades, and the staff time for reconciliation and access reviews. Costs rise with more event types, more target systems, more custom mappings and more sites. Ask the partner to itemize each line against the written scope, to state exactly which environments are covered, and to confirm how change requests are priced.
Questions to ask an implementation partner before signing
Start with the connectors, because they decide what the integration can do on day one. Ask the partner which connector serves each target: the source HR system (Frappe HR, OrangeHRM or Odoo), Active Directory or Microsoft Entra ID, and Keycloak. Ask whether each one is supported by the midPoint connector catalog or would be custom work, and what that custom work would cost in time and in maintenance after handover. Ask how the partner handles connector versions when midPoint moves to a new feature release, since the midPoint releases page lists a different support window for each line. Confirm in writing which release line the partner will deploy and who patches it.
Next, ask how mover and leaver rules are tested before anyone trusts them with production accounts. A good answer names the test cases: a joiner whose start date is in the future, a manager change that should remove old group memberships, a leaver whose access must end at a stated time while records remain in the HR system, and a contractor who is not an employee record at all. Ask for a test matrix with expected results, a sandbox that uses copies of HR data rather than live employee records, and a written rule for who signs off each scenario. Ask how a rehire is matched to a former identity, so the partner does not create a duplicate account or reactivate a leaver's old entitlements without review. Also ask how reconciliation works: how often midPoint compares HR-driven state with accounts in Keycloak and the directory, what happens to differences, and whether anyone reviews them before corrections run.
Finally, ask about evidence and operations. Confirm how midPoint and Keycloak logs are kept, where they are stored, how long they are retained, and which fields show who changed an entitlement and why, since the ability to explain a leaver's access removal is often what an auditor asks for first. Ask who has production access during support, whether that access is named, time-limited and recorded, and how upgrade plans are tested against the sandbox before production. Ask how the partner scopes work in writing: the connectors, environments, rules, test cases, handover documents and what is excluded. Most engagements are fixed-scope, so ask for the deliverables list and acceptance criteria before work starts, not after.
How DeployOpen scopes and supports this provisioning build
This sequence turns an HR-to-identity provisioning idea into a written scope, a tested joiner, mover and leaver flow, and an evidence pack that your own auditors can review. Each step ends with an output your team can inspect before the next one starts.
Agree the written scope and deliverables
DeployOpen reviews your HR records, identity sources, target applications and compliance obligations, then writes a fixed scope with deliverables, responsibilities and timelines. Your HR lead, IAM owner and security lead sign off before any build work starts. You know this step is done when the signed scope names every HR event type, connector, target system and out-of-scope item, and states who owns each decision.
Map HR attributes and lifecycle events
DeployOpen works with your HR administrators to map the fields that drive accounts, such as employee ID, legal name, department, manager, job code, location, employment status and start and end dates. The team defines which HR events trigger joiner, mover and leaver actions, and which fields are authoritative in the HR system. The output is a reviewed attribute and event matrix, with each mapping marked as confirmed, pending or excluded.
Build the HR to midPoint and Keycloak chain
DeployOpen configures the feed from Frappe HR or OrangeHRM into midPoint, sets up the midPoint resources through the ConnId connectors that match your directories and applications, and connects midPoint to Keycloak for account and role propagation. Build work happens in a non-production environment inside your infrastructure. The step closes when test joiners, movers and leavers flow end to end and the resulting account states match the approved matrix.
Test the lifecycle and the identity layer
DeployOpen runs functional tests for each lifecycle path, including edge cases such as rehires, retroactive changes and leavers with active sessions. Security testing covers the identity layer, including the midPoint and Keycloak administrative interfaces, the HR integration endpoints, secrets handling and access paths to connected systems. The output is a test report with findings, severity and retest results, and a list of accepted residual risks signed by your security owner.
Harden, document and hand over operations
DeployOpen applies production hardening to the database, clustering, TLS, logging and backup settings, and documents the runbooks for connector failures, reconciliation errors and emergency account disablement. Your operations team is trained on these runbooks and on the upgrade approach for midPoint and Keycloak. The step is complete when the runbooks are accepted, a production change record exists, and your team has executed at least one controlled test restore.
Prepare evidence for compliance assessments
DeployOpen assembles the evidence your assessors will ask for: configuration baselines, the attribute and event matrix, access review outputs, change records, log samples showing joiner, mover and leaver actions, and test results. DeployOpen prepares and organizes this evidence but does not issue audit reports, attestations or certifications. Your independent auditor or certification body makes those determinations. The output is an evidence index mapped to the control areas you have chosen to assess.
Support operations through a retainer
After handover, ongoing support, upgrades and continuous testing can be covered by a retainer agreed in writing. Upgrade work covers midPoint release changes and Keycloak minor releases, which the Keycloak project plans four times a year, with each upgrade tested against your mapping and connector set before it reaches production. Ask for the retainer scope, response expectations and upgrade notice terms in writing before signing.
