We isolated the issue to the installed **Zoho QuickSupport** application.

On a fresh Windows 11 personal PC, using a separate personal Zoho Assist account, QuickSupport installs and launches normally. QuickSupport verifies its own signature successfully. When joining a session, QuickSupport downloads the current `Connect.exe` version `2026.8.17.0`, then fails with:

`Signature mismatch for Connect.exe`

The downloaded file is not corrupt. Its SHA-256 is:

`7bac0608d0ea0866a130878cb0976e7a9909f185e190953a4214df566f519f32`

That exactly matches the hash in Zoho's CDN filename.

Windows validates `Connect.exe` successfully:

* Signer: `ZOHO Corporation Private Limited`

* Digital signature status: `This digital signature is OK.`

* Certificate status: `This certificate is OK.`

* Signer thumbprint: `5f98d651693aad693f165f6b27896c0b51d4f2c6`

* Chain:

  `GlobalSign Root CA - R3`

  → `GlobalSign Code Signing Root R45`

  → `GlobalSign GCC R45 EV CodeSigning CA 2020`

  → `ZOHO Corporation Private Limited`

`QuickSupport.exe` is also validly signed, but with a different Zoho signing certificate:

* Signer thumbprint: `9cfe33a8a1fb933bedf943ef4263d03b6a5f828e`

* Chain includes:

  `GlobalSign GCC R45 CodeSigning CA 2020`

So the exact condition is:

**Windows accepts both `QuickSupport.exe` and `Connect.exe` as validly signed, but QuickSupport internally rejects the current `Connect.exe` with `Signature mismatch for Connect.exe`.**

The two executables are signed by different Zoho certificates/chains:

* `QuickSupport.exe` uses the non-EV GlobalSign code-signing chain

* `Connect.exe` uses the EV GlobalSign code-signing chain

This is reproducible on a fresh personal PC and separate personal Zoho Assist account, so it is not specific to our corporate Zoho configuration.