Written for Synergy 3 (v3.7.2) and Synergy 1 (v1.21.4), checked 3 October 2026. Releases before Synergy 1 (v1.21.2) behaved differently; see Earlier releases under Licensing and activation.
Synergy 1 and Synergy 3 are on-premise software. They run entirely on your own machines and local network. They do not route your input through our servers, and nothing you type or view is sent to us. We recommend Synergy 1 for business, and Synergy 3 is supported for business too. This page describes how Synergy 1 works, where Synergy 3 differs, what data it does and does not handle, and how we manage security. It is intended to support vendor security reviews and procurement assessments.
For the settings and deployment controls referred to throughout this page, see: Business & Enterprise Hardening Guide
Summary for reviewers
Synergy 1 shares one keyboard and mouse across multiple computers on the same network. Input events are relayed directly between the controlling machine and the controlled machines over an encrypted connection. There is no cloud service in the path, no hosted data store, and no subprocessor chain handling customer data. This is the core of our security posture: the product has a deliberately small data footprint because it never takes custody of your data in the first place.
Architecture and data flow
A Synergy 1 deployment consists of one server and one or more clients on the same local network.
The server is the machine whose physical keyboard and mouse are shared. The clients are the machines that receive input. When the cursor moves to a client screen, the server sends keyboard and mouse events to that client over the network. Input is relayed in real time and is not retained after delivery.
The connection is a direct network link between machines you control. Synergy 1 does not proxy, mirror, or relay this traffic through any external service.
Synergy 3 shares input the same way, and adds a background service on each computer that finds your other computers on the local network (multicast DNS, on by default, turned off with Auto discover) and keeps their settings in step over a second direct connection: the screen layout, hotkeys, and the security and copy and paste settings. Keyboard, mouse and clipboard data never use that connection. It is not encrypted with TLS, and computers recognize each other on it by your license's serial key. Synergy 3 has no cloud relay either.
Network and ports
Synergy 1 communicates over a single TCP port on your local network. The default port is 24800, and it is configurable. No inbound connections from the internet are required. In a segmented or air-gapped environment, Synergy 1 operates without any internet access after activation, and can be licensed with no internet access at all (see Licensing and activation below).
Synergy 3 uses TCP port 24800 for input too, plus TCP port 24802 for its settings connection and multicast DNS for auto discovery. Its window talks to its service on port 24803, which listens only on the computer itself.
The Windows installers add firewall exceptions for the Synergy 1 core process and for the Synergy 3 core and service processes. Managed deployments that use the host firewall as a control should replace these with their own scoped rules. The hardening guide covers this.
Encryption in transit
Input traffic between the server and clients is encrypted with TLS, enabled by default in Synergy 1 and Synergy 3.
- TLS 1.2 is the enforced minimum. SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1 are disabled. TLS 1.3 is used where both machines support it.
- Certificates are generated locally on each machine. The default key size is 2048-bit RSA, and 4096-bit is selectable in settings.
- Machines authenticate each other by certificate fingerprint rather than by a certificate authority chain. The first time two machines connect, the fingerprint is shown for confirmation, and fingerprint checking is enabled by default.
In Synergy 3 the default key size is 4096-bit RSA, with 2048-bit selectable, and computers verify each other in both directions by default: before two computers connect, both screens show a code computed from both certificates, and a person on each computer accepts the other.
Because trust is pinned to a fingerprint rather than delegated to a CA, there is no certificate authority to compromise and no PKI to integrate. In a managed deployment, expected fingerprints can be distributed during provisioning so users are never asked to make a trust decision.
Data collected and not collected
Synergy 1 is designed to handle as little data as possible.
- Screen contents are never captured, recorded or transmitted. Synergy 1 has no screen capture path and no video channel. It shares input only, not display output. This is the structural difference between Synergy 1 and remote access tools such as RDP and VNC, which work by transmitting the screen.
- Your input is never sent to us or to any third party. Keyboard and mouse events travel directly between your own machines and nowhere else.
- There is no analytics or behavioural telemetry in any edition. The only outbound connections Synergy 1 makes are licence activation, a daily usage report sent by business editions only, and an optional update check. Synergy 3 makes the same three (its update check can't be turned off), plus account sign-in if a user chooses it and error reports, which are on by default and can be turned off. All of them are described below, and none of them carries any input data.
Keyboard input is not recorded at Synergy 1's default settings. The one exception is diagnostic logging, covered in the next section, because we would rather state it than have you discover it.
Logging
Synergy 1's default log level records connection and status information only, and no keyboard input. Writing logs to a file is also off by default, except on Windows, where the background service always writes the core's output to C:\ProgramData\Synergy\synergy-daemon.log.
Synergy 3 also records no keyboard input at its default level (Info), but always writes its log to files on the computer.
At the most verbose diagnostic level (Debug 1 in Synergy 3), which we sometimes ask for when troubleshooting a difficult issue, Synergy 1 additionally records key identifiers. A log captured at that level can therefore contain what was typed. It is not the default, it has to be deliberately selected, and the log stays on your own machine unless you choose to send it to us.
Two practical consequences:
- If you are attaching a log to a support ticket, a log captured at the verbose level may contain sensitive input. Review it first, or ask us whether a lower level is sufficient for the problem.
- In a managed Synergy 1 deployment, the log level is one of the settings worth locking. Making the settings file read-only prevents the log level being raised, and Synergy 1 handles this properly: the settings window tells the user the file is read-only and disables the controls rather than failing silently. The hardening guide covers how to deploy this.
Licensing and activation
Synergy 1 activates a licence once per computer, when the core first starts in a given role (server or client). Activation, the business usage report and the optional update check are the only ways the application contacts us, and none of them carries any input data. The Enterprise edition is licensed by agreement rather than enforced in the software, so an Enterprise install has no serial key, never activates and makes no licence calls.
Synergy 3 follows the same activation model and sends the same activation request and business usage report, described below.
What activation sends
The activation request contains your serial key, the application version, your operating system name and version, whether the machine is acting as server or client, the activation protocol version, and two identifiers derived from your machine ID and hostname. Those two identifiers are hashed (SHA-256) before they leave your computer, so we do not receive your hostname or your hardware ID. We record the public IP address the request arrives from.
When activation happens
Entering a serial key does not contact us; the key is checked on the machine itself. The first time the core starts as a server, or as a client, the machine activates in that role. The application remembers only the role it last activated in: a routine restart is silent, and only a change of role reaches our server. There is no periodic licence check, no grace period and no remote deactivation: once a computer has activated, nothing we do can deactivate it. A new server install is turned away when the licence has no server activation slots left, and any install is turned away when the serial key doesn't match a valid licence; client activations are unlimited and never consume a slot. Time-limited keys (trials and subscriptions) also carry their end date, and the application asks for a new serial key at launch once it has passed. If our systems cannot be reached at activation, the core starts anyway and the machine tries again at its next core start, so a network outage or a maintenance window never blocks anyone's work.
Business usage report
Once a machine has activated, business editions send a usage report at application launch and once every 24 hours after that while the application is open. It contains the serial key, which identifies the licence and the person or organisation it was issued to, the application version, the operating system name and the same two hashed identifiers as activation, and we record the public IP address it arrives from. The report is sent for licence compliance, so that seat usage can be reconciled against the licence at renewal, and for nothing else. The response carries nothing the application acts on, and a report that fails for any reason is silently ignored. Personal licences never send it, and neither do offline keys. Our privacy policy covers how it is handled.
The report is mandatory for business editions and there is no setting to turn it off. If your policy does not allow it, block the usage endpoint (symless.com/synergy/api/product/usage) at the firewall: the application tolerates that silently and keeps working. If you need genuinely zero telemetry, the Enterprise edition is the option: it is licensed by agreement rather than enforced in the software, so there is no serial key, no activation and nothing sent.
Update check
The update check is on by default and can be turned off in settings with Check for updates on startup. When enabled, the check runs once per application launch and sends only the application version, whether it is a personal or business edition, the system language, and the operating system name and version. It sends no serial key and no machine identifier.
Synergy 3 checks for updates each time its window opens, sending the application version, the operating system name and version, the processor architecture and the system language, and no serial key or machine identifier. It has no setting to turn the check off; it only shows a notice and never downloads anything by itself.
Error reports (Synergy 3)
Synergy 3 sends error and diagnostic reports to us when something goes wrong, so we can fix it. They are on by default and contain the error, recent log lines, the computer's host name, operating system and memory, and the email address of the license. They contain no keyboard input at the default log level. To stop them, turn off Send error and diagnostic reports on the Troubleshooting page on each computer. Synergy 1 sends no error reports.
Offline activation
Offline activation is included in every product and edition. The machine displays a short challenge code derived from its hardware identifier and serial key. That code is exchanged out of band for a response code, which the machine verifies locally with no network access of any kind. Both codes are short enough to be read out or typed by hand, which is what makes the process workable on a genuinely disconnected machine. The challenge is shown on the server at core start; clients on an offline key never prompt and never contact us. An offline key makes no licence calls and never sends the usage report.
The higher business tiers add flexibility in how activation is managed, and the Enterprise edition removes enforcement altogether: there is no key, no per-device challenge and no activation step, because the licence is an agreement rather than something the software checks. Contact us about offline licence keys if this applies to your environment.
Earlier releases
Releases before Synergy 1 (v1.21.2) behaved differently: business installs checked the licence at core start and roughly once a day after that, with a 14-day grace period, and a licence could be deactivated remotely. All of that is gone in 1.21.2 and later. A machine that updates activates once more at its next core start and then follows the model above.
The Windows background service
On Windows, Synergy 1 installs a background service that runs with system privileges. It exists so that keyboard and mouse sharing continues to work on screens that Windows protects from ordinary applications, such as UAC prompts and the login screen.
This service is installed on Windows only. On macOS and Linux, Synergy 1 runs entirely as the logged-in user, with no privileged component at all.
Where a deployment does not need input on the login screen or on UAC prompts, the service can be configured to run Synergy 1 as the logged-in user instead, or bypassed entirely. The hardening guide covers both.
Synergy 3 installs a similar service on Windows, Synergy Core Daemon, also with system privileges. On macOS and Linux Synergy 3 runs as the logged-in user; on macOS, a login-screen component is added only when a user turns on Run on the login screen and enters an administrator password.
Vulnerability disclosure and security response
We operate a coordinated vulnerability disclosure process and publish our own security advisories, with CVE identifiers, the Synergy 1 versions affected, and the version each issue was fixed in: Synergy security advisories
That list is the authoritative record, and it is the one your vulnerability scanner reads.
Synergy 1's core input-sharing engine is an open source project we maintain, which publishes advisories of its own. Every one of those that affects Synergy 1 is mirrored to our list and restated with the Synergy 1 versions affected, so you do not need to cross-reference the two: our list is complete for Synergy 1, and the version numbers on it are Synergy 1 version numbers.
To report a security issue in Synergy 1 or Synergy 3, please use private vulnerability reporting so we can fix it before it becomes public: report a vulnerability
Please do not open a public issue for a security problem. We will acknowledge your report, keep you updated as we investigate, and credit you in the advisory when we publish unless you would prefer otherwise.
Code signing and supply chain
Synergy 1 and Synergy 3 release binaries for Windows and macOS are code signed so that customers can verify authenticity and integrity. Windows binaries and installers are signed with an SSL.com certificate, and macOS binaries are signed with an Apple Developer ID and notarized by Apple.
Synergy 1's core input-sharing engine is open source and available for independent review and audit. This means the most security-relevant part of the product can be inspected directly rather than taken on trust.
Compliance posture
SOC 2
Synergy 1 is on-premise software and is not a hosted service. It never receives or processes your data on our infrastructure, so there is no service environment for a SOC 2 audit to cover and no subprocessor chain to assess. We address security through this documentation and through the open-source auditability of the core engine rather than through a SOC 2 report. In our experience the reduced data footprint simplifies vendor security assessments.
Privacy
Because Synergy 1 does not capture screen contents, does not record keyboard input at its default settings, and does not route input through our servers, the personal data it handles is limited to what is required for licence activation, the business usage report and, where enabled, update checks, plus Synergy 3's error reports while they are turned on. Our privacy policy describes what we collect and how it is handled.
Vendor questionnaires
We can complete standard vendor security assessments, including HECVAT, and customer-specific questionnaires on request. This overview is written to map onto the questions those assessments ask.
Deploying across an organisation
For firewall scoping, locking configuration down centrally, disabling clipboard sharing across a data boundary, reducing the privileges the Windows service runs with, and deployment in regulated environments, see: Business & Enterprise Hardening Guide
Contact
For security documentation requests, vendor questionnaires, or to arrange a review call, contact sales@symless.com or support@symless.com.
To report a security vulnerability, please use private vulnerability reporting on the repository rather than email, so the report stays confidential until a fix is available: report a vulnerability