AnyDesk Security: Access Control, my.anydesk Administration and Abuse Prevention

AnyDesk gives anyone who holds a device's ID and an accepted credential a live session on that device, and attackers routinely talk users into installing it or reuse leaked unattended passwords, so an unmanaged or loosely configured AnyDesk estate is a ready-made remote access channel. The tool is popular with IT teams and service providers because it is small, fast and works without inbound firewall changes, and the same qualities make it attractive to scammers and intruders. This guide covers how identity and access work in AnyDesk, my.anydesk II roles, API credentials, session history and activity logs, a hardening baseline built on custom clients, and how to find and block AnyDesk you do not manage. It also covers the clean-up still needed after the 2024 code signing certificate replacement. It is written for IT administrators, endpoint and identity engineers and SOC teams. Feature names and licence tiers are from AnyDesk's public support documentation as checked in November 2026; confirm paths in your own console.

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

Key takeaways

• The device decides who gets in. Interactive Access, the Access Control List, permission profiles and Unattended Access are set per client, so central control comes from custom clients built in my.anydesk II, not from asking users to change settings.
• Unattended passwords are standing credentials. Anyone with the AnyDesk ID and the Unattended Access password gets whatever the permission profile allows, so require 2FA for Unattended Access and avoid the Full Access profile.
• Restrict who can connect, not just how. An Access Control List with a namespace wildcard, or the Same License Only connection policy, means a stolen password is useless from an outside client.
• Old certificates still matter. After the 2024 incident AnyDesk revoked its old code signing certificate; clients signed by philandro Software GmbH should be replaced, and binaries signed with the revoked certificate are a hunting lead.
• Unmanaged AnyDesk is the bigger risk. CISA has documented portable AnyDesk used in help desk refund scams, so allowlist your own build and block every other AnyDesk binary and cloud connection.

How identity and access work in AnyDesk

AnyDesk has two kinds of identity. Each client has an AnyDesk ID and optionally an alias, and its local settings decide which incoming sessions it accepts. my.anydesk II is the management console where users, roles, licences, custom client builds and session history are managed. A session succeeds when the connecting client passes the target's access rules and either a person on the target accepts the request or the connecting user supplies the Unattended Access password.

Ways a session is authorised

Interactive Access

Under Settings, Access, Interactive Access there are three options: "Always show incoming session requests", "Only show incoming session requests if AnyDesk window is open" and "Never show incoming session requests". The last option means only Unattended Access with a password can connect, which AnyDesk's security tips call exclusive unattended access. It suits servers and kiosks with no user; set the Unattended Access password first or the device becomes unreachable. For staff workstations, the middle option reduces the chance of a background request being accepted by mistake.

Unattended Access and 2FA

• Password rules: AnyDesk requires at least 8 characters, no simple or repeating patterns and a mix of letters, numbers and symbols, and recommends more than 12. AnyDesk stores passwords as salted hashes.
• 2FA: select "Enable Two-Factor Authentication" in the Unattended Access section and enrol an authenticator app. Administrators can let users skip 2FA for saved logins or for short-term passwords such as remote restart; leave both off unless a documented workflow needs them.
• Enforced 2FA: in a custom client build, Step 2 Security, Permission Profiles, "Require 2FA for Unattended Access" (documented for Windows clients at version 9.7.0) means Unattended Access will not work until 2FA is active and is disabled again if 2FA is removed. End users without admin rights cannot turn the requirement off.
• Tokens: changing the Unattended Access password invalidates every saved token. Clearing the save-login checkbox stops new tokens but existing tokens stay valid until cleared, so clear them as part of any incident or leaver process.

Account authentication for my.anydesk II

Console users can enable MFA under My profile, Multi-Factor Authentication, using an authenticator app. On Ultimate-Cloud, organisation owners can choose the User Provider under Organization, General: Admin (manual users), LDAP (directories such as Active Directory) or IDP, which uses OpenID Connect for single sign-on with corporate credentials. Use the IDP provider where available so joiners, leavers and MFA are governed by your identity provider. See How Single Sign On Works and the MFA Guide.

Admin roles and privileged access

my.anydesk II controls which client builds exist, who can create them, which devices hold your licence and who can close sessions. Treat Owner and Admin as tier-zero roles.

• Keep admins few: the Ultimate-Cloud admin role can edit most sections apart from licence, invoices and personal profile. Assign it to named platform owners and give technicians support_agent or a custom role.
• Control build creation: creating custom clients requires admin, IT agent or similar permissions. Whoever can create a build can ship a client with a preset password and broad permission profile to every device, so build creation belongs under change control.
• Log access is privileged: only the built-in Owner and Admin roles can read the Activity Log on Ultimate-Cloud; custom roles cannot be given this permission. Plan how security staff get read access without broader admin rights, for example by exporting the log.
• Review quarterly: compare role holders against HR records and your identity provider. See the Privileged Access Management Guide.

Integrations, API tokens and service accounts

The my.anydesk I REST API authenticates with a License ID and an API Password, requested from AnyDesk support with your customer number (on-premises licences configure the REST API from the appliance console). As documented for version 1.1.1, the API can read licence and client details, remove clients from the licence, read session history, add session comments, close active sessions, change or remove aliases and list address books.

• Treat the API Password as a privileged secret: it can close sessions, remove clients and read the full session history for the licence. Store it in a secrets manager, restrict which systems can use it and record an owner. See the API Key Management Guide and the Secrets Management Guide.
• Rotation is a support process: AnyDesk's API page does not describe self-service rotation, so agree a rotation and revocation route with AnyDesk support before you need it.
• Licence key as a credential: AnyDesk's offboarding advice includes resetting the licence key (License, About, Reset) after a leaver, which downgrades any client still holding the old key. Treat the key like a shared secret.
• Public build links: a custom client with the Public download type can be downloaded by anyone with the link. Use Private downloads (users sign in with a linked account) and recreate any public link that has leaked.

Logging and detection

What to alert on

• Console changes: new builds, permission profile changes, new admins, role and permission set edits, especially outside change windows.
• Unusual sessions: sessions to servers outside maintenance windows, from addresses outside your licence or namespace, or to finance and HR workstations.
• Unapproved binaries: AnyDesk running from Downloads or temp folders, portable copies, or any AnyDesk binary that is not your custom build. ATT&CK tracks this as T1219.002 Remote Desktop Software.
• Old signer: AnyDesk executables still signed by philandro Software GmbH on Windows, or binaries signed with the revoked certificate. Code signing abuse maps to T1553.002 Code Signing.

Metrics

• Percentage of AnyDesk installations that are your custom build (target 100%).
• Percentage of Unattended Access devices with 2FA required.
• Number of Owner and Admin accounts, and percentage of console users on SSO or MFA.
• Unapproved AnyDesk executions detected per month and median time to removal.
• Clients still signed by the old certificate (target zero).

Hardening baseline

Custom clients are the main lever: a build created in my.anydesk II under Builds carries security settings such as the Access Control List, Unattended Access, permission profiles and proxy configuration to every device that installs it. The baseline below assumes you deploy only your own builds.

The Default profile allows everything except enabling privacy mode and creating TCP tunnels; Screen Sharing allows viewing only. Privacy mode blanks the target screen, which is useful for confidential maintenance but also hides an attacker from the user, so grant it deliberately.

Rollout order

1. Inventory: find every AnyDesk installation, its signer, version and whether it is linked to your licence. Add AnyDesk to your RMM register. See the RMM Tool Security Guide.
2. Secure the console: enable SSO through the IDP user provider or MFA for every console user, then cut Owner and Admin to named owners.
3. Build and pilot: create a custom build with the baseline, deploy it to an IT pilot group and confirm support workflows, including remote restart and supplier access.
4. Replace by ring: roll out to workstations, then servers, then supplier-managed devices, removing older clients and any still signed by philandro Software GmbH. Keep the previous build available to redeploy as the rollback.
5. Restrict the network: apply the connection policy, then block AnyDesk executables that are not your build and, for on-premises deployments, block AnyDesk cloud addresses.
6. Monitor: export the Activity Log and session history to the SIEM and build the alerts above.

On-premises option

AnyDesk On-Premises (Ultimate) runs your own appliance server on physical or virtual hardware. Only custom clients created for that deployment can connect; standard clients and other organisations' custom clients cannot find the server. Sessions work without internet access, the server can sit in a DMZ restricted to internal IP addresses, and AnyDesk cloud addresses can be blocked at the firewall so only on-premises clients work. You hold the session history and can restrict access by IP address. It suits regulated or isolated environments, at the cost of running and patching the appliance yourself.

Blocking AnyDesk you do not manage

The CISA, NSA and MS-ISAC advisory AA23-025A (January 2023) describes help desk-themed phishing that led staff to run portable AnyDesk, which needs no installation or administrator rights, followed by a refund scam. The advisory says application controls should prevent both installation and execution of portable versions of unauthorised RMM software. Allowlist your build by signer and path, block every other AnyDesk binary including portable copies, and filter AnyDesk cloud domains from hosts that should not use it. See the Application Allowlisting Guide.

Common misconfigurations

• Full Access as the unattended profile: every leaked Unattended Access password becomes complete control, including file transfer and tunnels.
• No Access Control List: without an ACL or connection policy, a password works from any AnyDesk client in the world.
• Shared unattended passwords that never change: passwords in tickets or shared between technicians survive staff changes. AnyDesk's offboarding advice is to change them, block the leaver's ID or alias in the ACL, remove their client and reset the licence key.
• Old clients still installed: clients signed by philandro Software GmbH should be replaced; for custom clients, download the build again from Builds, check the signature (AnyDesk Software GmbH on Windows) and redeploy, and for on-premises deployments redeploy the clients. See the Compromised Code Signing Certificate Playbook.
• Console accounts without MFA: my.anydesk credentials offered for sale after the 2024 incident were attributed by AnyDesk to old infostealer infections, which is why console MFA or SSO matters.
• Users who trust the caller: AnyDesk states that it responds only to support tickets you initiate, and scammers impersonate AnyDesk, Microsoft and other companies. Teach users that IT never starts an unsolicited session. See the Vishing and Help Desk Social Engineering Awareness Guide.

Framework mapping

Practitioner checklist

• Inventory every AnyDesk installation, signer, version and licence link; remove anything you do not manage.
• Enable SSO through the IDP user provider or MFA for every my.anydesk II user, and keep Owner and Admin to named owners.
• Deploy only custom builds with Private download, an Access Control List on your namespace and Require 2FA for Unattended Access.
• Set the connection policy to Same License Only where the business allows.
• Use a restrictive custom permission profile for unattended devices instead of Full Access.
• Replace any client still signed by philandro Software GmbH and hunt for binaries signed with the revoked certificate.
• Store the REST API Password in a vault with an owner and an agreed revocation route.
• Export the Activity Log and session history to the SIEM and alert on build, role and out-of-hours session events.
• Block portable and unapproved AnyDesk with application allowlisting and DNS filtering, and train users on remote support scams.

Standards and references

• AnyDesk: Set up Unattended Access
• AnyDesk: Require 2FA for Unattended Access (Custom Clients)
• AnyDesk: Setting up Permission Profiles
• AnyDesk: Security tips and offboarding
• AnyDesk: Activity Logs
• AnyDesk: How to ensure I use AnyDesk with the latest code signing certificate
• 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 · Remote Access Identity Guide · Code Signing Security Guide · Privileged Remote Access Buyers Guide