From Classical ML to LLM-Powered Device Recognition — how we taught machines to identify every device on earth, and why we're now using AI to build the fingerprints themselves

Every network is a zoo. Smart TVs, industrial PLCs, MRI scanners, IP cameras, thermostats, managed switches, unmanaged printers, containers pretending to be hardware — all of them announcing themselves through dozens of network protocols. Some are cooperative. Many are not.

Our job is to figure out what each one is. Not just “it’s a printer” but specifically: this is an HP LaserJet Pro M404dn running firmware 002.2322A. That level of specificity is what unlocks lifecycle data, vulnerability mapping, and the kind of asset intelligence our customers need to make decisions.

We do this across more than two billion data records collected from our consumer app, enterprise customers, and B2B partners — spanning 68 supported protocols and a device landscape that grows more diverse every quarter.

And the technology behind it is — I think this is worth saying out loud — deliberately old-school.

Old-school ML, deliberately

Our device recognition engine leans heavily on classical machine learning. We use supervised segmentation approaches — ensembles of decision trees, random forests, and in some areas neural networks — trained on the billions of labeled observations in our data lake.

These models learn to map protocol signal patterns to device identities through statistical clustering and classification. This is a deliberate choice, not a constraint.

Device recognition at our scale has very specific requirements that favor these approaches:

Speed. Inference needs to happen on every device, on every scan, continuously — sometimes on edge agents with no cloud connectivity. The models need to be fast and compact enough to ship with the agent.

Interpretability. When a customer asks why a device was classified a certain way, we need to trace the reasoning back to specific signal patterns — not a black-box probability.

Incremental updates. New device types need to fold into existing models without retraining everything from scratch. Our Spark jobs update existing clusters incrementally, and every prediction can be traced to the specific features that drove the classification.

The result is a system that looks unfashionable by current standards but is extremely effective for this specific problem domain.

The architecture: evidence, not classification

The recognition engine is built around a concept we call leads. Every recognition source — whether a deterministic rule, an ML model, an enterprise credential scan, or a crowd-sourced user correction — produces an independent scored lead.

A lead is a hypothesis: I think this device is a specific type, brand, model, and OS, and my confidence in that hypothesis is a calibrated rank between 0 and 1.

We have dozens of recognition modules producing these leads, each specializing in different protocol signals. Some are the ML models described above. Others are rule-based: pattern matchers, protocol parsers, brand-specific helpers.

Per-field blending, not winner-takes-all

The key design decision is how conflicts are resolved. The blending engine does not pick a single winning source. Instead, it selects the best value for each identity field independently — type, brand, model, and OS can each come from a different source, whichever has the highest confidence for that specific field.

When multiple sources agree on a field, agreement bonuses compound the confidence. A weak signal that corroborates a moderate one produces a stronger result than either alone.

High-trust sources — like enterprise credential scans that report exact device identity — naturally dominate when available. Statistical models and heuristics fill in the gaps when they are not. No signal is ever discarded. The system gets incrementally better with every new data point, from every source, on every network.

The data lake: three worlds, one training set

The models are only as good as their training data. What makes ours unusual is that it comes from three fundamentally different sources that make each other stronger.

Consumer users — millions of people scanning their home networks through our Fing app — generate the broadest device diversity on earth. Every IoT sensor, every smart TV brand, every obscure router from a startup that launched last month. And they actively correct misidentifications, creating crowd-sourced labeled data covering the long tail of devices that no enterprise dataset would ever contain.

B2B partners — network equipment vendors like Netgear and Cisco — contribute telemetry from the infrastructure side. They see the network from a different vantage point than endpoint scanning, and their continuous feedback loop improves recognition across managed network environments.

Lansweeper business customers — across SMB, mid-market, and enterprise — contribute the most valuable data of all. Enterprise credential scans provide confirmed ground-truth labels at massive scale. When a device is identified via WMI as a Dell OptiPlex 7090 running Windows 11 23H2, that is not a statistical guess. That is the highest-confidence training signal in the system — one that makes every ML model smarter for every other network where the same device type appears without credentials.

The combination is what creates the moat. Consumer breadth, partner scale, enterprise ground truth. A competitor would need to build all three channels simultaneously and accumulate years of observations to approach it.

The bottleneck was never inference

For years, the workflow for expanding device coverage followed the same pattern. A data scientist would query our analytical databases for clusters of unrecognized devices. They would examine the SNMP sysDescr strings, DHCP option sequences, and MAC prefixes.

Then they would search vendor documentation — often scattered across multiple languages, PDF datasheets, and support forums — to identify the device family. Write a recognition rule. Submit a pull request. Code review. Regression testing. Deploy.

This process worked. Our recognition accuracy is a direct product of years of this disciplined work. But it has an inherent scaling problem.

The number of connected device types is growing exponentially. OT environments alone have introduced 26 protocol categories we now support. Medical devices add four more. Each category has dozens of vendors, and each vendor has hundreds of model variants with firmware-specific fingerprint variations.

Each investigation takes 30 to 90 minutes of expert time. The long tail of rare devices rarely gets prioritized. And the knowledge about how to research a specific vendor’s product line lives largely in the heads of the people who have done it before.

The bottleneck was never the ML models. It was fingerprint engineering: the human work of researching what a device is and encoding that knowledge into a form the recognition engine can use.

Enter LLM-powered deep research

This is where we started applying a genuinely different approach. We are now building MLOps workflows that use Claude Code and LLM-based deep research to automate the most time-consuming parts of the fingerprint engineering process.

Surfacing the highest-impact unknowns

The pipeline starts with what we already have. Automated jobs surface the highest-impact unknown device clusters from the data lake — devices with rich protocol fingerprints but no specific model-level recognition, ranked by prevalence × fingerprint richness. These are the devices where a new fingerprint would have the most impact.

Deep research: investigating the device

The LLM then performs deep research. Given a cluster of unrecognized devices sharing a common SNMP sysDescr pattern — say, “Siemens SIMATIC S7-1500, FW V2.9.4” appearing across 14,000 instances on 890 networks — the system searches vendor product documentation, firmware release notes, technical datasheets, and community forums.

It identifies the exact product family, the firmware versioning scheme, the OT protocol category, and the device classification hierarchy. The output is not a report. It is a working recognition artifact.

Two kinds of output

For straightforward cases, the system generates configuration fingerprints: structured definition files that map a protocol pattern to a device identity and slot into the existing fingerprint tables without code changes.

For complex cases — where a vendor embeds model information in protocol fields using proprietary encoding — it generates parser code: brand-specific SNMP miners, SSDP drivers, or protocol handlers that extract type, brand, model, and operating system from raw protocol data.

Every generated artifact goes through the same governance pipeline as human-written code. Automated regression testing. Confidence rank calibration review. Staged rollout. The LLM accelerates creation. The existing quality gates ensure correctness.

What actually changed

The shift is not about replacing the team. It is about changing what the team spends time on.

Instead of manually researching vendor documentation for the 500th SNMP sysDescr pattern, the data scientists now review and refine LLM-generated fingerprints. They focus on architectural improvements to the recognition engine itself. They design new ML features for the Spark analyzers. They work on problems that genuinely require human judgment and deep domain expertise.

The throughput improvement is significant. Device categories that would have taken weeks — an entire OT vendor’s product line, a hospital’s worth of medical imaging equipment, a factory floor of Modbus-speaking controllers — can now have initial fingerprint coverage generated in hours rather than weeks.

But the more important change is in what becomes possible at all. The long tail of rare devices — the ones seen on only a few hundred networks, never important enough to prioritize manually — can now be addressed. Customers with niche OT environments or specialized medical equipment often have the most urgent need for accurate device recognition, precisely because their devices are the ones that generic tools miss.

The compounding effect

There is one more dynamic worth describing, because it explains why this approach gets better over time rather than plateauing.

Every new fingerprint — whether generated by a human or an LLM — feeds back into the data lake. The next time the ML models retrain, the newly recognized devices contribute confirmed labels that improve recognition of similar devices across all networks.

A fingerprint for one Siemens PLC model improves the MAC clustering model’s understanding of the entire Siemens MAC address range. A new medical device parser improves DHCP fingerprinting for the vendor’s entire product line. The LLM workflow does not just add individual fingerprints. It accelerates the entire flywheel that makes the statistical models smarter.

What comes next

We are early in this integration. The current pipeline focuses on the highest-impact unrecognized device clusters. But the direction is clear.

As we expand passive traffic observation capabilities, the volume of protocol signals feeding the pipeline will grow substantially. More signals means more devices with rich fingerprints waiting to be identified — and more opportunities for the LLM to investigate.

We are building closed-loop validation where LLM-generated fingerprints are automatically tested against credential-scan ground truth. When a fingerprint correctly identifies a device that a credential scan later confirms, it is promoted. When it does not match, it is flagged for review.

And the same deep research capability extends naturally into catalog enrichment — discovering lifecycle dates, firmware update timelines, and vulnerability advisories from the same vendor documentation the LLM already reads during device investigation.

We are not replacing old-school ML with deep learning. We are using LLMs to feed the old-school ML better data, faster. The statistical models stay. The human experts stay. What changes is the pace at which the system learns new devices.

And in a world where the number of connected device types is growing faster than any team can manually catalog, that pace might turn out to be the most important thing we changed.