Skip to main content
Uninstalling is deliberately a full reset, not a “leave it lying around” removal. The agent reverses every system change it made, drops the enrollment, and removes the local state, so a later reinstall starts clean rather than silently resurrecting an old device identity. This is the mirror of Installing the agent.
A device that is uninstalled stops being protected the moment the service stops. Nothing leaving that machine is inspected afterwards. Uninstall on a managed fleet is a change worth scheduling, not one worth doing ad hoc.

​
Who can uninstall

The Windows agent runs as a LocalSystem service and the macOS agent runs a root guardian, so removal requires administrator rights on the device. A standard employee cannot uninstall it, and an attempt to disable protection without those rights is reported as a tamper event rather than silently succeeding. Attempts that do reach the machine (the root CA removed, the proxy configuration reverted, the interceptor killed) are recorded as high-severity, hash-chained entries in the audit trail and surface on the device row in Endpoint → Devices.

​
Uninstall codes

A workspace decides whether removing the agent needs permission. The setting is the uninstall mode, and it applies to every device: Under enforce, a plain msiexec /x exits with 1603 and the agent stays in place. There are two ways to allow a removal:
  • A code. Issue a one-time code for one machine, or a code that works on every machine in the workspace, and pass it to the uninstall:
    A code is shown once when it is issued and is not written to the installer log. A per-machine code works once. An unused code can be withdrawn.
  • An authorization pushed to chosen machines. The platform tells those devices that a removal is approved, so the uninstall command needs no code. This is the one to use from an MDM. Pushing an authorization is an API call today (POST /api/runtime-security/agent/devices/uninstall-authorizations).
Issuing a code for one machine needs endpoint.devices.uninstall_code. Issuing a workspace-wide code, pushing an authorization, and changing the mode need endpoint.devices.uninstall_code_workspace. Admin holds both by default. Every issue, withdrawal and mode change is recorded in the audit trail, and a mode change takes about three minutes to reach the devices. See Endpoint permissions.
The mode only takes effect once the platform has a signing key for codes. Without one the devices are told the mode is off, because a device must never be told to demand a code that nobody can issue. Going to enforce adds an “Update MDM uninstall scripts” item to your Pending actions.
A removal under enforce, or any removal that used a code or an authorization, reports itself to the console, marks the device as uninstalled, and frees its seat. Under off the console is not told: the row stays active and keeps its seat until you revoke it.

​
Uninstall on Windows

​
Interactively

Settings → Apps → Installed apps → the Blindsight entry → Uninstall, or the same entry in Programs and Features. Run it as an administrator.

​
Silently

If you no longer have the original MSI, uninstall by product code. The product code changes whenever the agent updates itself, so look it up from the stable UpgradeCode rather than hardcoding it. A stale code fails with 1605.
Push either form through Intune, GPO, or SCCM the same way you pushed the install.
An upgrade is not an uninstall, even though the MSI technically removes the old product first. The installer distinguishes the two: a major upgrade keeps enrollment, the CA, the pseudonymization vault, the undrained event spool, the user’s sign-in, and their settings. A real uninstall keeps none of it.

​
What a Windows uninstall does, in order

  1. Stops and deletes the BlindsightDLP service.
  2. Restores the system proxy, WinHTTP proxy, proxy environment variables, browser policies, and firewall rules from the snapshot taken at install time. This runs after the service stops, so the guardian cannot re-apply the configuration it is trying to remove.
  3. Removes the per-machine inspection root CA from the machine trust store, matched by SHA-1 thumbprint, and deletes the on-disk CA material.
  4. Terminates anything still running: the desktop app, stray agent processes, and the local inspection proxy.
  5. Removes the HKLM autostart value and both scheduled tasks (\Blindsight\ServiceGuard, \Blindsight\ConnectivityGuard), then the \Blindsight\ task folder itself. Left behind, ServiceGuard would keep trying to start a service that no longer exists.
  6. Deletes %ProgramData%\Blindsight in full, including the device enrollment record and the pseudonymization vault.
  7. Deletes .blindsight from every user profile on the machine, plus the LocalSystem profile at %WINDIR%\System32\config\systemprofile\.blindsight, which is where the service’s own CA private key and log live.
  8. Removes the program files.
Every step is best-effort and idempotent, so a partially broken install still uninstalls cleanly rather than failing halfway.

​
Uninstall on macOS

Every macOS disk image carries Uninstall Blindsight.command. It is the supported way to remove the agent.
1

Run the uninstaller

Open the disk image and double-click Uninstall Blindsight.command. It opens in Terminal and asks for an administrator password itself. From a shell:
Run it from the account of the person who uses the Mac. The per-user state it removes belongs to the account that started it.
2

Read the verification it prints

The uninstaller reports each step as removed or absent, then checks that no agent process is left running.
Dragging the app to the Trash is not an uninstall. It leaves the inspection certificate trusted and the network services pointed at a proxy that no longer answers.

​
What a macOS uninstall does, in order

  1. Stops and removes the root guardian LaunchDaemon first, because its job is to put back what it finds missing.
  2. Stops and removes the login item.
  3. Stops anything still running, including the whole-device lane when it is on.
  4. Restores each network service’s automatic proxy to what it was before the agent’s first run. A setting is only touched while it points at the agent, so a company PAC or proxy survives the uninstall.
  5. Restores the Firefox policy file that was there before, or removes the agent’s own.
  6. Removes pf rules left by agent versions that used them.
  7. Removes the inspection root CA from the login and System keychains, and from any JDK trust store.
  8. Removes /Applications/Blindsight Mac.app.
  9. Removes ~/.blindsight and /Library/Application Support/Blindsight, including the sign-in, the local event store and the pseudonymization vault.
  10. Ejects the mounted installer image.

​
Retire the device in the console

Uninstalling clears the device end. It does not remove the row.
1

Revoke the device

Endpoint → Devices, find the machine, revoke it. Its enrollment credential stops being accepted, so a copied credential file cannot be used to impersonate the device.
2

Decide about its events

Events the device already sent stay in the workspace. They are evidence, and retiring hardware is not a reason to lose the record. Retention is governed by your workspace settings, not by the device.
3

Rotate the token if the machine was lost

If the device was lost rather than decommissioned, mint a new enrollment token and revoke the old one. See Fleet rollout.

​
What you lose

A genuine uninstall permanently destroys the pseudonymization vault on that device (pseudonym_vault.db and vault.key). The vault holds the only mapping from a surrogate back to what the person actually typed. Once it is gone, every past conversation on that device is left showing a realistic stand-in that can never be resolved again, and nothing can recover it.If you need those mappings, resolve or export what you need before you uninstall.
Also gone from the device, and not recoverable from it:
  • The local event store and anything in the spool that had not yet reached the platform.
  • The device’s enrollment identity. A reinstall enrols as a new device with a new row.
  • Local agent logs, which is worth remembering if you are uninstalling to resolve a support case. Collect them first.

​
Common workflows

  1. Resolve anything you still need from the vault.
  2. Uninstall on the device (msiexec /x, or the macOS teardown).
  3. Revoke the device row in Endpoint → Devices.
  4. Leave its events in place. They stay as evidence.
  1. Point the MDM’s uninstall command at the pilot smart group.
  2. Watch Endpoint → Devices until every device in the group stops reporting.
  3. Revoke the pilot enrollment token so nothing re-enrols against it.
  1. Uninstall, which is safe to run even against a half-installed agent.
  2. Confirm %ProgramData%\Blindsight is gone. Its presence is what makes a reinstall silently re-adopt the old enrollment.
  3. Install again with CLOUD_BASE and ENROLL_TOKEN passed explicitly.
  4. Delete the stale device row in the console. The reinstall creates a new one.
They cannot, and that is the design. Route the request to whoever owns the endpoint policy. If the machine genuinely should not be protected, remove it through the MDM rather than by granting local admin rights.

​
See also

Installing the agent

Packages, silent install, and what it changes on the device.

Devices

Revoking a device, health, and tamper events.