How to Uninstall SentinelOne When the Passphrase Is Missing

Learn how to remove the SentinelOne agent when Anti-Tampering blocks uninstallation. Covers remote console uninstall, per-agent passphrase retrieval, Windows/macOS/Linux commands, recovering orphaned agents from the decommissioned view, and the decommissioning order that prevents the problem.

Removing a SentinelOne agent requires a per-agent uninstall passphrase issued by the management console. If the console record still exists, retrieve it from Sentinels → select endpoint → Actions → Agent Actions → Show Passphrase, or issue a remote uninstall and skip the passphrase entirely. If the endpoint no longer appears in the console, check the decommissioned agents filter first — offline endpoints are hidden after the retention window, not deleted, and the passphrase is usually still recoverable.

An administrator clicks Uninstall in Programs and Features and nothing happens. Or the uninstall appears to complete and the agent is still running after reboot. Or a script that cleared fifty endpoints fails silently on the fifty-first.

None of this is a defect. Anti-Tampering is working. Disabling endpoint protection is an early step in most hands-on-keyboard intrusions, so the agent is built to resist removal — including by a local administrator with full rights on the machine. Authorisation has to come from the console.

The problem arises when that authorisation is gone, and the usual cause isn't an attack. It's an ordinary habit: cleaning up the console before cleaning up the endpoint.

This guide covers the supported removal paths, the recovery sequence for orphaned agents, and the process change that stops it recurring.

Also Read: Deploying the SentinelOne Windows Agent via Intune

How the Uninstall Authorisation Model Works

Three characteristics explain most field confusion.

Characteristic	Implication
Per-agent, not per-tenant	Every agent has a unique passphrase. A value from one machine will not work on another. Bulk scripts with a hardcoded passphrase fail everywhere except the test endpoint.
Stored console-side	The passphrase lives in the console record. The agent validates it but cannot reveal it. Delete the record and the authorisation goes with it.
Regenerated on upgrade	A passphrase exported six months ago may be invalid against the current agent build. Treat exported passphrases as perishable.

An account-level uninstall password is also available in the console — a single credential authorising removal across an account. Useful for large-scale decommissioning, and a high-value secret that deserves domain-admin-grade handling.

Prerequisites

SentinelOne Management Console access with a role permitted to view passphrases and issue uninstall actions
Local administrator rights on the target endpoint, for any local removal
The agent installer package, if using the msiexec method
Console scope covering the site the agent is registered to

Note: Show Passphrase is permission-gated. A read-only or restricted console role will not see the action — this is regularly misdiagnosed as the feature being unavailable in the tenant.

Path 1: Agent Is Online and Visible in the Console

This is the clean case and should be the default for every planned removal.

SentinelOne Management Console → Sentinels → select the endpoint → Actions → Uninstall

The console authorises internally. No passphrase changes hands, the action is logged against an identified user, and the agent record updates correctly. Nothing runs on the endpoint.

Use this whenever available. It avoids every failure mode described below. Local uninstalls should be the exception, not the routine.

Path 2: Endpoint Cannot Be Reached from the Console

Where the agent is offline or network-isolated, retrieve the passphrase and remove locally.

Step 1: Retrieve the Passphrase

Sentinels → select the endpoint → Actions → Agent Actions → Show Passphrase

Step 2: Run the Platform Command

Windows — elevated command prompt, using the agent MSI:

cmd

msiexec.exe /quiet /norestart /x <AgentInstaller>.msi UNINSTALL_KEY="<passphrase>"

Or the uninstaller inside the agent directory:

cmd

cd "C:\Program Files\SentinelOne\Sentinel Agent <version>"

uninstall.exe /uninstall /norestart /q /k "<passphrase>"

The agent directory is version-numbered, so any fleet script must resolve the path dynamically rather than assume a fixed build. A reboot is required to complete removal on Windows.

macOS — disable protection first, then uninstall:

bash

sudo sentinelctl unprotect --passphrase "<passphrase>"

sudo sentinelctl uninstall --local

Linux — issued through the full binary path:

bash

sudo /opt/sentinelone/bin/sentinelctl control uninstall --passphrase "<passphrase>"

Quarantined files: The --unquarantine flag restores quarantined files during removal. Without it, they are deleted permanently. This matters if the endpoint is going to forensics or if quarantined items are still under investigation.

Syntax varies across agent versions. Validate against your tenant's package documentation before automating.

Path 3: Endpoint Is Gone from the Console

Work through these in order before concluding the passphrase is unrecoverable.

1. Check the decommissioned agents view

This resolves most cases. Endpoints offline beyond the retention window are hidden from the standard Sentinels view rather than deleted. Open the Filters panel and enable the decommissioned agents filter. The record — and the passphrase — is usually still there.

2. Widen the search scope

A console user scoped to one site will not see an endpoint registered to another. Search at global or account scope, using hostname, agent UUID, serial number, and last known IP.

3. Check for an account-level uninstall password

If configured, it may authorise removal without the per-agent value.

4. Confirm which console owns the agent

An apparently orphaned agent is sometimes enrolled elsewhere — a previous MSP's tenant, a distributor's console, or a site moved during a restructure. If ownership has transferred, the outgoing party can issue the passphrase or run the remote uninstall. Raising this commercially is usually faster than any technical workaround.

5. Escalate to SentinelOne Support

Where the record is genuinely unrecoverable, have the following ready to shorten the ticket:

Information	Purpose
Tenant and account ID	Identifies the environment
Agent UUID or serial	Locates the agent record
Hostname	Cross-reference identifier
Approximate decommission date	Narrows the record search
Evidence of ownership	Required before a passphrase is issued

6. Last-resort local removal

SentinelOne documents a Safe Mode removal path in which the passphrase requirement is relaxed. It requires local administrator rights plus physical or out-of-band access.

Treat as a controlled exception. Raise an approved change record, log who performed it and on which asset, and confirm the endpoint is rebuilt or re-enrolled. An undocumented Safe Mode removal is operationally indistinguishable from an attacker disabling EDR — if it appears in telemetry without a paper trail, it should trigger investigation.

7. Rebuild

Where nothing above applies, reimaging remains reliable. On a machine already being decommissioned, this is often the pragmatic answer rather than the failure it feels like.

Removing Agents at Scale

Console-driven bulk uninstall handles most fleet-wide removals and should be the first choice.

Where local removal is genuinely required across many endpoints — a tenant migration, for instance — the management API exposes an agent passphrases endpoint returning per-agent values for agents matching a filter. The account-level uninstall password can also be retrieved via API.

Security: An export of every uninstall passphrase in the estate is one of the more sensitive artefacts your team will produce. Scope the API token tightly, store output in a secrets manager rather than a spreadsheet, and destroy it when the migration completes. Because passphrases regenerate on upgrade, retrieve them close to execution rather than months ahead.

Validation

Do not treat a silent exit code as success.

Windows: SentinelOne services and C:\Program Files\SentinelOne\ are gone after the required reboot
macOS / Linux: sentinelctl no longer responds and the agent daemon is not running
Console: endpoint status updates to reflect removal rather than continuing to report offline
Quarantine: if --unquarantine was intended, confirm restored files exist before wiping
Re-enrolment: the endpoint appears as a new agent record in healthy state

Common Issues and Troubleshooting

Uninstall exits silently but the agent is still present after reboot

Anti-Tampering rejected the request — usually a wrong, expired, or omitted passphrase. Re-retrieve from the console rather than reusing a stored value; passphrases regenerate on agent upgrade.

Bulk script works on the test machine and fails everywhere else

A single passphrase was hardcoded. Passphrases are per-agent. Use console-driven bulk uninstall, or retrieve per-agent values via the management API immediately before execution.

Show Passphrase is not visible in the console

Role-based permission restriction, not a missing feature. Have a suitably privileged console role perform the action, or adjust role permissions.

Endpoint cannot be found in Sentinels

Most often the agent has passed the offline retention window and sits in the decommissioned view. Enable the decommissioned agents filter, then search at global scope using UUID or serial as well as hostname.

Windows uninstall script fails with path not found

The agent directory is version-numbered (Sentinel Agent <version>) and the script assumes a static path. Resolve the directory dynamically at runtime.

Quarantined files missing after removal

The --unquarantine flag was omitted; quarantined items are deleted by default. Not recoverable post-removal — include the flag wherever an endpoint may be subject to investigation.

Prevention: Decommission in the Right Order

Nearly every lost-passphrase case traces to one inverted sequence:

Remove the agent from the endpoint — remotely from the console where possible
Confirm removal completed
Only then decommission the console record

The common error is doing step three first, because tidying the console is the visible task and the endpoint is already switched off in a store cupboard. The moment that record goes, so does the authorisation to remove the agent.

Three supporting practices:

Capture passphrases before storing offline assets. Into a secrets manager — not a shared drive or ticket comment — with the agent version noted alongside so you know whether it remains valid.
Put agent removal in the asset lifecycle runbook, alongside disk wipe, domain unjoin, and licence reclaim. When it lives only in an engineer's head, it gets skipped.
Reconcile the console against your CMDB. Agents in the decommissioned view that map to in-service assets are exactly the future orphans this article exists to prevent.

Security Considerations

An endpoint with the agent removed is an unprotected endpoint. The gap between removal and rebuild or re-enrolment routinely stretches from minutes into weeks, and machines have been quietly returned to production inside that window. Make the replacement control — reimage, re-enrol, or network isolation — part of the same change, not a follow-up task.

Protect the account-level uninstall password as you would a domain administrator credential. Scope API tokens narrowly and expire them when the work completes. Alert on Safe Mode removals, since the relaxed passphrase requirement makes it the technique an attacker with local access would reach for.

Anti-Tampering is inconvenient by design. The friction is the feature working. The objective is not to bypass it but to operate within it deliberately, so that the only people removing agents from your estate are the people who are supposed to be.

Dealing with orphaned agents, a tenant migration, or a large-scale decommissioning exercise? Talk to NetNXT →

FAQ

1) How do I find the SentinelOne uninstall passphrase?

In the management console, go to Sentinels → select the endpoint → Actions → Agent Actions → Show Passphrase. The value is unique to that agent and stored console-side, not on the endpoint.

2) Can you uninstall SentinelOne without the passphrase?

Yes. If the agent is online, issue a remote uninstall from Sentinels → Actions — the console authorises internally. An account-level uninstall password also works without the per-agent value.

3) Why does my SentinelOne uninstall passphrase no longer work?

Passphrases regenerate on agent version upgrades, so exported values expire. The other common cause is reusing one passphrase across endpoints — they are per-agent and never transferable.

4) I deleted the endpoint from the console. Can I still remove the agent?

Usually yes. Enable the decommissioned agents filter in Sentinels — endpoints past the retention window are hidden, not deleted. If genuinely absent, escalate to SentinelOne Support with the tenant ID, agent UUID, and proof of ownership.

5) How do you uninstall the SentinelOne agent on Linux and macOS?

On Linux, run sudo /opt/sentinelone/bin/sentinelctl control uninstall --passphrase "<passphrase>". On macOS, run sentinelctl unprotect first, then sentinelctl uninstall --local. Add --unquarantine to restore quarantined files.