Revised 21 September 2026. Applies to Synergy 1.21.
This guide covers Synergy 1. It does not apply to Synergy 3, which has a different configuration and deployment model. For hardened and regulated environments we recommend Synergy 1.
This guide covers the controls available when deploying Synergy 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 is, what data it handles, 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 Synergy 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 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 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 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 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 platform OpenSSL defaults and are not configurable from Synergy. An environment that mandates a specific suite policy has to apply it through the system OpenSSL configuration.
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 certificate | On |
security/keySize |
Key length | 2048, with 4096 selectable |
Using your own certificate
Synergy 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 TLS 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 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 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 beside the settings file:
<settings path>/tls/trusted-servers
<settings path>/tls/trusted-clientsEach line takes the form v2:sha256:<hex digest>. 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 rather than an application setting, so it lives in the server configuration.
| Key | Default | Effect |
|---|---|---|
clipboardSharing |
true | Master switch for clipboard forwarding |
clipboardSharingSize |
3 MiB | Maximum payload; setting it to 0 disables sharing |
Editing the generated server configuration file by hand does not hold, because Synergy 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.
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 writes its own log beside the system settings file.
To fix the log level and keep file logging off across the estate, set these in the locked settings file:
[General]
logLevel2=INFO
logToFile=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. Locking these two keys means a user cannot raise the level or redirect the log to a file of their choosing.
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 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 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 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 reads a locked settings file that you deploy, applies it over the user's own settings at every launch, and greys out the controls it covers. The application never writes to the file, and a standard user cannot override a setting it contains. Locked settings are enforced on Business Team and 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 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 and RPM | Your package manager's non-interactive mode |
There are no custom MSI properties for pre-seeding configuration. Deploy the locked settings file alongside the package. Fleet-wide Windows steps are covered in: Synergy Business Silent & Automated Deployment (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.
Regulated environments
Synergy 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, keep the Synergy 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 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