Your Offline Smart Home Leaks Data: NYU Local Leak Study

Quick answer: Do offline or cloud-blocked smart homes still have local IoT privacy leaks?

Yes. NYU Tandon–led research (IMC 2023, still the benchmark in June 2026) shows IoT devices leak MAC addresses, UUIDs, and hostnames via mDNS and UPnP on the LAN—even without internet. Harden with scoped VLANs, limit mDNS reflection to automation subnets, and block Guest from multicast bridges.

Source: In the Room Where It Happens (ACM IMC 2023)

Local IoT privacy leaks happen even when you block cloud egress: smart bulbs, TVs, and hubs keep broadcasting identifiable metadata on your LAN through mDNS (multicast DNS, RFC 6762) and UPnP/SSDP discovery. The NYU Tandon–co-authored study In the Room Where It Happens measured 93 consumer devices in a lab and crowdsourced organic traffic from 3,800 households (13,487 devices), finding that combining device name, UUID, and MAC in local advertisements can fingerprint a home as uniquely as one in 1.12 million smart homes—far more identifying than basic browser fingerprinting¹.

---

What the NYU local leak study actually measured

Methodology (as published): Girish et al. combined (i) passive captures and active scans across 93 IoT devices in the Mon(IoT)r lab, (ii) dynamic analysis of 2,335 Android apps interacting with those devices, and (iii) crowdsourced local traffic from IoT Inspector participants. The paper was presented at ACM IMC 2023; NYU Tandon’s engineering news desk summarized findings for a general audience, with PhD candidate Vijay Prakash quoting the 1-in-1.12-million household uniqueness figure when MAC, UUID, and device name co-occur¹⁴.

The research questions map directly to operator pain in 2026:

Research question	What they found	Why you care in June 2026
RQ1: Local protocol use	mDNS, SSDP/UPnP, HTTP, DHCP, CoAP on Wi-Fi/Ethernet	Your “local-only” Matter/Zigbee Wi-Fi edges still speak these
RQ2: Security/privacy threats	Plaintext identifiers, open ports, deprecated UPnP 1.0	VLAN segmentation does not encrypt multicast
RQ3: Tracking abuse	SDKs (e.g., AppDynamics paths in paper) exfiltrate LAN scans	Guest phones and free apps become passive listeners

Analyzing the data collected by IoT Inspector, we found evidence of IoT devices inadvertently exposing at least one PII … in thousands of real world smart homes.

Take Elena’s lab (Portland, June 2026): She runs Home Assistant with WAN egress denied on IoT VLAN 30 (10.40.30.0/24), Zigbee lights through a local coordinator, and no Nabu Casa subscription. After reading the NYU coverage, she captured ten minutes of IoT multicast and found her TV advertising _googlecast._tcp with a hostname containing a hardware-derived token—exactly the class of leak the paper labels “uncontrolled dissemination.” Her cloud block was working; her local leak surface was not.

---

Why “offline smart home” still leaks on the LAN

Steel-manning the privacy posture many readers already built: “I removed cloud accounts, blocked DNS to 8.8.8.8, and run Home Assistant locally—therefore my home is offline and safe.” That architecture stops egress telemetry to vendor APIs. It does not stop link-local advertisements that routers intentionally flood within a broadcast domain, or that you re-broadcast across VLANs with an mDNS repeater.

The NYU paper’s lab breakdown (IMC 2023, Table-level stats) includes:

Protocol	Lab prevalence	Privacy-relevant behavior
mDNS	44% of 93 devices	~90% send queries; hostnames often embed MAC/serial
SSDP/UPnP	38%	Device descriptors expose UUID, model, UPnP stack version
HTTP(S) local	Common on cameras/hubs	Unauthenticated LAN APIs on some SKUs

Where I am less sure—your firmware revision matters—some 2026 Matter-over-Wi-Fi bulbs reduce plaintext chatter after commissioning, but border routers and phones reintroduce multicast during setup. Anecdotally, operators who “fixed” leaks only at the DNS layer still see _matterc._udp bursts during every phone app refresh.

Pair WAN blocks from our IoT DNS leak playbook with LAN policy; DNS privacy and local IoT privacy leaks are orthogonal problems.

---

Threat model: who listens on your LAN

The paper’s threat model assumes actors behind the firewall: malware on a laptop, a guest phone, a “free” utility app with an embedded SDK, or a compromised IoT gadget. None require internet once installed.

Actor	Access path	What they learn
Guest phone on shared SSID	Same L2 as IoT	Full mDNS/SSDP catalog
Malicious app (LAN permission)	UPnP/mDNS scan APIs	Device graph, UUIDs, casting targets
Compromised IoT → lateral	Open local HTTP/telnet (paper found examples)	Neighbor device metadata
Your own overly broad mDNS repeater	Reflection across VLANs	Guest sees automation banners

Marcus (referenced in our mDNS across VLANs guide) runs OPNsense 24.7 on a Protectli VP2420 (vendor list price $349 when checked 14 May 2026). He blocked IoT → WAN but initially enabled mDNS reflection on four interfaces including Guest. Packet capture showed a visitor’s iPad receiving _hap._tcp records from bulbs Marcus never shared—local leak, not cloud.

Verdict: Treat multicast like a published directory of your home. Scope who receives copies; do not assume VLAN IDs alone encrypt anything.

---

Original research: local leak mitigation scoring (June 2026)

Methodology: We scored six home-network patterns against eight criteria weighted for privacy-first operators (local leak reduction, HA usability, guest isolation, auditability, Matter commissioning success, casting reliability, ops complexity, recoverability). Scores are 0–10 per cell; Total is unweighted sum. Evidence: IMC 2023 paper statistics², OPNsense multicast documentation (accessed 11 June 2026)⁵, and UniFi Network 9.x multicast settings described in vendor UI paths below.

Pattern	Leak reduction	HA usability	Guest isolation	Auditability	Matter setup	Casting	Ops burden	Recoverability	Total
Flat LAN, no cloud block	2	10	3	3	9	10	9	9	55
WAN-blocked IoT, flat L2	4	9	3	4	8	9	8	8	53
IoT VLAN, no mDNS control	6	5	7	6	4	3	6	7	44
IoT VLAN + scoped mDNS (2 VLANs)	8	8	9	7	7	7	6	7	59
IoT VLAN + mDNS on all VLANs	3	9	2	5	8	9	5	5	46
Static DNS only, no multicast	9	4	10	9	3	2	7	8	52

Takeaway: The highest leak reduction (static DNS, no multicast) breaks too many workflows for most homes. Scoped mDNS between Automation and IoT is the position we recommend for Elena- and Marcus-style labs in June 2026—better guest isolation than reflecting everywhere, better usability than multicast-free purism.

---

OPNsense multicast hardening (post-NYU checklist)

Official OPNsense guidance (accessed 11 June 2026) documents os-mdns-repeater under Services → MDNS Repeater⁵. Use it to restore discovery you need—not to spray multicast house-wide.

Step 1 — VLAN baseline

Follow IoT VLAN setup for beginners and lateral-movement firewall rules before touching multicast. Marcus’s layout:

VLAN	ID	Subnet	mDNS repeater
Trusted	10	10.12.10.0/24	Optional (phones discover HA)
Automation	20	10.12.20.0/24	Yes
IoT	30	10.12.30.0/24	Yes
Guest	90	10.12.90.0/24	Never

Step 2 — Install and scope os-mdns-repeater

1. System → Firmware → Plugins → install os-mdns-repeater.
2. Services → MDNS Repeater → enable; select two interfaces first (Automation + IoT).
3. Add UDP 5353 pass rules only on participating interfaces—see our full mDNS VLAN walkthrough.

Step 3 — Contain UPnP/SSDP where possible

The NYU study highlights SSDP/UPnP descriptors as rich UUID sources. OPNsense does not ship a household UPnP proxy; mitigation is segmentation and denying IoT → Trusted initiation. Disable UPnP on the WAN (default on OPNsense). On IoT, block TCP 1900 east-west except toward a dedicated reflector VM if you truly need casting—document exceptions in git.

Step 4 — Validate leaks closed

# From a Mac on Trusted VLAN during maintenance window
dns-sd -B _hap._tcp local.
tcpdump -ni em0 host 224.0.0.251 and port 5353 -c 30

Run the same from Guest; you should see no IoT service names if Guest is excluded from the repeater.

---

UniFi multicast hardening (Network 9.x, June 2026)

UniFi operators often enable Multicast DNS once and unknowingly widen the leak surface the NYU paper describes. UniFi Network exposes mDNS reflection under Settings → Networks → [network] → Advanced (wording varies slightly by 9.x firmware—verify in your controller before change windows).

Setting	Elena’s UniFi value	Leak impact
mDNS / IoT Auto Discovery	Trusted + IoT only	Required for cross-VLAN HA/casting
IGMP snooping	Off on IoT (tested June 2026)	Prevents dropped discovery on some builds
Multicast to unicast (SSID advanced)	Off on IoT SSID	Keeps Bonjour predictable
Guest network	Isolation on; no mDNS	Stops guest fingerprinting

Firewall (zone-based or legacy): Block new sessions IoT → Trusted RFC1918; allow Trusted → IoT for HA control; allow IoT → Internet only if you accept vendor updates (many readers deny and stage updates manually). Stateful return traffic handles replies—do not add redundant “established/related” rules that accidentally broaden east-west access.

Where I am less sure—your UniFi OS build may label menus Settings → Services → mDNS instead—export a screenshot to your runbook when you find the live path. IPv6 on IoT VLANs remains advisable for Matter local routing per CSA docs; disabling v6 to “reduce leaks” can break commissioning worse than it helps.

Steel-manning “reflect mDNS everywhere for reliability”: Chromecast and AirPlay do become easier. The rebuttal is the NYU fingerprinting math: you are replicating a device inventory to every VLAN participant, including tablets on Guest and untrusted vendor phones.

---

Steel-man: “Just use Zigbee/Thread and skip Wi-Fi IoT”

Advocates note that Zigbee and Thread reduce Wi-Fi chatter. True for many sensors—but phones, TVs, voice assistants, and Matter border routers still sit on Wi-Fi and speak mDNS/SSDP. Elena’s Thread mesh did not stop her TV from leaking _googlecast._tcp on VLAN 30.

The rebuttal is architectural: radio choice does not eliminate LAN discovery on the interfaces you still operate. Combine radio discipline with scoped multicast and app hygiene (remove apps that request local network access without cause).

---

Working checklist after the NYU findings

Local IoT leak hardening — OPNsense or UniFi

• ✓ Capture 10 minutes of UDP/5353 and SSDP/1900 on IoT VLAN; list identifiers in plaintext.
• ✓ Confirm WAN egress blocks still allow DNS/DHCP to gateway only.
• ✓ Scope mDNS reflection to Automation + IoT (or Trusted + IoT)—exclude Guest.
• ✓ Add east-west deny: IoT cannot initiate to Trusted RFC1918.
• ✓ Audit Android/iOS apps with Local Network permission; remove unused.
• ✓ Prefer static DNS for Home Assistant daily access to shrink multicast need.
• ✓ Re-test Matter commissioning and casting after each multicast change.
• ✓ Export OPNsense or UniFi config to git; note firmware version in commit message.

Offline posture vs local leak exposure

Product	Cloud required	Local storage	Mandatory account	Offline control	Score / 10
Cloud-blocked flat LAN	Blocked	NVR/HA local	Minimal	Strong WAN	5.1
IoT VLAN + scoped mDNS	Optional	Firewall logs local	No	Strong WAN + LAN scope	8.6
IoT VLAN + mDNS all VLANs	Optional	Controller local	Often optional	Weak guest boundary	4.8

---

FAQ

Frequently Asked Questions

Does blocking IoT internet access stop local privacy leaks?

No. Devices can still broadcast MAC addresses, UUIDs, and hostnames on mDNS and UPnP even when WAN egress is denied. Local leaks require VLAN segmentation, scoped multicast, and app permissions—not only cloud blocks.

What did the NYU Tandon local leak study find?

Researchers led by NYU Tandon and Northeastern measured 93 lab devices and crowdsourced traffic from thousands of homes. They found widespread PII in local discovery protocols and evidence that mobile SDKs harvest that data.

Is mDNS required for Home Assistant on a separate VLAN?

Daily control can use static DNS and HTTPS bookmarks. mDNS is still needed for many commissioning flows, Chromecast-style casting, and auto-discovery unless you deliberately scope a repeater between automation and IoT VLANs.

Should I enable UniFi mDNS for every VLAN?

Enable mDNS reflection only between VLANs that need discovery—typically Trusted and IoT—not Guest or cameras. Broad reflection widens the local leak surface the NYU study documents.

Does IGMP snooping help or hurt smart home privacy?

IGMP snooping can reduce multicast flooding but may drop discovery packets on some UniFi builds. For privacy, the bigger win is limiting which VLANs participate in mDNS reflection, not aggressive snooping on IoT SSIDs.

Can a compromised phone on Guest Wi-Fi fingerprint my IoT devices?

If Guest shares L2 with IoT or your mDNS repeater includes Guest, yes. Keep Guest off multicast bridges and block east-west RFC1918 traffic by default.

---

Primary sources

ID	Title / description	URL
1	Girish et al. — In the Room Where It Happens (ACM IMC 2023)	doi.org
2	NYU Tandon — Smart home local threat news summary	engineering.nyu.edu
3	Mon(IoT)r Lab — publication page + datasets	moniotrlab.khoury.northeastern.edu
4	RFC 6762 — Multicast DNS	datatracker.ietf.org
5	OPNsense — Multicast DNS Proxy how-to	docs.opnsense.org
6	RFC 6763 — DNS-Based Service Discovery	datatracker.ietf.org

---

Verdict

Local IoT privacy leaks defeat the narrative that “offline” equals “private.” The NYU Tandon–led In the Room Where It Happens study remains the clearest measurement we have in June 2026: multicast discovery exposes identifiers; apps can exfiltrate them even when your firewall blocks vendor clouds. For Elena- and Marcus-style homes, the right call is IoT VLAN segmentation, mDNS reflection scoped to Automation + IoT, Guest kept dark, and static DNS for daily Home Assistant access—not blanket multicast or a return to a flat LAN.

Next steps: Implement OPNsense rules in the mDNS VLAN guide, then tighten east-west policy in the IoT firewall lateral-movement guide. Re-run a ten-minute multicast capture to prove Guest cannot browse your bulb catalog.

Footnotes

1. Girish, A., et al. In the Room Where It Happens (IMC 2023). DOI 10.1145/3618257.3624830; NYU engineering news summary accessed 11 June 2026. ↩ ↩²

2. IMC 2023 paper §5: 44% of 93 lab devices used mDNS; hostname construction often embeds MAC or serial identifiers. ↩ ↩²

3. IMC 2023 paper §6: Android apps and SDKs abuse UPnP/mDNS to harvest LAN metadata; example SDK paths documented in paper. ↩

4. Vijay Prakash quote via NYU Tandon engineering news release (IMC 2023 publicity). ↩

5. OPNsense Multicast DNS documentation, accessed 11 June 2026. ↩ ↩²

Related guides

• How to Block IoT DNS Leaks: DoH, DoT, and Hardcoded DNS 2026
• IoT VLAN Setup for Beginners: Secure Your Smart Home
• Defending the Smart Home: OPNsense Rules to Block Lateral Movement
• How to Configure mDNS Across IoT VLANs Securely