Teleport Security: Protecting CAs, Roles, Recordings and Bots

Teleport replaces standing SSH keys and passwords with short-lived certificates, which moves the crown jewels from thousands of servers into a handful of certificate authorities, roles and join tokens. Whoever controls the cluster's CAs, the right to edit roles, or a long-lived join token controls access to every enrolled server, Kubernetes cluster, database and desktop. This guide covers how to harden a Teleport cluster as documented by Teleport: protecting and rotating the CAs, designing roles and Access Requests so no single account can escalate, requiring MFA for sessions and administrative actions, recording and exporting sessions, and running Machine and Workload Identity bots safely. It is written for platform, infrastructure and identity engineers who run Teleport, self-hosted or Teleport Enterprise Cloud. For the general discipline, see the Privileged Access Management Guide.

This is an independent guide from NHI Mgmt Group, based on Teleport's public documentation as of November 2026. It is not sponsored or reviewed by Teleport. Product features change, so confirm settings against Teleport's current documentation.

Key takeaways

• The CAs are the cluster. In Teleport, access is revoked with locks or by rotating a CA rather than with traditional certificate revocation, so plan and rehearse CA rotation before you need it.
• Role editing is the real admin right. Anyone who can create or update role resources, or change resource labels that roles match, can grant themselves access, so design RBAC without an all-powerful standing admin.
• MFA belongs on sessions and admin actions, not just login. Per-session MFA (require_session_mfa) and MFA for administrative actions limit what a stolen on-disk certificate can do.
• Access Requests need thresholds and deny rules. Two approvers, a max_duration and a deny.request.roles list stop a phished user from talking a reviewer into an admin role.
• Bots should join with delegated, non-renewable methods. Teleport strongly discourages static tokens; cloud, CI and Kubernetes join methods prove the workload's identity each time instead of relying on a secret.

How identity and access work in Teleport

A Teleport cluster has an Auth Service, which holds the certificate authorities and issues certificates, a Proxy Service, which is the public entry point, and agents that protect resources such as SSH servers, Kubernetes clusters, databases, applications and Windows desktops. Users authenticate with local credentials or through an OIDC, SAML or GitHub connector, and receive short-lived X.509 and SSH certificates that encode their roles and traits. Every component authenticates to the others with certificates as well, which is why Teleport maintains several independent CAs.

The attacker techniques this design is meant to defeat are ATT&CK T1552.004 Private Keys (stealing SSH keys from disk) and T1021.004 SSH lateral movement. The techniques that remain relevant against Teleport itself are T1078 Valid Accounts (a compromised identity provider account), T1550 Use Alternate Authentication Material (a stolen certificate used before expiry) and T1098 Account Manipulation (editing roles or users). For SSH certificate fundamentals, see the SSH Protocol and Certificate Authority Guide.

Protecting the CA keys

• Self-hosted Enterprise: Teleport Enterprise supports keeping CA private keys in a hardware security module or a cloud key management service, and FIPS builds. Teleport documents that Teleport Cloud and Teleport Community Edition do not currently support HSMs or KMS, so on Community Edition the keys live in the cluster state backend and the backend becomes tier-zero.
• Backend and host access: Teleport's guidance on privileged accounts warns that a user with elevated access to the Auth Service host, the Teleport configuration file or the storage backend can bypass role-based controls. Restrict root on Auth Service hosts, encrypt and restrict the backend, and keep it off networks that ordinary engineers reach.
• Rotation: each CA rotates independently through the phases standby, init, update_clients, update_servers and back to standby, with a rollback phase available before the final step. Rotation can be manual (an admin advances each phase) or semi-automatic with a grace period. From version 17.0.5, tctl auth rotate with no arguments opens an interactive rotation interface that checks readiness between phases.

Admin roles and privileged access

Teleport has no fixed "administrator" switch: power comes from roles. A role can allow logins, resource access through label selectors, Access Request rights and rules that grant verbs such as create and update on cluster resources like role, user, token, cert_authority and cluster_auth_preference. The preset roles are a starting point, not a target state.

Teleport's guide to reducing blast radius describes the controls that turn this into least privilege:

1. Remove standing admin: design RBAC so there is no all-powerful administrator, and give privileged roles a short max_session_ttl (the documented example uses 4h).
2. Require dual authorisation: a requestable role carries thresholds such as approve: 2, deny: 1, so one compromised reviewer cannot approve escalation alone.
3. Deny requests for the most sensitive roles: spec.deny.request.roles stops users even asking for, say, editor. Deny rules take precedence over allow rules.
4. Restrict requests by trait: request rights can depend on identity provider traits, so only members of a given team can request that team's elevated role.
5. Cap request duration: request.max_duration limits how long an approved request lasts; Teleport documents that it can never exceed fourteen days.

Labels are part of the security boundary

Roles grant access by matching labels on resources. Teleport warns that anyone who can add or change labels, including dynamic labels generated by commands on the host, can cause privilege elevation when other users' roles are evaluated. Restrict who can edit agent configuration files, review the commands behind dynamic labels and avoid wildcard label matches in privileged roles. For the wider pattern, see the JIT Access Guide.

MFA for logins, sessions and admin actions

• Phishing-resistant second factor: set second_factors: ["webauthn"] in cluster_auth_preference with the correct rp_id, and optionally restrict authenticator models with attestation_allowed_cas. Teleport's identity provider compromise guide recommends cluster-wide WebAuthn so an attacker who owns the identity provider still does not hold the user's hardware factor.
• Per-session MFA: require_session_mfa: yes makes every connection to a resource require a fresh MFA check, which limits a stolen login certificate. SSO users must register an MFA device in Teleport to use it.
• MFA for administrative actions: resetting users, inviting users, editing configuration and access resources, approving Access Requests, creating join tokens, impersonation and creating bots then need an MFA check. Teleport enforces this automatically when WebAuthn and/or SSO MFA are the only second factors, not when OTP is also enabled, so removing OTP is what switches it on.
• Device Trust (Enterprise): resources with device mode "required" accept only enrolled, trusted devices, and audit events carry the device information.

See the Phishing-Resistant MFA Guide and the Identity Provider Tenant Compromise Playbook.

Integrations, API tokens and service accounts

Machine and Workload Identity runs the tbot agent, which authenticates to the cluster as a bot user and writes short-lived credentials for SSH, Kubernetes, databases, applications and tctl. Bots authenticate with join tokens that name the bot and the proof required (the join method), and every tbot connection creates a server-side Bot Instance so individual installations can be tracked and locked. Teleport's MFA for admin actions guide recommends bots rather than certificates made with tctl auth sign for automation, because those certificates stop working for admin actions once MFA is enforced.

• Scope bot roles: each bot gets only the roles its job needs, matched by labels; the terraform-provider preset should belong to one bot used by one pipeline.
• Keep credential lifetimes short: tbot outputs take a credential_ttl and renewal_interval; Teleport's examples use values such as 1h or 30m with a 15m renewal.
• Constrain delegated tokens: pin cloud joins to an account, role or service account, and CI joins to a repository and branch or environment, so another project on the same platform cannot join as your bot.
• Access Request plugins: Slack, Jira, PagerDuty, ServiceNow and similar plugins hold Teleport credentials and approval context; run them under the access-plugin preset or a narrower role, ideally through a bot.

See the CI/CD Pipeline Identity Security Guide for pipeline trust design.

Logging and detection

Teleport writes a structured audit log of logins, certificate issuance, session starts and resource changes, and records interactive sessions. The cluster-wide session_recording setting (or the session_recording_config resource) chooses one of four modes: node and proxy record asynchronously, node-sync and proxy-sync record synchronously, on the agent or the Proxy Service respectively. Windows, database and Kubernetes sessions are always recorded on the host running that Teleport service. At-rest encryption of recordings is supported in all four modes. Teleport Enterprise Cloud offers External Audit Storage, which writes audit events to Athena and recordings to S3 in your own AWS account; self-hosted clusters forward events with the Event Handler to SIEM platforms.

Metrics that show the controls work:

• Number of users holding editor or any role with write rules on role outside an Access Request (target: zero people, one or two bots).
• Share of joins using delegated methods, and count of static tokens (target: zero static tokens).
• Median age since last rotation for the user and host CAs, and date of the last rehearsed rotation.
• Percentage of privileged Access Requests with two approvals and a duration under the policy cap.
• Audit event delivery lag into the SIEM and any gaps in recording uploads.

See the CIS Control 8 Audit Log Management Guide for retention and review.

Hardening baseline

A phased rollout keeps engineers working while the controls tighten. Test each step in a staging cluster or a trusted leaf cluster first.

1. Inventory: export roles, users, connectors, tokens and bots (tctl get roles, tctl tokens ls, tctl bots ls). Record who holds preset roles and which tokens are static.
2. Protect the keys: on self-hosted Enterprise move CA keys to an HSM or KMS; on any edition restrict root on Auth Service hosts and lock down the backend.
3. Strengthen authentication: enable WebAuthn, then remove OTP to activate MFA for administrative actions; pilot require_session_mfa on a group before cluster-wide. Roll back by restoring the previous cluster_auth_preference, which you saved in step 1.
4. Remove standing privilege: replace standing editor and broad access with narrow roles plus requestable roles that carry thresholds, deny lists and max_duration.
5. Fix machine access: move bots and agents from static tokens to delegated join methods; delete static tokens from teleport.yaml once nothing uses them.
6. Record and export: choose a recording mode (Teleport notes that asynchronous modes buffer recordings on local disk, where they are more exposed to tampering before upload, while synchronous modes terminate a session if an event cannot be recorded), enable recording encryption, and stream audit events to the SIEM.
7. Rehearse revocation: practise a lock on a test user and bot instance, and a manual CA rotation of the user CA with the rollback phase, so the team knows the timings before an incident.

Small versus large estates: a small team on Teleport Cloud gets managed key storage and should concentrate on roles, MFA and bots. A large self-hosted estate carries the backend, HSM and Auth Service hosts itself, and benefits most from trusted clusters that separate recording policy and blast radius per environment.

Common misconfigurations

• Standing editor for the platform team: one phished laptop yields the ability to write roles. Grant editor through two-approver Access Requests instead.
• OTP left enabled "for convenience": it disables automatic MFA for administrative actions and leaves a phishable factor in place.
• Static join tokens in configuration management: a long-lived secret in a repository lets anyone join an agent or bot. Teleport strongly discourages static tokens.
• No rehearsed CA rotation: because certificates cannot be revoked individually, a suspected CA or backend compromise needs a rotation; doing it for the first time during an incident risks an outage of every OpenSSH host trusting the openssh or user CA.
• Delegated join tokens without constraints: a GitHub or cloud join rule that allows any repository or account in the organisation lets an unrelated workload act as a privileged bot.
• Treating the vendor as outside scope: the access platform is itself a tier-zero supplier; see Remote access and PAM vendors as tier-zero suppliers.

Framework mapping

Practitioner checklist

• List every user and bot holding editor, terraform-provider or write rules on role, user, token or cert_authority, and remove standing human assignments.
• Set second_factors to WebAuthn (and SSO MFA if used), remove OTP, and confirm admin actions now prompt for MFA.
• Enable require_session_mfa for privileged roles at minimum.
• Give requestable privileged roles two-approver thresholds, a max_duration and deny rules for the top roles.
• Replace every static join token with a delegated join method or a short-TTL ephemeral token, constrained to the expected account or repository.
• Store CA keys in an HSM or KMS where the edition supports it; otherwise restrict and monitor the backend and Auth Service hosts.
• Choose a session recording mode deliberately, enable recording encryption, and stream audit events to the SIEM with alerts on role.* and auth_preference.update.
• Rehearse a lock and a user CA rotation at least once a year and record the runbook.

Standards and references

• Teleport: Reducing the Blast Radius of Attacks
• Teleport: Certificate Authority Rotation
• Teleport: Harden your Cluster Against IdP Compromises
• Teleport: MFA for Administrative Actions
• Teleport: Join Methods and Tokens
• Teleport: Teleport Session Recording
• Teleport: Session and Identity Locking
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Privileged Remote Access Buyers Guide · SSH Protocol and Certificate Authority Guide · JIT Access Guide · SSH Key Compromise Response Playbook