NYDFS Named MSPs in an N-central Alert: What NYC Finance Firms Must Ask Their Provider This Week

On August 11, 2026, the New York State Department of Financial Services sent every firm it regulates an industry letter that names a product and the class of vendors that run it. The product is N-able N-central. The vendors are managed service providers.

If you are a state-chartered bank, an RIA, an insurer, a check-casher, or a licensed lender in New York City—or a 15-person shop in Staten Island, Midtown, or Jersey City that sells into those firms—the letter is addressed to you. It is not addressed to your MSP. DFS regulates the covered entity. Your job this week is to get a written answer from the people who already have administrator rights on your network: do you, or anyone you subcontract, use N-central?

A year-old SOC 2 PDF does not answer that. Neither does a SHIELD checklist. We already covered N.Y. General Business Law § 899-bb for NYC SMBs on this blog. This post is 23 NYCRR 500 vendor and MSP risk: what the letter actually requires, what the campaign does after the console is taken, and nine questions you can paste into an email today.

What DFS told covered entities to do

DFS described an active campaign against a Known Exploited Vulnerability in N-central. Some MSPs use that console as their remote monitoring and management system: the place they watch endpoints, push patches, and open remote sessions. Once attackers have the console, DFS said, they may create or register new services so access continues after compromised N-central credentials are revoked. From there they move laterally into customer networks and information systems with administrator privileges.

Covered entities must promptly determine whether N-central is used in their own environment or by any MSP or other Third-Party Service Provider that supports their information systems. Where it is used, work with the provider to review N-central activity for unauthorized or persistent access; verify that applicable security updates—including software patches and other mitigations—have been implemented; and evaluate whether any systems or credentials were affected.

The letter says the vulnerability is likely limited to MSPs. It also says senior governing bodies and senior officers still have to oversee third-party service providers. Cybersecurity incidents that originate at a TPS still have to be reported under 23 NYCRR § 500.17.

That is an operator task. It is not a policy rewrite you can finish in the next board packet.

What the campaign actually does

N-able says it detected exploitation on July 31, 2026. The flaw allowed remote administrative access to the N-central console without authentication. After that, actors used Take Control to reach managed devices and registered Cloudflare tunnel services on those devices so they could stay in after N-central access was revoked.

Two CVEs matter, in order. CVE-2026-18556 was the first authentication bypass. CVE-2026-18577 is the incomplete-patch path: authentication bypass and account takeover in N-central versions through 2026.3.1. Hotfix 1 (build 2026.3.1.7) shipped August 2. Hotfix 2 (build 2026.3.1.10) shipped August 6 and is required even if Hotfix 1 was already applied. N-able says hosted N-central (NCOD) was mitigated on the vendor side. On-premises consoles have to be upgraded by the operator who runs them.

Applying Hotfix 2 closes the hole that let attackers in. N-able is explicit that it does not remove an actor who is already present. That is why “we patched” without a review of accounts, new services, and Take Control sessions is not a close.

Huntress has observed exploitation. In the cases they published, Take Control sessions showed up under the default username “MSP Support,” and the actors went after high-value servers, typically domain controllers. Huntress also published dated patch-rate snapshots that should stay dated. At 12:45 a.m. ET on August 3, 55.6% of reachable cloud N-central servers in their partner and customer set were still unpatched. Later that day they reported almost all of those cloud servers patched, while 28.6% of reachable self-hosted servers in that same update were still unpatched. Those are August 3 snapshots, not today’s rate.

CISA added both CVEs to the Known Exploited Vulnerabilities catalog, as reported by Help Net Security. A DFS spokesperson told American Banker the Department is aware of impact to a limited number of covered entities, and that the August 11 letter followed awareness of ransomware activity involving exploitation of the N-central vulnerability in MSP environments with downstream impact to financial-services organizations.

IoCs exist. Treat them as a starting point. Huntress noted that several of the early IP addresses N-able published were VPN exit nodes, not a private attacker network you can block once and forget.

We are not going to invent a New York City victim list. If your MSP has not answered the questions below, you do not know whether you sit behind a patched hosted console, an unpatched on-prem box, or a console that was already used to open a session on your domain controller.

SHIELD already applied. This letter is Part 500.

If counsel forwarded the letter and said “we already do SHIELD,” that is the wrong statute for this week.

The SHIELD Act is the New York Attorney General’s reasonable-safeguards rule for private information of New York residents. We walked that checklist for NYC SMBs here: NYS SHIELD Act compliance. Vendor selection and contract language sit in SHIELD’s administrative safeguards. SHIELD did not name N-central on August 11, and a completed SHIELD workbook does not tell you whether your MSP’s RMM is the product in the letter.

23 NYCRR 500 does. Section 500.11 requires a written third-party service provider security policy: identify the TPS, set minimum practices, do diligence, and reassess on a risk basis. Section 500.4 puts senior officers and the senior governing body on the hook for cybersecurity oversight, including TPS. Section 500.17 is the incident-reporting clock. The August 11 letter reminds you it covers incidents that originate at a TPS, not only ones that start on your own servers.

DFS’s October 21, 2025 guidance on managing TPS risk said the part firms like to skip: a covered entity may not delegate Part 500 compliance to the MSP. If the MSP’s RMM is the path in, you still own the diligence, the oversight, and the notice.

The 15-person firm that sells into a DFS-regulated bank is not a spectator. You may not be the one filing the 500.17 notice, but the bank will ask you the same questions. A stolen admin session is still an identity problem, and a tenant or file-room lockout is still a backup problem. Those posts are the mailbox and the restore. This one is the vendor with the keys.

Nine questions to email your MSP this week

Copy these into an email. Ask for written answers, not a call recap.

1. Do you use N-able N-central to monitor, patch, or remotely access our systems—or does any subcontractor or downstream provider you use?
2. If yes, is that console N-able-hosted (NCOD) or on-premises on your servers or a subcontractor’s?
3. If on-premises, what exact build are you on, and on what date did you apply Hotfix 2 (2026.3.1.10)? “We patched in early August” is not an answer. Hotfix 1 (2026.3.1.7) is not the current required build.
4. Is the N-central console reachable from the public internet, or is access limited to VPN or allow-listed admin networks?
5. Have you reviewed N-central activity since July 31, 2026 for unauthorized logins, new or unexpected users, password resets, and newly registered services?
6. Have you reviewed Take Control and other remote-control sessions against our environment—especially any session under the default “MSP Support” identity, any session that does not match a ticket, and any session that touched a domain controller, file server, or backup host?
7. On our endpoints, have you looked for the persistence N-able described: a registered Cloudflared service, unusual Take Control activity, and a file named svchost.exe in a user’s Documents folder? A clean indicator scan is a start, not a close.
8. Were any of our systems or credentials affected? If you cannot say no with a review behind it, say what you have not checked yet.
9. If you find unauthorized or persistent access that originated in your environment, who notifies whom, in writing, and on what clock—so we can meet 23 NYCRR § 500.17 if we are a covered entity?

A useful reply names the product, the build, the date, whether the console is internet-exposed, and the review that was actually run. “We take security seriously” is not a reply. “We blocked some IPs” is not a review. If the answer to question 1 is no, get the subcontractor half of that sentence in writing too.

What MicroSky will actually do

MicroSky is a Staten Island / NYC MSP. We will not answer this letter with a generic EDR laundry list.

If you ask us the same questions—whether you are a current client, a DFS-regulated firm checking a provider, or a 15-person shop that sells into one—we will tell you, in writing:

• whether N-central is in the stack that touches your environment;
• whether Hotfix 2 is on, and on what date, if an on-premises console is in that stack;
• whether that console is internet-exposed;
• and we will walk a Take Control log review for sessions that do not match your tickets, including the “MSP Support” pattern Huntress documented.

We will not claim a tool we do not run, and we will not claim a tool we do. The point of the DFS letter is a factual answer from the people who actually have the console.

If the review turns up unauthorized access, the next conversation is containment, credential review, and whether 500.17 or SHIELD notice is in play—not a slide about endpoint agents.

Ask this week, in writing

Call MicroSky at (718) 672-2177 or visit microskyms.com. We serve NYC, Staten Island, New Jersey, and the tri-state. Bring the August 11 letter and the nine questions. Ask for the four answers above, in writing, this week.