Infrastructure access in 2026: revisit Teleport, Boundary and Warpgate before you hand out another SSH key

Manoj Shukla
October 31, 2026

Every engineering team has an access story it does not like to tell. A new developer joins, and someone appends her public key to authorized_keys on fourteen servers by hand. A contractor leaves, and nobody is fully sure which hosts still trust his key. The production PostgreSQL password sits in a shared password manager folder that thirty people can open, and it has not changed since the database was created. The Kubernetes admin kubeconfig was copied to four laptops during an incident two years ago. The bastion host works, but its logs say only that somebody logged in as ubuntu at 11:42 PM.

None of this happens because people are careless. It happens because the simple tools, SSH keys, shared passwords and one jump box, are fast on day one, and the cost shows up slowly. When an auditor or a customer security questionnaire asks “who accessed production, when, and what did they do”, the honest answer is usually “we can find out, roughly, in a few days”.

This post revisits three tools that teams look at when they decide to fix this: Teleport, the largest and most complete access platform; HashiCorp Boundary, the identity based session broker from HashiCorp, now part of IBM; and Warpgate, a younger, single binary bastion written in Rust. Around them we will also look at the simpler option that many teams should consider first, plain OpenSSH certificates from a small CA such as step-ca, and at the OpenBao or Vault SSH secrets engine, Tailscale SSH on a mesh VPN, JumpServer and Pomerium. The goal is not to crown a winner. The goal is to be clear about what each tool really changes in your access path, what its licence lets you do in 2026, and how much operational weight you are signing up for.

There is one piece of news you should know before reading further. On 8 October 2026 HashiCorp archived the Boundary Community Edition repository and said no new Community Edition releases, bug fixes or security patches are planned. That changes the Boundary discussion a lot, and we will come back to it several times.

If you are new to this series, a few earlier posts connect directly. Access tools are only as good as the identity behind them, so read Keycloak and its alternatives first if your SSO is not settled. Short-lived SSH certificates and database credentials often come from a secrets manager, covered in Vault and OpenBao. The step-ca side of certificates is in TLS certificate automation in 2026. If your real problem is that SSH ports are open to the internet, start with mesh VPNs in 2026. Secrets that applications use inside Kubernetes are a different problem, covered in Kubernetes secrets delivery in 2026. Fine grained permissions inside your own applications are in authorization in 2026, and the HTTP proxy layer that Pomerium and Warpgate both touch is in reverse proxies in 2026. Keys leaking into Git is its own topic, in secret scanning in 2026.

A scenario to keep us honest

To keep this practical, we will use one invented company through the post. Santra Logistics is an invented example, not a real business. It is a cold chain logistics firm based in Nagpur, with reefer trucks moving oranges, dairy and pharma consignments across Maharashtra, Madhya Pradesh and Telangana. The tech team has 14 people, led by an engineer called Ketaki, plus two contractors who look after the warehouse management system.

What they run:

About 40 Linux VMs across a rented rack in a Nagpur data centre and one public cloud region.
One kubeadm Kubernetes cluster for the tracking APIs, driver app backend and customer portal.
PostgreSQL for orders and billing, MySQL for the warehouse system (a vendor product), and Redis.
Four Windows servers for the accounting package, reached over RDP.
An internal Grafana and a small admin web app for dispatch.

How access works today:

One bastion VM with a public IP and SSH open to the internet, protected by fail2ban.
Personal SSH keys copied into authorized_keys on each server by an Ansible playbook, which nobody has run fully since March.
The PostgreSQL app_admin password and the MySQL root password in a shared vault folder.
Two admin kubeconfigs with client certificates valid for a year.
RDP through a port forward on the bastion.

What triggered the review: a pharma customer’s audit asked for evidence of who accessed the production database in the last quarter and asked whether sessions were recorded. The team could produce bastion login lines, but not which database user did what. In the same month a contractor’s laptop was stolen, and it took two days to confirm that his key had been removed from every host.

Santra is a company of well under 100 employees with revenue well under the equivalent of ten million US dollars. Keep that in mind, because it matters for Teleport’s licence.

The short version

Teleport is the most complete option: SSH, Kubernetes, databases, web apps, Windows desktops and more, all through short-lived certificates issued by its own CA, with session recording and a strong audit log. The open source code is AGPLv3, but the official Community Edition binaries since version 16 are under a commercial licence that allows use only by organisations with fewer than 100 employees and less than USD 10 million annual revenue. Community Edition SSO is GitHub only; OIDC and SAML are Enterprise features.
Boundary is a clean design for brokering sessions to targets by identity, with workers that proxy traffic and integration with Vault for dynamic credentials. It has been under the Business Source License since version 0.14, and the Community Edition repository was archived on 8 October 2026. Session recording and SSH and RDP credential injection were already HCP Boundary and Boundary Enterprise features. In late 2026 it is a reasonable choice only if you plan to pay for HCP Boundary or Boundary Enterprise.
Warpgate is the simplest to stand up: one binary, Apache 2.0, a web admin UI, OIDC SSO built in, session recording, and support for SSH, HTTPS, Kubernetes, MySQL, PostgreSQL, RDP and VNC. Users connect with their normal clients. It is younger, has a smaller team, and has published a steady stream of security advisories in 2026, which you must keep up with.
Plain OpenSSH certificates from a small CA, with SSO in front, solve the key sprawl problem for SSH alone with very little new software. Many teams should start here and add a proxy only when they need recording or database access.
For Santra, the plan we arrive at is: SSH certificates first, then Warpgate (or Teleport Community Edition, which they qualify for today) for recorded database, RDP and admin web access, then retire the shared passwords.

Where things stand on 31 October 2026

Teleport

Current release line is 18.x. The latest release on the official changelog is 18.11.8, dated 29 October 2026. Version 19.0.0 appears in the upstream changelog only as unreleased.
18.11.0 (25 August 2026) added Linux desktop access for X11 hosts, export of desktop session recordings to video, and a generic OIDC join method for bots and agents.
18.10.7 (19 August 2026) publicly disclosed a batch of High severity fixes that shipped earlier in private release 18.10.1, including an SSO MFA bypass, a Kubernetes Access URL encoding RBAC bypass, and a cross-cluster authentication bypass through x509 subject forgery in trusted clusters.
Teleport now ships private security releases regularly (18.11.3 on 2 October and 18.11.5 in October 2026 were both private) and discloses details in a later public release. Plan for this pattern: you upgrade first, you read the details later.
Licence: source under AGPLv3 (the /api module is Apache 2.0). Official Community Edition binaries, images and AMIs since Teleport 16 (June 2024) are under the Teleport Community Edition License, a modified Apache 2.0 licence limited to organisations with fewer than 100 employees and less than USD 10 million annual revenue. The licence file also has a “critical security exception” that lets any company run specific designated security patch versions for internal use.
The repository has about 21,000 GitHub stars and dates from March 2015.

Boundary

Latest releases are 0.21.3, 0.20.3 and 0.19.5, published 30 April 2026. 0.21.3 fixed CVE-2026-7776, a denial of service during TLS handshakes on workers (HashiCorp bulletin HCSEC-2026-11).
The GitHub repository was archived on 8 October 2026. The README now says Community Edition is no longer under active development, that no new CE releases, maintenance updates, bug fixes or security patches are planned, and that future work goes into HCP Boundary and Boundary Enterprise.
Licence: Business Source License 1.1 for Boundary 0.14.0 and later, with IBM now named as licensor. The additional use grant allows production use as long as you do not offer it to third parties as a competing hosted or embedded product.
Recent features before the archive: RDP targets and RDP credential injection, and boundary connect helpers for MySQL, MongoDB, Cassandra and Redis in 0.20.0 (25 September 2025); Vault LDAP as a credential source, known_hosts verification for SSH targets and idle session closing in 0.21.0.
SSH and RDP target types, session recording and credential injection are documented as HCP Boundary and Boundary Enterprise features. Community Edition has TCP targets with credential brokering.

Warpgate

Latest release is v0.30.2, published 26 October 2026, a day after v0.30.1 and a week after v0.30.0 (19 October 2026).
0.30.0 added Vault and OpenBao secret backends for target passwords and keys, short-lived OpenSSH certificates signed per connection by Vault or OpenBao for target authentication, OIDC back-channel logout and RDP Graphics Pipeline support.
0.29.0 (18 September 2026) added per-session admin approvals (just in time access), a global MFA enforcement policy and Kubernetes tickets, and started logging Kubernetes exec, attach, port-forward and debug containers in the structured audit log.
0.30.1 fixed seven security advisories, including a High severity one where the Kubernetes proxy followed upstream redirects and could fetch internal URLs from Warpgate’s network position.
Licence: Apache 2.0. The repository was created in February 2022 and has about 8,000 GitHub stars. Releases are Linux binaries for x86_64 and arm64, plus a Docker image and a Helm chart.

Around them

step-ca (smallstep/certificates, Apache 2.0) latest is v0.30.2 of 23 March 2026. It can act as an SSH CA for both user and host certificates.
OpenBao (MPL 2.0) latest releases are v2.7.2 and v2.6.5 of 26 October 2026. Its SSH secrets engine can sign SSH certificates, as Vault’s does.
Tailscale (client BSD 3-Clause) latest is v1.104.4 of 28 October 2026. Tailscale SSH lets the tailnet policy decide who can SSH where, without managing keys.
JumpServer (GPLv3) has three supported lines with releases in October 2026: v5.1.1 (20 October), v4.10.20 (23 October) and v3.10.24 (27 October).
Pomerium (Apache 2.0) latest is v0.33.6 of 27 October 2026. It is an identity aware proxy, strongest for HTTP apps, with TCP tunnelling for other protocols.

The first questions to ask

Before you compare products, answer these honestly. They decide more than any feature matrix.

Which protocols do people really use? Count them. If it is only SSH, you may not need a proxy at all. If it is SSH plus PostgreSQL plus RDP plus three admin web UIs, a proxy starts to pay for itself.
Do you need session recording, or only an access log? A log of who connected to what and when is cheap. A replayable recording of every keystroke and every SQL statement is heavier, needs storage and retention rules, and must itself be protected.
Where does identity come from? If you already have Google Workspace, Microsoft Entra ID or Keycloak, the access tool should trust that and not keep its own user list.
Who are you, legally, for licence purposes? Employee count and revenue decide whether Teleport Community Edition binaries are allowed. Whether you will pay a vendor decides whether Boundary is still on the list.
What is the blast radius of the access tool itself? Whatever you put in the middle becomes the most valuable system you run. It holds a CA key or target credentials. Plan its patching, backups and high availability as seriously as your production database.
What happens when it is down at 2 AM? You need a documented break glass path that does not depend on the tool, and you need to test it.

How each one works

Teleport

Teleport has an Auth Service, which is the certificate authority and the policy and audit brain, and a Proxy Service, which is the public entry point. Resources are reached through agents: the SSH Service on each host, the Kubernetes Service, the Database Service, the Application Service and the Windows Desktop Service. Agents dial out to the proxy over a reverse tunnel, so targets in private networks do not need inbound ports.

A user runs tsh login, authenticates (locally with MFA, or with SSO), and gets short-lived SSH and X.509 certificates that carry their roles. After that, tsh ssh, tsh kube login, tsh db connect and the web UI all use those certificates. When the certificate expires, access ends without anyone touching the server. Teleport can also front plain OpenSSH servers in “agentless” mode by making sshd trust Teleport’s user CA.

A minimal role that lets a developer SSH as ubuntu to non-production hosts and read one database looks like this:

kind: role
version: v8
metadata:
  name: dev-readonly
spec:
  options:
    max_session_ttl: 8h
  allow:
    logins: ['ubuntu']
    node_labels:
      env: ['staging', 'dev']
    db_labels:
      env: ['staging']
    db_users: ['readonly']
    db_names: ['orders']

Session recording is on by default for SSH. Recordings and the audit log go to local disk or to object storage, depending on your backend configuration. Teleport can also run “enhanced session recording” with BPF on the node, which records commands, network and file events, not only terminal output.

Boundary

Boundary has controllers, which hold the configuration in PostgreSQL and make decisions, and workers, which proxy the traffic. Users authenticate with a password, OIDC or LDAP auth method, ask for a session to a target, and the controller authorises it. The client, boundary connect, then opens a local port and tunnels through a worker to the target. Sessions have a time limit and a connection count limit set on the target.

Boundary’s distinctive idea is the split between credential brokering and credential injection. With brokering, the controller fetches a credential (for example dynamic PostgreSQL credentials from Vault) and returns it to the user, who then logs in. With injection, the worker uses the credential on the user’s behalf and the user never sees it. Injection for SSH and RDP is an HCP and Enterprise feature.

A target in Terraform with a short session limit looks like this:

resource "boundary_target" "orders_db" {
  name                     = "orders-postgres"
  type                     = "tcp"
  default_port             = 5432
  scope_id                 = boundary_scope.prod.id
  host_source_ids          = [boundary_host_set_static.db.id]
  session_max_seconds      = 3600
  session_connection_limit = 5
  brokered_credential_source_ids = [
    boundary_credential_library_vault.orders_ro.id
  ]
}

The design is clean and the ideas (scopes, host catalogs, targets, credential libraries) are worth learning even if you do not adopt Boundary.

Warpgate

Warpgate is one process. It listens on ports for each protocol you enable, terminates the client’s connection, authenticates the user against its own user database or an OIDC provider, then opens its own connection to the target and relays traffic, recording as it goes. For SSH, the user connects with any normal SSH client and encodes the target in the username, for example ssh -p 2222 'ketaki:orders-db-01@warpgate.santra.example'. Warpgate logs in to the target with its own client key (or, from 0.30, with a short-lived certificate signed by Vault or OpenBao), so users never hold target keys.

For databases, users point psql or mysql at Warpgate and encode the target in the username in a similar way; the documentation shows the exact separator for each protocol. For HTTP targets, Warpgate acts as an authenticating reverse proxy. Kubernetes access goes through a Kubernetes listener and generated kubeconfigs. RDP and VNC work from native clients and from the browser.

Configuration is a YAML file plus a database (SQLite by default, PostgreSQL or MySQL for a cluster). The setup command generates the file:

./warpgate --config /srv/warpgate/warpgate.yaml unattended-setup \
  --data-path /srv/warpgate/data --http-port 8888 --ssh-port 2222 \
  --postgres-port 55432 --record-sessions --external-host warpgate.santra.example

Targets, roles and users are then managed in the admin UI, the API, a Terraform provider or a Kubernetes operator. “Tickets” give a time-limited credential for one target without a full account, which is handy for a vendor engineer.

The simpler option: OpenSSH certificates from a small CA

OpenSSH has supported certificates since version 5.4 in 2010. Instead of copying public keys to every server, you tell each sshd to trust one CA public key, and you sign each user’s key with a short validity and a list of allowed principals.

# on each server, once (sshd_config)
TrustedUserCAKeys /etc/ssh/user_ca.pub

# signing a user key for 8 hours, allowed to log in as ubuntu
ssh-keygen -s user_ca -I ketaki@santra -n ubuntu -V +8h ~/.ssh/id_ed25519.pub

In real use you do not sign by hand. step-ca with an OIDC provisioner, or the SSH secrets engine of OpenBao or Vault, issues the certificate after SSO login. Host certificates fix the other half, the “unknown host key” prompt that everyone clicks through. This removes key sprawl and gives you expiry. It does not give you session recording, database access or a single audit view.

The others in brief

Tailscale SSH puts SSH behind the tailnet. The policy file decides who can SSH to which tagged machines and as which user, and Tailscale handles the keys. It can send recordings to a recorder node. It is attractive if you already use Tailscale; the coordination server is Tailscale’s SaaS, or Headscale if you self-host, with fewer features.
JumpServer is a full privileged access management suite under GPLv3, popular in China and parts of Asia, with asset management, web terminals, recording and approval flows. It has more moving parts than Warpgate. Read its security advisory history carefully before exposing it.
Pomerium is an identity aware proxy. For web admin tools it is excellent: every request is checked against policy with SSO identity. For SSH and databases it tunnels TCP through its client, which gives you identity at the door but not protocol level recording.

Side by side

Protocols covered

Teleport: SSH (its own and OpenSSH), Kubernetes API, many databases (PostgreSQL, MySQL, MongoDB, Redis, SQL Server and cloud databases), HTTP and TCP apps, cloud consoles, Windows desktops over RDP and, from 18.11, Linux X11 desktops. It also now proxies MCP servers for AI agents.
Boundary: generic TCP targets in Community Edition, with boundary connect helpers for SSH, PostgreSQL, MySQL, MongoDB, Cassandra, Redis, RDP, HTTP and kube. SSH and RDP target types with protocol awareness are HCP and Enterprise.
Warpgate: SSH, HTTPS, Kubernetes, MySQL, PostgreSQL, RDP and VNC, all protocol aware.
OpenSSH certificates: SSH only.

Identity and SSO

Teleport Community Edition: local users with MFA (TOTP, WebAuthn, passkeys) and GitHub SSO. OIDC and SAML connectors need Enterprise. For a company on Google Workspace or Entra ID, this is a real limitation.
Boundary: password, OIDC and LDAP auth methods in all editions, with managed groups from OIDC claims mapped to roles.
Warpgate: local users with TOTP, plus OpenID Connect SSO with role mapping from claims. From 0.30 it accepts OIDC back-channel logout, so a sign-out in the identity provider ends Warpgate sessions.
OpenSSH certificates: whatever your CA trusts; step-ca and OpenBao both accept OIDC.

Session recording and audit

Teleport: SSH sessions recorded by default, Kubernetes exec sessions, database queries in the audit log, desktop sessions recorded and, from 18.11, exportable to video. Enhanced recording with BPF captures commands even inside scripts.
Boundary: session recording for SSH and RDP into signed BSR files in S3 compatible storage, HCP and Enterprise only. Community Edition gives you session and connection events but not content.
Warpgate: records SSH terminal sessions, database queries, HTTP requests, Kubernetes activity and RDP sessions, with live view and replay in the admin UI. From 0.29 the structured audit log includes Kubernetes exec, attach and port-forward.
Remember one limit that applies to every proxy: if a user gets a root shell on the target, they can do things the proxy cannot see, such as starting a background process or opening an outbound connection. Recording is evidence, not prevention.

Access requests and just in time access

Teleport: role and resource access requests with reviews, Slack and Jira plugins, and access lists. The richer parts of this workflow are positioned as Enterprise features; check the edition comparison for the exact cut before you plan around it.
Boundary: no built-in request and approval flow; you combine short sessions with role changes from your own tooling.
Warpgate: from 0.29, a target can require an admin to approve each session, with timeout and approval caching. Tickets give time-limited access to one target. 0.30.2 also ends sessions immediately when the role assignment is revoked.

Operations

Teleport: several services and agents on every target or near them, a backend for cluster state (SQLite for a single node, or etcd, DynamoDB, Firestore or PostgreSQL for HA), object storage for recordings, and frequent upgrades with version compatibility rules between Auth, Proxy and agents. There is a managed updates system for agents. It is a serious platform and wants an owner.
Boundary: controllers, workers and a PostgreSQL database, plus usually Vault for credentials. With Community Edition archived, operations now also means owning an unmaintained codebase.
Warpgate: one binary or container, a config file and a database. A Helm chart exists, and 0.30 moved the Docker image to distroless with a Helm chart update to 0.2.0. Clustering with a shared database is supported. It is the lightest of the three by far.
OpenSSH certificates: one CA service and a line in sshd config on each host. The hard part is the CA key, which you must protect like a root password.

Security record

Teleport: a large surface and a mature disclosure process. The most serious recent issue was CVE-2025-49825, a critical remote authentication bypass published in June 2025. In 2026 the project fixed many High severity issues, published in batches, for example in 18.7.6 (encrypted recording authorisation, cross-node recording access) and 18.10.7 (SSO MFA bypass, Kubernetes RBAC bypass, trusted cluster subject forgery). The volume reflects both the size of the product and active review.
Boundary: relatively few published issues; the latest was CVE-2026-7776 (worker TLS handshake DoS), fixed in 0.21.3. After the archive, any new Community Edition issue will not be fixed upstream.
Warpgate: 29 published GitHub advisories at the time of writing, including one Critical (a reflected XSS in the SSO return endpoint, June 2026) and several High ones in 2026, such as an unauthenticated connection that could stall the accept loop (August) and the Kubernetes redirect issue fixed in 0.30.1. Fixes have shipped quickly, and the maintainers describe them clearly in release notes. Being written in safe Rust removes memory safety bugs, not logic bugs.
OpenSSH: a long and well understood record. Using certificates adds a CA you must protect but removes the need for any extra network-facing service.

Licence and governance

Teleport: AGPLv3 source; Community Edition binaries under a size-limited commercial licence since v16; Enterprise is commercial. Building from source yourself puts you under AGPLv3, which is allowed for any size, but you then own the build and the upgrades. Gravitational (Teleport the company) controls the project.
Boundary: BSL 1.1 since 0.14, IBM as licensor after its acquisition of HashiCorp, and Community Edition archived in October 2026. Governance is entirely the vendor’s.
Warpgate: Apache 2.0, led by its original author with outside contributors, funded partly by donations and the FLOSS/fund. Low licence risk, higher “small team” risk.
step-ca Apache 2.0, OpenBao MPL 2.0 under the OpenSSF, JumpServer GPLv3, Pomerium Apache 2.0.

Performance

There is little independent benchmark data for access proxies, and for human access the proxy is rarely the bottleneck. The one concrete published figure we found is the vendor’s own: Teleport’s 18.8.0 release notes say internal changes reduced latency by roughly 100 ms when opening shells or launching commands and about 150 ms for SFTP, measured by Teleport on an m7i.xlarge EC2 instance, with about 23 MiB less memory per shell session in exchange for about 7 MiB more baseline memory. That is Teleport’s own run. In our small Warpgate drill the idle process used about 44 MB of resident memory, which says nothing about load. Where performance does matter is bulk data: database dumps, large file copies and port forwards all pass through the proxy, so size it and place it near the targets.

A worked plan for Nagpur

Here is how Ketaki’s team could move, in order, without a big bang.

Write down every access path in a short document: who uses SSH, to which hosts, which databases, the four RDP servers, the admin web apps, the kubeconfigs, and the vendor contractors. Mark each with “needs recording” or “log is enough”.
Put the bastion behind the mesh VPN they already trialled, and close public port 22. This alone removes the internet-facing attack surface.
Move SSH to certificates. Run step-ca with an OIDC provisioner pointing at their Google Workspace, issue 8 hour user certificates, and add TrustedUserCAKeys plus host certificates through Ansible. Remove authorized_keys entries host by host after two weeks of parallel running.
Choose the proxy. Santra qualifies for Teleport Community Edition today, but it needs Google SSO, which Community Edition does not offer, and the team is growing, so the licence could stop fitting in a year. Warpgate covers PostgreSQL, MySQL, RDP and the admin web apps with OIDC and recording, under Apache 2.0, and two people can run it. They pick Warpgate, and keep Teleport Enterprise as a known option if needs grow.
Deploy Warpgate on two VMs in the Nagpur rack with a PostgreSQL database, behind the VPN only, with listeners bound to the internal interface. Turn on recording, set the MFA policy, and connect OIDC with group to role mapping.
Databases first. Create orders-db and wms-db targets with read-only and admin roles. Admin targets require session approval. Rotate the shared PostgreSQL and MySQL passwords and store the new ones in OpenBao through Warpgate’s secret backend, so no human sees them.
RDP and web apps next. Move the accounting servers and the dispatch admin app behind Warpgate. Close the RDP port forward on the old bastion.
Kubernetes. Either use Warpgate’s Kubernetes listener for the few people who need cluster admin, or issue short-lived kubeconfigs through OIDC directly to the API server. Revoke the two year-long admin client certificates by rotating the cluster CA if needed.
Contractors get Warpgate tickets for the warehouse targets with an expiry, not accounts.
Break glass. Keep one sealed SSH key and one database admin password in an offline safe, owned by two named people, and test it every quarter. Subscribe to Warpgate’s security advisories and agree an upgrade window of a few days for High and Critical fixes.
Evidence for audit. Export Warpgate’s audit log to their log system, set recording retention to match the customer contract, and do a monthly review of who has admin roles.

When each is better

Teleport is better when you have many protocols and many resources, want certificate based access everywhere including Kubernetes and cloud consoles, and either qualify for Community Edition and can live with GitHub SSO, or will pay for Enterprise. It is the most complete product here.
Boundary is better when you are already a HashiCorp customer with Vault Enterprise and want HCP Boundary as a managed service with credential injection and recording. Its identity based session model is elegant.
Warpgate is better when you want a self-hosted, Apache licensed bastion that users reach with their normal clients, with recording and OIDC, and you have a small team that will not run a platform.
OpenSSH certificates are better when your access problem is mainly SSH key sprawl and you do not need recording.
Tailscale SSH is better when you already run a tailnet and want SSH access to follow the same policy.
Pomerium is better for web admin tools where per-request identity and policy matter more than recording.

When not to adopt each

Do not adopt Teleport Community Edition if your organisation has 100 or more employees or USD 10 million or more revenue, unless you build from AGPL source and accept that, or you buy Enterprise. Do not adopt it either if you need OIDC or SAML SSO and will not pay.
Do not adopt Boundary Community Edition in late 2026 for anything new. It has no planned fixes. If you already run it, plan a move to HCP or Enterprise, or to another tool, within your next budget cycle.
Do not adopt Warpgate if you cannot commit to upgrading within days of a security release, or if your auditors require a vendor support contract that it does not offer.
Do not adopt any proxy if the only real problem is SSH keys. Certificates are smaller and safer.
Do not adopt Tailscale SSH as your only control if the coordination server is not under your control and your compliance rules say it must be.

A short history

2010: OpenSSH 5.4 adds certificate support, the quiet foundation for most of what follows.
2015: Gravitational open sources Teleport, focused on SSH with certificates and recording; the repository dates from March 2015.
2020: HashiCorp announces Boundary in October; the repository dates from January 2020.
2022: Warpgate’s repository is created in February by the author of the Tabby terminal.
2023: HashiCorp moves its products, including Boundary from 0.14, to the Business Source License in August.
2024: Teleport 16 (June) moves Community Edition binaries to the size-limited commercial licence.
2025: IBM completes its acquisition of HashiCorp in February. Teleport publishes the critical CVE-2025-49825 in June.
2026: Warpgate adds session approvals (0.29) and Vault and OpenBao integration (0.30); Teleport reaches 18.11; HashiCorp archives Boundary Community Edition on 8 October.

Decision guide

You only need SSH, and the team is small

Use OpenSSH certificates from step-ca or OpenBao with SSO, plus a mesh VPN. Add a proxy later only if recording becomes a requirement.

You need recorded access to databases, RDP and web apps, and you self-host

Warpgate is the lightest choice. Teleport Community Edition is the richer one if you qualify for the licence and GitHub SSO is acceptable.

You are a large company with many teams and compliance needs

Evaluate Teleport Enterprise and HCP Boundary or Boundary Enterprise side by side with a paid pilot. Compare SSO, access request workflows, recording storage and support terms.

You already run Boundary Community Edition

Do not panic, but plan. Pin the last version (0.21.3), keep it off the internet, and decide within months whether to pay for HCP or Enterprise or move to another tool.

You live in Tailscale already

Try Tailscale SSH with session recording for servers, and Pomerium or Warpgate for web and database access.

Checklist

Every access path listed with owner and protocol.
No SSH port open to the internet.
SSH user certificates with hours of validity, and host certificates.
No shared human passwords for production databases; rotated after migration.
SSO with group based roles, and MFA enforced.
Session recording on for admin access, with retention and access rules for the recordings themselves.
Audit log shipped off the access server.
Just in time approval for the most sensitive targets.
Contractor access time-limited.
Break glass path documented, owned by two people and tested quarterly.
Licence checked against company size and plans for the next two years.
Security advisory subscription and an agreed upgrade window.

Common mistakes

Adding a proxy but keeping the old keys. If authorized_keys still works, people will use it. Remove the old path.
Binding everything to all interfaces. In our drill, Warpgate’s generated config listened on [::] for every protocol, including those not enabled. Bind to internal addresses and put the proxy behind the VPN.
Treating recordings as harmless. Recordings contain secrets that people typed and data they queried. Restrict who can watch them.
Forgetting the licence when the company grows. Teleport Community Edition is fine at 60 people and not at 120.
Long certificate lifetimes “for convenience”. A 30 day SSH certificate is just a key with a calendar. Keep it to a working day.
No break glass test. The access tool will be down one day, maybe during the incident you most need it for.
Ignoring the tool’s own patching. The access proxy is the most attractive target you run. Patch it first, not last.

The drill we ran

We ran a small, loopback-only drill with Warpgate v0.30.2 on 31 October 2026, using the single Linux binary from the GitHub release, inside a scratch directory. Nothing was installed system-wide.

unattended-setup failed with a relative data path and worked with an absolute, existing directory. It generated the config, a self-signed TLS certificate and a SQLite database in about 1.6 seconds.
The generated config bound every listener to [::], all interfaces. We changed them to 127.0.0.1 before starting.
The running process listened on 127.0.0.1 for SSH, HTTPS and PostgreSQL. Idle resident memory right after start was about 44 MB. The admin web endpoint answered HTTP 200.
A login with a wrong password returned 401 and produced an audit line plus a login protection record counting the failed attempt by IP and by user. The correct password returned 201 and an audit line.
We did not proxy a real SSH or database session, because the box had no SSH client or server and we did not install system packages. So we did not test session recording. Treat the recording claims in this post as coming from the project documentation, not from our hands.

If you repeat this, add a local sshd on a high port as a target and record one session, then check the replay in the admin UI.

Unlearn, re-learn

Unlearn “access means a key on the server”. Re-learn that access can be a short-lived certificate or a brokered session that expires by itself.
Unlearn “the bastion log is our audit trail”. Re-learn that an audit trail names the person, the target, the role and, where needed, the content.
Unlearn “open source means free for us forever”. Re-learn to read the licence of the binary you actually download, and to watch the vendor’s direction, as the Boundary archive shows.
Unlearn “the bigger platform is safer”. Re-learn that every option here had serious advisories in 2026, and the real control is how fast you patch.
Practise a quarterly access review and a break glass test, and apply the smallest tool that closes your actual gap.

Sources

Releted Posts

Container registries in 2026: revisit Harbor, Zot and CNCF Distribution before you push another image

Manoj Shukla
October 14, 2026

Picture a product engineering team in Bengaluru that runs about forty microservices on Kubernetes for a B2B payments product used by NBFCs across Karnataka and Maharashtra (an invented example, not a real client).

Manoj Shukla
October 31, 2026

On a cloud cluster, you write type: LoadBalancer in a Service and a minute later an IP address appears. On your own servers, the same line gives you a Service that sits in <pending> forever.

Manoj Shukla
October 31, 2026

Most teams do not decide to build a distributed coordination system. It creeps in. A scheduled job runs on one VM.

Infrastructure access in 2026: revisit Teleport, Boundary and Warpgate before you hand out another SSH key

A scenario to keep us honest

The short version

Where things stand on 31 October 2026

Teleport

Boundary

Warpgate

Around them

The first questions to ask

How each one works

Teleport

Boundary

Warpgate

The simpler option: OpenSSH certificates from a small CA

The others in brief

Side by side

Protocols covered

Identity and SSO

Session recording and audit

Access requests and just in time access

Operations

Security record

Licence and governance

Performance

A worked plan for Nagpur

When each is better

When not to adopt each

A short history

Decision guide

You only need SSH, and the team is small

You need recorded access to databases, RDP and web apps, and you self-host

You are a large company with many teams and compliance needs

You already run Boundary Community Edition

You live in Tailscale already

Checklist

Common mistakes

The drill we ran

Unlearn, re-learn

Sources

Teleport

Boundary

Warpgate

Around them

Related posts on Revisit.Tech

Releted Posts