N-central vulnerability exposes MSP risk: What the N-able incident means for your RMM security?

Your RMM has administrative access to every device you manage — unattended, at all hours, across every client environment you run. That access is not a feature. It is the product. And it makes your RMM vendor one of the highest-stakes decisions in your stack, not because of what it does when things go well, but because of what happens when they don't.

On August 1, N-able disclosed CVE-2026-18577, a critical vulnerability in N-central — the RMM platform thousands of MSPs use to centrally patch and remotely access every device across every client they run — that let attackers gain administrative control of the console without valid credentials. Once inside, attackers used N-central's own remote-control feature to pivot into managed endpoints, including domain controllers, across multiple organizations, before N-able shipped a hotfix on August 2 (Huntress's incident writeup has the full timeline). CISA added it to its Known Exploited Vulnerabilities catalog the same week and ordered US federal agencies to patch within days.

When I learned of this vulnerability, it brought me back to the discussions we had when developing LogMeIn Resolve in 2021 on the heels of a larger, well-published supply chain attack. One of our lead engineers boldly said these attacks would continue to grow, and we needed to do something different to protect our customers. So we did, with Resolve’s zero trust architecture, adding controls designed to prevent a single compromise at the management layer from affecting everything downstream, meaning every managed environment an MSP is responsible for.

Resolve's architecture is built on the assumption that the server will be compromised at some point. The question we asked ourselves is the same one I’d ask any RMM vendor today: If the infrastructure is compromised, what can an attacker really do? In LogMeIn Resolve’s case, they won’t be able to reach your endpoints. The zero trust signature key can prevent attackers from executing privileged actions on managed endpoints — because no one, not even the vendor, holds that key.

Architecture is one of the most important considerations, but not the only one.  There is more to consider, so before your next renewal conversation, or before you evaluate a new platform, here are six questions worth asking your RMM vendor.

Most MSPs I talk to think of their RMM deployment model as an IT preference; however, it’s actually a security decision and one that doesn’t often get treated that way often enough.

The on-premises appliance has an under appreciated problem. It's a server that needs patching, hardening, and endpoint protection — but in practice, it rarely gets treated like one. It's not a workstation, so EDR often skips it. It's not a cloud service, so no one's watching its security posture but you. And it sits on your network with elevated access to every device you manage.

N-able's incident confirmed this pattern almost exactly: the N-central appliance runs on a locked-down Linux build and, per outside incident responders, doesn't typically have EDR deployed on it because it's managed like an appliance rather than a server.

Cloud-native deployment shifts that responsibility to the vendor. Whether that matters depends entirely on how well the vendor has secured and audited that infrastructure — which is what Questions 3 and 6 are for.

Ask your vendor: “If I'm running your product on-premises, what's my responsibility for securing that server? Is EDR supported and recommended on it?”

This is arguably the most important architectural question in the list, and one that should be top of mind when speaking with a vendor. The answer tells you almost everything you need to know about a vendor’s architecture.

In a conventional server-trust architecture, the server is a trusted node. An attacker who gains administrative access to it inherits that trust — including the ability to push commands, scripts, and remote sessions to every managed device connected to it. The backend is the key to the kingdom — which is exactly what played out in the N-able incident, when attackers who compromised the console used its built-in remote-control feature to reach managed endpoints, including domain controllers, across multiple organizations. This is the architecture LogMeIn Resolve’s zero trust approach was designed to move beyond.

A zero trust architecture works differently. Every command sent to a managed endpoint is signed by the technician's private key — a key that never leaves the technician's machine. The endpoint verifies the signature before executing anything. A compromised backend server can't push malicious commands, because it never had the private key to begin with — the backend only holds the public key, and the private key can't be derived from it. Any command that fails that signature check gets discarded at the device instead of executed.

David Bisztrai, GoTo’s VP of Engineering for LogMeIn product line, puts it this way: "Think of a big safe in a bank. In a traditional system, attackers dig a tunnel to get in, and once they're inside, they find the real treasure: the endpoints. The backend talks to the device, the device trusts it, and it executes whatever command it gets. Our zero trust architecture starts from the same assumption — that someone will eventually find a tunnel to our safe. But when they get there, they won't find the treasure. They'll find thousands of small lockers, and each one can only be opened with a signature key that lives in the customer's hands, not ours. Even if you reach the safe, you can't open anything."

This is a design question, not a patch question. No hotfix changes which model your vendor was built on.

Ask your vendor: “If your infrastructure was fully compromised, what would stop an attacker from using your platform to reach my managed endpoints?”

Speed matters. Completeness matters more. Those two things are not the same question, and the difference between them is where the real risk lives.

A patch that closes the reported attack vector while leaving an adjacent one open can create false confidence that the problem is resolved. Follow-on patches for RMM vulnerabilities happen across the industry, and the N-able incident is just one example of this. Attackers exploited a new vector related to the earlier fix.

Attackers don't need to find a new vulnerability. They just need the vendor's patch to be incomplete.

The question isn't just “how fast do you patch?” It's “how do you validate that the fix is actually complete?” 

Ask your vendor: “When was the last time you issued a follow-on patch for a vulnerability you thought was already resolved — and what did your testing process miss the first time?”

This is a logistics question as much as a security one. It’s the question most MSPs don’t ask until a patch has already been out for a week, and half their self-hosted servers are still exposed.

For cloud-hosted deployments, vendors push security fixes centrally — many customers never even know a patch went out. For on-premises deployments, that job lands on you.

The N-able incident put real numbers on that gap. Per Huntress's telemetry across its own partner and customer base, more than half of reachable cloud-hosted N-central servers were still unpatched in the first day after N-able's hotfix shipped. By the next update, cloud patching had largely caught up — but nearly three in ten reachable self-hosted servers were still unpatched.

“Patch lag in the field isn't a rounding error — it's the slowest ten or twenty percent of devices that never quite catch up, and that's exactly the slice attackers are counting on," said Steve Shattuck, Vice President of Global Partner Ecosystems at GoTo.

Ask your vendor: “For a critical security hotfix, how many of your customers are typically still running a vulnerable version 48 hours after release? How do you actually know that?”

Encryption is table stakes. What matters more is whether the platform enforces permission controls, keeps an audit trail, and gives the end user real control over their own device. What truly separates vendors is what happens above the baseline of encrypting sessions.

Unattended access deserves particular scrutiny here. How does it get set up? Who approves it? Who can revoke it? These questions shape your own exposure — and your ability to look a client in the eye and explain how their systems are actually being accessed.

Ask your vendor: “Can an end user revoke unattended remote access themselves, without going through the MSP? Where is that documented and surfaced to the user?”

There's a difference between a vendor who says “we take security seriously” and one who holds certifications that required an independent auditor to verify it. The first is a statement. The second is evidence.

Certifications worth asking about: ISO/IEC 27001:2022, SOC 2 Type II, BSI C5. Each represents external, audited validation of security controls — not an internal assessment the vendor wrote about itself. External penetration testing by third-party firms sits on top of that as a separate, valuable layer of assurance, and plenty of vendors skip it.

Ask your vendor: “Which certifications do you hold, and when were they last audited? Do you run external penetration testing, and can you share the scope?”

No vendor can promise a zero-incident future. That includes us. The honest question was never “has this vendor ever had a problem?” It's “what does their architecture do to limit the blast radius when something goes wrong?”

A zero trust model that cryptographically isolates endpoint access from backend compromise is structurally more resilient — not because it prevents every attack, but because it stops one class of attack from turning into a catastrophic cascade. That's a design property. It either exists or it doesn't.

LogMeIn Resolve was built on this model, specifically because our engineering team anticipated that RMM platforms would become high-value supply chain targets. The recent N-central incident reinforces why this architectural approach matters.

If you’re currently using an RMM that runs on a conventional server-trust model, these six questions are worth asking this week and not just at your next renewal.