Written for Synergy 3 (v3.7.2) and Synergy 1 (v1.21.4), checked 3 October 2026.
For hardened and regulated environments we recommend Synergy 1, because only Synergy 1 can lock settings so users cannot change them. Synergy 3 is supported for business too, and its controls are in the Synergy 3 section of this guide. The other sections describe Synergy 1.
This guide is for Synergy Business and Synergy Enterprise deployments. It covers the controls available when deploying Synergy 1 or Synergy 3 across managed endpoints: network scoping, transport security, configuration lockdown, service privileges, and deployment in regulated environments. It is written for security architects and endpoint engineers.
For what Synergy 1 and Synergy 3 are, what data they handle, and how we disclose vulnerabilities, see: Security and Architecture Overview
Before you start
Deploy the current release. Security fixes ship in ordinary releases, so version currency is the single most effective control available to you. Advisories, with the versions affected and the version each issue was fixed in, are published here: Synergy security advisories
Audit for old builds before or alongside a new rollout. Long-lived installations are the usual problem, not new ones.
Threat model
Two things are worth being clear about before choosing controls.
Synergy 1 transmits no screen content, so it provides no visual feedback channel. An operator has to be physically in front of the monitors to use it, and a compromised link yields blind input injection at best, not remote control. This is a materially smaller exposure than a remote access tool.
The trust relationship runs both ways. A client accepts input, options and clipboard data from its server, so a client connecting to a server outside your control is taking a risk in the same way the server is. A threat model that only hardens the listening side is incomplete.
Network exposure and firewall scoping
The server opens a listening TCP socket and clients connect outbound to it. The default port is 24800, configurable through the core/port setting or the port field in the settings window.
- Scope inbound access by host, not by subnet. Permit connections to the listening port only from the specific client machines in that user's screen group. These are machines on one desk, so the permitted set is small, static and known.
- Deny the port at the network perimeter and between VLANs. Synergy 1 is designed for machines in one physical location. There is no legitimate reason for the port to be reachable across sites or from a remote network.
- Block it inbound from any untrusted or guest network.
- Synergy 1 needs no inbound access from the internet and uses no cloud relay.
Replace the installer's firewall rules. The Windows installer adds two Windows Firewall exceptions for the Synergy 1 core process, and they are not scoped to a port, an address range or a network profile. If you rely on the host firewall as a control, remove them after install and add your own scoped rule by policy.
Transport security
TLS is enabled by default, with TLS 1.2 as the enforced minimum and TLS 1.3 used where both machines support it. Older protocol versions are disabled and cannot be re-enabled.
Cipher suites are the OpenSSL defaults and are not configurable from Synergy 1. On Linux, Synergy 1 uses the system OpenSSL, so an environment that mandates a specific suite policy can apply it through the system OpenSSL configuration. The Windows and macOS builds ship their own OpenSSL, so a system-wide OpenSSL policy does not reach them.
Machines authenticate by certificate fingerprint rather than by a CA chain, so there is no PKI to integrate with. Three settings govern this, and all appear in the settings window.
| Setting | Settings window | Default |
|---|---|---|
security/tlsEnabled |
Enable TLS Encryption | On |
security/checkPeerFingerprints |
Require client certificates | On |
security/keySize |
Key length | 2048, with 4096 selectable |
Using your own certificate
Synergy 1 generates a self-signed certificate on first run and stores it at <settings path>/tls/synergy.pem. To supply your own, point security/certificate at your file, either through the Certificate field in the settings window or with tlsCertPath in the locked settings file.
The file must be a single PEM containing both the certificate and its private key. Synergy 1 reads the certificate and the key from that one path, so a certificate file without its key beside it will fail to load.
Supplying your own certificate does not change how peers authenticate. Synergy 1 pins peer identity to the certificate fingerprint and never validates a chain, so your internal certificate authority is not consulted and a CA-issued certificate earns no additional trust. Use your own certificate where policy requires you to control the key material, not to obtain chain validation.
Pre-seeding fingerprints
Trusted peers are recorded in two plain text files in the TLS directory (on Windows, always under C:\ProgramData\Synergy):
<settings path>/tls/trusted-servers
<settings path>/tls/trusted-clientsEach line takes the form v2:sha256:<hex digest>, with the digest in lowercase. Writing these during provisioning means users are never asked to make a trust decision, which removes the most likely place for a user to click through a warning. Contact your account manager before you build provisioning tooling around this file, and they will arrange for our engineers to confirm the format against the release you are deploying.
Where users do confirm fingerprints, tell them to treat an unexpected prompt on an established pairing as something to investigate rather than accept.
Clipboard sharing
Clipboard sharing moves user data between machines and is the control most likely to matter at a data boundary.
Disable it where machines sit on different sides of a security or validation boundary. It is a server option: in the Server Configuration window, untick Enable clipboard sharing (the size cap is Limit to:, in MB). In settings files the keys are:
| Key | Default | Effect |
|---|---|---|
internalConfig/clipboardSharing |
true | Master switch for clipboard forwarding |
internalConfig/clipboardSharingSize |
3072 (KiB, so 3 MiB) | Maximum payload; setting it to 0 disables sharing |
Editing the generated server configuration file by hand does not hold, because Synergy 1 rewrites that file from its own settings every time the server starts. Set it in the server configuration window, or lock it, as below.
File transfer and drag and drop between machines are not implemented, so there is nothing to disable there.
Logging
The default log level records no keyboard input, and writing logs to a file is off by default, with one exception: on Windows, the background service always writes the core's output to C:\ProgramData\Synergy\synergy-daemon.log, whatever the file logging setting says.
The most verbose diagnostic level records key identifiers, so a log captured at that level can contain what was typed. It is not the default and has to be deliberately selected, but in a managed estate it is a setting worth controlling rather than leaving open. The locked settings file below covers the log level along with everything else.
When file logging is switched on, the log is written to the user's home folder by default: C:\Users\<user>\synergy.log on Windows and ~/synergy.log on macOS and Linux. The Windows service log above is separate and is always on, so at the most verbose level it records key identifiers on disk; controlling the level matters most on Windows.
To fix the log level and keep file logging off across the estate, set these in the locked settings file:
[log]
level=INFO
toFile=falseThe levels, from least to most detail, are FATAL, ERROR, WARNING, INFO, DEBUG and VERBOSE. Only VERBOSE records key identifiers, so any level below it is safe from that point of view. Synergy 1 reapplies these two keys at every launch, so a user who raises the level or turns on file logging keeps that change only until the application next starts; the settings window does not grey these controls out.
If you collect logs centrally for support, set a policy on which level is acceptable and review captured logs before they leave the endpoint.
The Windows service and its privileges
On Windows, Synergy 1 installs a service running with system privileges so that input works on screens Windows protects, such as UAC prompts and the login screen. The service is installed on Windows only. On macOS and Linux, Synergy 1 runs entirely as the logged-in user with no privileged component.
Two settings reduce the privilege, and both are legitimate configurations where pre-login and secure desktop input are not needed.
| Setting | Effect | What is lost |
|---|---|---|
daemon/elevate set to false |
Service remains, but Synergy 1 runs as the logged-in user | Input on UAC prompts and the login screen |
core/processMode set to Desktop |
Service is bypassed entirely | The same, plus input before login |
The service is privileged by design, so the usual endpoint controls apply: restrict who can install or modify it, monitor for unexpected changes, and keep the version current.
Locking configuration down
Synergy 1 reads a locked settings file that you deploy and applies it over the user's own settings at every launch. The application never writes to the file. It greys out the TLS, certificate, key length, client certificate and clipboard sharing controls when the file sets them; other locked settings (the log level among them) stay editable during a session and are put back at the next launch. Locked settings are part of Synergy Business Advanced (previously Business Team) and Synergy Enterprise.
Lock the settings this guide recommends: TLS on, the key length you require, clipboard sharing off where a data boundary applies, and the log level and file logging covered above.
The file locations, the full list of lockable settings, the value rules and the permissions to set so users cannot edit the file are covered in: Lock down Synergy 1 settings so users cannot change them
One limit to plan around: the locked file is a control for standard users. A local administrator can still replace it, and pointing the server at an external configuration file or running the core process directly bypasses it. Restrict who can do those things on the endpoint by your usual means.
Packaging and deployment
| Platform | Format | Silent install |
|---|---|---|
| Windows | MSI | msiexec /i Synergy.msi /qn |
| macOS | DMG | Repackage as a PKG for Jamf or similar |
| Linux | DEB, RPM, Arch package and Flatpak | Your package manager's non-interactive mode |
Synergy 3 ships in the same formats, and on Linux it installs to /opt/Synergy. Neither MSI has custom properties for pre-seeding configuration or a serial key. For Synergy 1, deploy the locked settings file alongside the package. Fleet-wide steps, including the silent install command for each product, are covered in: Deploy Synergy 1 or Synergy 3 across your organization, including silent install on Windows
Default install locations
| Platform | Installed to |
|---|---|
| Windows | C:\Program Files\Synergy |
| macOS | /Applications/Synergy.app |
| Linux |
/usr/bin, placed by the package manager |
The macOS DMG needs wrapping for most managed deployment tools. Contact your account manager if this affects your rollout, and they can arrange a session with our deployment engineers to work through a packaging approach for your tooling.
- Deploy through your existing tooling rather than allowing individual installation, so version, configuration and licensing stay under central control.
- Licence centrally rather than through individual purchases, so entitlement and version currency can be tracked.
- Plan for your packaging window. Where a packaging and validation cycle runs for several weeks, make sure licence validity spans it, or apply the final licence key after deployment. Contact your account manager if your packaging window is tight, and licence validity can be arranged around it.
Synergy 3
Synergy 3 shares input over the same kind of TLS connection as Synergy 1, on TCP port 24800, and adds a background service that discovers your other computers and keeps their settings in step. Harden it with the settings below. Most of them apply to all of your computers at once: a change made on any computer reaches the others. Synergy 3 has no locked settings file, so a user who can open Synergy 3 can change these settings; where that matters, deploy Synergy 1.
Network
- Scope ports 24800 and 24802 the same way. 24800 carries keyboard and mouse input. 24802 carries the settings Synergy 3 keeps in step between computers (the screen layout, hotkeys, and the security and copy and paste settings), never keyboard, mouse or clipboard data.
- Turn off auto discovery where computers are added by hand. Synergy 3 announces itself on the local network with multicast DNS so your other computers can find it. Turn off Auto discover on the Screen layout page to stop it.
- Port 24803 listens only on the computer itself (127.0.0.1), between the Synergy 3 window and its service, so it needs no firewall rule.
The Windows installer adds two Windows Firewall exceptions, for synergy-core.exe and synergy-service.exe, not scoped to a port, an address range or a network profile. Replace them with your own scoped rules if you rely on the host firewall.
Encryption and verifying computers
On the Security page, keep TLS encryption (recommended) on (the default) and choose the Key length you require (4096 by default, 2048 selectable). Keep Only allow verified computers (recommended) on (the default): the primary computer then asks each computer for its certificate, and a person on each computer accepts the other before they connect. Accepted computers are listed under Other computers, where Forget removes one.
Copy and paste
Where computers sit on different sides of a data boundary, turn off Text and image copy and paste on the Copy & paste page. The setting applies to all of your computers.
Logging and error reports
Leave Log level on the Troubleshooting page at Info (the default) unless we ask for more detail. Debug 1 is the most verbose level of the shared input engine, which can record key identifiers, as in Synergy 1. Synergy 3 always writes its logs to files: C:\ProgramData\Synergy\logs on Windows, ~/Library/Logs/Synergy on macOS and ~/.local/state/Synergy on Linux.
Synergy 3 sends error and diagnostic reports to us by default. They include the computer's host name and the email address of the license. To stop them, turn off Send error and diagnostic reports on the Troubleshooting page on each computer.
Service and settings folder
On Windows, Synergy 3 installs a service, Synergy Core Daemon, running with system privileges so that input works on screens Windows protects, such as UAC prompts, and starts its background process (synergy-service.exe) for each user at sign-in. Where input on UAC prompts isn't needed, turn off Run as system to allow UAC interaction on the Miscellaneous page (under Advanced) so the input engine runs as the logged-in user. On macOS and Linux Synergy 3 runs as the logged-in user; the optional macOS login-screen agent is added only when a user turns on running on the login screen and enters an administrator password.
On Windows, Synergy 3 keeps one set of settings for the whole computer in C:\ProgramData\Synergy, including the serial key and the computer's certificate, and its installer gives every local user full control of that folder. On a computer shared by several people, any of them can change Synergy 3's settings or read those files.
Regulated environments
Synergy 1 is deployed in healthcare, pharmaceutical and financial services, and what makes it work in those environments is how little crosses between the machines. With clipboard sharing disabled, there is no file transfer, no screen content and no clipboard. The only thing travelling between the two computers is keyboard and pointer input, over an authenticated TLS connection between two named machines. That is a far narrower and more easily described path than a shared drive, a remote desktop session or a removable device.
Build the deployment around that property.
- Decide the boundary first, then configure to it. Where the machines sharing a keyboard sit on different sides of a security or validation boundary, disable clipboard sharing and lock it in the locked settings file. Input is then the only thing that can cross, and a user cannot re-enable the rest.
- Describe the path explicitly in your assessment. An assessor will want to know what can move between the two systems. With the configuration above, the answer is short enough to state in a sentence, which is usually the difference between a quick sign-off and a long conversation.
- Treat the crossing as an approved interface. Where a boundary is one your policy treats as absolute, use Synergy 1, keep the server on one side and document the interface as you would any other, with the same review and sign-off. Your account manager can arrange a technical review with our engineers to work through your specific topology and the controls that fit it.
- Put Synergy 1 through change control like any other installed software. On a validated workstation it changes the validated state, so it goes through your normal qualification, and each upgrade is a change in its own right. Record the version you deployed on each machine, because that is what you check an advisory against when one is published.
Getting help
For deployment questions, vendor security assessments, or to arrange a review call, contact sales@symless.com or support@symless.com.
To report a security vulnerability, use private vulnerability reporting rather than email: report a vulnerability