---
title: Your RMM vendor says take the server offline: run the MSP outage and compromise check (N-central Able2Shell, Nov 2026) | ctxsec
url: https://ctxsec.com/playbooks/rmm-platform-zero-day-offline-response
---

[← Playbooks](/playbooks)

# Your RMM vendor says take the server offline: run the MSP outage and compromise check (N-central Able2Shell, Nov 2026)

For when an RMM platform has public, unpatched exploit chains and the vendor pulls hosted service and tells on-prem customers to shut down (N-able N-central, Nov 9, 2026). Built from N-able's status updates and Huntress's guidance.

For: MSP owner / operations, SOC, IT admin

[1. Take it offline and prove it](#s1)[2. Keep clients running without the console](#s2)[3. Look for use before shutdown](#s3)[4. Restore only on the vendor's word](#s4)[5. Reduce the next blast radius](#s5)

1.

Step 1 of 5

__

### Take it offline and prove it

Do what the vendor says, then confirm from outside that the console no longer answers.

   - Shut down or firewall on-prem N-central servers; block inbound at the edge, not just the service
   - Check from an external host that the web console and agent ports no longer respond
   - Note the exact time it went dark for your incident timeline

2.

Step 2 of 5

__

### Keep clients running without the console

Use the vendor's fallback paths instead of standing up ad-hoc remote access tools.

   - N-able Login / n-able.app for asset view, patching, scripting and Take Control
   - Tell clients what is paused (monitoring alerts, scheduled scripts, patch windows)
   - Don't open RDP or install unvetted remote tools as a workaround

3.

Step 3 of 5

__

### Look for use before shutdown

Exploit code was public before the shutdown; check from Nov 8 onward.

   - Console logins and admin account creation you can't explain
   - New or edited scripts, automation policies and scheduled tasks pushed to devices
   - Remote sessions and file transfers outside normal hours
   - On endpoints: new services, remote access tools or local admins created by the RMM agent

4.

Step 4 of 5

__

### Restore only on the vendor's word

Apply the hotfix first, then bring the server back on a restricted network.

   - Install the vendor's validated hotfix and confirm the build number
   - Restrict console access to VPN or allowlisted IPs before reopening
   - Rotate console admin passwords, API keys and any credentials stored in the RMM

5.

Step 5 of 5

__

### Reduce the next blast radius

An RMM server can push code to every client at once.

   - Require MFA and IP allowlists for the console
   - Alert on mass script deployment and new admin accounts
   - Keep an out-of-band way to reach clients that doesn't depend on one RMM

Original content by ctxsec. Printable checklist: use your browser's print view.