FreeIPA or Kanidm: which fits your Linux identity estate
Choose FreeIPA when Kerberos single sign-on, an integrated certificate authority, a cross-forest trust with Active Directory, or central sudo and HBAC policy is a hard requirement for your Linux hosts. Choose Kanidm when you want one modern server with OAuth2/OIDC, SSH key distribution, RADIUS and TPM-protected offline Unix login, and you do not need Kerberos or an AD trust. The decision turns on four questions: whether Kerberos or an AD trust is non-negotiable, how much footprint and operating skill your team can carry, how often you can absorb upgrades, and how much migration the estate can take on at once.
Start with the protocol list. If applications or hosts depend on Kerberos tickets, or Windows users must reach Linux resources through a cross-forest trust, FreeIPA is the path that supports them today. Confirm the trust prerequisites early: the IPA DNS domain must not overlap with any domain in the AD forest, and the trust relies on Samba components, so review the FreeIPA Trusts page with your Windows team. Kanidm's README does not list Kerberos or an AD trust among its features, so treat those as gaps to verify, not as options to assume.
Upgrade cadence and team size often decide it in practice. Kanidm releases quarterly, supports each stable release for 4 months, and upgrades only from the previous minor version, so you need a regular upgrade routine. FreeIPA is packaged in Fedora, Debian, CentOS and Red Hat Enterprise Linux, and its deployment guidance calls for multiple replicas per datacenter, which adds operating work. Kanidm's comparison page is vendor-authored and reports benchmark gains, which it notes may vary, so run your own load tests. If you migrate, the kanidm-ipa-sync tool can bring accounts and groups across for coexistence, but it requires LDAPS to one FreeIPA server and a manual retro changelog change, so budget that effort before you commit.
Which scenario points to FreeIPA and which to Kanidm
This table maps common Linux identity scenarios to the platform that fits each one best, and names the condition that tips the decision. Read each row against your estate: the deciding factor is usually whether Kerberos, Active Directory trusts or a certificate authority are hard requirements, or whether the main need is modern logins and SSH key handling for a smaller team.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Services that require Kerberos SSO | FreeIPA | Kerberos is a hard requirement because MIT Kerberos KDC is built into FreeIPA. Kanidm's documented feature set does not list a Kerberos KDC, so confirm with the Kanidm project before relying on it. |
| Active Directory users reaching Linux resources | FreeIPA | FreeIPA can establish a cross-forest trust with AD. The IPA DNS domain must not overlap any AD forest domain. Kanidm's listed features do not include an AD trust. |
| Web apps needing OIDC logins | Kanidm | Kanidm provides an OAuth2/OIDC provider with token exchange. This fits when the main need is modern web sign-in rather than Kerberos. Confirm each client's required flows against Kanidm's documentation. |
| SSH key distribution across Linux hosts | Kanidm | Kanidm lists SSH key distribution as a built-in feature. FreeIPA also manages SSH keys through its host and user model, so compare the admin workflow against your own host count. |
| Small team wanting one server to run | Kanidm | Kanidm's README describes a single identity server with two-node replication and says no other components are needed. Choose FreeIPA only if you also need Kerberos, a CA or AD trust. |
| Regulated estate needing its own CA | FreeIPA | FreeIPA integrates a Dogtag certificate authority. Kanidm's supplied facts do not describe an internal CA, so confirm whether its TLS and certificate workflow meets your assessor's expectations. |
| Legacy LDAP-only applications | Neither alone | FreeIPA exposes LDAP through 389 Directory Server, and Kanidm offers a read-only LDAPS gateway. Check whether applications need write access, which the gateway does not provide. |
| Mixed estate during migration | Coexistence via kanidm-ipa-sync | kanidm-ipa-sync copies accounts, groups and importable password formats from FreeIPA into Kanidm. It needs LDAPS to one FreeIPA server and a manual retro changelog change followed by a reboot, so plan a maintenance window. |
What the architecture means for daily operations
FreeIPA and Kanidm store and replicate identity data in very different ways, and those differences shape upgrades, recovery and who on your team can run the service. The cards below tie each architectural choice to the operational work it creates, so you can check it against your own staffing and change process.
Multi-master replication topology
FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory, so any replica accepts writes and changes flow between them. The FreeIPA deployment recommendations advise at least two to three replicas in each datacenter and no more than four replication agreements per replica. Operationally, you must design the replication topology deliberately and monitor it, because a poorly planned mesh is hard to correct later. Ask who owns topology changes on your team.
First server holds CA duties
The first FreeIPA server handles certificate renewal and CRL publication by default. If you run the integrated Dogtag CA, that server becomes an operational dependency that needs its own monitoring, patch window and recovery plan. Confirm which server holds these roles in your design and whether you have a documented procedure for moving them. Kanidm has no equivalent integrated CA role to plan around, so this cost belongs only to the FreeIPA side of the comparison.
Backup restore cautions
FreeIPA provides ipa-backup and ipa-restore, with full backups or online data-only backups. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Your runbook should state which backup type you use, how often you test restores, and how you rebuild replicas after a restore. Ask your team to rehearse this in a non-production environment before relying on it.
Kanidm's own replicated database
Kanidm does not depend on an external database server. It uses SQL as a durable key-value store, implements its own query and indexing layer, and replicates changes with eventually consistent replication. This removes a database to run, but it also means your recovery and capacity planning follow Kanidm's model rather than a database team's existing playbooks. Two-node high availability through replication is the documented HA setup, so confirm with the project whether that meets your availability target.
Mandatory TLS everywhere
Kanidm's FAQ states that TLS for all connections is mandatory rather than an optional feature added later. For operations, this means certificate issuance and rotation must work for every client, service and LDAPS consumer from the first day. Plan how certificates will be issued and renewed, since a lapsed certificate will stop logins rather than degrade them. Compare this with how your current FreeIPA or legacy LDAP clients are configured for TLS.
CLI-first administration model
Kanidm's README says administration is offered primarily through its CLI, while the web UI is designed more for user interactions. Administrators who prefer graphical consoles will need to build CLI-based runbooks, scripts and change records. Confirm that your administrators are comfortable with this model and that your automation can call it. FreeIPA offers its own web UI and command line, and its new web UI was in beta at release 4.13.0, so compare the two admin experiences during evaluation.
Capability comparison: Kerberos, AD trust, OIDC, SSH keys and more
This table sets FreeIPA and Kanidm against the capabilities that usually decide a Linux identity shortlist, from Kerberos and Active Directory trusts to OIDC, SSH keys and offline Unix login. Read each row as a question about your estate: if you need the capability on the left-hand platform, check whether the right-hand cell covers it or only partly covers it. Where a cell says to confirm, verify that point with the vendor or in a test deployment before you commit.
| Capability | FreeIPA | Kanidm |
|---|---|---|
| Kerberos KDC | MIT Kerberos KDC provides single sign-on for Linux and UNIX clients | Not listed as a feature; confirm whether Kerberos is needed before choosing |
| Certificate authority | Integrated Dogtag CA issues certificates and handles renewal and CRL publication | Not listed as a feature in the README; confirm certificate issuance needs with the project |
| Active Directory cross-forest trust | Supported with Active Directory on Windows Server 2008 R2 or later, through Samba components; IPA DNS domain must not overlap the AD forest | Not listed as a feature; AD trust is not part of Kanidm's documented scope |
| DNS and NTP | Optional ISC BIND DNS and NTP are part of the bundle | Not listed as a feature; plan separate DNS and time services |
| OAuth2 and OpenID Connect | Not a stated core feature of FreeIPA; confirm the fit for your web applications | OAuth2/OIDC provider with token exchange is a listed feature |
| SAML | Not listed as a core feature in the supplied material; confirm before relying on it | Not listed; a GitHub issue proposing SAML, opened in August 2023, is still open, and maintainers advise OAuth2/OIDC first, LDAP app passwords second, SAML last |
| SSH key distribution | Available through the FreeIPA stack for Linux hosts; confirm the exact workflow in your environment | Listed as a feature |
| RADIUS | No native RADIUS server listed; FreeIPA can proxy OTP checks to an existing RADIUS server | Listed as a feature, served by Kanidm itself |
| LDAP service | 389 Directory Server, multi-master LDAPv3 for users, groups, hosts and policies | Read-only LDAPS gateway for legacy systems; not a full write-capable directory |
| OTP support | HOTP (RFC 4226) and TOTP (RFC 6238) tokens, including software tokens and hardware tokens such as YubiKeys | Passkeys and WebAuthn are the listed second-factor approach; confirm OTP options before migration |
| Passkeys and attestation | Not listed as a core FreeIPA feature in the supplied material; confirm | Passkeys (WebAuthn) including attested passkeys are listed features |
| TPM-protected offline Unix login | Not listed in the supplied material; confirm offline login needs with your SSSD setup | Listed as a feature |
| Web UI scope | Web UI for administration; a new web UI was introduced as a beta in 4.13.0 | Self-service web UI for users; administration is primarily through the CLI |
| Backup tooling | ipa-backup and ipa-restore with full or online data-only backups; restoring an outdated backup into an active replica topology can break replication | Backup and replication details to confirm in the Kanidm book for your version |
License and paid options: FreeIPA under GPL-3.0, Kanidm under MPL-2.0
FreeIPA is licensed under GPL-3.0-or-later, and the project is a community effort with no paid edition of its own. The software bundles 389 Directory Server, MIT Kerberos, the Dogtag certificate system and optional DNS and NTP components, so the license covers the whole stack that you deploy and modify. Reading the license file tells you what you may change and redistribute, but it says nothing about who will fix a defect on your timeline.
- Community license, no edition split: The COPYING file governs the full product, so there is no feature-gated tier to compare against.
- Distribution packaging: FreeIPA ships in Fedora, Debian and CentOS, and Red Hat Enterprise Linux offers it as Identity Management.
- Vendor-backed build on RHEL: Red Hat's supported Identity Management on RHEL is the only paid route named in the supplied facts, and its support scope is tied to RHEL.
- Community release cadence: Fixes arrive through upstream releases such as 4.13.4, so your patch process depends on tracking those releases yourself.
- Mapping your obligations: Confirm which distribution package and version your team will run before you assume a support window.
Before you commit, ask whether your organization needs a contract with a named vendor for patching, and confirm which distribution and version your audit scope will reference.
Kanidm is licensed under the Mozilla Public License 2.0 (MPL-2.0), a file-level copyleft license. The supplied facts describe a quarterly release process with a short support window per release, so the operational question for Kanidm is less about license cost and more about how quickly you must move to a newer minor version. The license file answers what you may use and modify, while the support guidelines answer how long a given release keeps receiving support.
- File-level copyleft: MPL-2.0 requires changes to covered files to stay under MPL-2.0, which is different from the whole-program obligations of GPL-3.0.
- Quarterly releases: Kanidm releases on February 1, May 1, August 1 and November 1.
- Four-month support window: Each stable release is supported for 4 months, so a deployment can fall out of support within one quarter.
- Upgrades step by one minor version: Upgrades are supported only from the previous minor version, for example 1.2.0 to 1.3.0 but not to 1.4.0.
- Recent releases: The supplied facts list v1.11.0 on August 2, 2026 and v1.11.2 on September 11, 2026.
Ask the Kanidm maintainers or your integrator how long a version you deploy today will receive security fixes, and plan an upgrade path that moves one minor version at a time.
Neither platform sells a paid edition in the supplied facts, so the support question is who answers for your deployment. For FreeIPA, the vendor-backed route is the Red Hat build on RHEL. For Kanidm, the facts describe the upstream support policy and do not name a commercial support contract. Regulated buyers usually need a named party with a written support commitment, and that party may be a vendor, an integrator or an internal team with defined on-call duties.
- Vendor support for FreeIPA: Only the RHEL Identity Management route is named as vendor-backed, and its scope is limited to RHEL.
- Community support for both: Upstream projects support their own release lines, but they do not provide contractual response times in the supplied facts.
- Integrator support: DeployOpen supports self-hosted platforms in the client's infrastructure under retainers, and scope and deliverables are agreed in writing before work starts.
- Support evidence: Ask any provider for written patch timelines, supported version lists and escalation paths.
- Internal ownership: If your team owns patching, name the owner and the upgrade calendar in your change records.
Before you rely on either project, obtain the written support terms you need for your risk register, and confirm them with the vendor or integrator rather than assuming the license covers them.
Release cadence shapes the operating cost of both platforms even though neither license charges a fee. Kanidm's quarterly cycle and short support window mean a team must plan regular minor upgrades, each one a single step. FreeIPA is distributed through operating system packages, so its upgrade cycle often follows the distribution's release schedule, and the 4.13 line is the current upstream series in the supplied facts.
- Kanidm upgrade steps: Move one minor version at a time, since skipping a minor version is not a supported upgrade.
- FreeIPA upgrade path: Follow the distribution package for your platform, and check the upstream release notes for security fixes such as those in 4.13.4.
- Test environment: Keep a replica or staging environment that runs the same version as production before each upgrade.
- Backups before upgrades: FreeIPA documents ipa-backup and ipa-restore, and restoring an outdated backup into an active replica topology can break replication.
- Change windows: Schedule upgrades against the quarterly Kanidm dates or the distribution's release calendar.
Before committing, ask how many upgrade cycles per year your team can staff, and confirm the support end date of the exact version you plan to deploy.
When Kerberos and Active Directory trust decide the choice
If your Linux estate depends on Kerberos single sign-on or must share users with Active Directory, that requirement alone may decide the choice. FreeIPA bundles an MIT Kerberos KDC with its directory and certificate authority, and it can establish a cross-forest trust with an AD domain on Windows Server 2008 R2 or later so AD users reach Linux resources. The supplied facts do not describe a Kerberos KDC or an AD trust for Kanidm, so treat that as unconfirmed until the Kanidm maintainers or your own proof of concept show otherwise. Ask them directly whether Kerberos tickets, keytab-based service authentication and cross-forest trusts are on the roadmap, and what they support today.
The trust has a hard prerequisite. The IPA domain must use a DNS domain that does not overlap with any domain in the AD forest, so plan the naming before installation, because it is difficult to correct afterward. Confirm the DNS design with your AD team, and check which Windows Server versions your domain controllers run, since the supported floor is Windows Server 2008 R2. Also note that FreeIPA establishes the trust through Samba components, which adds moving parts you must test during an upgrade.
Coexistence is a practical option if you cannot switch in one step. Kanidm documents kanidm-ipa-sync, which copies accounts, groups and importable password formats from FreeIPA into Kanidm, but it needs LDAPS to one specific FreeIPA server and a manual change to FreeIPA's retro changelog plugin followed by a reboot. For AD users, the trust means logins and group memberships keep working from Windows while Linux services stay on FreeIPA, and moving them to Kanidm changes their authentication path for any Kerberos-dependent service. Map those services first, then decide which users and hosts move and when.
Moving from FreeIPA to Kanidm or back: what transfers and what is rebuilt
This sequence shows which identity data moves cleanly between FreeIPA and Kanidm, which dependencies must be rebuilt by hand, and how to cut clients over without breaking Kerberos-dependent services. Each step should be proven in a test estate before anything changes in production.
Inventory Kerberos, host policy and certificate dependencies
The team that runs FreeIPA lists every Kerberos principal, keytab, service principal and trust in use, plus every host-based access control rule, sudo rule and certificate issued by the integrated Dogtag CA. Record which applications depend on Kerberos tickets, which hosts rely on certificates from the CA, and which AD trusts exist. Done means the inventory is signed off by the application owners, and each item is marked as transfers, rebuilt or retired. Kanidm does not provide a Kerberos KDC, so any Kerberos-dependent service needs a separate plan.
Confirm the kanidm-ipa-sync prerequisites
Before any sync runs, the FreeIPA administrator confirms that Kanidm can reach one specific FreeIPA server over LDAPS, and that the retro changelog plugin is configured as the Kanidm documentation describes. That plugin change is manual and requires a reboot of the FreeIPA server, so schedule it in the test estate first and record the result. Done means a test bind over LDAPS succeeds from the sync host and the FreeIPA server has rebooted cleanly with the plugin active. Confirm the exact steps against the current Kanidm book for your release.
Run kanidm-ipa-sync in a test estate
Run kanidm-ipa-sync from the Kanidm tools container to copy accounts, groups and importable password formats from FreeIPA into a non-production Kanidm instance. Compare user counts, group memberships and login behavior against the FreeIPA source for a sample of accounts. Password formats that Kanidm cannot import will not carry over, so those users need a reset path. Done means a reconciliation report shows which objects synced, which were skipped and why, and the sample logins work. Repeat the run until the differences are understood.
Rebuild Kerberos-dependent services and host policy
Kerberos service principals, keytabs and sudo or HBAC rules do not move through the sync, so the team rebuilds them on the target platform or keeps FreeIPA running for those workloads. For a move to Kanidm, the owners must decide which services stop needing Kerberos, which switch to OAuth2/OIDC or LDAP, and how host access is re-expressed through Kanidm's Unix integration. For a move back to FreeIPA, sudo and HBAC rules need manual migration through LDIF. Done means each rebuilt service passes a functional test in the test estate and the host policy matches the signed-off inventory.
Cut over clients to the new identity source
Switch Linux hosts from the FreeIPA-backed SSSD configuration to the target setup, which for Kanidm means its Unix integration with TPM-protected offline login where the hardware supports it. Change one host group at a time, starting with non-critical systems, and keep a rollback copy of the SSSD and PAM configuration. Test SSH key distribution, sudo behavior and offline login on each group. Done means each host group authenticates the sample accounts, and the rollback path has been exercised once.
Decommission FreeIPA after a verified backup
Before any FreeIPA server is removed, take a full backup with ipa-backup and store it outside the replica topology. FreeIPA's backup guidance warns that restoring an outdated backup into an active replica topology can break replication, so restore tests must run on isolated hosts only. Remove replicas one at a time, confirm that certificate renewal and CRL publication have moved if the CA is retired, and update DNS entries that pointed to the IdM servers. Done means the backup restores in the test estate, no client still points to a retired server, and the decommission record is filed for auditors.
Where FreeIPA and Kanidm projects usually run long
Projects that run long on the FreeIPA side usually stall in the design work before any server is built. Replica topology is the first decision: the FreeIPA deployment recommendations advise at least two to three replicas in each datacenter and no more than four replication agreements per replica, and any replica running PKI or DNS needs its own planning. DNS and certificate design take time because the IPA domain must not overlap any domain in an AD forest if you plan a cross-forest trust, and the CA choice shapes renewal and CRL publication. Client enrollment then has to match the DNS layout, including at least two DNS servers in each client's resolv.conf. Teams that skip these checks often rebuild the topology after the first pilot.
On the Kanidm side, the long tail sits in application and host rollout rather than in the server itself. Each OAuth2 client needs registration, redirect URI review and claim mapping, and each SSH key rollout means changing how sshd on every host gets its keys. RADIUS integration needs the network team to point existing devices at the new service, and TPM-based offline login needs a device inventory to confirm which hosts have usable TPMs before users are told to rely on them. Ask the vendor or your own test environment to confirm the exact client registration and TPM requirements for your hardware and applications before you commit a date.
The slips that recur on both sides are the same. Dependency mapping is usually incomplete: nobody has a full list of which applications, sudo rules or scripts depend on LDAP bind accounts, Kerberos principals or specific hostnames. Application re-integration takes longer than expected because each application has its own login code path. If you run kanidm-ipa-sync during coexistence, change control around the manual retro changelog plugin edit and the reboot it requires must be scheduled with the owners of the FreeIPA server, not handled as a routine tweak. Team skills are the last constraint: Kanidm is administered primarily through its CLI, and FreeIPA operations need Kerberos and LDAP experience. Plan training and a named owner for each platform before the cutover window.
How much effort and cost to expect when choosing and running either
What drives the running cost of FreeIPA compared with Kanidm?
Running cost follows the number of components you operate, the people who maintain them and how often you upgrade. FreeIPA bundles 389 Directory Server, MIT Kerberos, the Dogtag CA, SSSD on clients and optional DNS and NTP, so you plan for more moving parts, replicas and certificate work. Kanidm is a single server with its own database and replication, so its footprint is smaller, but the skills gap and the upgrade cadence still matter. Infrastructure, staff time, upgrade testing and support contracts are the four lines to compare. Ask each vendor or partner to price them separately in writing, using your own replica count and user base.
Can our own team run FreeIPA or Kanidm without outside help?
Yes, many teams run either platform in-house, but the required skill set differs. FreeIPA rewards staff who already know Kerberos, LDAP, certificate lifecycles and DNS, and its deployment guidance calls for multiple replicas per datacenter and careful backup handling. Kanidm favors a smaller set of skills centered on its CLI, TLS and OAuth2/OIDC, though its own documentation notes weaker coverage for some Unix and SQL-backed alternatives it compares against. Assess your team against the operating tasks in each project's documentation before deciding. Outside help is usually bought for design, migration or periodic review rather than daily administration.
What does a fixed-scope FreeIPA or Kanidm implementation need from our side?
A fixed-scope engagement is agreed in writing before work starts, so the client must define the inputs that set the scope. Expect to provide a list of systems and applications that authenticate, the Linux, Windows and network estate, DNS domain plans, certificate requirements, and named owners who can approve changes and test results. If you need Active Directory trusts, the scope must name the AD forests involved. Access to test environments, change windows and a decision on backup and recovery targets also shape the work. Incomplete inputs are the most common reason written scopes change after kickoff.
Can Kanidm replace FreeIPA for Kerberos services?
Not on the evidence supplied here. FreeIPA combines an MIT Kerberos KDC with its directory and Dogtag CA, and it is the component that gives Linux hosts and services Kerberos single sign-on. Kanidm's documented feature set centers on OAuth2/OIDC, SSH key distribution, RADIUS, passkeys and TPM-protected offline Unix login, and it does not list a Kerberos KDC among those features. Confirm with the Kanidm maintainers whether any Kerberos-dependent service in your estate, such as NFSv4 with Kerberos, Hadoop or AD-trust authentication, can work without it, and test that path before you commit.
How long does a migration from FreeIPA to Kanidm take?
The duration depends on the estate, not on a fixed rule, so no timeline can be given without assessing it. The main drivers are the number of users, groups, hosts and sudo or HBAC rules that must be recreated, the number of applications that bind to LDAP or Kerberos, and whether Kerberos-dependent services must keep running during cutover. Kanidm provides kanidm-ipa-sync for accounts, groups and importable password formats, but it needs LDAPS to one FreeIPA server and a manual change to the retro changelog plugin followed by a reboot. Sudo and HBAC rules and certificates need separate work. Ask for a written assessment that lists each dependency before agreeing a schedule.
Does a regulated buyer need vendor-backed FreeIPA on RHEL?
It depends on your regulator, your audit scope and your internal support policy, so confirm it with your compliance lead and auditor. FreeIPA is packaged in Fedora, Debian and CentOS and in Red Hat Enterprise Linux as Identity Management, and the community project has no paid edition of its own. A vendor-backed build on RHEL brings a support agreement scoped to RHEL, which some buyers need for contractual or procedural reasons. Kanidm's license and release model differ, and its support guidelines describe a four-month support window per stable release, so compare those windows with your patch policy. Neither DeployOpen nor the upstream projects issue certifications that replace this review.
What should we ask for in a written quote for either platform?
Ask for a quote that separates the scope, the deliverables and the recurring costs. Request a list of included components, such as installation, replica design, certificate setup, AD trust configuration, backup testing, migration and documentation, with a named deliverable for each. Ask which items are one-time and which recur, such as support, upgrades and testing retainers. Require the assumptions behind the estimate, including user counts, number of sites and systems in scope, and the client responsibilities listed above. Also ask what changes the price, how change requests are priced, and how acceptance is tested. DeployOpen does not publish a price list, so a quote follows from the written scope.
How DeployOpen helps choose, implement or migrate between them
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For FreeIPA vs Kanidm, we start by testing which identity model your estate needs, then build and hand over the chosen platform or the migration path between them.
How we scope
- We confirm whether Kerberos, Active Directory trusts or SSSD-based Linux login are required before choosing a platform.
- The written scope lists the systems, user populations, OAuth2 or OIDC clients and SSH hosts in each phase.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We install the chosen platform in your cloud accounts, data centers or air-gapped networks, with replicas placed per your recovery needs.
- Where coexistence is needed, we plan and test synchronization from FreeIPA into Kanidm, including the FreeIPA server changes it requires.
- We test authentication paths, backup and restore, and upgrade steps against the release policy of the chosen platform.
How we hand over
- You receive documentation of the configuration, replication topology, backup procedures and the operating runbook.
- Compliance-relevant evidence, such as access control settings and logging, is prepared for your independent auditors, since DeployOpen does not issue audit reports or certifications.
- Handover includes a review of administrator skills, including CLI-based administration where the platform relies on it.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so release changes are planned rather than reactive.
- We can align upgrade windows with the release cadence of the platform you run and confirm the supported version path before each change.
- Confirm with us in writing which support hours, response terms and upgrade responsibilities apply before you sign.
