What's on My Network? Using Large Language Models to Identify Real-World IoT Devices at Scale
Paper • 2510.13817 • Published
Request API access
Model weights are not distributed. Approved requests receive credentials for the hosted inference API. Requests are reviewed by hand, usually within a week, and we may follow up by email before deciding.
By requesting access you agree that: you will use the model for research or network-administration purposes only; you will not use it to identify, deanonymize or target individual people or households; you will not resell, proxy or share your credentials; you will cite the CoNEXT 2026 paper in any resulting publication; and you will contact us for a higher rate limit rather than working around the one you are given. Credentials are issued to a named person, carry an expiry, and can be revoked.
Log in or Sign Up to review the conditions and access this model content.
What's on My Network? Identifying Real-World IoT Devices at Scale
A language model that tells you what a device is from the traces it leaves on the network -- a MAC prefix, a hostname it announced over DHCP, the domains it talks to -- and explains how it reached that answer.
Paper: What's on My Network? Using Large Language Models to Identify Real-World IoT Devices at Scale -- Proceedings of the ACM on Networking (CoNEXT 2026). Preprint: arxiv.org/abs/2510.13817. Access: weights are not distributed. Hosted inference is available on request -- use the access form at the top of this page.
Why this matters on a real network
Most organizations cannot answer a basic question about their own network: what is actually on it? Endpoint agents cover laptops and servers, but a large and growing share of what sits on a corporate LAN cannot run an agent at all -- cameras, badge readers, printers, sensors, conference-room displays, building controls, lab and medical equipment, contractor hardware, and whatever staff quietly plugged in. These devices appear in DHCP logs and traffic as a MAC address and a few scraps of text, and often nobody knows what they are, who owns them, or what they should be talking to.
That gap has practical consequences:
Asset discovery. Inventories are assembled by hand and go stale immediately. Identifying devices from traffic that is already being collected turns inventory into something continuous instead of an annual spreadsheet exercise.
Security monitoring. You cannot judge whether behavior is abnormal without knowing what the device is. A thermostat opening an SSH session matters; a laptop doing the same does not. Identity is what makes the rest of the signal interpretable.
Incident response. When an alert fires on an IP address, the first question is always what is that. Answering it from metadata already in hand saves the hours usually spent tracing a MAC to a switch port to a closet.
Network segmentation. Putting devices on the right VLAN presupposes knowing what they are. Identification is the step that makes zero-trust segmentation tractable for equipment that cannot authenticate itself.
Vulnerability and privacy assessment. Knowing a device's vendor and class is what lets you map it to advisories and end-of-life notices, and to see which devices are sending data off-network and to whom.
The hard part is that the metadata is thin and getting thinner. MAC addresses are randomized, hostnames are absent or meaningless, discovery protocols are encrypted, and the long tail of vendors is enormous. Traditional identification is a pile of rules over OUI tables and DHCP fingerprints, and those rules fail exactly where you need them most: on unfamiliar devices, in the tail, and under drift. Treating identification as a language problem over whatever metadata happens to exist lets the model degrade gracefully rather than return nothing, and lets it explain which evidence it leaned on so an analyst can judge whether to believe it.
Model Information
| Task | Identify a device's vendor from network metadata, with an explanation |
| Base model | Llama 3.1 8B |
| Training | Instruction tuning with curriculum learning over long-tail vendors |
| Vendors covered | 2,015 |
| Top-1 accuracy | 98.69% |
| Macro accuracy | 90.73% |
| Training corpus | IoT Inspector, real home networks, collected under IRB |
| Serving | 4-bit quantized on vLLM, greedy decoding |
| Availability | Hosted API; weights not released |
| License | CC BY-NC 4.0 |
What it reads
Every field is optional. The model is trained for sparsity, so more fields give a better answer but none is required -- which is the point, since on a real network you rarely have all of them.
| Field | Meaning |
|---|---|
oui_friendly |
Vendor from the MAC OUI lookup |
dhcp_hostname |
Hostname the device claimed over DHCP |
remote_hostnames |
Remote hostnames contacted, via DNS or TLS SNI |
user_agent_info |
User agent seen in plaintext HTTP |
mdns_info |
mDNS records, JSON |
ssdp_info |
SSDP records, JSON |
user_labels |
Any label the device's owner gave it |
talks_to_ads |
Whether it contacts known ad or tracking domains |
How it was built
Supervision was the bottleneck: the IoT Inspector corpus is large and real, but unlabeled. Vendor labels were generated with an ensemble of large language models and kept only where they were stable, using mutual-information and entropy-based scores to decide which labels to trust. The identification model was then instruction-tuned on that labeled set with curriculum learning, so that rare vendors are not drowned out by the head of the distribution.
Evaluation
98.69% top-1 and 90.73% macro accuracy across 2,015 vendors. Macro accuracy is the number to look at: it weights rare vendors equally with common ones, which is where rule-based identification collapses.
Beyond the headline, the paper evaluates the model on an independent IoT testbed rather than only on held-out data from the same source, measures what happens when individual metadata fields are withheld, tests behavior under protocol drift and deliberately spoofed or obfuscated input, and assesses the quality of the explanations themselves. See the paper for the full tables.
How to use
Access is gated. Request it at the top of this page: state your affiliation and what you intend to do, and agree to the terms. Requests are reviewed by hand, usually within a week, and approved requests get a personal API key by email. Keys carry a daily limit and an expiry and can be revoked.
If you run IoT Inspector you do not need to request anything -- device identification is built in.
curl -s -X POST "https://rameen-mahmood--dev-id-predict.modal.run" \
-H "Content-Type: application/json" \
-H "x-api-key: YOUR_KEY" \
-d '{"fields": {
"oui_friendly": "Amazon Technologies Inc.",
"dhcp_hostname": "echo-dot-jkl",
"remote_hostnames": "device-metrics-us.amazon.com"
}}'
{
"vendor": "Amazon",
"explanation": "The device is a smart speaker developed by Amazon."
}
Add "reasoned": true for a longer explanation that walks through the evidence.
Identifying many devices
The GPU scales to zero, so a request that arrives on its own pays about a minute of startup, while requests arriving together are nearly free. Send up to 100 devices per call rather than one call per device -- rate limits are metered on cold starts as well as devices, so batching is both cheaper and faster.
{"devices": [
{"mac_address": "...", "fields": {"oui_friendly": "..."}},
{"mac_address": "...", "fields": {"dhcp_hostname": "..."}}
]}
Cache results by MAC. Identifying the same device twice helps nobody.
Training data
We are not able to share the underlying data. It comes from real home networks collected under IRB, and the consent we have does not extend to redistribution -- device metadata stays re-identifying at the household level even after deidentification, so this is a constraint we are working within rather than a policy choice. Aggregate statistics and the label taxonomy we are happy to share; just ask. The same reasoning applies to the weights, since a model fine-tuned on hostnames from real homes carries a memorization risk we cannot rule out for third-party deployments.
Responsibility
Device identification is dual-use: the same inference that helps a team inventory its own network helps someone else profile a network they do not own. Access is gated, issued to named people with a stated purpose, and revocable, and the terms prohibit use against individuals or households. If you believe access is being misused, contact us.
Citation
@article{mahmood2026whats,
title = {What's on My Network? Using Large Language Models to Identify
Real-World IoT Devices at Scale},
author = {Mahmood, Rameen and Peddinti, Sai Teja and Ahmed, Tousif and
Huang, Danny Yuxing},
journal = {Proceedings of the ACM on Networking},
volume = {4},
number = {CoNEXT2},
articleno = {26},
year = {2026},
publisher = {Association for Computing Machinery},
doi = {10.1145/3808674}
}
Inference Providers NEW
This model isn't deployed by any Inference Provider. 🙋 Ask for provider support