If an attacker gets into the console your MSP uses to manage your network, the honest answer is: they get administrator-level reach into your systems too, often without tripping a single alarm you control. That is not a hypothetical. On August 11, 2026, the New York State Department of Financial Services issued an industry letter describing exactly that pattern in an active campaign against N-able's N-central remote monitoring and management platform, and it is the reason I am writing this piece under my own name rather than leaving it to a headline.
I run an MSP. The tooling my team and every competitor of mine relies on to keep your systems patched, monitored, and supported is the same category of tool named in that letter. I am not writing this to score points off N-able — the vulnerability could have surfaced in any RMM platform, including the ones behind Securafy's own operations. I am writing it because the DFS letter marks a shift worth naming plainly: regulators are no longer treating a vendor's breach as only the vendor's problem.
DFS's alert names two vulnerabilities, CVE-2026-18556 and CVE-2026-18577, both authentication-bypass flaws in N-central, the RMM platform N-able describes as software MSPs use to "centrally monitor, patch, and remotely access their customers' services and endpoints," per the letter. The second CVE exists because the first patch was incomplete — CVE-2026-18577 is described by NVD as resulting from "an incomplete patch for CVE-2026-18556," and both carry a CVSS 4.0 base score of 8.2 and sit in CISA's Known Exploited Vulnerabilities catalog.
The mechanics matter more than the CVE numbers. DFS states plainly that "threat actors are targeting a Known Exploited Vulnerability in N-central to compromise MSP environments," and that once inside, "attackers are using a compromised MSP's environment to move laterally into their customer's networks and information systems with administrator network privileges." The letter adds a detail that should concern anyone who thinks a patch closes the incident: "threat actors may create or register for new services, allowing continued access even after compromised N-central credentials are revoked." That is not smash-and-grab. That is an attacker planting a way back in before anyone notices they were there.
No — and treating it as one is the mistake I want to head off. Most coverage of an RMM vulnerability reduces to "did you apply the patch." Patching matters, but DFS's letter is doing something else: it is telling regulated entities that oversight of the vendor is now their job, not just their provider's. The letter states that "the senior governing bodies and senior officers of DFS-regulated entities must actively engage in cybersecurity risk management, including through monitoring and oversight of third-party service providers," and that DFS "expects DFS-regulated entities that may be exposed to cybersecurity risk related to the N-central vulnerability to appropriately manage this risk through due diligence and engagement with Third-Party Service Providers on this issue."
The letter also points regulated entities back to their existing incident-reporting obligation under 23 NYCRR § 500.17, confirming that a cybersecurity incident "originating at Third-Party Service Providers" still has to be reported to DFS. If you are a regulated entity, or if your cyber insurer or your board is asking similar questions in the wake of this alert, the vendor's product name is not the deliverable. Your documented due diligence on the provider is.
I understand the instinct. A headline names a vulnerability, and the natural response is to call your IT provider and ask if they run the affected software. Ask that question about N-central this week and you will get a clean answer either way. But the next RMM vulnerability will involve a different vendor, and the one after that will too — every MSP's tooling is a target precisely because it is trusted and privileged inside every client network it touches.
The right question is architectural, not brand-specific: what does your provider's management tooling let an attacker reach if that tooling is fully compromised, and what actually stops it from getting further? An MSP whose honest answer is "our console has never been breached" has no answer at all, because that outcome was never guaranteed to anyone — it is a description of luck so far, not a control. Remote management tools exist to grant privileged, wide-reaching access with minimal friction. That is the entire point of the product category, and it is exactly the access profile an attacker wants once inside. The risk is not a defect to be patched away one CVE at a time; it is structural to how remote management works. What can be engineered is how far a compromise travels before it is stopped — the blast radius, not the possibility.
Ask questions that reveal architecture, not intentions. Here is what a credible answer sounds like on each point, based on the controls that CISA's joint guidance on protecting managed service providers lays out for exactly this scenario.
| What to ask | What a good answer sounds like |
|---|---|
| Privileged access management on the RMM itself | RMM administrator accounts are treated as privileged accounts, subject to least-privilege scoping and periodic access review — not standing, unrestricted admin for every technician. |
| MFA on the console | Multifactor authentication is enforced on every account with access to the console, with monitoring for failed logins and re-enrollment attempts, not just "MFA is available." |
| Network segmentation | The provider's connection into your network is a dedicated, restricted path, segregated from your other systems, so a compromised console cannot reach everything at once. |
| Default-deny application control | Unknown or unapproved binaries do not execute even under admin credentials pushed from the console — allowlisting, not just antivirus, stands between a stolen session and code execution. |
| Logging you can see | You receive visibility into the provider's activity, connections, and presence on your network, not just a promise that "we log everything internally." |
| Written notification commitment | A contractual, specific timeframe for notifying you of a confirmed or suspected incident on the provider's side — not "as soon as reasonably possible." |
CISA's guidance backs each of these directly: it recommends that MSP accounts with customer access "should be treated as privileged" and have MFA enforced, that providers "segregate customer data sets from each other" and from internal networks, and that contracts require providers to "notify the customer of confirmed or suspected security events and incidents occurring on the provider's infrastructure." The same advisory recommends customers use a dedicated, restricted connection method to MSP infrastructure rather than open, unsegmented trust. If your provider cannot answer these in specifics, that gap is your risk, not a hypothetical one.
This is not a fringe concern regulators invented for one industry. The NIST Cybersecurity Framework 2.0 dedicates an entire category under its Govern function, GV.SC, to "Cybersecurity Supply Chain Risk Management," describing outcomes where an organization's risk from suppliers, products, and third parties is "understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship" — not assessed once at contract signing and forgotten. A prior joint advisory from CISA, the NSA, the FBI, and international cyber authorities made the same point years ago about MSPs specifically, warning that a single compromised provider "can significantly increase downstream risk to the businesses and organizations they support." What DFS did on August 11 is take that general principle and turn it into a specific, dated compliance expectation tied to a live campaign.
None of this is unique to regulated financial entities. If you are evaluating how to meet cyber insurance requirements with an MSP, your underwriter is asking versions of these same questions about vendor oversight, because insurers have caught up to the same reality DFS is describing. We have also written about what underwriters are actually asking for heading into next year in our piece on cyber insurance readiness for SMBs, and the overlap with this DFS letter is not a coincidence — both are downstream of the same shift toward holding the client accountable for vendor exposure.
Treat "what happens to my network if your console is breached" as a standing due-diligence question, not a one-time incident question you ask after a headline. Put it on the same recurring calendar as your insurance renewal or your compliance review, and expect your provider to answer it the same way each time, with specifics rather than reassurance. If you are still deciding what kind of provider relationship fits your risk profile, our overview of MSP versus MSSP versus vCISO walks through where accountability for exactly this kind of question typically sits in each model. And if you have not mapped your obligations broadly, our guide to cybersecurity and compliance for SMBs in 2026 is a reasonable starting point before you get to vendor-specific questions.
The same discipline applies beyond RMM tools. Any system with broad, trusted, standing access into your environment deserves this scrutiny — including the AI tools your teams are adopting now. Our piece on AI security for small businesses walks through where those risks and controls start, and our practical guide to AI governance for small and mid-sized businesses covers the oversight structure that question needs, for the same underlying reason: trusted access without oversight is trusted access without a floor.
We are not exempt from any of this, and I am not going to pretend otherwise. Every MSP's tooling carries the same structural exposure described above, ours included. What we control is the blast radius if it is ever tested: privileged accounts on our own management tooling are scoped and reviewed, MFA is enforced on every console with client access, our connections into client environments are segmented rather than flat, and our clients get visibility into our activity on their networks rather than a black box they have to trust blindly. We build our incident-notification commitments into the contract with a specific timeframe, not a vague promise, because a client finding out about an issue affecting their network on their own timeline is a failure regardless of what caused the underlying incident.
If you ask us these questions, we expect to answer them the same way twice — once today and again in a year, with the same specificity. That consistency, more than any single control, is what due diligence on a provider is actually testing for.
The N-central alert will fade from the headlines within a news cycle or two, but the underlying question it raises about your provider's console does not expire when the patch ships. Make it a standing item, not a one-time scare.
If your team is moving faster with AI than your guardrails are, start with structured training rather than another tool. Securafy AI University gives your people role-based AI training with security built into the material, not bolted on afterward.
If you would rather talk through your specific environment first, book a strategy call with Securafy and we will walk your current AI usage, exposure, and the fastest path to safe adoption.