Running security and IT for small businesses often means that when I onboard a new client, I spend a lot of my time discovering the mistakes their former MSP left behind. Over a few months, in two completely unrelated environments, I walked in and found the same thing that previous provider had left switched on: SMBv1 — the 2010-era file-sharing protocol behind WannaCry, NotPetya, and EternalBlue — running in production.
I’m not going to name the MSP. I don’t need to. The findings speak for themselves, and this is a pattern piece, not a callout. Identifying details about the businesses are changed or withheld; the technical content is exactly as I found it.
What SMBv1 actually is, and why it has no business running in 2026
Server Message Block is how Windows machines share files and printers over a network. Version 1 dates to the late 1980s, was already creaking by the time of the current century, and should have been dead a decade ago. When two machines negotiate an SMB connection, they agree on a dialect; an SMBv1 host answers that negotiation with the string NT LM 0.12. That string is the tell. If you can make a host answer with it, the host speaks a protocol with no modern integrity or authentication guarantees and a history of catastrophic, wormable, pre-authentication remote-code-execution bugs.
The most famous of those is EternalBlue (MS17-010) — the SMBv1 vulnerability that powered WannaCry and NotPetya in 2017 and did billions of dollars of damage. Microsoft patched it in March 2017 and has been telling people to rip SMBv1 out entirely ever since. It is disabled by default on modern Windows. Finding it enabled, on a production server, in 2026, under a paid provider’s care, is not a nitpick. It is a paid professional missing something a one-line compliance check would have caught.
Environment one: a decade of data behind SMBv1
The first one I found by accident, doing ordinary infrastructure work on a franchise business’s back-office network — the box that runs the point-of-sale reporting and the accounting SQL database. A decade of financial and operational data lives on that server. SMBv1 was enabled on it.
I turned it off that night and rebooted the box. I’ll be honest about what happened next, because it’s the realistic texture of this work: the reboot briefly broke the application’s connection to its SQL Server, and I spent a little while chasing a driver exception before it came back clean. Disabling a legacy protocol on a production server at 11 p.m. is not a zero-risk action, and pretending otherwise is how people talk themselves out of doing it. It was still the right call, and it took twenty minutes.
Then I filed a formal complaint. Because the response you get to a finding like this is always some version of “but you haven’t been compromised,” and that sentence is not a defense of anything. The absence of an incident is not the presence of a control. A decade of accounting data sitting behind the WannaCry protocol on a paid provider’s watch is not made acceptable by the fact that no one has happened to walk through the door yet. That environment is now remediated — SMBv1 off — and I’m the one who turned it off, not the provider being paid a retainer to have caught it in the first place.
Environment two: the machine everyone forgot
The second one was worse, and it’s a healthcare environment, so I’m going to describe it in deliberately general terms.
On that network there is a piece of embedded medical-adjacent equipment — the kind of specialized appliance that quietly runs a decade past the death of the operating system inside it. This one runs Windows XP. And when I measured its SMB dialect, it answered with NT LM 0.12 and nothing else. It speaks SMBv1 only. It cannot negotiate SMB2 or SMB3 at all.
That detail matters more than it first appears, because it changes the remediation. On a normal machine you fix this by turning SMBv1 off and letting it fall back to a modern dialect. You can’t do that here — SMBv1 is the only language this device speaks. Disable it and the device goes dark. So the machine is stuck: an unpatchable, end-of-life, SMBv1-only host that meets every precondition for EternalBlue — and it sits on the same flat, unsegmented network as the server holding regulated patient records, including controlled-substance data.
Let me be precise about the claim, because precision is the whole point of doing this honestly. What I proved is that this device speaks SMBv1 and only SMBv1 — that’s a measured dialect negotiation, not a guess. That, plus an unpatchable Windows XP OS, means it is EternalBlue-exposed by definition: the vulnerable protocol is present, mandatory, and unpatched. What I did not do is fire the exploit at a live medical device on a production healthcare network to watch it fall over. I don’t need to detonate it to know it’s a landmine, and detonating it would be reckless. “SMBv1-only embedded XP, EternalBlue-exposed by construction” is the accurate statement; “confirmed exploited” would be a lie I’m not willing to tell for a better headline. (There was also a second, easier finding on that network — an end-of-life Windows 8.1 box with SMBv1 needlessly enabled alongside modern dialects. That one’s the cheap fix: just turn v1 off.)
The part that turns a bad finding into a disqualifying one
Here is the detail that should end the conversation about whether that MSP was earning its retainer. While I was in there, I checked the backups.
They weren’t running.
Sit with the combination. This is a network with an unpatchable, wormable, remote-code-execution-exposed host sharing a flat segment with regulated patient data — the single most ransomware-attractive setup I can think of — and its backups were not active. So it was both maximally exposed to ransomware and had no recovery path from it. Vulnerable to the exact outcome the vulnerability invites, and uninsured against it. If that network had been encrypted tomorrow, the answer to “restore from backup” would have been: what backup.
A managed service provider has exactly two jobs that matter more than any other: don’t leave known-wormable protocols running in production, and make sure the backups actually work. This one missed both, on the same network, in a healthcare setting.
Why I keep being the one who finds these
None of this took special tooling or a penetration-testing engagement. SMBv1 shows up in a dialect negotiation that takes seconds to run. A dead backup shows up the moment you ask “when was the last successful restore test?” and actually wait for the answer. These are line items on a compliance checklist. The reason I keep finding them is not that I’m doing something clever; it’s that the people being paid to look weren’t looking.
The uncomfortable generalization, if you’re a business owner paying an MSP: “we’ve never been breached” is not evidence that your provider is doing the work. It is evidence that you haven’t been unlucky yet. The questions that actually tell you something are boring and specific — give me the SMB dialect inventory for every server; show me the last successful backup restore test with a date on it; show me which end-of-life devices are isolated on their own network segment and which are sitting next to the crown jewels. If your provider can’t answer those quickly, the absence of an incident so far is the only thing standing between you and a very bad week — and that’s not a plan. It’s a coin that hasn’t come up tails yet.