SentinelOne Agent Offline: Firewall Block or Broken Registration?
Reach 50,000+ security professionals
Sponsor a newsletter slot and put your brand in front of CISOs, engineers, and IT decision-makers.
A SentinelOne agent that shows offline or not reporting in the management console is one of the most common operational tickets an EDR team handles, and one of the easiest to mishandle by guessing at a fix instead of isolating the failure first. The console's offline status is a single signal that can be produced by two structurally different problems: a network path failure (something between the endpoint and SentinelOne's cloud is blocking the connection) or a broken local registration (the agent itself has lost its binding to its site, usually from an invalid certificate or a corrupted install). Applying a network fix to a registration failure, or vice versa, wastes a ticket cycle and leaves the endpoint unprotected for longer than necessary.
This guide walks through the diagnostic sequence that separates the two causes, the specific fix for each, how to validate the fix actually held, and the point at which the issue belongs with SentinelOne support rather than continued local troubleshooting.
If this is happening across a batch of endpoints right after a rollout, check the deployment process itself before working through this guide endpoint by endpoint; a systemic deployment gap produces the same offline symptom on many hosts at once, and the fix is different from a one-off failure.
What offline actually means, and the two root causes behind it
SentinelOne's management console marks an agent offline when it misses its expected check-in window with the cloud management plane. That status alone does not tell you why the check-in stopped, and treating every offline agent as the same problem is the most common troubleshooting mistake. In practice, the vast majority of offline agents fall into one of two buckets.
The first and by far the more common cause is a local firewall or network control blocking outbound HTTPS traffic on port 443 to the SentinelOne management domain. This includes host-based firewalls, network perimeter firewalls, corporate web proxies, and any TLS-inspection or SSL-decryption appliance that breaks the agent's certificate-pinned connection.
The second cause is a broken local agent registration: the agent process is running, but its binding to the management site has failed or been lost. This shows up as empty management-server and site configuration values on the endpoint, or as a certificate-related error in the local event log, and it happens after certificate expiration, a botched uninstall or reinstall, or an install that never completed the site-bind step.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Diagnostic sequence: isolate the cause before changing anything
Do not guess. Run this sequence on the affected endpoint, or have the end user run it under your remote guidance, before touching firewall rules or reinstalling the agent. It takes under ten minutes and tells you definitively which of the two buckets you are in.
Start in the console: check the agent's last-seen timestamp and the site or group it is assigned to. A last-seen time of days or weeks, combined with a device the CMDB shows as active, points to a persistent problem rather than a transient blip.
On the endpoint itself, open an elevated command prompt (Windows) or terminal (macOS/Linux) in the SentinelOne agent's install directory and check the agent's own view of its connection state. On Windows, run sentinelctl status from the Sentinel Agent folder under C:\Program Files\SentinelOne\ and review the Protection and Infected fields, then check sentinelctl config server.mgmtServer and sentinelctl config server.site. If either value returns empty, the agent has lost its site binding, which points to a registration failure rather than a network problem. On macOS, sudo sentinelctl status should show Connected: on; on Linux, sudo sentinelctl management status should show Connectivity: On with a valid SentinelOne URL populated.
If the mgmtServer and site values are populated but the agent still will not check in, test raw network reachability independent of the agent: run Test-NetConnection -ComputerName <your-management-console-URL> -Port 443 in PowerShell, or telnet <management-console-URL> 443 from an elevated prompt (the Telnet client may need to be enabled first via Turn Windows features on or off). A connection failure here confirms a network or firewall block. A successful connection with the agent still failing to check in, combined with empty config values, points back to registration.
On Windows, also check Event Viewer under Applications and Services Logs > SentinelOne > Operational for Event ID 5, which is associated with a registration failure caused by an invalid certificate or connection issue. Its presence corroborates a registration-side fix rather than a network-side one.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Fixing a confirmed network or firewall block
Once the diagnostic sequence confirms the agent cannot reach the management console over the network, the fix is entirely on the network and firewall side; do not touch the agent's local registration.
Allowlist outbound HTTPS (port 443) to the SentinelOne management domain at every layer the traffic passes through: host-based firewall (including third-party endpoint firewalls that predate the EDR deployment), the network perimeter firewall, and any web proxy the endpoint routes through. Confirm the exact management console URL for your tenant rather than assuming a generic wildcard covers every required subdomain; pull the specific URL from your SentinelOne console's site configuration.
If the environment uses SSL/TLS inspection or decryption on outbound traffic, exclude the SentinelOne agent's traffic from inspection. SentinelOne's agent uses certificate pinning for its management connection, and a decrypting proxy that re-signs the certificate with its own CA will break the handshake even though the destination and port are correctly allowed. This is one of the most common false negatives in this kind of troubleshooting: the firewall rule looks correct, the port is open, and the connection still fails because inspection is rewriting the certificate.
After updating the allowlist or inspection exclusion, do not wait for the agent's natural heartbeat interval to confirm the fix. Force a reconnect attempt with sentinelctl reload -m -a to restart the agent's services and re-test the connection immediately.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Fixing a broken local agent registration
When the diagnostic sequence shows a reachable network path but an empty or invalid site binding, or a logged Event ID 5, the fix is local to the endpoint and does not require any firewall change.
First, confirm the agent build is current. Older agent versions can run into TLS-negotiation problems against the current management console; if the endpoint is on a version several releases behind current, plan an upgrade rather than repeatedly troubleshooting a registration that may simply be failing a modern TLS handshake.
If the version is current and the mgmtServer/site values are empty, re-bind the agent to its site using a fresh site token generated from the console rather than reusing an old one, since a token tied to a rotated or deleted site will fail silently. If the bind command fails repeatedly against a fresh token, the local install itself is likely corrupted rather than simply unbound. In that case, uninstall the agent using the passphrase generated in the console for that endpoint (SentinelOne agents are protected against unauthorized local uninstall, so this passphrase is required) and reinstall the current package rather than continuing to attempt repairs on a damaged install.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Validating the fix
Do not close the ticket on the first successful check-in. Confirm the fix from both sides and watch it hold across at least one full heartbeat cycle before treating it as resolved.
On the endpoint, re-run sentinelctl status (or the platform-appropriate equivalent) and confirm the management-server and site values are populated and the connection indicator shows connected. In the console, confirm the agent's last-seen timestamp has updated to the current time and that it has returned to its expected site and policy group; a rebind performed against the wrong site token can silently move an endpoint to the wrong group, which is worth a manual check rather than an assumption.
For a network-side fix specifically, wait through at least one full check-in interval rather than relying on the single forced reconnect from sentinelctl reload -m -a. An intermittent proxy failure or a firewall rule that only partially covers the required destinations can produce one successful check-in followed by another drop, and that pattern only shows up if you watch past the immediate fix.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Failure cases and when to escalate to SentinelOne support
Some offline agents will not resolve through the steps above, and continuing to cycle through the same diagnostic sequence past that point wastes time that is better spent collecting a diagnostic bundle for vendor support.
Escalate when the network path tests clean, the agent shows a valid site binding, and it still fails to check in after a reinstall; when the same endpoint drops offline again within a day or two of a confirmed fix, suggesting an intermittent cause the local diagnostics cannot isolate; or when the Event Viewer or agent logs show an error code that is not one of the two causes covered here.
Before opening a ticket, collect the agent's diagnostic log bundle so the vendor is not starting from zero. On Windows, run LogCollector.exe from the Tools subfolder inside the SentinelOne agent's install directory (C:\Program Files\SentinelOne\Sentinel Agent <version>\Tools) with a working directory argument, which packages the agent's logs into a compressed bundle. On macOS, sudo sentinelctl logreport generates a similar bundle on the desktop; on Linux, sudo sentinelctl log generate followed by a target path does the same. The console itself can also pull a bundle remotely for an online-but-misbehaving agent via Actions > Troubleshooting > Fetch Logs, which is useful when the endpoint is intermittently reachable rather than fully offline.
Include in the support ticket: the agent version, OS and build, the exact connectivity test results from the diagnostic sequence above, whatever event ID or error text appeared in the local logs, and the collected log bundle. A ticket that already shows the network path was tested and the local config was checked resolves faster than one that starts with 'the agent shows offline.'
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
The bottom line
An offline SentinelOne agent is a two-branch problem disguised as a single console status: a blocked network path or a broken local registration, and the fix for one does nothing for the other. The sentinelctl status and config output, together with a direct port-443 connectivity test to the management console, checked before any change is made, tell you which branch you are on in under ten minutes. If the exercise has you reconsidering the platform entirely rather than just fixing today's ticket, the CrowdStrike vs. SentinelOne comparison and best EDR platforms guide cover that decision separately from this one.
Frequently asked questions
Why does a SentinelOne agent show offline in the console while the process appears to be running on the endpoint?
The console's offline status only means the agent missed its expected check-in window with the SentinelOne management plane; it does not distinguish why. The two most common causes are a network or firewall path blocking outbound HTTPS (port 443) to the SentinelOne management domain, and a broken local registration where the agent has lost its binding to its site, usually from an invalid certificate, a corrupted install, or an incomplete site-bind step. Running sentinelctl status (or the platform equivalent) on the endpoint and checking whether the management-server and site configuration values are populated tells you which of the two you are dealing with before you change anything.
How do I tell whether a SentinelOne agent is offline because of a firewall block or a broken registration?
Run sentinelctl status (Windows and macOS) or sentinelctl management status (Linux) on the endpoint first. If the management-server and site values are empty, the registration is broken regardless of network state. If those values are populated, test raw connectivity to the management console independently of the agent using Test-NetConnection -ComputerName <management-console-URL> -Port 443 in PowerShell or telnet on port 443. A failed connection test with populated config values points to a network or firewall block; a successful connection test with empty config values points to a broken local registration.
What Windows Event ID indicates a SentinelOne agent registration or certificate failure?
Event ID 5, logged under Applications and Services Logs > SentinelOne > Operational in Windows Event Viewer, is associated with a SentinelOne agent registration failure caused by an invalid certificate or a connection issue during the registration handshake. Its presence, combined with empty management-server and site configuration values from sentinelctl config server.mgmtServer and sentinelctl config server.site, points to a registration fix (re-binding or reinstalling the agent) rather than a firewall or network change.
How do I test whether a firewall or proxy is blocking a SentinelOne agent's connection to the management console?
From an elevated command prompt or PowerShell session on the endpoint, run Test-NetConnection -ComputerName <your-management-console-URL> -Port 443 (or telnet <management-console-URL> 443, enabling the Telnet client first if needed) to test raw TCP reachability independent of the SentinelOne agent itself. A failed connection confirms a network-side block: check the host firewall, the network perimeter firewall, and any web proxy the endpoint routes through, and specifically check whether SSL/TLS inspection is re-signing the certificate on the SentinelOne management connection, since certificate pinning breaks that handshake even when the port is technically open.
How do I re-register or rebind a SentinelOne agent that has lost its connection to its management site?
First confirm the agent build is current, since older versions can run into TLS-negotiation failures against the current management console. If the version is current and sentinelctl config server.mgmtServer or server.site returns empty, generate a fresh site token from the SentinelOne console (an expired or rotated token is a common silent cause) and run the bind command against it. If binding still fails against a fresh token, the local install is likely corrupted: uninstall using the console-generated passphrase for that specific endpoint and reinstall the current agent package rather than repeating bind attempts against a damaged installation.
When should I escalate a SentinelOne offline agent issue to vendor support instead of continuing to troubleshoot locally?
Escalate when the network connectivity test to the management console succeeds, the agent shows a valid site binding, and it still will not check in after a clean reinstall; or when the same endpoint drops offline again within a day or two of a confirmed fix, which suggests an intermittent cause the local diagnostic sequence cannot isolate. Before opening the ticket, collect the agent's diagnostic log bundle (LogCollector.exe on Windows, sentinelctl logreport on macOS, sentinelctl log generate on Linux, or Actions > Troubleshooting > Fetch Logs from the console for an intermittently reachable agent) so vendor support is not starting the investigation from zero.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Daily briefings + Google Top Stories in one step.
Enter your email and we'll subscribe you to the daily briefing and add Decryption Digest to your Google Search feed at the same time.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.