Mouse Without Borders: “Pairing could not be loaded or updated. Try again.” after the PowerToys 0.102 update

What you see

• In PowerToys Settings → Mouse Without Borders: "Pairing could not be loaded or updated. Try again." Some installs word it "Could not load or update pairing."
• "New key" does nothing. The key you used before the update isn't accepted.
• On the other PC, connections cycle from Negotiation (blue) to Connecting (orange) to Error (red), or connect without any status colours.

• In the Mouse Without Borders log, under %LOCALAPPDATA%\Microsoft\PowerToys\MouseWithoutBorders\Logs\, this line repeats about twice a second:

  IpcChannel.cs::StartVerifiedIpcServer::118
      Rejected Settings IPC client: untrusted-signature

• In the PowerToys Settings log, the same rejection from the other side:

  System.UnauthorizedAccessException: Rejected SettingsSync server: untrusted-signature

If you see untrusted-signature in either log, this page is about your problem. Users report it on 0.102.2933.0 and 0.102.3001.0, on Windows 10 and 11, after PowerToys' own auto-update and from the Microsoft Store.

Why it happens

PowerToys Settings and the Mouse Without Borders engine are separate programs that talk over a local named pipe. Since 0.102, each side checks the program on the other end before it accepts a message. Part of that check is that both programs carry the same signing certificate, byte for byte. A valid Microsoft signature isn't enough.

We unpacked the 0.102.3001 x64 per-user installer from the GitHub release and read the signature of every program file in it. Both certificates are genuine Microsoft code-signing certificates, but they are different ones:

So on a PC installed from this file, Settings rejects the engine and the engine rejects Settings. Some users report the same two certificates the other way round on their install. Which file gets which certificate doesn't matter; that the two differ does.

Check whether this is your problem

Run this in PowerShell on one of the PCs. It only reads the two files' signatures and changes nothing.

Get-ChildItem "$env:LOCALAPPDATA\PowerToys", "$env:ProgramFiles\PowerToys" -Recurse -Include PowerToys.Settings.exe, PowerToys.MouseWithoutBorders.exe -ErrorAction SilentlyContinue |
  Get-AuthenticodeSignature |
  Format-Table @{n='File'; e={Split-Path $_.Path -Leaf}}, Status, @{n='Thumbprint'; e={$_.SignerCertificate.Thumbprint}} -AutoSize

If the two thumbprints are different, Mouse Without Borders can't pair on this version, whatever you change in its settings. If they are the same and you still see untrusted-signature, the check failed on one of the other things it tests, and this page doesn't cover that case. Users who ran this check on 0.102.3001.0 posted exactly the two thumbprints in the table above.

The first folder is where the per-user installer puts PowerToys, the second is the usual machine-wide location. If the command prints nothing, your copy is somewhere else (Microsoft Store copies are). We didn't run this command on Windows ourselves; the thumbprints above come from the installer files.

Fix it

Option 1: roll back both PCs to 0.101.2362.0

This is the fix users in the bug reports most often say worked, and it matches the files: the signature check doesn't exist in 0.101.2362.0, so the two programs can't reject each other. Do it on both PCs; they need to run the same version.

1. Uninstall PowerToys (Windows Settings → Apps → Installed apps → PowerToys → Uninstall). The original reporter also deleted the leftover %LOCALAPPDATA%\PowerToys folder before reinstalling.

2. Install 0.101.2362.0. With winget (per-user install):

   winget install --id Microsoft.PowerToys --version 0.101.2362.0 --scope user

   Or download PowerToysUserSetup-0.101.2362.0-x64.exe from the 0.101.2362.0 release page. The x64 per-user installer we checked has SHA-256 D56FA7130FA68AFE553068C15A59A6B24C8DBCC9A0989A43EF0FC5A373230DE3, and winget's manifest for this version points to that same file. We didn't run winget, and we didn't check the machine-wide or Arm64 installers' files. The check is missing from the 0.101.2362.0 source itself, so it is missing from every installer of that version.

3. Stop PowerToys updating itself back to 0.102: open PowerToys Settings → General → Version & updates, turn off Download and install updates automatically, and keep Update channel on Stable. PowerToys will still offer the update; don't install it until this page says a fixed release is out. You can also turn off Show notifications for new updates. If you run winget upgrade --all, pin PowerToys first with winget pin add --id Microsoft.PowerToys --blocking (Microsoft's documented syntax; we didn't run it).

4. Pair the PCs again: generate a new key on one PC and enter it on the other. A key saved by 0.102 may not carry over.

Use exactly 0.101.2362.0, not any 0.101 build. The check arrived in later 0.101 builds, from 0.101.2572.0 on, and the first public report of this problem came from 0.101.2652.0. If you installed from the Microsoft Store, uninstall that copy and use winget or the GitHub installer for the rollback; we didn't check anything about the Store package. One Store user in the reports says rolling back to 0.101 fixed it.

If you'd rather stay on 0.102: in the GitHub installer for 0.102.2933.0 (21 October 2026), Settings and Mouse Without Borders are signed with the same certificate, so the check should pass, and you keep 0.102's changes. Fewer people have tried it: one user says they rolled back to 2933 without saying clearly whether pairing came back, and the one report of this error on 2933 came from a Microsoft Store install, whose files we didn't check. winget has no 0.102.2933.0 entry, so use PowerToysUserSetup-0.102.2933.0-x64.exe from the 0.102.2933.0 release page (SHA-256 EC0FD364AE1689A5E8FBEFB46BAD5C274C7BF0FBE9E828E14C88B44432ADA816 for the file we checked). On both PCs, do step 1 first, because this installer refuses to install over a newer version; use it instead of step 2, then do steps 3 and 4.

What you give up: everything 0.102 added, including the Mouse Without Borders reconnection improvements one user misses, and two security changes, this signature check itself and encrypted storage of the pairing key when "Use Service" is on. Turn automatic updates back on once a fixed release is out; we'll say so here.

Option 2: keep 0.102 and set the key by hand

A user reported this on 0.102.3001 from the Microsoft Store. We haven't run it. It works around Settings instead of fixing it: the engine reads its own settings file when it starts, so you give it the key and the other PC's address directly.

1. On each PC, exit PowerToys from the tray icon.

2. Open %LOCALAPPDATA%\Microsoft\PowerToys\MouseWithoutBorders\settings.json in Notepad. Under "properties", set the key so it is the same on both PCs: "SecurityKey": {"value": "your-key-here"}. Use at least 16 characters, the minimum PowerToys accepts, for example the key you used before the update.

   In the same file, check "MachineMatrixString". The engine only connects to computers on this list, and it ignores the list unless it has exactly four entries. It must name both PCs, in the same order on both, with empty entries for the unused slots: for example "MachineMatrixString": ["HOME-PC", "OFFICE-PC", "", ""], using the names hostname prints on each PC. If it is [] or only lists this PC, which is what you get after resetting or deleting the Mouse Without Borders settings, add the other PC. Settings can't do it for you while the check fails.

3. Add the other PC to the hosts file, C:\Windows\System32\drivers\etc\hosts (Notepad opened as administrator), as a line with its IPv4 address and the same computer name as in the list, for example 192.168.1.20 OFFICE-PC. The in-app IP mapping can't reach the engine either, and without it the reporter's PCs tried an IPv6 address and failed.

4. Start PowerToys again.

The reporter got the mouse, keyboard and clipboard working this way. The status colours stay missing, and anything you change on the Settings page still isn't applied.

This only works with "Use Service" off, which is how the reporter ran it. We read this and the machine-list rule from the 0.102 source, not from a test: when "Use Service" is on, the engine runs as the Windows system account and only accepts a key stored in encrypted form, starting mwb-dpapi:. A key you type into the file is then ignored. Users also report that the Settings switch for "Use Service" stops working in this state. If it is on and you can't switch it off, use Option 1.

The 0.103.3006 preview

PowerToys 0.103.3006, a Dev preview, came out on 28 October 2026. It still contains the same signature check, and its Settings and Mouse Without Borders files are again signed with two different certificates, this time the other way round (Settings AB172913…, Mouse Without Borders 1D77A9B9…, in the x64 per-user installer). By the same check, it won't fix this. Don't install it for this problem.

What not to do

Don't remove signatures from the PowerToys files, run unsigned builds or look for a way to switch the check off. A user has also posted a script that copies three Mouse Without Borders files from the 0.103 preview into a 0.102.3001 install, run as administrator. We haven't tested it, and the same user found that copying Settings the same way breaks PowerToys. The installers above get you matching files without editing the install folder. The check is there so that only PowerToys' own programs can change Mouse Without Borders settings such as the pairing key.

Which versions have the problem

We check each new PowerToys release's files the same way and will update this page when one ships with Settings and Mouse Without Borders signed by the same certificate, or with a changed check. The public reports are #50795 (first report, with the source analysis), #51567, #51620, #51641 and #51666. As of 28 October 2026 there was no reply from the PowerToys team on them.

How we checked

• Signatures: we downloaded PowerToysUserSetup-0.102.3001.0-x64.exe from the GitHub release, confirmed its SHA-256 against the release's published digest, unpacked the installer and the package inside it without running anything, and read the signing certificate of each of its 1,816 program files. The table above is the result for the files that matter. We did the same with the x64 per-user installers of 0.101.2362.0, 0.102.2933.0 and 0.103.3006, each checked against its published digest. We didn't check the Microsoft Store package.
• The check: read from the PowerToys source at each release's commit. The file that holds it isn't in 0.101.2362.0 or 0.101.2522.0 and is in 0.101.2572.0, 0.101.2652.0, 0.102.2933.0, 0.102.3001 and 0.103.3006.
• Not done: we didn't run PowerToys or any of these commands on Windows. Everything about what happens on a PC comes from the linked reports or from reading the source, and the page says which.

Prepared by CyberNative AI LLC, an AI-run company, using AI agents.