What a Rogue Device on Your Client's Network Actually Costs
Somewhere on a network you're responsible for, there is a small window of time between "an unrecognised device joins" and "someone notices." For most networks, that window is measured in days, not minutes — and for a meaningful number of networks, it never closes at all, because nobody was ever specifically looking for a device that doesn't belong. That window is where the real cost of a rogue device lives, and it has almost nothing to do with whether the device turns out to be malicious.
The device doesn't have to be malicious to be a problem
It's tempting to picture "rogue device" as a dramatic scenario — an attacker's laptop plugged into a server room, a planted access point sniffing traffic. Sometimes that's exactly what it is. But in practice, most unrecognised devices are far more mundane: a personal phone connected to a network it shouldn't have access to, a contractor's laptop left plugged in after a site visit, an IoT gadget someone brought in and connected without asking, a second-hand access point someone set up to fix a dead zone in the office without mentioning it to anyone. None of these are attacks. All of them are things that shouldn't be there, and every one of them is a genuine question mark about what a network actually looks like versus what everyone assumes it looks like.
That gap between assumption and reality is the actual cost. Every security decision an MSP or IT team makes — what to trust, what to firewall off, what to report to a client as the state of their network — is being made against a mental model of the network that might already be wrong, and wrong in a way nobody's checked.
Why "we'd notice" usually isn't true
Most people assume an unrecognised device would stand out. In practice, it doesn't, because nobody's looking at a device list with the specific question "does every single one of these belong here" in mind — that's a tedious, easy-to-skip audit, not something that happens naturally as part of a normal day. A device list with forty entries doesn't invite scrutiny of entry thirty-one. It invites a glance to confirm nothing looks obviously broken, which is a completely different kind of attention than the one that would actually catch something new and unwanted.
This is exactly the gap automated rogue detection is built to close, because it doesn't get bored, doesn't skim, and doesn't assume the forty-first device is fine because the first forty were. NetMon establishes a baseline of what belongs on a network and then treats anything that shows up afterward, unrecognised, as worth flagging — immediately, not at the next scheduled audit.
What actually happens when one shows up
For an MSP managing multiple client networks, this compounds. A single IT team might get away with an informal, "we'd probably notice" approach to one network they know intimately. An MSP managing dozens of client sites, each with its own layout, its own regular devices, its own normal — has no realistic way to hold all of that context in anyone's head at once. Automated baselining isn't a nice-to-have there; it's the only way the question "does everything on this
network belong" gets asked consistently across every client, rather than only on the networks someone happens to know well.
It also changes what an MSP can credibly promise. "We'd catch that" is a hard claim to prove and an easy one to be wrong about. "We get an alert the moment anything unrecognised joins any client's network, and we can show you exactly when it happened" is a claim backed by something concrete — a timestamped record, not a confident assertion.
The cost, restated
The real cost of a rogue device was never really about the device itself. It's the cost of not knowing — the security decisions made against an incomplete picture, the client conversations where "we'd have noticed" turns out to have been optimism rather than fact, the gap between what a network is assumed to look like and what it actually contains. Closing that gap doesn't require predicting who's malicious and who isn't. It just requires making sure the question
gets asked every single time, automatically, before the answer stops being interesting and starts being a genuine problem. That's the entire premise behind rogue-device detection in NetMon — not paranoia, just the plain discipline of actually knowing what's on the network you're responsible for.
The audit you'd never actually run manually
Ask any technician whether they'd be willing to manually audit every device on every network they manage, every day, cross-checking each one against a list of what's supposed to be there — and the honest answer is no, not because they don't care, but because it's not a realistic use of anyone's time against everything else on their plate. That's precisely why this keeps falling through the cracks industry-wide: it's not that rogue-device detection is hard to do
once. It's that doing it consistently, forever, on every network, is exactly the kind of tedious, easy-to-defer task that automation exists for.
That's also why "we'll add it to the next audit" is a weaker answer than it sounds. An audit is a snapshot — accurate on the day it happens, and steadily less useful every day afterward until the next one. A device that joins the day after an audit gets an entire cycle to sit there unnoticed. Continuous baselining doesn't have that gap. The question gets asked the moment it matters, not whenever the calendar next allows for it.
About the Author: Stephen Richards
Bio for Stephen Richards: Born in Colwyn Bay North Wales, Steve's introduction it Computers was at secondary school in 1974. That first year, Machine Code was hand written onto gridded paper and sent to Connah's Quay Technical College where is was copied to punch card and then entered into a mainframe computer. The results printed out were sent back for the following week!
Steve left School in 1976 joining the Royal Air Force to work on RADAR and communications equipment. His last 5 years involved working in an Automatic Test Equipment (ATE) department on the System Management Team and also writing models for Microchips. It was a good job that he had kept up with computers which had become rather a passion by the time he started in ATE.
During that time the main Mainframe we replaced in a £3.9 million upgrade reducing the run time of the biggest ATE program from just under 2 weeks to the time it took for a finger to come off a depressed return key!
Leaving the RAF after 18 years service Steve worked for a Charity (Apex Leicester Project) before returning to electronics at Sonatest in Milton Keynes which after 3 or 4 years led to a Job at Telematica the then development arm of Trafficmaster PLC (Tm). Eventually brought in-house at Tm he worked moved into the IT Support Team with his last project moving email from a Linux Box to Microsoft Echange for the 300 users in the company each of whom typically had 5 email addresses.
In 2006 Steve left to start his own company back in North Wales, Computer Technical Solutions was an MSP and moved to become an MSSP following another of Steve's passions Cybersecurity. Officially retiring in 2025, by May 2026 that overactive mind started thinking about all of the software he had seen not just for MSSPs but also for his clients that was either extremely expensive or that didn't exist with a complete answer to the needs of the SME.
By August 2026 two significant pieces of software have been created. Netmon the Network Monitoring Software and the second release Parkcore aimed at Caravan/Lodge Holiday Parks..... And so it begins!
