midPoint security hardening guide

Why midPoint security hardening decides whether your identity governance can be trusted

midPoint security hardening is the work of configuring the application, its repository database, its connectors and the infrastructure around them so that the platform that grants and removes access cannot be turned against you. It covers five areas: administrator authorizations, protection of connector credentials and secrets, audit trail configuration, TLS to target systems, and protection of the repository database. Because midPoint holds credentials for many target systems and decides who receives access to them, a default or loosely configured installation is a high-value target. An attacker who controls midPoint can often create accounts, assign roles and read the credentials it uses to reach directories, cloud tenants and business applications.

These five areas are harder than they look because none of them sits in one place. Administrator authorizations are defined inside midPoint's own object model, but the accounts behind them depend on how the application is connected to the directory or login mechanism you use. Connector credentials are stored in midPoint's configuration, which lives in the repository database, so a database weakness becomes a credential weakness. Audit trail settings, TLS to each target system and the network paths between application nodes and the database are set in different layers, often by different teams. A control that looks complete in the midPoint user interface can still be bypassed through a database account, a connector service account or an unencrypted hop.

Keep one distinction clear before you start. midPoint is an identity management system, not an access management or single sign-on server. Evolveum states that midPoint does not implement the server side of OAuth2, OpenID Connect or SAML. Its own login can authenticate against an external SSO service, but that is a separate decision with its own design, so this page treats the login of midPoint's user interface as out of scope and focuses on the controls that govern the platform's administrative power and its connections to other systems.

Hardening choices also depend on the release you run and the Java runtime it requires. Evolveum's system requirements recommend Java 25 for midPoint 4.11 and later, with Java 21 supported, and Java 21 for 4.10 and older, with Java 17 supported. The 4.11 release is planned for 21 October 2026 according to the midPoint releases page. Before you finalize settings, confirm with Evolveum which runtime and database versions your release supports, and check the release notes for any change to security defaults. Treat the Java runtime, the PostgreSQL version and the midPoint release as one configuration baseline that you test together.

Which midPoint components hold credentials, access rights and audit data

A midPoint deployment is several components that each hold a different kind of sensitive data. Hardening starts with knowing which node, database, connector, scheduler or log stream holds credentials, access rights or audit records, and what someone could reach through it. The cards below take each component in turn so the hardening work can be scoped and checked component by component.

Midpoint application nodes and web interface

The midPoint application nodes run the engine that evaluates roles, assignments and policies, and they serve the web interface that administrators and approvers use. Anyone with an administrator or approver role can view identities and change assignments, so the scope of those authorizations decides how far a compromised account can reach. Check which roles hold administrative rights, how the web interface authenticates users, and which hosts can reach the node addresses directly.

PostgreSQL repository database server

The PostgreSQL repository is midPoint's native store for users, roles, resource definitions and task state, and it is recommended to run on a separate database server. Read access to the database exposes the full identity dataset, and write access can alter access rights without passing through the midPoint interface. Confirm that the database host accepts connections only from midPoint nodes, that database accounts are separate from administrator accounts, and that backups are protected to the same standard.

ConnId connector configurations

ConnId connector configurations hold the credentials midPoint uses to read and write accounts in LDAP directories, Active Directory, Microsoft Entra ID, SCIM endpoints and database targets. A connector account with broad rights on a target system turns a midPoint compromise into a compromise of every connected system. Review the privileges granted to each connector account, the TLS settings used to reach each target, and who can view or export connector configurations in the interface.

Quartz task scheduler and inter-node traffic

In a multi-node deployment, Quartz distributes scheduled tasks such as reconciliation and synchronization across nodes, and nodes send cache invalidation messages to each other over HTTPS. A task that runs with broad rights or an unexpected node can reconcile accounts it should not touch, and unencrypted or unauthenticated node traffic exposes state between nodes. Check which accounts own scheduled tasks, that inter-node traffic is encrypted, and that only cluster members can reach the node-to-node endpoints.

Audit and logging output

midPoint audit records and application logs show who changed which assignment, which account was provisioned, and which administrator ran a task. Audit data is evidence for access reviews, but log files can also carry sensitive attribute values or connector diagnostics. Confirm where audit records are stored, who can read or delete them, how long they are retained, and whether logs are forwarded to a store that administrators of midPoint cannot edit.

Which administrator authorization model and secret store fit your organization

This table compares the five decisions a team must make when hardening midPoint administration: role design, login source, connector secret storage, service account use and audit retention. Read each row as a choice with its operational cost, and use the right-hand column to match options to your organization's size, identity stack and review capacity.

Decision	Option	When it fits	Operational cost
Administrator roles	Few broad administrator roles	Small identity team with one trusted group operating midPoint	Low setup effort, but every administrator holds wide change rights and reviews are harder to evidence
Administrator roles	Narrow roles per function (for example, connector owners, role model authors, certification reviewers)	Larger team with separate duties for configuration, approvals and certification	More role design and periodic review of assignments, which recurs with every team change
Login source	midPoint's own authorization model with local administrator accounts	Organizations without a central identity provider for administrators, or as a documented fallback	Local password lifecycle, separate offboarding steps and manual evidence of who holds access
Login source	External identity for administrator login (SAML or OIDC provider), with midPoint roles mapped to groups	Organizations that already enforce MFA and joiner-mover-leaver processes centrally	Dependence on the external provider's availability and group design; confirm which login flows your version supports
Connector secrets	Stored in midPoint configuration	Small deployments with restricted access to the repository and configuration backups	Secrets travel with exports and backups, so backup access becomes a secret access path to review
Connector secrets	External secret store referenced from midPoint	Organizations with a vault or key management service already audited and operated	Integration effort, vault availability becomes a dependency, and rotation needs a tested procedure
Connector traffic account	Dedicated service account per connector with least privilege on the target system	Most production connectors, especially those writing to directories or cloud tenants	Ongoing rotation and ownership records for each account, and access reviews of the target system
Audit retention	Audit records kept in the midPoint repository only	Short retention needs or low audit volume	Database growth and limited separation from the system being audited
Audit retention	Audit records forwarded to a central log platform with retention set by policy	Regulated organizations that need evidence outside the identity platform	Forwarding pipeline to build and monitor, plus storage and retention costs that recur

How to harden a midPoint deployment in sequence

This sequence moves a midPoint deployment from a supported baseline to a configuration where the database, connectors, administrators and audit trail are each locked down and tested. Each step closes with a check that proves the control works, so the result is evidence you can show your security team and auditors.

Start from a supported release and patched runtime
Choose a midPoint release that is still in support. Midpoint 4.8 (Curie) is a long-term support release supported until 17 October 2028, and 4.10 (Braille) is supported until 26 November 2027. Pair the release with the Java version midPoint recommends for it: Java 21 for 4.10 and Java 25 for 4.11 and later. Host the PostgreSQL repository on a dedicated database server, separate from the application nodes. The step is done when the release, Java runtime, operating system and database host are recorded in a configuration baseline and each has its current vendor security patches applied.
Lock down database and network paths
Restrict the database port so only midPoint nodes can reach it, and block administrative access from user networks. Create a dedicated database role for midPoint with rights limited to its own schema, and require encrypted connections between midPoint and PostgreSQL. In a multi-node deployment, every node should use the same locked-down shared database. Confirm the exact privileges your release needs with the midPoint system requirements and PostgreSQL documentation. Check the result by connecting from a host outside the midPoint network segment, which should fail, and then from a midPoint node over an encrypted connection, which should succeed.
Configure TLS for the web interface and connectors
Serve the midPoint web interface over HTTPS using a certificate issued by your internal certificate authority. For each target connection, including LDAP, Active Directory, SCIM, Entra ID and database resources, configure the connector to validate the target's certificate chain against your trusted authorities. Do not turn off certificate verification to make a connection work. Test this by pointing one connector at a target that presents a certificate from an untrusted authority. The connection test should fail. After you add the correct authority to the trust store, the same test should pass.
Define administrator authorizations and service accounts
Limit the superuser role to a small, named group of administrators. Give operators, auditors and help desk staff roles that cover only their tasks, and create a separate service account for each connector or integration with only the access it needs. Keep service accounts out of interactive use where your release allows it. Confirm how authorizations apply to connector objects in your version's documentation. Check the result by signing in as a non-admin account and trying to edit a connector configuration. The change must be refused, and the attempt should appear in the audit trail.
Move connector secrets out of plain configuration
Connector configurations hold bind passwords, API tokens and client secrets. Store these as protected values, not as readable text in connector or resource objects. Where your release and connector support it, source the secrets from an external secret store and reference them from midPoint. Confirm the supported options for each connector in the Evolveum connector documentation. Check the result by exporting a connector object and searching the export, along with recent backups and logs, for a known test secret. The test value should not appear in plain text anywhere.
Configure audit trail output and retention
Enable auditing for changes to users, roles, resources and connector configuration, and send audit events to a destination your security team monitors. Set retention to match your records policy, and confirm which output destinations your release supports. Protect the audit store so administrators cannot alter or delete records they created. Check the result by making a test change to a connector as an administrator. The audit record should show who made the change and when, and it should reach the monitored destination within the time your team considers acceptable.
Run the security checks in verification
Run the security checks described in the verification section of this page against the baseline you recorded in the first step. Record each result, fix any failure, and rerun the affected check until it passes. Repeat the full set after every upgrade, configuration change or connector addition. The step is complete when every check has a recorded result, each fix has been retested, and the results are signed off by the people responsible for the identity platform and its security controls.

Controls for midPoint administrators, connectors and the repository database

Most midPoint hardening work comes down to who can change identity policy, what credentials each connector holds, and where sensitive data travels and rests. The cards below cover those controls in the order a reviewer would check them. Confirm exact setting names and defaults against the documentation for your midPoint release before you treat any control as in place.

Least-privilege administrator roles

midPoint administrators can change assignments, roles and mappings that grant access across the estate, so their rights should be split by task rather than granted as a single broad administrator role. Separate the people who configure objects from the people who approve changes, and make sure no one can both propose and approve their own change. Review the authorization definitions for your release and test each role with a non-administrative account before go-live.

Dedicated connector service accounts

Each ConnId connector should authenticate to its target with its own service account, not with a shared or human administrator identity. Grant that account only the rights needed for the object types and operations the connector performs, such as creating accounts in one directory container. Confirm which operations each connector needs for your target system before you set rights, because over-broad service accounts are a common finding.

Connector credentials outside exports and version control

midPoint configuration can be exported as XML objects, and those exports often end up in change tickets, backups and Git repositories. Connector passwords and other secrets should be held in a protected store or referenced from it, not written in plain text into exported objects or committed files. Check how your release encrypts or masks protected values in exports, and test an export and a repository diff to confirm no credential appears in readable form.

TLS on target and inter-node connections

Connector traffic to directories, databases and SaaS targets should use TLS with server certificate validation enabled, so that credentials and personal data are not sent in clear text or to an unverified endpoint. In multi-node deployments, cache invalidation between nodes also runs over HTTPS, so node certificates and trust stores need the same care. Confirm the TLS options for each connector and the inter-node settings in your release, and check that certificate verification is not disabled in test configurations that later move to production.

Repository database access and encryption

midPoint uses PostgreSQL as its native repository, and that database holds the identity model, assignments and audit-relevant state. Restrict network access so only the midPoint nodes can reach the database server, create a dedicated database user with rights limited to what midPoint needs, and require encrypted client connections. Keep database administrator accounts separate from the application user, and confirm the required privileges against the system requirements for your release.

Web interface network restriction

The midPoint web interface is an administrative surface, so it should only be reachable from the networks where administrators and approvers work. Enforce this at the load balancer or reverse proxy, and make sure the sticky load balancer in a multi-node layout applies the same rules to every node. Because the interface can authenticate against an external SSO service, confirm which login paths remain open and test that unauthorized networks receive no response from the administrative endpoints.

How hardening changes for single node, multi-node and Docker deployments

On a single Linux virtual machine, midPoint, its Java runtime and the web interface share one host, so the hardening boundary is the host itself. TLS is usually terminated either by a reverse proxy on the same machine or by the application listener, and that choice determines which process holds the certificate private key. There are no cluster peers in this shape, so no node-to-node channel needs protecting, but cache and task state stay local to the one node.

TLS termination: Decide between a reverse proxy on the VM and direct listener TLS, then restrict read access to the certificate private key to the service account and the people who renew certificates.
Node-to-node traffic: No peers exist, so there is no inter-node channel to protect. Confirm that cache and task settings point only at the local node.
Secrets: Store database and connector credentials in files owned by the service account, with permissions that block other local users from reading them.
File permissions and exports: Limit the midPoint home directory, logs and any exported configuration to the service account and named administrators. Exports can carry sensitive attributes.
Database path: The system requirements recommend a separate PostgreSQL server. Confirm that the connection between the VM and the database server is encrypted.

Before go-live, check that the host firewall exposes only the intended ports and that the service account cannot modify its own binaries.

What the midPoint audit trail should prove and where it must be kept

An auditor or security team reviewing a midPoint deployment needs to answer a small set of questions for any sensitive change: who changed an account, role, assignment or connector configuration, when the change was made, and from which session or interface it came. The audit trail is only useful if it can answer all three without relying on guesswork. Start by listing the object types that matter most to you (user accounts, role and assignment changes, resource and connector definitions, and administrative settings) and confirm that each of them produces an audit record in your configuration. Ask your implementation partner to show you a test change to each type and the resulting record, including the actor, timestamp and session identifier. Records kept only inside the midPoint application are weak evidence. The application database can be altered by anyone with database access, and application logs can rotate or be truncated before a review. Configure audit output so that records are also sent to a store outside the application, such as a centralized log platform or write-once storage managed by a different team. Confirm the exact audit event handlers and log destinations in the version you run, because the configuration syntax and available outputs change between releases. Check the release notes for the version you plan to use before you commit to a design. The audit store must be protected from the people whose actions it records. midPoint administrators hold broad authority over identity data, so an administrator who can modify both midPoint and the external store could alter their own history. Separate the duties: give the logging team or security operations group write-only or append-only access to the external store, restrict deletion rights to a small approved group, and alert on any gap in sequence or any retention policy change. Test this separation by attempting a deletion as a midPoint administrator and confirming that it fails and is itself logged. Retention should follow your organization's records policy and the regulations that apply to your sector, not a default value in the tool. Decide how long audit records must be kept online for investigation, how long they must be archived, and who approves destruction. Ask your partner to document where each retention setting lives, so that a change to retention is reviewable. Certification evidence from midPoint, such as the results of access review campaigns, depends on the same underlying records. If the audit trail is incomplete, the certification evidence built on it will be incomplete too. Independent auditors decide whether this evidence is sufficient for their assessment. DeployOpen prepares the systems, controls and evidence for that review, but it does not issue audit reports or attestations.

What drives midPoint hardening effort and how to keep it down

This table lists the factors that most change how much work midPoint hardening takes, with a way to reduce each one. Read each row as a lever: the driver on the left is what makes the work grow, and the middle column explains why, while the right column names the design choice that keeps it contained. The main takeaway is that most effort comes from repeating the same security setup per connector, per administrator role and per environment, so building those patterns once has the largest effect.

Driver	Why it changes effort	How to keep it down
Number of target systems and connectors	Each ConnId connector usually needs its own service account, least-privilege permissions, and TLS trust configuration, so every added target repeats those steps and their testing.	Use standard connector templates with one reviewed pattern for account naming, permissions and certificate handling, and document exceptions per target.
Service account model	Connector credentials multiply with targets, and unclear ownership makes rotation and review slow and error-prone.	Build the service account model once: one account per target with a documented scope, owner and rotation procedure, stored in the secret store.
Administrator roles and approval paths	Each midPoint administrator role, delegated authority and approval workflow needs its own authorization tests and periodic review.	Keep a small set of reusable administrator roles, and define approval paths as shared patterns instead of one-off workflows per team.
Existing certificate authority and trust	Without a central certificate authority, each target needs manual trust setup and renewal tracking, which adds work at every onboarding and expiry.	Reuse the organization's existing certificate authority and publish a standard trust bundle that midPoint nodes and connectors load.
Secret store and log platform	If no secret store exists, credentials are handled per system, and missing log forwarding means audit trail checks must be built from scratch.	Confirm whether an enterprise secret store and log platform are available before scoping, and connect midPoint to them rather than building local equivalents.
Network segmentation	Connectors, the repository database and the midPoint nodes need defined network paths, and each new path needs firewall approval and testing.	Map required flows once in a single diagram and reuse the same network zones for each target and environment.
Environments that mirror production	Staging and test environments that must match production controls double the configuration, certificate and access checks.	Manage environments from the same versioned configuration with only environment values changed, and test controls in the lowest environment first.
Customization that adds credentials or scripts	Custom scripts, scripted connectors or extra integrations often need their own secrets, permissions and review, which lengthens hardening.	Limit customization to documented needs, route new credentials through the same secret store process, and review each script before it reaches production.

How to test midPoint hardening and confirm it fails safely

Verification of a midPoint hardening baseline is a set of negative tests: each control is confirmed by trying to break it and checking that midPoint refuses, logs and withholds secrets as designed. A configuration that looks correct in the administration interface proves little until an unauthorized action is attempted and fails. Start with administrator authorizations. Create a test account that holds only the roles you intend to allow, sign in, and attempt to change a connector configuration, edit a resource, or assign a privileged role to a user. Each attempt should be denied. Repeat the test with the account holding no administrative role at all. Record the exact action attempted, the account used, the outcome and the time, because these notes become the evidence auditors ask for.

Next, test connector trust and transport. Point a connector at a target system presenting an expired certificate, a certificate signed by an authority midPoint does not trust, and a certificate whose host name does not match. In each case the connection should be refused and no data should be exchanged. Then attempt a database connection with TLS disabled and confirm that midPoint's repository configuration rejects it. Confirm the exact parameters with your PostgreSQL server settings and your midPoint version, because the behavior depends on the JDBC driver and the connector in use. The same approach applies to LDAP and Active Directory connectors, where you should verify that unencrypted binds are rejected rather than silently downgraded.

Then test secret handling in three places: exported configuration, logs and error messages. Export an object or a full configuration through the supported export function and search the output for connector passwords, bind credentials, API tokens and database passwords. Check that protected values are masked or stored through the configured protection mechanism. Review application and audit logs at a debug level used during troubleshooting, since verbose logging is a common leak path. Then force failures: stop the target system, stop the database, or enter a wrong connector password. The error shown in the interface, the logs and any notification should contain no credential material. This is the point where a failed connector or a database outage is most likely to expose secrets, so treat any leaked value as a defect to fix before go-live.

Audit testing covers two questions. First, administrative changes must produce audit records: make a test change to a role, a resource and a user, then confirm each change appears with the actor, the object and the time. Second, those records must not be alterable from the midPoint interface. Attempt to edit or delete audit entries using an administrator account, and confirm that no interface path allows it. Also confirm where the audit records are stored and who holds database rights to them, since a database administrator can usually change rows regardless of midPoint. Ask your security team to define how audit data is protected outside midPoint, and document that decision alongside the test results.

Run this full set after every midPoint upgrade, after every Java runtime change and after any change to connectors, certificates or database settings. Upgrades can reset defaults, and a feature release may alter how errors are rendered. Keep a dated record for each run that lists the test, the expected result, the observed result, the tester and the midPoint version. Retain the record with your change tickets so that the hardening state can be shown to auditors and to your own risk owners over time. Where a test fails, the record should show the fix and a retest. The outcome is evidence that the controls work as configured, not an assurance that the platform is secure in every respect.

What to monitor, back up, upgrade and document after hardening

Hardening sets the baseline, and the baseline holds only if someone runs it. The six areas below cover the recurring work that keeps midPoint's administrator access, connector secrets, audit trail, repository and runtime in the state you approved, along with the evidence auditors will ask for.

Review administrator and service accounts

Set a recurring review of who holds midPoint administrator roles and which service accounts can change configuration, resources or other identities. Compare current membership against the authorizations defined during hardening, remove access that no longer has an owner, and record who approved each change. Confirm with your identity and change teams which review cadence fits how often your organization changes access.

Rotate connector credentials and certificates

Connectors to target systems hold bind passwords, API tokens and client certificates that midPoint uses continuously, so an expired credential can stop provisioning without warning. Keep an inventory of every connector secret and certificate with its owner and expiry date, and schedule rotation ahead of expiry. After each rotation, run a test read and a controlled write against the target system, and confirm the new secret is stored only in your approved secret store.

Monitor audit output and failed logins

midPoint's audit trail records changes to objects and, depending on your configuration, authentication events. Forward audit output to your central logging platform, then alert on failed logins to the midPoint user interface, changes to administrator roles and repeated connector failures. Confirm with your configuration documentation which events your chosen audit level captures, and test that an alert fires when a deliberate test change is made.

Back up the repository database

The PostgreSQL repository holds midPoint's objects, assignments, audit records and task state, so it is the most important recovery point in the deployment. Schedule regular backups from the database server, keep copies outside the production network, and restore them to a separate environment at a set interval. A backup that has never been restored is unproven, so record how long each restore takes and confirm how point-in-time recovery is configured with your database team.

Plan upgrades and the Java runtime

Each midPoint release has its own support end date, and the Java runtime it needs follows a separate schedule. midPoint 4.8 is a long-term support release supported until 17 October 2028, 4.10 is supported until 26 November 2027, and 4.9 support ends on 18 October 2026. midPoint 4.11 is planned for 21 October 2026. Evolveum recommends Java 25 for 4.11 and later and Java 21 for 4.10 and older. Check current status with Evolveum, and test each upgrade and runtime change on staging first.

Document the hardening baseline

Write down the hardening baseline as it was approved: administrator roles and their members, service account permissions, connector secret storage, TLS settings for target systems, audit configuration and repository access. Keep the record under change control so every approved change updates it. Auditors test whether documented controls match the running system, so attach evidence such as configuration exports and review records. DeployOpen can prepare this evidence, while independent auditors assess it.

Questions teams ask before hardening midPoint

How much does midPoint security hardening cost?

Hardening is priced from a written scope, so no figure is given here, and the quote should show each cost component. Costs fall into four groups: DeployOpen's assessment, configuration and testing work under a fixed-scope agreement; your internal staff time for reviews and change approvals; infrastructure for test and production, including certificates, database backups and log storage; and any Evolveum subscription, which is purchased separately. Most of the work is one-time. Recurring costs come from re-checking the hardening after each upgrade, log retention and any retainer for ongoing support or testing. Ask for a quote that lists systems in scope, connector count, number of environments and which items are one-time or recurring.

How long does midPoint security hardening usually take?

The duration depends on scope, and no general figure is given without a written plan. The main factors are the number of target connectors and how each one authenticates, how many midPoint nodes and environments you run, whether the current configuration is documented, and how quickly certificates and database changes can be scheduled. Change windows matter, because production changes to TLS, database roles and administrator authorizations usually need approval and a rollback plan. Teams with a stable test environment and a named owner for administrator roles move faster than teams that must first inventory their setup. Ask for a phased timeline that separates assessment, test changes, production rollout and evidence collection, and confirm which dependencies sit with your team.

Can our own team harden midPoint without a partner?

Yes, an internal team can do it if it has the skills and time, but the gaps usually sit in the details. The work spans midPoint administrator authorizations, ConnId connector configuration, TLS and certificate management, PostgreSQL roles and backup protection, and audit logging with retention. Evolveum's documentation covers these areas, but applying them to your target systems requires testing that many teams have not done before. Consider whether one person can own the change, whether someone can test failure paths, and whether anyone outside the build team will review the result. A partner can supply fixed-scope delivery and independent review, while your staff keep ownership of the running system. Decide based on skills, capacity and the audit timeline.

What does midPoint hardening need from our team?

Hardening needs named people and access before work begins. Expect to provide test and production access to each target system, plus service accounts with the rights needed to test narrowed permissions. You will also need a certificate authority or PKI owner who can issue server and client certificates and manage trust chains, and database administrators who can handle PostgreSQL roles, backups and network access from midPoint nodes. A named owner for midPoint administrator roles should approve who can change configuration, roles and connectors. Finally, provide a change calendar, a log destination owner for the audit trail and a contact for each connected system. Ask that the scope list each item with the person responsible and the date it is needed.

Do Evolveum subscriptions cover security fixes for midPoint?

Evolveum's Product Support subscriptions cover resolving product bugs under an 8x5 next-business-day or 24x7 SLA option, and Platform Subscriptions add feature development and roadmap influence. The public subscription page does not state that every security fix is covered on every release line, so confirm in writing with Evolveum which fixes and which versions your subscription covers. Release support also matters: midPoint 4.8 is a long-term support release supported until 17 October 2028, midPoint 4.10 is a feature release supported until 26 November 2027, and midPoint 4.9 support ends 18 October 2026. Hardening does not replace patching, so plan upgrades around these end dates. The subscription page lists no prices, so request a quote from Evolveum.

Which parts of midPoint does security hardening cover?

Hardening covers the parts of a midPoint deployment that hold privileged access and credentials. The main areas are administrator authorizations, which limit who can change configuration, roles and connectors; credential and secret protection for connectors, so service account passwords are kept out of readable configuration; audit trail configuration, so administrative and provisioning actions are logged and retained; TLS to target systems, so traffic to directories and cloud APIs is encrypted and the certificates are trusted; and protection of the PostgreSQL repository, including roles, network exposure and backups. The exact list depends on the connectors and nodes you run. Ask the partner to map each area to your systems before the work starts.

What can break when we harden a running midPoint?

Several things commonly break when permissions and trust settings change on a live system. Narrowing administrator authorizations can stop scheduled tasks or approvals that previously ran under a broad account. Enforcing TLS can fail when a target system's certificate chain is missing from the trust store or the hostname does not match the certificate. Tighter database roles can block migrations, reporting or backups that relied on elevated rights. Stricter audit settings can fill disks or slow nodes if retention is not sized in advance. Test each change against a copy of production configuration and connectors, keep the previous configuration for rollback, and schedule changes with the owner of each target system. Confirm these behaviors against the release you run.

Does hardening midPoint make us compliant with audit frameworks?

No. Hardening makes the system and its controls easier to evidence, but it does not make midPoint compliant with any framework. Independent auditors or certification bodies assess compliance and decide whether controls operate as described over a period. DeployOpen prepares systems, controls and evidence for those assessments, such as documented administrator authorizations, configured audit trails, reviewed TLS settings and tested backups, but it does not issue audit reports, attestations or certifications. Before work starts, agree with your auditor which control requirements apply and how the evidence will be collected. Then keep that evidence current after upgrades, because a hardened configuration that drifts loses its value.

How DeployOpen scopes, hardens and hands over midPoint security work

DeployOpen plans and hardens midPoint inside your own infrastructure, working from a written scope agreed before any work starts. Each engagement covers administrator authorizations, connector credentials, audit trail configuration, TLS to target systems and protection of the repository database. Ongoing support and upgrades are available as a retainer.

How we scope

Inventory administrator accounts, roles and the authorizations each one holds in midPoint
Map every connector to its target system, its credentials and the network path it uses
Agree the written scope, deliverables and timeline with you before hardening work starts

How we build

Restrict administrator authorizations to least privilege, with a documented role for each admin task
Protect connector credentials and secrets, keeping them out of plain configuration files and version control
Configure audit trail retention, enforce TLS to target systems and limit database access to the midPoint service

How we hand over

Written configuration baseline and hardening record for your identity team to review and keep
Test evidence for each control, including authorization checks and TLS verification results
Runbook covering credential rotation, audit trail review and repository database backup procedures

How we support

Retainer support for midPoint patches, Java changes and hardening reviews after each upgrade
Re-test authorizations and connector configuration before each midPoint upgrade is applied
Ask Evolveum which subscription level fits your environment, alongside DeployOpen support