TeamViewer Security: Tenant Policies, Conditional Access, SSO and Connection Logs

A TeamViewer account or an unmanaged TeamViewer client gives whoever controls it an interactive session on the target device, so a loosely configured company profile, a reused password or a stray installation can turn an approved support tool into an attacker's front door. Convenience features such as Easy Access, saved passwords and connections from anywhere need control. This guide covers how identity and access work in TeamViewer, the admin permissions to restrict, script tokens, connection reports and event logs, a hardening baseline from TeamViewer settings policies, and how to block TeamViewer that your organisation does not manage. It is for IT administrators, endpoint and identity engineers, and SOC teams.

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

Key takeaways

• Two identities protect every session. The TeamViewer account of the supporter and the access settings on the target device both matter: harden accounts with SSO or enforced two-factor authentication, and harden devices with an enforced settings policy.
• Enforced policy beats local settings. A TeamViewer settings policy with the enforcement switch on greys out the setting on the device, so a user or an attacker on the device cannot weaken access control, passwords or logging.
• Conditional access is deny by default. On Tensor, conditional access routes connections through dedicated routers and blocks everything until a rule allows it, which is the strongest way to stop unmanaged TeamViewer use.
• Easy Access and script tokens are standing credentials. Easy Access grants account-based unattended access to devices, and script tokens cannot be edited once created, so both need owners, scoping and regular review.
• Turn logging on before you need it. Incoming connection reports and event logs are not complete by default: incoming reporting needs a policy setting and event logging must be switched on by a company administrator.

How identity and access work in TeamViewer

TeamViewer has two layers of identity. The first is the TeamViewer account of the person connecting, which belongs to a company profile managed in the web Admin settings or Management Console. The second is the device, identified by its TeamViewer ID, which accepts or refuses incoming sessions according to its local settings or an assigned policy. A session is allowed when the connecting account or ID satisfies the device's access rules and supplies an accepted credential.

How a supporter authenticates to a device

Password authentication uses the Secure Remote Password protocol (SRP version 6), so only a password verifier is stored on the device and account passwords are not sent to TeamViewer's servers, according to TeamViewer's security statement. Failed passwords trigger an exponentially growing wait, which the statement illustrates as 17 hours after 24 failed attempts. Newer clients use mutually authenticated TLS 1.3 with perfect forward secrecy and AES-256-GCM, and older connections use RSA 4096 key exchange with AES 256-bit encryption. None of this helps if the user reads the password to a caller.

Account authentication: SSO and two-factor authentication

• Single sign-on: TeamViewer SSO is set per email domain and uses SAML 2.0 with any compatible identity provider. It needs a Tensor licence and a client at version 13.2.1080 or later. You prove ownership with a DNS TXT record; TeamViewer checks for 24 hours, then verification must be restarted. Once active, users signing in with that domain are redirected to the identity provider, where your MFA and conditional access policies apply. See the SAML Security Guide.
• Customer identifier: the SSO setup generates a customer identifier returned to TeamViewer in a custom SAML claim named customeridentifier. TeamViewer does not store it and states it must not be changed; treat it as a secret in your identity provider configuration.
• Exclusion list: email addresses or user groups can be excluded from SSO. TeamViewer recommends excluding the owning admin account as a fallback if the identity provider fails. Keep that list to one or two named break-glass accounts with strong 2FA. See the Break-Glass Account Guide.
• Domain lock: administrators can block new account sign-ups that use the SSO domain, which stops staff creating private accounts with the corporate address outside the company profile.
• Enforced 2FA: without SSO, administrators can enforce two-factor authentication under Admin settings, Users, Edit, Two-factor authentication, Enable enforcement (Premium, Corporate and Tensor). Accounts use time-based one-time passwords. Where 2FA is not set up, TeamViewer's Trusted Devices feature requires email authorisation for new devices, browsers or IP addresses.
• 2FA for connections: separately from account 2FA, a device owner can require each incoming connection to be approved by push notification on a mobile device, which suits high-value unattended machines.

Admin roles and privileged access

Company administrators control SSO, policies, users and logging, so they hold tier-zero power over every device in the profile. TeamViewer's role permissions (Premium, Corporate and Tensor) are grouped as shown below; build roles from them rather than making every support lead an administrator.

• Reduce administrators: TeamViewer's Security Center counts administrator users and recommends fewer, with no hard limit. Track the count monthly.
• Add SSO domain owners deliberately: SSO domain ownership is not inherited within a company, and TeamViewer recommends adding other administrators as domain owners. A domain owner can redirect authentication, so record them.
• Use privileged access discipline: administrators should use separate admin accounts, SSO with phishing-resistant MFA and quarterly review. See the Privileged Access Management Guide and the Phishing-Resistant MFA Guide.

Integrations, API tokens and service accounts

The TeamViewer web API uses OAuth 2.0 and is commonly reached with a script token, created under Edit profile, Apps & Tokens, Create app or token (or Apps, Create script token in the Management Console). The person creating it ticks the permissions the token receives, and TeamViewer's documentation notes that a token cannot be edited after creation, only deleted. A script token acts with the permissions it was given for as long as it exists, which makes it a non-human identity in its own right.

• Least privilege per token: create one token per integration (ticketing, inventory, reporting export) with only the permissions it needs. A reporting export needs to read connection reports, not manage users or policies.
• Owner and purpose: record the creating account, the integration, the permissions and the storage location for every token.
• Vault, do not embed: keep tokens in a secrets manager and inject them at run time, never in scripts committed to repositories or in deployment packages. See the API Key Management Guide and the Secrets Management Guide.
• Rotate by replacement: because tokens cannot be edited, rotation means creating a new token, switching the integration, then deleting the old one. Script token changes appear in the event log on Tensor, so watch for tokens created outside a change.
• Deployment assignment: mass deployment assigns devices to the company profile; protect the assignment configuration as you would a token, and use the policy setting "Prevent removing account assignment" so local users cannot detach managed devices.

Logging and detection

TeamViewer offers two log sources in the company profile, plus local log files on each device. Neither is complete by default.

Because event log retention is fixed at one year, pull the log through the REST API or scheduled CSV export into your SIEM if your retention policy is longer. See the SIEM Guide.

What to alert on

• Account changes: 2FA deactivated, new administrator, permission changes, SSO exclusion list changes, new script tokens.
• Policy weakening: policy updated or deleted outside change windows, especially access control, password or logging rules.
• Unusual sessions: incoming sessions to servers outside maintenance windows, from origin IDs not in your company, sessions with file transfer to finance or HR endpoints, and black screen enabled during a session to a user's workstation.
• Unmanaged clients: TeamViewer processes on endpoints that are not assigned to the company profile, or DNS lookups to TeamViewer infrastructure from hosts with no approved client. ATT&CK tracks this behaviour as T1219.002 Remote Desktop Software under T1219 Remote Access Tools.

Metrics

• Percentage of company accounts using SSO or enforced 2FA (target 100%).
• Percentage of managed devices with an enforced settings policy and incoming reporting on.
• Number of administrator accounts and number of active script tokens, each with a named owner.
• Count of Easy Access grants per device group, reviewed quarterly.
• Unmanaged TeamViewer executions detected per month, and median time to remove them.

Hardening baseline

TeamViewer settings policies are the main tool. When a rule is enforced the device shows it greyed out and cannot change it; rules the policy does not define keep the local value, so define everything that matters. TeamViewer's Security Center checks devices without policies for five of these rules, which makes a good starting set.

Rollout order

1. Inventory: list every TeamViewer installation, licence and company profile, including those bought by departments or suppliers. Add TeamViewer to your software inventory and RMM register. See the RMM Tool Security Guide.
2. Secure accounts first: enable SSO with domain lock on Tensor, or enforce 2FA for every company member. Cut administrators to named owners.
3. Pilot the policy: assign the baseline policy to an IT device group without enforcement, confirm support still works, then enforce. Use "Inherit policy from group" so devices pick up group changes.
4. Roll out by ring: IT, then standard workstations, then servers and privileged devices, then supplier-managed devices. Keep a previous policy version to reassign if a ring breaks; reassigning the old policy is the rollback.
5. Turn on logging: event logging, incoming reporting and SIEM export, then build the alerts above.
6. Restrict the network path: on Tensor, deploy conditional access in audit of current traffic, write rules, then activate them and block the public TeamViewer master and router addresses.

Conditional access and blocking unmanaged TeamViewer

Conditional access (Tensor with the add-on, or Tensor Pro or Unlimited, client 15.5 or later) routes connections through dedicated routers and starts by blocking everything. Rules can be Internal or Organization (between companies), set for accounts, groups, user groups, directory groups or devices, and carry options for in-session features, approval by chosen users, allowed time slots and expiry. Where groups overlap, the most permissive rule wins. Rules are not active until an administrator selects Activate.

Managed clients receive the dedicated router addresses through the ConditionalAccessServers value (a REG_MULTI_SZ registry value on Windows, a preference on macOS, an entry in global.conf on Linux). TeamViewer then advises blocking master*.teamviewer.com and router*.teamviewer.com at the firewall. Clients without the router setting cannot go online, which blocks personal and attacker-installed TeamViewer on your network. Without Tensor, combine application allowlisting by publisher and path with DNS filtering. The CISA, NSA and MS-ISAC advisory AA23-025A says application controls should prevent both installation and execution of portable versions of unauthorised RMM software. See the Application Allowlisting Guide.

Common misconfigurations

• Policies assigned but not enforced: the policy sets defaults that a local user, or malware running as that user, can change. Enforce every security rule.
• Fixed passwords on unattended devices: personal passwords written in tickets or shared between technicians give anyone with the ID permanent access. Replace them with Easy Access for named accounts.
• Easy Access granted at too high a group: with "Inherit device group permissions to devices", a grant on a broad group reaches every device in it. Grant on small, purpose-built groups.
• Incoming reporting never switched on: outgoing reports exist by default, but sessions into your servers from a supplier or an attacker's account do not appear until the policy enables incoming reporting.
• Private accounts with the corporate domain: without SSO domain lock, staff create TeamViewer accounts outside the company profile that bypass 2FA enforcement and offboarding.
• Help desk impersonation: attackers call users pretending to be IT and ask them to install or open a remote support tool and read out the password. TeamViewer states it does not provide remote support services of any kind, and runs a scam report form. Teach users that your help desk never asks for an unsolicited session and that only allowlisted company accounts can connect. See the Vishing and Help Desk Social Engineering Awareness Guide and the Email Bombing and Help Desk Impersonation over Teams Guide.

Framework mapping

Practitioner checklist

• Inventory every TeamViewer licence, company profile and installation, including supplier and departmental ones.
• Enable SSO with domain lock (Tensor) or enforce 2FA for all company members; keep the SSO exclusion list to named break-glass accounts.
• Reduce administrators to named owners, build least-privilege roles and review them quarterly.
• Assign and enforce a baseline settings policy: no personal passwords, random password after each session, Windows logon not allowed, allowlist of company profiles, logging on.
• Replace fixed unattended passwords with Easy Access on small device groups and review grants quarterly.
• Create one least-privilege script token per integration, store it in a vault and rotate it by replacement.
• Turn on event logging and incoming connection reporting, and export both to the SIEM before the one-year retention expires.
• Block unmanaged TeamViewer with conditional access and firewall rules, or with application allowlisting and DNS filtering.
• Train users and the help desk on remote support scams and give them a fast way to report an unexpected session.

Standards and references

• TeamViewer: Security Statement, How secure is TeamViewer?
• TeamViewer: Policy settings
• TeamViewer: Conditional Access
• TeamViewer: Single Sign-On (SSO)
• TeamViewer: Auditability, event log
• TeamViewer: Connection reports
• CISA, NSA and MS-ISAC: AA23-025A, Protecting Against Malicious Use of Remote Monitoring and Management Software
• MITRE ATT&CK: T1219.002 Remote Desktop Software

Related NHI Mgmt Group resources: RMM Tool Security Guide · MFA Guide · Remote Access Identity Guide · Privileged Remote Access Buyers Guide