Open-source alternative to Okta Privileged Access: the short answer
If your renewal or add-on pricing change has put Okta Privileged Access under review, the short answer is that Teleport and JumpServer both cover SSH and RDP server access and session recording, while identity stays in Okta or Keycloak. You keep your existing identity provider for sign-in and group membership, and the bastion layer moves into infrastructure you run. Okta Privileged Access itself is a first-party app that depends on a workstation client, a server agent on each host, an optional gateway and a cloud tenant, so the open-source replacement changes where that control plane lives as well as what it costs.
Shared account vaulting and approval workflows differ by product and by edition, so do not assume parity with Okta. JumpServer documents credential and password rotation, ticket and just-in-time approval workflows as Enterprise features, while Teleport's Community Edition limits roles requests to the CLI and places just-in-time access requests and reviews in Enterprise Identity Governance. Confirm with each vendor which controls your edition provides, including moderated sessions, dual authorization and SSO options, before you map your current Okta policies. The rest of this page explains the coverage, the licensing limits and what a migration involves.
Which open-source option covers each Okta Privileged Access capability
This table maps each Okta Privileged Access capability to Teleport, JumpServer and secrets managers, and flags edition limits and gaps. Read each row as a question to confirm against your own environment, since Community and Enterprise tiers differ on several features. The main takeaway is that SSH, RDP and recording have open-source coverage, while SaaS service account management needs validation.
| Okta Privileged Access capability | Teleport | JumpServer |
|---|---|---|
| SSH server access | Covered. Certificate-based access with short-lived certificates, compatible with OpenSSH servers and clients. | Covered. SSH access through the KoKo proxy, with a web terminal (Luna) and a web interface (Lina). |
| RDP server access | Covered for Windows hosts. Confirm the Windows desktop access setup and edition for your environment. | Covered. RDP is listed as a supported protocol. RDP proxying (Razor) is a private Enterprise component, so confirm which edition you need. |
| Session recording | Included in both Community and Enterprise, with playback. Moderated sessions and dual authorization are Enterprise only. | Included in Community. Transcoding of recordings uses a private Enterprise worker, so confirm the scale you need. |
| Shared account vaulting | Partial. Teleport centers on short-lived certificates rather than stored shared passwords, so confirm how your shared accounts would be handled. | Covered in Enterprise. Password rotation is an Enterprise feature. Confirm the vaulting model in the Community edition. |
| Service account management for SaaS apps | Gap to confirm. Teleport's protected resources focus on infrastructure and databases, not SaaS application accounts. Confirm with the vendor. | Gap to confirm. Confirm whether SaaS account management meets your requirements, or pair with a secrets manager. |
| Access requests with approval workflows | Enterprise only. Community roles can only be requested through the CLI. Just-in-time requests and reviews sit under Identity Governance. | Enterprise only. Ticket and just-in-time approval workflows are listed as Enterprise features. |
| Single sign-on with your identity provider | Community supports GitHub SSO only. Okta, OIDC and SAML SSO require Enterprise. Keycloak or Okta can be the identity source in Enterprise. | SSO is an Enterprise feature. Confirm the supported protocol and identity provider combinations with JumpServer before planning. |
| Activity logging and audit trail | Audit events are captured by the cluster. Confirm the export path to your SIEM, since Okta sends activity to the System Log. | Operation logs are kept by the platform. Confirm how logs are forwarded to your SIEM and retained. |
Teleport or JumpServer: which fits which server estate
Teleport is built around identity-aware access. It ships as a single Go binary that includes an access proxy, a certificate authority that issues short-lived certificates, a unified access control system and a tunneling system that reaches resources behind the firewall. Users authenticate through their identity provider, receive a certificate that expires automatically, and connect to SSH nodes with OpenSSH clients. Teleport states that it is fully compatible with OpenSSH servers and clients, so existing SSH workflows can often continue with fewer shared keys to manage.
- Protocols: SSH nodes, Kubernetes clusters, PostgreSQL, MongoDB, CockroachDB, MySQL, internal web apps and Windows hosts.
- Licensing: The API module is Apache 2.0 and the rest of the source is AGPL-3.0. Community Edition builds are limited to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions.
- Session recording: Playback is included in both editions. Moderated sessions, dual authorization and Device Trust are Enterprise features.
- Release cadence: The changelog lists 18.11.0 on August 25, 2026, 18.11.3 on October 2, 2026 and 18.11.4 on October 14, 2026, so plan patch windows against a frequent release schedule.
- Single sign-on: Community Edition supports GitHub only, so Okta or Keycloak integration requires Enterprise.
Confirm with Teleport whether your organization falls under the Community Edition limits before deploying in production, and ask how the Enterprise quote covers active users and protected resources.
JumpServer is a bastion host and privileged access platform that puts SSH, RDP, Kubernetes, databases, websites, RemoteApp and VirtualApp access in one web workspace. Its open-source core includes Lina for the web interface, Luna for the web terminal, KoKo as the protocol connector and proxy, and Chen as the web database connector. It is distributed as container images on Docker Hub under the jumpserver organization and includes an installer project for installation and management. The quickstart expects a clean 64-bit Linux server with at least 4 CPU cores and 8 GB of RAM, installed with a quick_start.sh script from the GitHub releases.
- Licensing: GPL-3.0, with copyright held by FIT2CLOUD for 2014 to 2026. Community Edition is free for self-hosting up to 5,000 assets in a standalone topology.
- Enterprise components: Panda (Linux application connector), Razor (RDP proxy), Magnus (database proxy), Nec (VNC proxy) and a session recording transcoding worker are private Enterprise components. The Tinker Windows application connector is free for Community Edition.
- Enterprise features: Oracle and SQL Server access, password rotation, ticket and just-in-time approval workflows, custom roles, multi-tenancy, SSO, RADIUS, LDAP HA and cloud asset sync.
- High availability: Standard and Pro tiers offer active-standby HA, and Ultimate offers a full HA cluster. Community Edition runs as a standalone topology.
- Releases: v5.0.0 shipped on September 17, 2026 and v5.1.0 on October 15, 2026.
If your estate is mainly Windows RDP and shared accounts, test JumpServer's RDP path and password rotation on a representative host before committing.
A small estate of Linux servers reached mainly over SSH, managed by a platform team that already uses OpenSSH and certificate-based access, is where Teleport usually fits most directly. Because Teleport runs as a single binary and can run as a Linux daemon, a pilot can be built on a few nodes without a separate database tier. Short-lived certificates reduce the need to manage shared SSH keys on each host, which is one of the main reasons teams replace bastion hosts.
- Fit: A team of fewer than 100 employees with under $10,000,000 in annual revenue may use Community Edition, subject to the license terms.
- Identity: Community Edition SSO is GitHub only, so Okta or Keycloak login needs an Enterprise license.
- Access requests: Roles can be requested only through the CLI in Community Edition. Just-in-time requests and reviews are Enterprise features.
- Operations: A single binary simplifies upgrades, but each Teleport release must be tested against your agents and OpenSSH clients.
- Session evidence: Recording and playback are available in both editions, which supports basic review.
Confirm your employee and revenue position against the license file before you choose Community Edition for production use.
Estates that mix Windows RDP hosts, network devices, databases and shared administrator accounts often need a vault that rotates passwords and a workflow for approvals. JumpServer covers these needs in its web workspace, and its Enterprise tiers add password rotation, approval workflows and additional database protocols. Teams running Oracle or SQL Server access should check whether those protocols are covered by the tier they need, since these are listed as Enterprise features.
- Shared accounts: Credential vaulting and password rotation are central to this use case and are listed in the Enterprise feature set.
- Protocols: SSH, RDP, Kubernetes, databases and web access are covered through one interface.
- Sizing: The 4 CPU core and 8 GB RAM minimum applies to the quickstart. Production sizing for session volume and asset count should be validated in a load test.
- Scale: Standard and Pro add active-standby HA, and Ultimate adds a full HA cluster, so plan the tier around uptime needs.
- Support: Community support runs through GitHub and the forum, while Enterprise adds an SLA and account manager.
Ask JumpServer to confirm which protocol and rotation features apply to your exact tier before scoping the rollout.
Keeping Okta or Keycloak as the identity provider
Replacing Okta Privileged Access does not mean replacing Okta or Keycloak as the source of identity. The identity provider still authenticates people, and the access layer must trust its tokens, map its groups and revoke sessions when someone leaves. The cards below cover how Teleport and JumpServer connect to that provider, and what has to be rebuilt by hand.
Teleport SSO and Community limits
Teleport Community Edition limits single sign-on to GitHub, so connecting Okta or Keycloak through OIDC or SAML requires the Enterprise edition. Confirm this before design work starts, because the choice of edition determines whether the existing provider can be the login source at all. Teleport's license also limits Community builds to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, so larger organizations should treat Enterprise as the default path for this pattern.
JumpServer SSO and LDAP options
JumpServer's SSO integration is listed as an Enterprise feature, while LDAP and RADIUS are the directory and authentication paths to check against your Community deployment. Map which login method each administrator and operator uses, and test a break-glass local account before cutover. Confirm with JumpServer which protocols each edition supports for your Okta or Keycloak configuration.
Keycloak as the broker
Keycloak can sit between the access platform and an upstream directory, such as Active Directory or LDAP, and issue OIDC or SAML tokens to Teleport or JumpServer. This keeps one place for MFA policy and session lifetime while the access layer handles SSH and RDP. Document which realm, client and group claims each access platform expects, since mismatched claim names are a common cause of access failures.
Replacing the Okta OIDC and SCIM app
Okta Privileged Access runs as an OIDC and SCIM app in the identity tenant, and its activity flows into the Okta System Log. When Okta is replaced by Keycloak or the access layer changes, that app, its SCIM provisioning and its log events have no direct equivalent. Inventory every assignment and provisioning rule, then decide where the replacement access logs will be kept for audit.
Rebuilding group mappings
Okta group membership is currently what grants access to servers, vaulted accounts and approval workflows. Each group must be mapped to a Teleport role or a JumpServer user group, and that mapping must be tested with real accounts from each team. Keep a written mapping table that names the source group, the target role and the owner who approves changes.
Offboarding that still revokes access
Access revocation depends on the identity provider removing or disabling a user, and the access layer must honor that change quickly. Confirm how long an existing Teleport certificate or JumpServer session remains valid after a user is disabled, and test that a removed user cannot open a new SSH or RDP session. Add a documented check to the leaver process so access is not left open because only one system was updated.
Moving server access, recordings and shared accounts off Okta
This sequence moves SSH and RDP access, session recordings and shared account credentials from Okta Privileged Access to a self-hosted proxy, with every credential rotated and every audit record preserved before the Okta Team is decommissioned.
Inventory servers, accounts and access policies
Your team exports the list of servers enrolled in the Okta Privileged Access Team, the shared accounts vaulted in it, the service accounts used for SaaS apps, and the access request and approval rules that govern each one. Ask the Okta administrator to confirm which servers are reached over RDP and which over SSH, since the replacement must cover both. The step is done when every protected resource has an owner, a protocol and a list of the people or groups who reach it today.
Choose and deploy the access proxy in a test network
Decide between Teleport and JumpServer based on the protocols and features you inventoried, then deploy the chosen platform in a test network that mirrors production routing. Teleport runs as a single binary or a Kubernetes Helm deployment, and JumpServer installs on a clean 64-bit Linux server with at least 4 CPU cores and 8 GB of RAM using its quick_start.sh script. Confirm with the vendor which edition covers your needs, since features such as just-in-time requests, moderated sessions and RDP proxying vary between Community and Enterprise editions. The step is done when a test user can sign in through your identity provider and reach a test server.
Enroll servers with agents or OpenSSH-compatible access
Register each production server with the new proxy using the platform's agent or, for SSH hosts, its OpenSSH-compatible certificate flow. Teleport issues short-lived certificates and states it is compatible with OpenSSH servers and clients, which lets many hosts be enrolled without distributing shared keys. Windows hosts need a separate check of the RDP path during this step. The step is done when each server appears in the new inventory and a test session is recorded.
Move shared credentials and rotate them
Plan each shared account as a credential that must be replaced, not copied. Store the new credentials in JumpServer's asset store or in a secrets manager that your proxy can reach, then rotate every password, key and token that was held in the Okta vault so the old values no longer grant access. Your security team should approve the rotation order to avoid breaking scheduled jobs, and it should confirm that old values have been revoked. The step is done when the old Okta-vaulted credentials are invalid and the new vault holds the only working values.
Run old and new access in parallel
Keep Okta Privileged Access active while administrators and a defined pilot group use the new proxy for real work, and track any server or workflow that still depends on the old path. Compare session recording and approval behavior in both systems during this window, and document each difference for the security team. Confirm that policy changes made in one system are reflected in the other, or retire the old policy as soon as the new one is verified. The step is done when every inventoried server has been reached through the new proxy at least once and no open dependency on the Okta path remains.
Export recordings and System Log evidence
Before decommissioning the Team, export session recordings and the activity records that Okta Privileged Access sends to the Okta System Log, and store them in your retention system with their checksums and chain of custody. Confirm with Okta which export formats and retention limits apply to your tenant, since no migration tool for these records is supplied with this guide. Your compliance lead should check that the archive meets your audit and legal retention obligations. The step is done when the archive has been verified as readable and is recorded in your evidence register.
Decommission the Team and update runbooks
Remove the servers, service accounts and SCIM and OIDC connections from the Okta Privileged Access Team, then disable the app integration in Okta once no path depends on it. Update operator runbooks, onboarding and offboarding procedures, and the access control descriptions used in audit evidence so they name the new proxy, its logs and its approval workflow. Ask your auditor to confirm which evidence they will accept for the transition period. The step is done when Okta no longer brokers any server access, the runbooks name the new platform, and the audit evidence reflects the new control owner.
What does it cost and take to replace Okta Privileged Access?
What are the cost components when replacing Okta Privileged Access?
The cost splits into software licensing, servers and high availability, storage for session recordings, identity integration, migration effort and ongoing operations. Okta Privileged Access is sold as an add-on to Okta suites, and Okta's pricing page lists it without a published per-user price, so the comparison starts from the suite you already pay for. Teleport and JumpServer can each be run at no license cost in their open-source editions, but you still pay for the servers, the database, the people who operate the platform and any vendor support you choose. Ask each vendor to price every component separately so you can see what is one-time and what recurs.
Is JumpServer Community free for our number of servers?
JumpServer's pricing page lists a free self-hosted Community edition for up to 5,000 assets in a standalone topology. Assets include servers, network devices and databases, so count every target you plan to protect, not only Linux hosts. Above that count, or if you need active-standby high availability, the Enterprise Standard, Pro or Ultimate tiers apply, and JumpServer prices those by quote. Confirm the asset count and the topology you need in writing before you assume the Community edition covers the environment.
What licensing applies to Teleport Community Edition in a regulated organization?
Teleport's Community Edition license limits the distributed builds to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions. A larger organization therefore needs to look at Teleport Enterprise, which Teleport prices by quote based on active users and protected resources. Read the license with your legal team before deployment, and ask the vendor to confirm in writing which edition and terms apply to your headcount and revenue.
What drives the cost of a privileged access platform up?
The main drivers are the number of servers and resources, the number of active users, the high availability tier, and how long session recordings are kept. Teleport's pricing page says customers pay for active users and protected resources, so growth in either raises the license cost. Recording retention drives storage: every recorded SSH or RDP session consumes disk or object storage for as long as you keep it, and the volume depends on how many sessions run and how long they last. High availability adds servers and a database that can fail over, which raises both the infrastructure and the operations effort.
Can our team run Teleport or JumpServer without outside help?
A team with Linux administration, database and certificate management experience can deploy either platform alone, provided it has time to build the work. Teleport runs as a single Go binary on Linux or as a Kubernetes Helm deployment, and JumpServer installs on a clean 64-bit Linux server with at least 4 CPU cores and 8 GB of RAM using its quick_start.sh script. The harder work is the integration: connecting the identity provider, writing roles, moving shared accounts into a vault, rolling out clients to workstations and agreeing on recording and retention rules. Teams without that experience usually bring in a partner for the design and handover.
How long does a privileged access replacement take?
No duration is supplied for this migration, so treat any timeline as something to agree in writing rather than assume. The main drivers are the number of server groups and access paths, how many shared accounts need to be moved into a vault, whether Okta or Keycloak stays as the identity provider, and how many teams must be trained. A pilot on one server group is a common first step because it tests the workflow, the recording setup and the access requests before the rest of the estate moves. Ask for the phases and their exit criteria in the scope document.
What should we ask for in a written quote for this migration?
Ask for a line-item quote that separates license or subscription fees, infrastructure, database and storage, identity integration, migration, training and ongoing support. For each platform, request the edition, the asset or user count it is priced on, the high availability tier and whether recording retention is included. Ask how session recordings are stored, backed up and purged, which Okta or Keycloak features remain in use, what happens to the Okta System Log feed, and what support level and response terms apply. Fixed-scope agreements list deliverables and timelines in writing before work starts, so ask for the same from any partner.
Does Okta Privileged Access cost stay in place if we keep Okta for SSO?
Yes, the Okta Privileged Access add-on is separate from the identity provider, so keeping Okta or Keycloak for single sign-on does not remove the add-on cost on its own. Okta's pricing page lists Privileged Access as an add-on in the Starter and Core Essentials suites and gives resource units per license in Professional and Enterprise. If you keep Okta for sign-in and replace only the access layer, ask Okta which add-on lines and resource units you can remove at renewal. Keycloak can serve as the identity provider for Teleport or JumpServer without a per-user identity fee.
What you give up and what you gain when you leave the Okta add-on
The biggest gap is that Okta manages more of the surrounding work for you. Okta Privileged Access includes service account management for SaaS applications, which the open-source options covered here do not replicate in the same form. Teleport and JumpServer focus on the server access path, session recording and shared account vaulting, so any SaaS service account rotation you rely on today needs a separate owner, tooling or manual process. Okta also runs its own agents on workstations and servers and sends activity to the Okta System Log. With Teleport or JumpServer, you run the client, agents and gateway yourself, and audit events go to your own logging stack. Confirm which audit events you need in your SIEM and build that export before you cut over, because the System Log integration will not carry over automatically.
Support also changes shape. Okta Privileged Access sits under Okta's support contracts, while Teleport Community Edition and JumpServer Community edition are supported through GitHub and community channels (JumpServer also offers a forum). JumpServer Enterprise adds email and ticket support with an SLA and an account manager, and Teleport Enterprise adds its own commercial support tier. Check the Teleport license terms before you deploy: its Community Edition builds are available only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions. Larger organizations will likely need an Enterprise subscription or a support arrangement with DeployOpen or another provider for production use. Ask Teleport and JumpServer for written confirmation of your eligibility before you commit to a design.
What you gain is control over the access path and the evidence. Session recordings live on servers you choose, so retention, access to recordings and deletion follow your own policy rather than a vendor's. Teleport issues short-lived certificates and replaces shared SSH keys, and its SSH compatibility with OpenSSH clients and servers lets you keep existing command-line habits. JumpServer gives you a single workspace for SSH, RDP and other protocols on infrastructure you control. Both are open source, so your security team can review the code, pin versions and test patches before rollout. Teleport's API module is Apache 2.0 and the rest of its source is AGPL-3.0, while JumpServer is GPL-3.0, so have legal review how your use and any modifications fit those licenses.
Risks to plan for before cutover
Replacing Okta Privileged Access with Teleport or JumpServer moves session access, credentials and audit evidence into software you run. The cards below cover the licensing, upgrade, key and evidence risks that are easiest to miss until after cutover, with the questions to settle with each vendor and in your own environment first.
Teleport Community licensing limits
The Teleport Community Edition build is available only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions. Confirm your headcount and revenue against these limits before you commit to Community. If you exceed them, price Enterprise by quote, since Enterprise also adds features such as moderated sessions, dual authorization and Identity Governance that Community does not include.
GPL and AGPL obligations for modified builds
JumpServer is GPL-3.0 and most of Teleport's source is AGPL-3.0, so modifying either product, or offering a modified version to users over a network, can trigger source disclosure duties. Ask your counsel whether any connector, script, or patch your team writes will be distributed or made available to users. Keep configuration, integrations and playbooks outside the forked source tree where you can, and record which build and patch set you run.
Upgrade cadence and patch ownership
Teleport and JumpServer both ship frequent releases, including point releases and maintenance branches, so a fixed upgrade calendar matters more than the install itself. Decide who watches release notes, who tests upgrades against your Okta and SSH configuration, and who approves emergency patches. Confirm with each vendor which versions receive security fixes and how long older branches stay supported.
Certificate authority and key management
Teleport's certificate authority issues short-lived user and host certificates, so the CA private keys and signing configuration become the most sensitive assets in the deployment. Define where those keys are stored, who can rotate them, and how you recover if the CA is compromised or a host key changes. Test the procedure in a non-production cluster, and confirm which key storage options your edition supports, including any HSM support that is limited to Enterprise.
Audit evidence continuity
Session recordings and access logs must remain available for the period your auditors sample, even after the Okta tenant is retired. Confirm where recordings are stored, how long they are kept, and whether the same evidence can be exported in a form your assessor accepts. Check that events from the new system reach your central log store, and document the period in which both systems ran in parallel so the evidence trail has no gap.
Shared account vault migration
Credentials stored in the Okta Privileged Access vault will not move automatically into JumpServer or Teleport. Inventory every shared account, service account and rotation rule, then decide which secrets are re-entered, which are rotated at cutover, and which move to a dedicated secrets manager. Confirm with the vendor which password rotation features are included in your edition, since JumpServer lists password rotation as an Enterprise feature.
How access controls map to audit evidence
Session recording, approval records and certificate lifetimes are the evidence an assessor will ask for first. Each control theme in a privileged access review, such as who may reach a server, under what approval, for how long, and what they did once connected, has to be answered with records that the platform or its logs can produce. In Teleport, session recording with playback is available in both editions, so the recordings themselves can serve as evidence of activity on SSH nodes and Windows hosts. Moderated sessions and dual authorization, which add a second approver to a live session, are Enterprise features in Teleport's feature matrix, so confirm whether your control design depends on them. In JumpServer, the Community edition covers session recording for protocols it supports, while ticket and just-in-time approval workflows are listed among its Enterprise features. Before committing to either product, ask the vendor which recording and approval records are retained, where they are stored, and how long they can be kept.
Short-lived credentials shift the evidence question from stored secrets to issuance records. Teleport uses certificate-based authentication with automatic expiration rather than shared SSH keys, so the assessor's question becomes whether the certificate authority's issuance and role mappings are logged and reviewable, and whether access requests are tied to a named identity. With Okta Privileged Access, activity is sent to the Okta System Log, which gives a second source of events to reconcile against the platform's own records. If Keycloak remains the identity provider, its event logs and the identity provider's group membership changes become part of the same chain of evidence. Your team should confirm where each log lives, how it is protected from alteration, and how long it is retained.
DeployOpen prepares systems, controls and evidence for compliance assessments, including configuring recording, approval and log retention in your environment, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies. A practical first step is to map each control theme your assessor uses to a named record, an owner, and a retention period, then test that the record can actually be produced during a sample review. Scope and deliverables for this work are agreed in writing before implementation starts.
