When NYDFS sent its August 11 letter about the N-central vulnerability, it didn't address the managed service providers running the software. It addressed the banks and insurers those providers serve. This isn't an oversight; it's the regulatory structure you're working within.
The gap is structural: technology service providers don't have a sectoral regulator in the U.S. When a vulnerability emerges in software your MSP uses to manage your systems, no federal examiner is checking whether they patched it. That responsibility falls to you, even though you don't control their infrastructure.
This disconnect creates persistent myths about where your vendor management obligations begin and end. Here's what actually applies when your security depends on vendors outside regulatory reach.
Myth 1: "Our MSP is responsible for managing their own security vulnerabilities"
Reality: Your MSP is responsible for patching their systems. You're responsible for knowing whether they did it.
Attackers began exploiting the N-central flaw on July 31. N-able shipped a fix on August 2. By August 3, 28.6% of self-hosted N-central servers remained unpatched. If your MSP ran one of those servers, that two-day window could have given attackers control over every system they managed for you, including yours.
The NYDFS letter made the obligation explicit: find out whether any provider supporting your systems runs N-central, and if so, whether they've patched it. You can't delegate that inquiry. Your vendor management program must include named contacts at each critical provider and contractual language requiring them to respond to security questions.
When a regulator issues an alert about a vendor product, you have a limited window to demonstrate diligence. If something goes wrong and you didn't ask, examiners will note the gap in your program. If you asked and your vendor stonewalled you, that's a different conversation, but you need documentation showing you tried.
Myth 2: "Vendor security is a procurement issue, not an operational one"
Reality: Vendor security is an ongoing operational discipline, not a checkbox during contract signature.
Consider what happened at Sawyer Savings Bank. Three days after the N-central exploitation began, the bank closed all four branches. It reopened them a week later. The bank's CEO described the disruption as "likely the result of a vendor vulnerability," though he didn't name a specific vendor or confirm N-central involvement.
The operational impact was immediate: customers couldn't access branches for a week. The investigation is ongoing; weeks later, the bank is still determining what data may have been affected and to whom it belongs.
Your vendor management program needs procedures for chasing possible break-ins at important providers. That means more than an annual questionnaire. It means knowing which vendors have access to what systems, having a contact who can answer technical questions during an incident, and maintaining contractual rights to demand cooperation during an investigation.
When a vulnerability hits a vendor's infrastructure, you're not investigating their breach; you're investigating whether their breach became yours. That requires operational visibility you can't retrofit during a crisis.
Myth 3: "If regulators cared about MSP security, they'd regulate MSPs directly"
Reality: Regulators can't examine your vendors, so they examine how you manage your vendors.
The National Credit Union Administration has told Congress for years that it lacks authority to examine the vendors serving credit unions. It briefly held that authority around Y2K and lost it at the end of 2001. Banks face the same structural constraint: NYDFS regulates the banks it charters, not the technology providers those banks hire.
This isn't a gap regulators ignore. It's a gap they address by holding you accountable for your vendor relationships. The FFIEC IT Examination Handbook dedicates entire sections to third-party risk management because examiners can't reach the third parties themselves.
Your vendor management program is the control framework examiners can assess. They'll review your vendor inventory, your risk classifications, your due diligence documentation, your ongoing monitoring procedures, and your incident response protocols for vendor-originated events. If you treat vendor management as someone else's problem, examiners will treat your program as deficient.
Myth 4: "We're protected because our MSP uses the cloud-hosted version"
Reality: You're protected from this specific vulnerability if your MSP uses cloud-hosted N-central, but you're not protected from the broader risk class.
N-able's hosted N-central installations updated themselves automatically. MSPs running self-hosted copies on their own servers had to apply the patch manually. If your MSP uses the hosted version, they likely weren't vulnerable to this particular exploit.
But that doesn't answer the underlying question: how would you know which version they run? The only way to know is to ask. And if you don't have a process for asking that question when an alert arrives, you don't have a functioning vendor management program.
The N-central case is one vulnerability in one product. The pattern repeats across your vendor ecosystem: vulnerabilities emerge, patches ship, and you need to know whether your vendors applied them. Cloud hosting reduces some risks, but it doesn't eliminate your obligation to verify.
Myth 5: "If we don't see evidence of compromise, we can assume we weren't affected"
Reality: Absence of evidence isn't evidence of absence, and your investigation timeline doesn't match the attacker's.
Security firm Huntress saw fewer than 10 organizations compromised in its customer base. Sophos counted one confirmed and one suspected compromise in its monitored networks. Those numbers sound contained until you remember that security vendors only see the networks they monitor. NYDFS sees confidential incident reports from every firm it licenses, a much broader view.
The attacks looked "more opportunistic than targeted," according to Sophos. But opportunistic doesn't mean harmless. Storm-1175, the group Microsoft says likely exploited the flaw, listed Sawyer Savings Bank on its leak site on August 7. Whether that listing connects to N-central remains unconfirmed, but it illustrates the investigation timeline: weeks after the initial exploitation, affected organizations are still determining the scope of impact.
Your incident response procedures for vendor-originated events need to account for delayed detection. You might not see the compromise immediately. Your vendor might not report it promptly. By the time you're investigating, the attacker may have moved laterally across systems the vendor manages.
What to do instead
Build your vendor management program around three operational realities:
First, maintain an inventory of vendors with system access, categorized by the sensitivity of data they touch and the criticality of functions they perform. When an alert like the NYDFS letter arrives, you need to know within hours which vendors might be affected, not start building a list from procurement records.
Second, establish contractual obligations for security incident notification and cooperation. Your contracts should require vendors to notify you of security events affecting systems they manage for you, provide you with technical details sufficient for your own investigation, and cooperate with your incident response procedures. Those aren't negotiating points; they're baseline requirements.
Third, test your vendor incident response procedures before you need them. Run a tabletop exercise where a vendor reports a compromise. Who do you call? What questions do you ask? How do you assess whether the vendor's compromise affected your systems? What evidence do you need to satisfy examiners that you responded appropriately?
Regulators will expect you to ask your MSPs about vulnerabilities like N-central. They can't guarantee you'll get responsive answers. But they can, and will, assess whether you tried. The difference between a program gap and a documentation gap is the difference between a finding and a conversation.
Your vendors operate outside regulatory reach. Your vendor management program doesn't.
