FreeIPA has served a lot of engineering teams well. It is capable, it handles LDAP and Kerberos authentication reliably, and it is free. The problem is that it is also unmaintained in the sense that matters most: the operational model it represents, centralized directory-based SSH authentication with long-lived credentials, is increasingly misaligned with how modern cloud infrastructure is accessed and secured.

If you are running freeIPA for EC2 access today and thinking about a migration, you are in good company. The decision is not just "which tool replaces freeIPA" but "what does modern infrastructure identity look like, and how do we get there from here without breaking production?"

This guide covers the commercial alternatives worth evaluating, what a realistic migration roadmap looks like, and where identity governance fits into the new stack once you have landed on a replacement.

What You Are Actually Replacing

Before evaluating alternatives, it is worth being clear about what freeIPA is doing in your environment, because the replacement may not be a single tool.

FreeIPA is providing:

• A centralized user directory (LDAP-based) that EC2 instances use to authenticate login requests
• Kerberos-based authentication for users connecting to those instances
• Group-based access control for which users can log into which systems
• DNS and certificate management (in many deployments)

A modern replacement for this architecture typically separates these concerns: an IdP handles the authoritative user directory and authentication, and a separate tool handles the infrastructure access layer, connecting the IdP to your EC2 instances and managing the actual session brokering.

Commercial Alternatives Worth Evaluating

The specific tool choices depend on your environment, how deep your AWS investment is, and what the rest of your identity stack looks like. These are the most commonly recommended paths.

AWS IAM Identity Center (formerly AWS SSO). If you are running EC2 in AWS and not looking to introduce third-party dependencies, IAM Identity Center is the natural starting point. It integrates with AWS Systems Manager Session Manager, which allows you to access EC2 instances through the AWS console or CLI without managing SSH keys or LDAP credentials at all. SSM Session Manager eliminates inbound SSH entirely, which is a meaningful security improvement. The trade-off is that it is AWS-native and does not extend as cleanly to non-AWS infrastructure.

Teleport. One of the most widely recommended commercial alternatives specifically for replacing LDAP/Kerberos-based infrastructure access. Teleport eliminates static SSH keys and long-lived credentials, replacing them with short-lived certificates issued by your centralized IdP. Users authenticate through SSO, Teleport validates them against the IdP, and issues a certificate that expires after a defined window. All sessions are recorded. It extends to Kubernetes, databases, and internal applications alongside SSH. The learning curve is real but the security posture improvement is substantial.

Okta Advanced Server Access. If your organization is already standardizing on Okta for SaaS identity, Okta ASA extends SSO-based authentication directly to Linux and Windows server logins. Credentials are ephemeral, tied to the SSO session, and the tool integrates with Okta's existing access policies and MFA configuration. It removes the need for a separate infrastructure access layer if Okta is already your IdP.

HashiCorp Boundary. Relevant primarily if your team is already heavily invested in the HashiCorp ecosystem (Terraform, Vault). Boundary handles secure remote access using a zero trust model, integrating with Vault for credential brokering and Terraform for infrastructure provisioning. It is a more complex implementation than the others but fits naturally into HashiCorp-first environments.

The common thread across all of these is the move away from static credentials and persistent directory-based authentication toward ephemeral, SSO-backed access. That is the architectural direction the market has converged on, and whichever tool you choose should support it.

A Realistic Migration Roadmap

Migrating off freeIPA is rarely a clean cutover. The realistic path looks more like a phased transition that allows the old and new systems to run in parallel until you are confident the new one covers all your use cases.

Phase 1: Establish the new IdP as your source of truth. Before touching EC2 access, get your modern IdP in place: Okta, Azure AD/Entra ID, or AWS IAM Identity Center depending on your direction. Migrate user records, configure SSO for your SaaS applications, and establish this as the authoritative directory going forward. This creates the foundation the infrastructure access layer will rely on.

Phase 2: Deploy the new access infrastructure alongside freeIPA. Roll out your chosen infrastructure access tool (SSM agents, Teleport nodes, Okta ASA agents) to your EC2 instances. Configure it to authenticate against the new IdP. Run it in parallel with freeIPA during this phase. Engineers can log in through either path while you validate coverage.

Phase 3: Phased cutover by team or system. Shift teams to the new access method one at a time. Start with the teams most willing to test the new workflow, learn what breaks, and fix it before rolling out more broadly. The most common issues at this stage are automation scripts and CI/CD pipelines that use freeIPA service accounts or static SSH keys that need to be updated to use short-lived tokens or OIDC-based credentials.

Phase 4: Decommission freeIPA. Once you have verified that all human and non-human access through freeIPA has been migrated and no remaining traffic is using the old directory, remove the freeIPA clients from your EC2 instances and shut down the freeIPA server infrastructure.

The timeline for this varies significantly based on how many EC2 instances you are managing, how much automation depends on freeIPA credentials, and how much organizational appetite there is for parallel systems during the transition period.

The Distinction Between Authentication and Governance

One thing worth being clear on as you plan the new stack: the tools described above handle authentication, which is who can log in and how they prove it. They do not handle governance, which is who should have access, whether that access was properly approved, whether it has been reviewed recently, and what happens when someone's role changes or they leave.

For smaller organizations, the IdP and infrastructure access tool may be enough for initial governance needs. For organizations with compliance requirements (SOC 2, ISO 27001, HIPAA), or at a scale where access reviews and offboarding verification matter operationally, an IGA layer sits above the infrastructure tools and provides the governance program.

Zluri operates in this layer. It does not replace your IdP or infrastructure access tool. It sits above them, connecting to the access data they produce, and providing the governance processes that compliance and security programs require: self-service access requests with automated approval routing, access reviews that pull current data from your infrastructure tools, and offboarding workflows that verify access was actually revoked across all connected systems.

Zluri is explicit about what it does not do in this context: it does not handle SSH authentication, credential rotation, privileged session recording, or certificate management. Those belong to the infrastructure access layer. The governance layer is complementary, not a replacement.

What Good Infrastructure Access Governance Looks Like

Once your new infrastructure access stack is in place, the governance layer closes several gaps that the access tools alone leave open.

Self-service access requests. Instead of IT manually creating accounts or granting SSH access when a developer joins or needs access to a new system, employees can request access to specific AWS roles or infrastructure groups through a self-service catalog. The request routes to the appropriate manager or resource owner for approval, and provisioning happens automatically once approved.

Access reviews for infrastructure. Compliance frameworks that require demonstrating least privilege need evidence that access to sensitive systems is periodically reviewed. An IGA platform can pull access data from your infrastructure tools and run certification campaigns, routing approval requests to the right people and producing the audit evidence that external auditors require.

Offboarding verification. When a developer leaves, the offboarding process needs to confirm that their access was actually removed from EC2 environments, not just that someone ran the checklist. An IGA platform that maintains a continuous access record can verify completion and produce evidence for audit purposes.