FreeIPA for healthcare

Why FreeIPA fits Linux systems that hold patient data

FreeIPA fits a health system, clinic group or business associate that runs Linux clinical, research or integration systems and needs unique user identification and access records that can be explained later. It combines 389 Directory Server for users, groups, hosts and policies, an MIT Kerberos KDC for single sign-on, a Dogtag certificate authority for issuing certificates and SSSD on each client, and it runs entirely on servers you control. That on-premises model keeps identity data, keytabs and certificate keys inside your own data centers or cloud accounts rather than in a vendor service. For the team, the main change is one directory that every Linux host consults, so a person has one identity, one set of group memberships and one place where access is granted or removed. Kerberos tickets replace repeated password prompts for SSH and supported services, and host-based access control (HBAC) and sudo rules decide which accounts may log in to which systems and what privileges they receive there. Those rules are the evidence trail an auditor will ask about, so they should be designed around care teams and system roles before the first host is enrolled. FreeIPA is a community project licensed under GPL-3.0-or-later with no paid edition of its own, so there is no license fee to buy. What you pay a partner for is the work around the software: sizing and placing replicas, designing HBAC and sudo policy, setting up MFA and certificate lifecycles, integrating with any Windows-based clinical environment, and running backups and upgrades. Confirm with your own team which of those tasks you can staff and maintain over time before you scope the engagement.

Which HIPAA Security Rule requirements FreeIPA addresses

This table maps the technical safeguards in 45 CFR 164.312 and the workforce access management standard in 45 CFR 164.308 to what FreeIPA provides, what it leaves to you, and what you must document. Read it as a starting point for your risk analysis, not as a compliance determination, since HIPAA has no certification and an assessor will test your own evidence.

Requirement	What FreeIPA contributes	What the team must still document
Unique user identification (164.312(a)(2)(i), required)	Each person gets a unique directory identity, and Kerberos principals and SSSD map Linux logins to that identity on enrolled hosts.	Naming rules, prohibition on shared accounts, and how service accounts are owned and reviewed. Local accounts outside IdM must be inventoried separately.
Emergency access procedure (164.312(a)(2)(ii), required)	Replicas can keep authenticating users when a server or site is unavailable, provided replication and offline login are designed for it.	The break-glass procedure, who may invoke it, how it is logged, and how access is revoked afterward. Confirm offline login behavior on each client build.
Automatic logoff (164.312(a)(2)(iii), addressable)	FreeIPA does not manage session timeouts on its own. Timeouts are set in the operating system, SSH, display manager or the clinical application.	Your assessment of whether automatic logoff is reasonable, the timeout chosen, and any equivalent measure if you decide it is not reasonable.
Encryption and decryption (164.312(a)(2)(iv), addressable)	FreeIPA issues certificates and Kerberos keys, but it does not encrypt patient data at rest or in the applications that store it.	Which ePHI stores are encrypted, key management responsibilities, and the reasoning for any addressable decision.
Audit controls (164.312(b), standard)	FreeIPA keeps its own server and directory logs. Logs from clients, applications and the EHR must be forwarded to your logging platform.	Which systems produce audit records, retention, who reviews them and how reviews are evidenced.
Person or entity authentication (164.312(d), standard)	Kerberos single sign-on, OTP tokens, RADIUS proxying and smart cards support stronger authentication. Enforcement depends on your policies and client configuration.	Which accounts require MFA, how exceptions are approved, and how token issuance and loss are handled.
Workforce access management (164.308(a)(4), standard)	HBAC and sudo rules, groups and roles can restrict who logs in to which clinical hosts and who gets administrative rights.	Access request and approval workflow, role definitions tied to job function, and periodic access reviews with recorded outcomes.
Termination and access removal (164.308(a)(3)(ii)(C), addressable)	Disabling a directory account blocks Kerberos and LDAP-based logins across enrolled hosts.	Offboarding steps for accounts held outside IdM, such as EHR logins, and the timing you commit to internally.
Compliance standing	No FreeIPA feature establishes HIPAA compliance. HHS states that no Security Rule standard requires certification and does not recognize private certifications.	Your risk analysis, policies and evidence packages, which an OCR review or independent assessor would examine.

Modules and settings that matter for clinical Linux estates

A clinical Linux estate depends on a small set of FreeIPA settings: who each account is, how users prove identity, which hosts they reach, and whether workstations still work when the network does not. The cards below cover those settings and the recovery path that keeps them usable, with the target release confirmed before design starts.

Unique accounts and care team groups

Each clinician needs one named account, never a shared login, because HIPAA technical safeguards require unique user identification. Design groups around care teams and roles rather than individual wards, so that access follows the need-to-know model your compliance lead documents. Check how contractors, locum staff and service accounts are created, expired and reviewed. Ask who approves group membership changes and where that approval is recorded.

OTP and RADIUS-proxied MFA

FreeIPA supports HOTP and TOTP tokens, including software tokens and hardware keys such as YubiKeys, and can proxy OTP checks to an existing RADIUS server. Confirm coverage per application before promising MFA, since each login path (console, SSH, web, VPN, remote desktop) must be tested against the token type you choose. Plan token enrollment, lost-token recovery and who can reset a token.

Host-based access control and sudo

Host-based access control rules decide which users may log in to which hosts, and sudo rules decide what they may run once there. In a clinical estate this separates workstations on a ward from database and integration servers that hold patient records. Write rules around the systems each care team actually uses, then test denial cases as well as allowed logins. Review the rules whenever a host is added or moves between zones.

SSSD offline login on workstations

Shared or mobile clinical workstations must keep working when a link to the directory fails, but cached credentials are a risk on shared hardware. SSSD can cache credentials so that a user can log in offline, and the cache policy, expiry and lockout behavior must be set deliberately. Ask your clinical engineering team how many workstations are mobile and how often they leave the network. Test a full offline login and a credential revocation on a sample device.

Dogtag certificates for services

The integrated Dogtag certificate authority issues certificates for hosts and services, which supports TLS on internal applications and encrypted service traffic. Certificate renewal is handled by the first server by default, so the CA and its renewal schedule need an owner and a monitoring check. Confirm which services need certificates, which certificate profiles apply, and how an expired certificate would be recovered before an outage occurs.

Tested ipa-backup and restore

ipa-backup produces full or data-only backups, but a backup is only evidence if a restore has been rehearsed. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restore procedures must be written for your replica layout and run in a separate environment. Record the backup schedule, storage location, encryption and the date of the last successful restore test. Confirm these with your own recovery objectives.

Confirm the target release first

FreeIPA 4.13.4 fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and hardened authentication checks across the API. Confirm that your target release includes these fixes before finalizing the design, and plan the upgrade path for any server still running an earlier version. Document the version of every server and replica, since mixed versions complicate both upgrades and incident response.

How unique user identification is enforced without shared accounts

Every person and every service account gets its own identity in FreeIPA, and that identity is the only thing a clinical system should accept. FreeIPA stores users, groups, hosts and policies in its 389 Directory Server back end and issues Kerberos tickets from its MIT Kerberos KDC, so a person's login maps to one directory entry with one set of credentials. Service accounts for interfaces, batch jobs and monitoring should be created as separate entries, not as a borrowed clinician or administrator login. Roles follow group membership: clinical roles, unit-based groups and administrator groups are granted host access through host-based access control (HBAC) and sudo rules, so access is decided by who is in which group rather than by which workstation someone sits at. Confirm with your clinical and application owners which systems truly require a service identity and which accounts are human users, because that inventory determines the group model.

Deprovisioning is where unique identification most often fails in practice. When an employee leaves or changes roles, disabling the FreeIPA user should block Kerberos authentication and SSH logins on enrolled hosts, but your team must verify this by testing a disabled account against each host class, including any cached credentials that SSSD may hold for offline login. Remove the user from privileged and clinical groups as part of the same process, and check that application-level sessions and any tokens issued outside Kerberos are also revoked. Shared logins on clinical workstations, such as a generic ward account used across shifts, conflict with the unique user identification standard in 45 CFR 164.312(a)(2)(i), which is a required implementation specification. Design shared-use workstations around individual sign-on and session lock first. If that is not feasible, the team must document the exception and decide under 45 CFR 164.306(d) whether an equivalent measure is reasonable and appropriate, for example individual login at the application layer combined with logging that ties each action to a person. Have legal and compliance review that decision, since the rule requires the documented reasoning, not only the control.

Integrating FreeIPA with Windows-based clinical environments

Windows clinical applications and the workstations that run them usually authenticate against Active Directory, and FreeIPA does not change that. Windows machines cannot join FreeIPA as Linux clients, so the practical question is how users from an existing AD forest reach Linux services in FreeIPA. FreeIPA can establish a cross-forest trust with Active Directory through Samba components. The IPA domain must use a DNS domain that does not overlap with any domain in the AD forest, so naming is a design decision to settle before any trust is created.

Trust scope: Decide which AD users and groups need Linux access and map them through ID mapping and ID views rather than copying accounts.
DNS naming: Confirm the IPA DNS domain does not overlap any AD domain, because overlap blocks the trust.
Workstation boundary: Keep Windows workstations on AD group policy and treat FreeIPA as the identity source for Linux hosts only.
Clinical application logins: Map each application's authentication path, such as Windows integrated login, LDAP binds or Kerberos, to a supported identity source.
Change control: Record which trust settings and mappings clinical teams depend on, so server changes do not break logins.

Confirm the supported Windows versions and each clinical application's login path with its vendor before designing the trust.

How a healthcare FreeIPA rollout is sequenced

The sequence starts from the systems that hold ePHI and ends with a tested backup and an evidence package, so each later step rests on decisions already made. The schedule follows the written scope agreed before work begins.

Scope the ePHI systems and business associates
Map every Linux system, application and integration that creates, receives, maintains or transmits electronic protected health information, and list which Windows clinical systems need to authenticate against the same identities. Identify each business associate that administers or reaches those systems, since their access and contracts belong in the same review. The output is a written inventory of systems, user populations and access paths, agreed with your privacy and security leads before design begins.
Design the topology and server roles
Plan at least two to three FreeIPA replicas in each datacenter, following the project's deployment recommendations, and decide which replicas also run the certificate authority or DNS. Assign dedicated servers that run no other applications, and confirm that each client will have at least two DNS servers in its resolver configuration. The output is a topology diagram with replica counts, replication agreements, DNS locations and a named owner for each server role.
Build MFA and access policy
Define who may log in to which hosts, what privileges they receive and which accounts need a second factor. Configure OTP tokens for the populations that need them, and decide whether RADIUS proxying to an existing server is required. Write host-based access control and sudo rules from the inventory, so each clinical system maps to a named care-team or administrative group. The output is an access matrix that a reviewer can trace from a patient-data system back to the approved users and the factor they must present.
Enroll and test clients
Enroll a pilot set of Linux clients that represent each system class in the inventory, then test login, multi-factor prompts, sudo, host access denial for users outside the matrix and unlocking after a failed attempt. Repeat the tests on each supported distribution in your fleet before bulk enrollment. The output is a signed test record for each client class that shows the expected result beside the observed result, with failures resolved and retested.
Run backup and restore drills
Schedule full backups and, where the topology allows, online data-only backups, then restore them into an isolated test environment. Confirm that the restore procedure follows the vendor's guidance on which server handles certificate renewal and CRL publication, and that an outdated backup is never restored into an active replica topology. The output is a dated drill report recording what was restored, how long the operator steps took in practice and which gaps need a runbook change.
Assemble the evidence package
Collect the scope inventory, topology, access matrix, client test records, backup drill reports, change history and any business associate agreements that cover the administrators involved. Map each item to the HIPAA technical safeguard it supports, including unique user identification, automatic logoff and the addressable encryption specifications, and record the reasoning for any addressable item you chose not to implement as written. The output is a versioned package that your compliance lead and independent assessor can review. DeployOpen prepares this evidence but does not issue an audit report or certification.

Compliance considerations beyond the HIPAA Security Rule

The HIPAA Security Rule is not the only rule set that reaches patient data. Business associate contracts, a pending federal revision, voluntary frameworks, EU directives and data protection law can each apply to the same FreeIPA estate. Map which of these apply to your organization before you design identity controls.

Security Rule scope and business associates

The Security Rule applies to covered entities (health plans, health care clearinghouses and covered health care providers) and to their business associates, for all electronic protected health information they create, receive, maintain or transmit. If a partner runs or administers your FreeIPA servers and touches ePHI, that partner is likely in scope. Confirm your role in writing and map which Linux hosts hold ePHI, since the scope follows the data rather than the server label.

Business associate contract flow-down

A business associate contract under 45 CFR 164.314(a)(2)(i) must require the business associate to comply with the Security Rule, pass the same terms to subcontractors that handle ePHI, and report security incidents to the covered entity. For FreeIPA, this means your implementation partner, hosting provider and any managed support firm need matching terms. Ask who holds administrative credentials and how their access is logged and reviewed.

HHS proposed Security Rule revision

HHS proposed a major Security Rule revision on 6 January 2025 (90 FR 898). As of October 2026 no final rule has been published, and the Unified Agenda projects final action for July 2027. The proposal is a planning signal, not a current requirement, so design FreeIPA controls for the rule in force while tracking the docket. Confirm the status with counsel before each planning cycle.

HITRUST as a voluntary framework

HITRUST CSF is a voluntary framework that some payers and providers request from vendors. It is not required by HIPAA, and HHS does not recognize private certifications. HITRUST assessments produce certifications with fixed terms: e1 and i1 certifications last one year and r2 certifications last two years. Only an assessor can issue these, so DeployOpen prepares the controls and evidence but does not issue any attestation.

NIS2 health sector coverage

NIS2 Annex I lists health as a sector of high criticality, including healthcare providers and manufacturers of medical devices critical during a public health emergency. If your operations or subsidiaries are in the EU, identity controls such as MFA, access logging and incident handling may fall under NIS2 obligations. Confirm with local counsel which entities fall in scope and which national transposition rules apply to them.

GDPR Articles 32 and 34 and access control

In 2026 the French CNIL fined Hopital Prive de la Loire EUR 500,000 under GDPR Articles 32 and 34. The authority found that external access to the patient record system lacked VPN and multi-factor authentication, and that access rights ignored the care team's need to know. For FreeIPA, this points to MFA on every remote path into hosts holding patient data, and HBAC rules that reflect clinical roles. Check whether your EU patient data flows also fall under the European Health Data Space regulation.

What do healthcare teams ask before a FreeIPA build?

What does a FreeIPA build cost, and what drives the price?

The cost depends on the written scope, not on a list price. DeployOpen does not publish prices; a quote follows from an agreed scope of work. The main drivers are the number of Linux hosts to enroll, the number of replicas and data centers, whether Active Directory trusts or Windows integration are in scope, how many applications need single sign-on or certificate work, and how MFA is designed for administrators and clinical staff. One-time costs cover design, installation, migration and testing. Ongoing costs cover patching, upgrades, backups and monitoring, which can be run by your team or under a retainer. Ask for the quote to list each of these components separately, along with what is excluded.

How long does a FreeIPA deployment for healthcare take?

Duration is set by scope and by approvals, not by the software alone. The longest items are usually the systems inventory, the access policy sign-off, change windows on clinical systems and any integration with Windows-based environments. Build time grows with the number of replicas, the number of hosts to enroll and the number of applications that must authenticate against FreeIPA. Replica layout follows the FreeIPA deployment recommendations, which advise at least two to three replicas in each datacenter, so the topology decision should be made early. Ask for a timeline that separates design, pilot enrollment, production cutover and handover, with named dependencies for each phase.

What must our team provide before a FreeIPA engagement starts?

Your team needs to supply four things. First, staff with decision authority for identity, security and the clinical systems that will depend on the directory. Second, a systems inventory listing Linux and UNIX hosts, applications, service accounts, current LDAP or Active Directory sources and the owners of each. Third, network access between the planned FreeIPA servers, the clients, DNS and any external services, including the firewall rules and change approvals needed to open them. Fourth, written sign-off on the access policy: who may log in to which hosts, which groups map to which roles, and who may administer what. Agreeing this policy in writing before build is the step that most often prevents rework later.

Can our internal team deploy FreeIPA without an outside partner?

Yes, an internal team can deploy FreeIPA. FreeIPA is GPL-3.0-or-later licensed, a community project with no paid edition of its own, so the software itself carries no license fee. The real question is whether your team has the skills and time to design the topology, run certificate and DNS work, manage replication and keep servers patched and backed up. Many organizations split the work: internal staff own the day-to-day operations and an outside partner handles design, hardening, migration or testing. Assess your team against the specific tasks in the build, and ask any partner to put the division of responsibilities in the written scope.

Does FreeIPA alone make us HIPAA compliant?

No. FreeIPA can support technical safeguards, but HIPAA compliance is an organizational obligation that covers the whole Security Rule. The technical safeguard standard in 45 CFR 164.312 includes unique user identification, which FreeIPA helps you enforce, and automatic logoff and encryption specifications, which depend on how your systems are configured. Administrative and physical safeguards, risk analysis, policies, workforce training and business associate contracts under 45 CFR 164.314 remain your responsibility. HHS states there is no HIPAA certification, so no product or vendor can certify you as compliant. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports or attestations.

How are FreeIPA upgrades and backups supported?

Upgrades and backups are planned as recurring operational work. FreeIPA provides ipa-backup and ipa-restore, with full backups or online data-only backups. The backup documentation warns that the first server handles certificate renewal and CRL publication by default, and that restoring an outdated backup into an active replica topology can break replication, so restore procedures must be tested in a controlled environment. Upgrades move between 4.x releases; for example, the 4.13.4 stabilization release fixed two CVEs, which shows why security releases need a timely plan. Support can be run by your team or under a retainer. Ask any provider to define the backup schedule, restore tests, upgrade windows and who approves each change.

What to ask a partner before signing a fixed-scope FreeIPA contract

Start by reading the written scope against the controls you must evidence. For MFA, ask whether the scope covers the OTP token type (HOTP or TOTP under RFC 4226 and RFC 6238), hardware token enrollment, any RADIUS proxying to an existing server, and which Kerberos settings the MFA flow depends on. Ask for Windows integration to be defined as a named list of systems, such as clinical workstations or an Active Directory trust, with the trust type, DNS layout and ID mapping stated. Ask for backup testing to mean an actual ipa-restore into an isolated replica, with a recorded result, not only a backup job that reports success. Confirm that the scope names who performs each test and where the output is kept.

Ask how the partner handles ePHI during the engagement. Ask whether they will work on production data at all, whether test systems use synthetic identities, where any exported LDAP or log data is stored, how long it is retained and how it is destroyed. Ask whether a business associate agreement is needed. Under 45 CFR 164.314(a)(2)(i), a business associate contract must require the business associate to comply with the Security Rule and report security incidents, so a partner that handles ePHI, or that could reach it through a directory, will normally need one. Have your privacy or legal team confirm the answer rather than relying on the partner's view.

Ask who holds administrator credentials after handover. Ask for a list of every account with admin or Directory Manager rights, the break-glass process, how the partner's access is removed on the closing date, and whether a second person must approve any change to the first server, which by default handles certificate renewal and CRL publication. Finally, ask how the evidence package is delivered: the format, the version of the configuration captured, the list of tests with dates and results, and who signs off. Remember that fixed scope is agreed in writing before work starts, and that DeployOpen prepares evidence but does not issue audit reports or certifications.

How DeployOpen scopes and delivers FreeIPA for healthcare

DeployOpen plans, builds, documents and supports FreeIPA inside your own cloud accounts, data centers or air-gapped networks, so patient-data systems stay under your control. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.

How we scope

Map which Linux systems hold patient data and which staff roles need access to each one.
Document the unique user identification model, MFA coverage and emergency access procedure in the written scope.
Agree which Windows clinical systems need a trust or integration, and how each will be handled.
Confirm with your compliance and legal teams which HIPAA controls the evidence must support.

How we build

Design replica placement across sites, DNS locations and server roles before any installation begins.
Configure OTP tokens, access control rules and sudo policy to match the agreed care-team access model.
Test login, lockout, logoff and access denial paths and record the results for review.
Set up ipa-backup schedules and a documented restore procedure, tested against a non-production topology.

How we hand over

Deliver configuration documentation, runbooks and an access-control record mapped to the agreed scope.
Walk your administrators through daily operations, change control and certificate and backup checks.
Provide evidence packs that show configuration state, but note that independent auditors issue any assessment outcome.
Confirm acceptance criteria in writing before closing the engagement.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the build.
Plan FreeIPA version upgrades in a staging topology before any production change.
Re-test access controls after organizational changes, such as new care units or staff role changes.
Ask any support provider to confirm response expectations in the written retainer before you sign.