Your provider's RMM is Tier 0: 8 questions

On August 2, the vendor behind a widely used remote monitoring and management platform published a security advisory. The day after, CISA added the CVE to its Known Exploited Vulnerabilities catalog and gave federal agencies three days to remediate. If you are an IT director or a CFO who owns IT, and you do not run an MSP, you may have skimmed past it as channel news. It isn't channel news. It is a question about your estate.

Update — August 2026: the first hotfix was not enough, and the vendor said so

This post originally named 2026.3.1.7 as the fixed version. That is no longer the answer. On August 6, 2026 N-able published a second update, build 2026.3.1.10, and led with the part that matters:

"This is not a duplicate of our previous communication. Hotfix 2 is required, even if you already applied the earlier hotfix."

Read that against the argument this post makes. The original incident was an incomplete patch, which is why a provider who fixed the first CVE promptly was exposed anyway. Four days later the remediation turned out to be incomplete too. Anyone who patched to 2026.3.1.7, closed the ticket and reported the estate clean was wrong for a second time, through no new decision of their own. That is the pattern this post is about, happening twice in one incident.

The required action differs by deployment type, in N-able's own words. On-premises: "You must upgrade to 2026.3.1.10 immediately." Hosted: "No action is required. We have already applied mitigations to your environment." So "are we patched?" is the wrong question to ask your provider — the right one is "which of these two are we, and who verified it?"

The compliance clock is three days, not fifteen — and patching does not close it

Both N-central vulnerabilities are now on CISA's Known Exploited Vulnerabilities catalog, and the federal remediation windows are three days rather than the fifteen most people have internalised from BOD 22-01:

• CVE-2026-18577 — added August 3, 2026, due August 6, 2026.
• CVE-2026-18556 — added August 4, 2026, due August 7, 2026.

Both carry the same required action, which cites BOD 26-04 and CISA's "Forensics Triage Requirements." That second phrase is the one with a budget attached: the obligation is not only to patch but to establish whether you were already compromised. If your provider's answer to this incident was a version number, it was not an answer. These directives bind federal civilian agencies, not private contractors — but they are the clearest public statement available of how urgently the government treats this specific software, and that is a reasonable benchmark to hold a provider to.

It reached domain controllers, through a supported feature

Incident responders at Huntress reported that intruders used N-central's own Take Control remote-session feature to reach servers and workstations including domain controllers, and moved from one customer organisation into several.

No Kerberos setting, no tiering model and no privileged-access policy was bypassed, because none of them was in the path. The management plane was trusted, so a session opened from it was trusted. That is the whole argument for treating RMM as Tier 0, and it is now a documented incident rather than a thought experiment.

Here is the argument in one move. Every RMM agent running on your endpoints holds standing privileged access. That is not a flaw, it is the product: the agent exists so someone can push a patch at 2am, run a script across 400 machines, or take control of a laptop in Spokane without driving there. To do that, it executes as SYSTEM, on demand, without prompting the user, on every machine it manages. Which means the RMM is not one more application in your inventory. It is a control plane that sits above your entire fleet, and its blast radius is the fleet.

So the honest framing is not "was this vendor careless." Every vendor in this category carries the same structural exposure, and every provider that runs one — us included — is managing the same risk. The framing is: how would you know whether your provider handles it well? That turns out to be answerable, and the answers take about ten minutes to collect.

What actually happened

N-able published a security advisory dated August 2, 2026, describing "a vulnerability on all N-central servers running a version prior to 2026.3.1.7, which allowed them to obtain administrative access remotely." The advisory specifically addresses on-premises N-central customers.

The tracked identifier is CVE-2026-18577. NVD scores it CVSS 4.0 base 8.2, HIGH, and the vector carries E:A — attacked. CISA added it to the Known Exploited Vulnerabilities catalog on August 3, 2026, with a federal remediation due date of August 6 — a three-day window.

The attack path is worth reading in the vendor's own words, because it is the part that generalizes: "The attacker leveraged the Take Control feature and connected to systems within the N-central managed environment. Once on those devices, the attackers registered a new service for a CloudFlare tunnel, enabling persistence."

Note the shape of that. Administrative access to the management server was not the objective. It was the door. The objective was the managed endpoints underneath, reached through the platform's own legitimate remote-control feature — no malware required, because the tool already does that. And the persistence mechanism was an outbound tunnel registered as a service, which is a design that does not need any inbound firewall rule to survive. If your egress policy is "workstations can reach the internet," that persistence is invisible to the perimeter.

Why an incomplete patch is its own risk class

This is the part that deserves more attention than the CVE number.

CVE-2026-18577 is a bypass of an earlier vulnerability, CVE-2026-18556, which per the vendor "was fixed in 2026.2." Subsequent analysis "revealed another vector to exploit this vulnerability." The first fix was real. It was applied. It closed the path that was known at the time. And then the same underlying weakness turned out to be reachable another way.

Most patch programs are built on an assumption that nobody says out loud: that "patched" is a terminal state. You track a CVE, you apply the vendor's fix, you close the ticket, and the row goes green forever. Incomplete-patch bypasses break that assumption. "Patched" is a state you can lose without doing anything wrong. Your version did not change. Your configuration did not drift. Your ticket was closed correctly. The world's understanding of the bug changed, and your green row silently became a red one.

This matters operationally in three specific ways.

• Vulnerability scanners are version-matchers. Between the day the bypass exists and the day the scanner's signature is updated, a scan of an affected system returns clean. The clean result is accurate to the tool and wrong about the world.
• Remediated findings stop getting read. Once a CVE is marked fixed in a compliance workbook, nobody re-reads the vendor advisory for it. But the follow-on advisory is frequently published against the original CVE's lineage, which is exactly where nobody is looking.
• The exposure window is measured from the second advisory, not the first. If your provider patched the original issue promptly in 2026.2 and felt finished, their real clock started over on August 2 — and it started with an attacker already holding a working technique.

The practical correction is not complicated, but it does have to be deliberate: for the small set of systems that constitute your control plane, subscribe to the vendor's security advisory feed directly rather than relying on a scanner to notice, and treat a fix as provisional until the version that carries it has aged without a follow-on. That is a different posture than "we patch monthly," and it should only be applied to a handful of systems, because it is expensive attention. Which brings up the question of which systems deserve it.

Why RMM is Tier 0

The tiered administration model exists to answer exactly that. Tier 0 is the set of assets whose compromise equals compromise of everything below them — domain controllers, the identity plane, the systems that can write to those. The reason the model is useful is that it forces you to name a short list and then defend that list differently from everything else. We wrote up the mid-market version of that exercise in AD Tier-0 in 90 days: mid-market edition.

RMM belongs on that list, and it frequently isn't on it. The test for Tier 0 membership is functional, not organizational: can this thing execute code as SYSTEM on a domain controller? For any RMM managing servers, the answer is yes, by design, on demand. It also usually holds credentials for scripted tasks, often has an integration path into the ticketing system and the backup platform, and in most deployments is administered by people who work for a different company than the one whose assets it controls.

That last property is the one that makes it different from your domain controllers. Your Tier 0 identity assets are defended by controls you own and can audit. Your RMM is a Tier 0 asset defended by controls someone else owns. You are not going to audit your provider's infrastructure — that is neither realistic nor, honestly, useful. What you can do is establish whether they treat it as Tier 0, and that shows up in how they answer a small number of questions.

The pattern, not the incident

Treating this as one vendor's bad month misses what the calendar is saying. Between July 22 and August 3, 2026 — thirteen days — CISA added four separate security-management-plane products to the KEV catalog. Three of them landed inside a single eight-day stretch.

A firewall manager, an SD-WAN orchestrator, a security management server, an RMM. Four different vendors, four different codebases, one category: the console that manages the security of everything else. At least two of the four are explicitly the on-premises deployment — the version the customer hosts, patches, and is responsible for exposing or not exposing.

That is not coincidence, it is economics. Attackers have worked out that the highest-yield target in a mid-sized environment is not the endpoints. It is the one box that already has authenticated, trusted, standing access to all of them. One exploit against a management plane returns what dozens of endpoint compromises would, and it arrives pre-authorized.

The questions to ask your provider

These are diagnostic, not accusatory. The point is not to catch anyone out. It is that a provider who has thought about this can answer most of them from memory, and a provider who hasn't will need to go find out. Both responses are informative. "I don't know, I'll have it to you Thursday" is a perfectly good answer the first time. "That's proprietary" is not.

One more, if you want to test the culture rather than the controls: ask them to tell you about the last security advisory that affected their tooling, and what they did about it. A provider who has a story ready is a provider who has been paying attention. A provider who says nothing has ever affected them is telling you they don't read the advisories.

The honest close

Nobody in this industry gets to be smug about this one. Every provider that manages endpoints at scale runs a tool with these properties, and the alternative — no remote management — is worse for security, not better, because it means nothing gets patched. We run this class of tooling. So does every credible competitor we have. The structural exposure is shared.

What is not shared is how it is handled, and it comes down to two things that are unglamorous and measurable. The first is patch latency on Tier 0 tooling: hours, tracked, with dates you can produce on request. The second is blast-radius design: the assumption that the management plane will eventually be compromised, and the specific controls that limit what happens next — backups the RMM cannot reach, credentials it does not hold, network segments it cannot cross.

Neither of those shows up in a marketing page. Both of them show up in how fast someone answers question two. If you're going to spend ten minutes on this after reading it, spend them there.

Related reading

• The Tier 0 model itself, scoped for a mid-market environment: AD Tier-0 in 90 days.
• If question 4 landed awkwardly, the MFA-everywhere gap is also what underwriters now verify: cyber-insurance readiness for the mid-market.
• The tooling side of patch latency on a managed fleet: Intune for regulated fleets.
• If you are a defense contractor, a KEV listing is a contractual question as well as a hygiene one: CMMC Phase 2 suspended.
• Service detail: Identity, Security & Compliance and Managed IT support.

Sources

• N-able — N-central security update, August 2, 2026
• N-able — N-central security update, August 6, 2026 (Hotfix 2, build 2026.3.1.10)
• NVD — CVE-2026-18577 (authentication bypass using an alternate path, CWE-288)
• CISA — Known Exploited Vulnerabilities catalog
• Huntress — N-able N-central vulnerability exploitation (incident response findings)

If you want a senior engineer to map your Tier 0 boundary — including the management tooling that usually gets left off the list — the project intake form takes about three minutes. Two-business-day response with scope and a fixed-fee range.

Pro IT NW is a senior-led, vendor-neutral, labor-only Microsoft project consultancy in Seattle, working with regulated mid-market organizations. Nothing here is a claim about any specific provider's security posture, including our own — the questions above are the ones we think a buyer should be able to ask anyone, and get answers.