Skip to content

Teleport access control & privilege security checks

Admin roles, standing privileges, permission scopes and policy enforcement — the settings that decide how much damage one compromised account can do.

On Teleport, Black Cat runs 21 checks in this area on every scan. Each one below lists its severity, how to fix it, and the compliance controls it satisfies where a control applies. See what access the Teleport connector needs.

Checks (21)

severity: critical Role Has Wildcard Node Labels fix difficulty: medium #

Replace the wildcard node label selector with specific labels to enforce least-privilege node access

  1. Export the role with tctl get role/<name> > role.yaml
  2. Replace the wildcard (*) node label selector in allow.node_labels with specific key-value pairs
  3. Apply the updated role with tctl create -f role.yaml
  4. Test that legitimate users can still access the nodes they need

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: critical Role Has Wildcard Database Labels fix difficulty: medium #

Replace the wildcard database label selector with specific labels to enforce least-privilege database access

  1. Export the role with tctl get role/<name> > role.yaml
  2. Replace the wildcard (*) database label selector in allow.db_labels with specific key-value pairs
  3. Apply the updated role with tctl create -f role.yaml
  4. Verify that authorized users can still connect to the databases they need

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: critical Role Has Wildcard Kubernetes Labels fix difficulty: medium #

Replace the wildcard Kubernetes label selector with specific labels to enforce least-privilege cluster access

  1. Export the role with tctl get role/<name> > role.yaml
  2. Replace the wildcard (*) kube_labels selector in allow.kubernetes_labels with specific labels
  3. Apply the updated role with tctl create -f role.yaml
  4. Verify that authorized users can still access the Kubernetes clusters they need

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: high Role Has Wildcard App Labels fix difficulty: medium #

Replace the wildcard app label selector with specific labels to limit application access

  1. Export the role with tctl get role/<name> > role.yaml
  2. Replace the wildcard (*) app_labels selector in allow.app_labels with specific labels
  3. Apply the updated role with tctl create -f role.yaml
  4. Verify that authorized users can still access the applications they need

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: high Role Enables SSH Agent Forwarding fix difficulty: easy #

Disable SSH agent forwarding in the role to prevent lateral movement via agent hijacking

  1. Export the role with tctl get role/<name> > role.yaml
  2. Set forward_agent to false in the role options
  3. Apply the updated role with tctl create -f role.yaml
  4. Confirm that users requiring agent forwarding have a documented exception process

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: high Role Has Unlimited Session TTL fix difficulty: easy #

Set a reasonable maximum session TTL in the role to limit the duration of access certificates

  1. Export the role with tctl get role/<name> > role.yaml
  2. Set max_session_ttl to an appropriate value such as 8h or 24h in the role options
  3. Apply the updated role with tctl create -f role.yaml
  4. Verify that new sessions respect the updated TTL

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: high Role Allows Impersonation fix difficulty: medium #

Review and restrict impersonation permissions to only those explicitly required

  1. Export the role with tctl get role/<name> > role.yaml
  2. Review the allow.impersonate.users and allow.impersonate.roles fields
  3. Remove or restrict impersonation to only the minimum required users and roles
  4. Apply the updated role with tctl create -f role.yaml
  5. Audit who holds this role and confirm the access is justified

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: high Role Has Broad Admin RBAC Rules fix difficulty: medium #

Restrict the role RBAC rules to specific resources and verbs instead of wildcard access

  1. Export the role with tctl get role/<name> > role.yaml
  2. Replace wildcard resource (*) entries in allow.rules with specific resource names
  3. Restrict verbs to the minimum required (e.g., read instead of *)
  4. Apply the updated role with tctl create -f role.yaml
  5. Test that legitimate admin operations still work as expected

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: medium User Account Is Locked fix difficulty: medium #

Investigate why the user account is locked and take appropriate action

  1. Run tctl get lock to view active locks affecting this user
  2. Review the lock message to understand the reason for the lock
  3. If the lock was created in error, delete it with tctl rm lock/<id>
  4. If the lock is valid (e.g., security incident), ensure the user account is deprovisioned
  5. Update access policies to prevent future unauthorized access

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: medium Local User Has No SSO Identity fix difficulty: medium #

Link the local user account to an SSO identity or migrate them to SSO-only authentication

  1. Determine if this user should be managed via SSO
  2. If yes, have the user log in via the SSO connector to automatically link their identity
  3. If the user no longer needs access, delete the account with tctl rm user/<name>
  4. If local access is intentional (e.g., break-glass account), document the exception

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: medium User Has Excessive Roles fix difficulty: medium #

Reduce the number of roles assigned to the user to enforce least-privilege access

  1. Run tctl get user/<name> to view the user's current role assignments
  2. Review each role and determine which are actually required
  3. Remove unnecessary roles with tctl edit user/<name>
  4. Consider consolidating permissions into fewer, more targeted roles

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: high User Has Admin Role fix difficulty: medium #

Review whether the user requires admin-level access and remove it if not justified

  1. Run tctl get user/<name> to review the user's role assignments
  2. Identify roles with admin in the name and review their permissions
  3. If admin access is not required, replace the admin role with a least-privilege role
  4. Apply changes with tctl edit user/<name>
  5. Document the justification if admin access is retained

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: high Auth Connector Maps Claims to Admin Role fix difficulty: medium #

Restrict SSO role mappings so they do not grant admin roles automatically

  1. Export the connector with tctl get saml/<name> or tctl get oidc/<name>
  2. Review the claims_to_roles or teams_to_roles mappings
  3. Replace admin role assignments with least-privilege roles appropriate for the SSO group
  4. Apply the updated connector with tctl create -f connector.yaml
  5. Test SSO login to verify users receive the correct roles

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: medium Auth Connector Has Broad Claim Mapping fix difficulty: medium #

Replace wildcard claim values with specific claim values to restrict role assignments

  1. Export the connector with tctl get saml/<name> or tctl get oidc/<name>
  2. Identify claims_to_roles entries with a wildcard value (*)
  3. Replace the wildcard with the specific claim values that should receive the role
  4. Apply the updated connector with tctl create -f connector.yaml
  5. Test SSO login to verify only intended users receive the role

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: high Auth Connector Has No Role Mappings fix difficulty: medium #

Configure role mappings in the auth connector so SSO users receive appropriate access

  1. Export the connector with tctl get saml/<name>, tctl get oidc/<name>, or tctl get github/<name>
  2. Add claims_to_roles or teams_to_roles mappings appropriate for each SSO group
  3. Apply the updated connector with tctl create -f connector.yaml
  4. Test SSO login to verify users receive the expected roles

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: medium GitHub Connector Maps All Teams fix difficulty: medium #

Replace the wildcard team mapping with specific GitHub team names to restrict access

  1. Export the connector with tctl get github/<name>
  2. Replace the wildcard (*) team entry in teams_to_roles with specific team names
  3. Apply the updated connector with tctl create -f connector.yaml
  4. Test GitHub SSO login to verify only members of the specified teams receive access

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: critical Token Uses Static Join Method fix difficulty: hard #

Migrate from static token join to a cloud-native join method such as iam or ec2

  1. Determine the target node's cloud environment (AWS, GCP, Azure)
  2. Configure the appropriate join method in the token spec (e.g., join_method = iam)
  3. Add the required IAM policy or metadata to the target node
  4. Create a new token with tctl create -f token.yaml
  5. Update the node configuration to use the new token and join method
  6. Delete the old static token with tctl rm token/<name>

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: high Token Has No Expiry fix difficulty: easy #

Set an expiry on the provisioning token to limit its validity window

  1. Export the token with tctl get token/<name> > token.yaml
  2. Set an appropriate expires field in the token spec (e.g., 24 hours from now)
  3. Apply the updated token with tctl create -f token.yaml
  4. If a permanent token is needed, consider using a cloud-native join method instead

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: critical Token Grants Auth System Role fix difficulty: medium #

Remove the Auth role from provisioning tokens that are not specifically needed for auth server joining

  1. Review whether this token is legitimately used for an auth server join
  2. If not needed, delete the token with tctl rm token/<name>
  3. If needed, restrict the token scope and ensure it expires immediately after use
  4. Rotate all credentials on any nodes that joined using this token

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: high Token Grants Admin Role fix difficulty: medium #

Remove admin roles from provisioning tokens to prevent privilege escalation via node joining

  1. Export the token with tctl get token/<name> > token.yaml
  2. Remove the admin role from the roles list in the token spec
  3. Apply the updated token with tctl create -f token.yaml or create a new token
  4. Review nodes that joined using this token and audit their effective permissions

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: high Trusted Cluster Has Broad Role Map fix difficulty: medium #

Replace the wildcard remote role mapping with specific roles to limit access from the trusted cluster

  1. Export the trusted cluster with tctl get trusted_cluster/<name> > tc.yaml
  2. Replace the wildcard (*) entry in role_map.remote with specific role names from the remote cluster
  3. Apply the updated configuration with tctl create -f tc.yaml
  4. Test that legitimate cross-cluster access still works as expected

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

More Teleport checks

The information on this page is provided for general informational purposes and is believed to be accurate as of its most recent update. Product names, logos, and trademarks are the property of their respective owners and are used for identification purposes only; their use does not imply any affiliation with or endorsement by those owners. Descriptions of third-party applications and of compliance frameworks are based on publicly available documentation and may change over time.

See these checks run on your stack

Start a free 14-day trial — no credit card required.

Start Free Trial