← Back to Blog

Teleport's Top Offering Is Certificates That Expire By Default In 12 Hours. Here's What That Actually Buys You.

Teleport's Top Offering Is Certificates That Expire By Default In 12 Hours. Here's What That Actually Buys You.

There's a banner across the top of every page on goteleport.com right now: "Teleport Named an Overall Leader in Zero Trust Platforms by KuppingerCole Analysts."

Most vendors put that report behind a form. You give them your work email, your company size, and your job title, and in return you get a PDF that says the vendor is great. Teleport doesn't do that. The "Download Report" button links straight to a 3 MB file with no form in front of it. So I downloaded it. All 109 pages, published July 13, 2026, written by Alexei Balaganski, KuppingerCole's lead analyst and CTO.

Credit where it's earned: publishing the whole thing ungated is rare, and it's the opposite of what a company does when the report is thin. But I read it anyway, because a banner is a banner. I went in expecting to catch marketing doing what marketing does. Mostly I couldn't. The claims check out, with one exception I'll get to, and the product underneath them is built on one sharp idea worth stealing even if you never buy it.

Teleport is a commercially available product and I have no relationship with them. I'm writing this as an endpoint security admin who has spent years watching credentials pile up in places nobody remembers putting them.

The top offering, in one sentence

Teleport calls its flagship the Teleport Infrastructure Identity Platform. Underneath that name sit five products: Zero Trust Access, Machine and Workload Identity, Identity Governance, Identity Security, and the newer Agentic Identity Framework.

Ignore the org chart. There's one idea holding all of it up, and KuppingerCole states it more plainly than Teleport's own homepage does:

"Rather than vaulting, rotating, or brokering static credentials, Teleport acts as a certificate authority that issues short-lived X.509 and SSH certificates to all identities, including human users, services, CI/CD pipelines, IoT devices, workloads, and AI agents, at the moment access is requested."

That's the whole company in a sentence. A password vault's job is to store your secrets safely. Teleport's argument is that you shouldn't have secrets to store in the first place.

The difference matters more than it sounds. A vault is a box with valuables in it, and a box with valuables in it is a target. Every vault deployment eventually grows a bootstrap problem: something has to authenticate to the vault, so now you have one credential that opens the box holding all the others. Teleport's answer is to make the credential worthless by making it expire before anyone can do much with it.

How short is short

Here's the part the marketing pages never print, so I pulled it from the source.

Teleport's certificate durations are constants in api/defaults/defaults.go:

// MinCertDuration specifies minimum duration of validity of issued certificate
MinCertDuration = time.Minute

// MaxCertDuration limits maximum duration of validity of issued certificate
MaxCertDuration = 30 * time.Hour

// CertDuration is a default certificate duration.
CertDuration = 12 * time.Hour

Twelve hours by default. Thirty hours is the ceiling, no matter what you put in a role. One minute is the floor if you want to get aggressive.

The 12 hours is a workday, and that's not an accident. You log in with coffee, your cert dies around the time you stop caring about work. The 30 hour ceiling is the interesting one: it's not in the documentation anywhere I could find, only in the code, and it's the number that quietly caps how lazy your longest-lived human session can get.

Teleport's own docs print the result like this:

tsh login --proxy=teleport.example.com --user=alice

> Profile URL:        https://teleport.example.com:443
  Logged in as:       alice
  Cluster:            teleport.example.com
  Roles:              devs*
  Logins:             admin
  Kubernetes:         enabled
  Kubernetes groups:  edit
  Valid until:        2021-03-26 07:13:57 -0700 PDT [valid for 12h0m0s]
  Extensions:         permit-port-forwarding, permit-pty

valid for 12h0m0s. That line is the product. Your roles, your Unix logins, your Kubernetes groups, and an expiry are all baked into a certificate sitting in ~/.tsh. Then you just use normal tools:

tsh ssh admin@db-01

No key in ~/.ssh that outlives your employment. No shared deploy_rsa that four people have and nobody rotated after the last one quit.

Now here's the sharp edge, straight from Teleport's own FAQ on the engineering page: the certificates "auto-expire without revocation."

There is no revocation list. No CRL to publish, no OCSP responder to run, no distributed cache of "actually, never mind" to keep consistent. That's an enormous operational simplification, and it's elegant. It also means a stolen certificate works until it expires, unless you lock the identity. Teleport's answer to revocation isn't a CRL, it's a deny-list checked at connect time. Same goal, different shape, and the operational difference is most of the point.

Teleport's answers here are where the money lives. Locks kill an identity across every protocol at once, but locks are part of Identity Governance, which is Enterprise only. Device Trust binds a cert to a registered machine, also Enterprise only. Per-session MFA makes a stolen cert useless without a touch on a hardware key, and that one is free. And there's a clever one the analyst singled out: Teleport counts certificate renewals and flags mismatches, so a cloned renewable identity gets caught when two copies both try to renew. KuppingerCole listed it as a strength, describing it as detecting "mismatches between expected and observed certificate usage counts."

So the pitch isn't "nothing can be stolen." It's "the stolen thing has a short shelf life, and here are four paid features that shorten it further."

A role is just YAML

The authorization model is RBAC with attribute extensions, and roles are plain YAML. Current schema is version: v8 as of Teleport 18. The bit that matters:

kind: role
version: v8
metadata:
  name: example
spec:
  options:
    # max_session_ttl defines the TTL of certificates issued to users with this role
    max_session_ttl: 8h
    forward_agent: true

max_session_ttl is the dial. Set it to 8h and this role's people get eight hour certs instead of twelve. If a user holds several roles, Teleport takes the shortest TTL, not the longest. That default is the correct one and I wish more products picked it.

Role templates are where it gets useful. Teleport can interpolate traits that came from your identity provider:

kind: role
version: v7
metadata:
  name: devs
spec:
  allow:
    logins: [ '{{internal.logins}}' ]
    kubernetes_groups: [ '{{internal.kubernetes_groups}}' ]
    node_labels:
      '*': '*'

tctl create -f role.yaml

The point of {{internal.logins}} is that you stop maintaining a mapping. Someone's group membership changes in Okta, their next certificate reflects it, because the cert is minted fresh at login and the trait is read at mint time. There's no sync job to fall behind.

Just in time access, and where the paywall lands

This is the flow everyone demos:

tsh request create --roles=dba --reason="PagerDuty INC-4471, replica lag on db-03"

The requester waits. An approver runs:

tsh request review --approve --reason="on call, confirmed the page" <request-id>

The requester's certificate is reissued with the dba role attached and an expiry on the elevation. Not a permanent group membership someone forgets to remove. A cert that forgets on its own. You can bound it explicitly:

tsh request create --roles=dba --max-duration=4h --reason="INC-4471"

The ceiling on max_duration is 14 days, per the roles reference.

Now the part the demo skips. Access Requests are Enterprise. Teleport's own docs page for the feature opens with a banner reading "Identity Governance is available only with Teleport Enterprise." Community Edition, per the feature matrix, "only can request roles through CLI." You get a stripped version: no automatic approvals, no Access Lists, no dual authorization, and no locks, which means no way to kill a live identity mid-session.

Approval routing is genuinely murky, and I'll flag it rather than pretend. The feature matrix lists "Access Request Integration: Slack, Teams, Discord, Mattermost, PagerDuty, Opsgenie, Email" as available in all three editions including Community, while the Access Requests docs recommend approval plugins only "for Teleport Enterprise" and mark Access Reviews through Slack and PagerDuty as Enterprise. Teleport's own two pages disagree. If that routing is why you're buying, get it in writing.

The free tier is more generous than most people assume. Session recording with playback, enhanced session recording, RBAC, per-session MFA, structured audit logs, SIEM export, and most of Machine and Workload Identity are all in Community Edition. That is not a crippled demo.

But there's an SSO tax, and it's a steep one. Community Edition's single sign-on is GitHub only. No SAML, no OIDC, no Okta, no Entra ID. If your company authenticates with anything other than GitHub, the free tier's identity story ends at the door, and the thing you came for (certs that carry your IdP's groups) is exactly what you can't have.

Your CI has an immortal key in it

The strongest under-marketed piece is Machine ID, and it's mostly free.

Think about what lives in your CI secrets right now. Probably an SSH key, or a cloud access key, that was generated once, pasted into a settings page, and has been sitting there ever since with nobody's name on it. It doesn't expire. It doesn't rotate. Nobody knows which of the forty workflows still needs it.

Teleport's tbot replaces it with a certificate the pipeline earns at runtime by proving what it is. On GitHub Actions the proof is GitHub's own OIDC token:

jobs:
  demo:
    permissions:
      # required or tbot cannot authenticate with the cluster
      id-token: write
      contents: read
    runs-on: ubuntu-latest
    steps:
      - name: Fetch Teleport binaries
        uses: teleport-actions/setup@v1
        with:
          version: auto
          proxy: example.teleport.sh:443
      - name: Fetch credentials using Machine & Workload Identity
        id: auth
        uses: teleport-actions/auth@v2
        with:
          proxy: example.teleport.sh:443
          token: example-bot
          certificate-ttl: 1h
      - name: Run hostname via SSH
        run: tsh ssh root@example-node hostname

There is no secret in that file. id-token: write lets the runner ask GitHub for a signed statement about which repo and which workflow is running, Teleport checks that statement against a join token, and issues a certificate good for one hour. Steal the YAML, get nothing. Fork the repo, get nothing, because the OIDC claim won't match. The same trick runs one layer down for workload to workload traffic, where Teleport issues SPIFFE compliant X.509 certs for mutual TLS.

What the report actually says

Now the report itself. Page numbers below are the report's own printed folios, which run one lower than the sheet number your PDF viewer shows.

Teleport is one of nine Overall Leaders. Page 10, verbatim: "The Overall Leaders in the Leadership Compass on Zero Trust Platforms are Microsoft, Teleport, Cisco, Broadcom, Netskope, NetFoundry, Appgate, Zero Networks, and Illumio." Twenty vendors were rated. Nine made Overall Leader. "An Overall Leader" is accurate, and it's a real result, and it's also a category with nine members rather than a podium with one.

Teleport is not a Market Leader. It took Overall, Product, and Innovation Leader: three of the four designations. Page 15: "The Market Leaders are Microsoft, Cisco, Broadcom, Fortra, Sophos, and Ivanti." Teleport isn't there, and the report explains why in its own challenges list: "Customer install base concentrated in North America; limited EMEA and APAC market presence." Market Leadership measures reach, not quality. The report is explicit that "a vendor may be highly innovative or technically strong while still remaining a challenger in market leadership."

The "#2" claim checks out. Teleport's press release says it took "the #2 spot for Product, and Innovation Leadership." That exact phrase appears nowhere in the report, and KuppingerCole never prints a rank number beside a vendor name, so I assumed for about an hour that someone in marketing had invented it. They hadn't. The Product and Innovation charts are scored horizontal axes, and on both of them Microsoft's dot sits furthest right with Teleport's immediately next to it. The prose matches: "Microsoft is recognized for its work on security and governance controls for agentic AI across its entire portfolio. Teleport demonstrates innovation through its certificate-centric architecture..." Second of twenty, twice. The claim is fair, and I was wrong to doubt it. This is the part where reading the primary document cut against my own hunch, which is exactly why you read it.

One thing is trimmed, and it's the thing you'd want. Teleport's landing page and press release both quote Balaganski like this:

"Teleport demonstrates overall leadership through its strong infrastructure identity architecture, short-lived certificate model, mature access workflows, and depth of coverage. Its focus on secretless access and machine identity governance aligns closely with the direction of the Zero Trust Platforms market."

The sentence doesn't end there. In the report it runs on across pages 11 and 12:

"...aligns closely with the direction of the Zero Trust Platforms market, even though it complements rather than replaces broader SSE or SASE platforms."

Every vendor on earth trims an analyst quote to its endorsement half, so this isn't a scandal. It's just that the dropped clause happens to answer the first question a buyer asks: does this replace my VPN and my secure web gateway? No. The report makes the same point again in Teleport's challenges list, and Teleport published the whole report ungated, so nothing here is actually hidden. It just isn't in the pull quote.

Both lists from page 82, at equal length. The strengths:

  • Secretless architecture issues short-lived certificates to all identities at access-request time
  • Identifies stolen renewable certificates by detecting mismatches between expected and observed certificate usage counts
  • Database RBAC enforces access at the database, table, and operation level, with SQL activity captured in structured audit logs
  • Purpose-built AI agent governance for infrastructure access, including identity-aware session recording, approval workflows, and audit trails for agent actions
  • Secure authentication and governance for AI agent-to-tool invocations
  • AI-powered Session Summaries identify privilege escalations and other security-relevant behaviors

And the challenges, which no Teleport marketing I found mentions:

  • The platform is infrastructure-access-oriented, designed to complement rather than replace ZTNA/SSE platforms
  • No DLP or content inspection capabilities
  • Session risk signals raise alerts but don't currently trigger automated session revocation, which the report notes is planned
  • Customer install base concentrated in North America, limited EMEA and APAC market presence

That's a good report card. Six real strengths, four honest limits, none of them fatal.

One thing that isn't about Teleport at all: every "news" article about this rating that I found (Manila Times, SourceSecurity, SecurityInformed, ITNewsOnline) is the same GlobeNewswire press release reprinted. That's one source wearing four hats, not four sources agreeing. That's the wire business, not Teleport's doing, but it's worth knowing when a rating looks independently corroborated and isn't.

The 9.8

If your whole product is "there are no secrets to steal, only certificates we verify," then the code that verifies certificates is the entire trust anchor. In June 2025, that code had a remote authentication bypass rated CVSS 9.8.

CVE-2025-49825. Network attack vector, low complexity, no privileges, no user interaction, full compromise of confidentiality, integrity, and availability. Patched in 17.5.2, 16.5.12, 15.5.3, 14.4.1, 13.4.27, and 12.4.35.

Two bits of context belong right next to that number, one in each direction. The 9.8 is the CNA's score, assigned by GitHub through the coordinated disclosure, not an independent NVD assessment: NVD lists its own base score as "not yet provided" and flags the record as not prioritized for enrichment. And CISA's SSVC entry on that same record lists exploitation as "none," meaning it was never observed being used in the wild. Cutting the other way, that same CISA entry marks it automatable "yes" with technical impact "total." So: never seen exploited, but if someone had figured it out, it would have scaled.

The bug is a beautiful lesson. Here's the vulnerable function from tag v17.5.1, in lib/srv/authhandlers.go:

for _, checker := range checkers {
    // if we have a certificate, compare the certificate signing key against
    // the ca key. otherwise check the public key that was passed in. this is
    // due to the differences in how this function is called by the user and
    // host checkers.
    switch v := key.(type) {
    case *ssh.Certificate:
        if apisshutils.KeysEqual(v.SignatureKey, checker) {
            ca = cas[i]
            break
        }
    default:
        if apisshutils.KeysEqual(key, checker) {
            ca = cas[i]
            break
        }
    }
}

This function answers "was this signed by a CA I trust?" It's supposed to receive a raw public key. But SSH lets a certificate be encoded where a public key goes, so an attacker could hand it a certificate instead. The code then helpfully unwraps it and compares the inner certificate's SignatureKey field against the trusted CA. That field is attacker controlled. You can just write the real Teleport CA's public key into it.

And the real CA's public key isn't a secret. Teleport serves it from /webapi/auth/export, an endpoint their own source code comments describe as "a public/unauthorized endpoint," because public keys are supposed to be public. That's not the bug. Publishing a CA's public key is normal and correct.

So: fetch the CA public key, build a nested certificate that merely claims that CA in a metadata field, sign the outer thing with a key you own, and Teleport agrees the certificate came from an authority it trusts. Not a crypto break. A type confusion. The code asked a question and accepted the attacker's word for the answer.

The fix removed the unwrapping entirely. Current master:

for _, checker := range checkers {
    if apisshutils.KeysEqual(authority, checker) {
        ca = cas[i]
        break
    }
}

No type switch. The parameter got renamed from key to authority, which tells you someone understood exactly what went wrong. Compare what you were given against what you trust. Don't unwrap it first.

Two footnotes on this, one in Teleport's favor and one not. In their favor: Teleport Cloud wasn't affected, and they shipped patches back to version 12, which is more back-porting than most vendors bother with. Not in their favor: NVD's record for this CVE still says "At time of posting, there is no available open-source patch," which was true during the embargo and is badly stale now. If you scan NVD and panic, that's why.

None of this makes the certificate model wrong. It makes it a model, implemented by people. The 2019 Doyensec audit found that a holder of valid node credentials could abuse the session recording facility to read and write arbitrary files. Teleport has also had an earlier 9.8, CVE-2021-41393, for SSH host certificate forgery. The architecture removes whole categories of risk. It does not remove the code.

The bill

Teleport does not publish prices. The pricing page renders a headline reading "Transparent Pricing. Pay only for what you use: active users and protected resources," and then a form. I appreciate the irony more than I appreciate the page.

The licensing is where small shops need to pay attention, because it surprises people:

  • The source is AGPLv3. Client libraries and docs are Apache 2.0.
  • The prebuilt Community Edition binaries, from version 16 forward, carry a license restriction that has nothing to do with AGPL. Teleport's own words: "Companies may use Teleport Community Edition on the condition they have less than 100 employees and less than $10MM in annual revenue (AR)." Also: no reselling, no embedding.

So "free and open source" needs an asterisk. The code is AGPL and you can build it. The binaries most people actually download come with an employee count and a revenue cap attached. If you're a 40 person shop doing $6M, you're fine. Cross either line and the free tier isn't yours anymore, and the thing you'd be buying starts with the SSO you already needed.

When this is the wrong tool

The report scopes this plainly: "Teleport is best suited to engineering-forward organizations with complex, distributed infrastructure across clouds, on-premises environments, Kubernetes, databases, and AI workloads." If that isn't you, here is the field, with real numbers:

Option Cost What you give up
Plain OpenSSH CA (ssh-keygen -s) $0, already installed Everything else. No UI, no audit, no Kubernetes or database access. You build it.
AWS SSM Session Manager $0 on EC2 AWS only. And logging does not work for port forwarding or SSH sessions, which surprises people. Hybrid nodes start costing $0.05 per session on September 30, 2026.
Tailscale Free to 6 users, then $8 or $18 per user per month Different model. WireGuard identity, not SSH certs. Session recording needs a recorder node you host, and it fails open by default unless you configure otherwise.
Cloudflare Access for Infrastructure Free to 50 users Your sshd has to trust Cloudflare's CA, and you run cloudflared on every target.
HashiCorp Vault SSH CA Free (self-hosted) You now operate Vault, and Vault has the bootstrap problem Teleport is trying to delete.
StrongDM ~$70 per user per month, published on their blog and not their pricing page Money.
Teleport Unpublished See above.

If you have twelve servers, one cloud, and four engineers, a plain OpenSSH CA and a Saturday afternoon gets you most of the security benefit of this entire post. Certificates that expire are not a Teleport invention. ssh-keygen -s has signed certificates for years, with TTLs and principals built in. What Teleport sells is not the certificate. It's the part where you don't have to build the machinery around it for SSH and Kubernetes and Postgres and RDP and CI and now MCP servers, all with one audit trail.

That's worth real money. Just buy it for that reason, and not because of a banner.

Steal the idea, skip the invoice

You probably aren't buying Teleport this week. Take the idea anyway, because the idea is free:

  1. Find your longest-lived credential. It's in a CI settings page. It's an SSH key or a cloud access key with no owner and no expiry. That single credential is worth more to an attacker than your firewall is worth to you.
  2. Give it an expiry. OIDC federation from GitHub Actions to AWS or GCP is free and removes the static key entirely. Same trick Teleport charges for, without Teleport.
  3. Make the short thing the default, not the exception. Twelve hours as a default is the whole design. Not "we rotate quarterly."

Rotation is a chore you'll skip. Expiry is a physics problem the attacker has to solve.

Fact-check notes and sources

Everything above was read from the primary source. Where a number exists only in code and not in documentation, I said so.

Related reading

This post is informational, not legal or security-consulting advice. Teleport, KuppingerCole, Tailscale, StrongDM, Cloudflare, HashiCorp, Okta, and AWS are named under nominative fair use. No affiliation, sponsorship, or endorsement is implied in either direction. Product facts, prices, and version numbers were verified against primary sources on July 15, 2026, and this category moves quickly. Verify before you buy.

← Back to Blog

Accessibility Options

Text Size
High Contrast
Reduce Motion
Reading Guide
Link Highlighting
Accessibility Statement

J.A. Watte is committed to ensuring digital accessibility for people with disabilities. This site conforms to WCAG 2.1 and 2.2 Level AA guidelines.

Measures Taken

  • Semantic HTML with proper heading hierarchy
  • ARIA labels and roles for interactive components
  • Color contrast ratios meeting WCAG AA (4.5:1)
  • Full keyboard navigation support
  • Skip navigation link
  • Visible focus indicators (3:1 contrast)
  • 44px minimum touch/click targets
  • Dark/light theme with system preference detection
  • Responsive design for all devices
  • Reduced motion support (CSS + toggle)
  • Text size customization (14px–20px)
  • Print stylesheet

Feedback

Contact: jwatte.com/contact

Full Accessibility Statement • Privacy Policy

Last updated: April 2026