Left on Default

The topic of cybersecurity - especially the "everyday" kind we brush against without even realizing it - is particularly close to me. Today we can use technology not only to create, but also to study the phenomena around us. So I decided to take a look at what our everyday digital lives look like in the radio spectrum - the signals our WiFi- and Bluetooth-based devices broadcast to their surroundings all the time, in the background.

This article grew out of one of my side projects. It is about simply listening to what is publicly available over the air as I move around the city and travel - and about the implications for our security.

Opinions are my own. Nothing here is professional security advice.

What the study involved

I recorded what signals my mobile device "sees" in its immediate surroundings as I move around the city, using a phone app I wrote myself - though you can just as easily use publicly available ones. To be precise about what that means: at its core this is the same information any phone gathers the moment you open its WiFi or Bluetooth list. The app recorded that scan metadata as returned by the phone's operating-system APIs, including technical fields (the WPS flag and the Bluetooth address used for the address-format heuristic) that the everyday interface does not show. It did not connect to WiFi networks, pair with Bluetooth devices, authenticate, or exchange application data. Two things interested me:

• WiFi: which access points were in range, how they are secured, and what they are named.
• Bluetooth: which broadcast addresses were visible and whether their bit patterns were consistent with address randomization (more on that in a moment).

An important caveat up front: I am not counting unique physical devices. For WiFi, I count unique BSSIDs - the access-point addresses reported by the phone's scan results; a single physical router or mesh system may contribute several BSSIDs across bands, guest networks or nodes. For Bluetooth Low Energy, I count unique broadcast addresses. To give a sense of scale: 48,000+ unique WiFi BSSIDs and 42,000+ unique BLE addresses came into range. These are observations gathered over a few weeks of walks around Warsaw, Poland.

One more word about those publicly available apps, because it fits the theme of this article a little too well. Some scanning apps are intentionally designed to contribute observations to shared or public databases. That can be useful, but before using one, check what is uploaded, how long it is retained, and who can access it - a healthy dose of skepticism is the right default here. For this project I wanted a private dataset, so I used my own tool and infrastructure: I know exactly how the data is collected, where it is stored, and that it goes no further.

WiFi: one piece of good news and a few warning signs

I still remember the days when there was a lot of talk about moving from the WEP protocol to WPA2. WEP was a form of protection that was easy to break, and it was rightly heading for the scrapheap.

And here is the first, positive observation: WEP has practically disappeared. Today, almost everyone uses WPA2, with WPA3 becoming increasingly common.

Two labels there may be unfamiliar: WPA2-EAP is the enterprise, login-based variant you meet at offices and campuses, and OWE is encrypted open WiFi: no password is required and the radio link is encrypted, although the network does not authenticate itself to you the way a password-protected one does.

Moving away from WEP is not a matter of taste. The standard was deemed insecure more than two decades ago, and since 2018 the direction of travel has been WPA3 - with stronger key agreement and protection even for weaker passwords.

Source: Wi-Fi Alliance, WPA3 security program

That is a good sign, and largely thanks to the default settings of internet providers. When you order home internet, the router usually arrives with WPA2/WPA3 already set from the start. The user does not have to do anything, and that is the whole point. But - and this is where our titular "default" begins - the same default setting that helps us can also leave a few doors open. Here are three worth paying attention to. Only one of them is purely a default problem, but it happens to be the most common.

Research shows how strongly provider choices can shape the result. A 2012 wardriving study of 7,847 access points in Leeds, UK found large ISP-correlated differences: 98.9% of observed Virgin Media access points used WPA2, while 38.6% of O2 access points still used WEP. The authors argued that ISP configuration and equipment-upgrade policies were an important influence on home-network security.

Source: "Not All ISPs Equally Secure Home Users" (SECRYPT 2013)

1. Some hardware is still stuck on old protocols

Despite the great overall picture, a small number of access points still use WPA(1) and WEP - around 160 in total, well under half a percent of everything seen. This is usually old equipment that someone forgot about. The obvious move here, if it were my router, would be to go into the settings and switch to the highest available protocol - WPA2 at the very least, WPA3 where the hardware allows.

2. WPS: convenience that lowers the bar

This is the most interesting finding of this section. WPS (Wi-Fi Protected Setup) is a simplified way of connecting to a network - via a PIN or a button, without typing a password. The problem is that on many routers its PIN method can lower security no matter how strong your WiFi password is - it applies to WPA2 and WPA2/WPA3 mixed-mode networks alike, because that PIN is easier to attack than the password itself.

And there is a lot of it: 40.5% of the observed BSSIDs (roughly 19,600 access points) advertised WPS support. That flag does not show whether the PIN method is active or vulnerable. I also grouped the flagged BSSIDs by inferred hardware or provider family, but this is not a vendor security ranking: the shares are not normalized by each group's presence along my routes, and the attribution is approximate. The largest observed groups were:

Two more notes on reading the chart: the shares largely reflect how common each brand simply is along the routes I covered, and one of the labels, Kaon, is a hardware maker whose boxes several providers ship, not an operator. What the chart shows is that advertised WPS support appears in broad equipment families, not in scattered individual setups. The clustering warrants questions about model- or provider-level configuration, not conclusions about a company or a verified factory default.

The vulnerability is not theoretical. Back in 2011, CERT/CC warned that the design of the eight-digit WPS PIN reduces the effective search space to about 11,000 attempts, and that on routers without an effective lockout policy an attacker within radio range could recover the network password. The recommended fix was, and remains: disable the WPS PIN function if you are not knowingly using it.

Source: CERT/CC, Vulnerability Note VU#723755

To be fair, this is not uniformly dangerous today: the weakness hit older routers hardest, and many newer models harden or disable the PIN method. And to be precise about what my numbers show: what I record is the WPS flag a network advertises - it cannot tell whether the vulnerable PIN method is actually active underneath. But from the outside you usually cannot tell which default you got either - and that uncertainty is exactly the point. So the low-effort takeaway, the one I would follow myself, is to turn WPS off if you are not consciously using it (and most people are not). You gain a little security while losing practically nothing.

3. Network names: when an SSID says too much

Here the matter is more debatable. The default name from the manufacturer itself (something like Orange_home_02) is usually low-risk - though, as the WPS chart above shows, even a default label quietly tells everyone which provider or hardware family sits behind the network. But there are two nuances.

First, you can hide the network name (a hidden SSID): the network does not appear on the list of available ones, and you connect by typing the name manually. In the study, a hidden SSID was used by 12.4% of observed access points - but I mention it because the data shows people do it, not because it is worth copying. It is not real protection (the name still travels in other frames anyone can see), and it can even backfire: depending on the operating system and settings, a phone or laptop saved to a hidden network may keep sending directed probes for that name wherever it goes, which can make your devices easier to recognize elsewhere, not harder.

Second, and more important: be careful about naming a network in a way that reveals whom it belongs to. I saw networks named with a first name, someone's initials, a company name, or in a way that plainly suggests the owner or a specific property. It is a small thing that, combined with location, can tell a stranger more than you would want.

A network name is public by design - everyone in range can see it, whether or not they can connect. So it is worth keeping anything that identifies the owner, the family, or the address out of it.

Bluetooth: privacy that comes built in

Bluetooth is the second major stream of signals we encounter every day in enormous quantities - headphones, watches, bands, trackers, gear in cars. And here a lot of the work is already being done for us: many modern BLE devices use private, rotating addresses automatically, which makes a stable address much less useful for long-term tracking.

What is anonymization about? Every radio device has a MAC address - a kind of digital "serial number" visible in the air. If it were fixed, it would be possible to track that the same device shows up in the same place every day, travels the same route, comes home at the same time. That is why modern devices randomize (rotate) their MAC address every so often, to make such profiling much harder.

The mechanism appears to be in wide use - though here I owe you the biggest caveats of the whole study. First, what my scanner sees are broadcast addresses, not physical devices: a rotating device leaves behind many addresses while a fixed one leaves just one, so none of these percentages is an estimate of how many physical devices rotate. Second, the classification itself is a heuristic. The Bluetooth specification defines these subtypes by an address's two most significant bits only once the address is already known to be a random (not manufacturer-assigned) one - and scan data does not always carry that information. What I could do is read each address's bit pattern and filter out addresses with known manufacturer prefixes; a public address with an unregistered prefix can still land in either bucket and inflate it. With that in mind: 41.7% of the observed addresses match the resolvable-private bit pattern - the format designed to rotate. 29.2% match the random-static pattern - random-looking, but typically stable for long stretches, so trackable in practice. The remaining 29.1% carried a known manufacturer prefix or matched neither pattern. Treat all three shares as estimates of address formats, not as a precise classification of addresses - let alone devices.

This is not a matter of individual manufacturers. Address privacy is written directly into the Bluetooth Low Energy specification (the so-called resolvable private address, designed to reduce trackability). Apple documents randomized Bluetooth addresses across its platforms, and on the WiFi side Android has shipped randomized MAC addresses by default since Android 10.

Source: Bluetooth SIG, on address privacy (LE Privacy), Apple Platform Security (Bluetooth) and Android documentation (WiFi MAC randomization)

Where it is implemented, address privacy works automatically, with no action needed from the user - and in those cases, "default" works in our favor.

What I would change at home

To be clear, I am not a security engineer - just someone who spent a while looking at this data. So treat the following as the sensible, low-effort steps the numbers kept pointing to, not as expert instructions. Even doing a couple of them puts you ahead.

If you have WiFi at home:

• Use WPA3-Personal when all your devices support it; otherwise WPA2 with AES/CCMP - and disable WEP, WPA/TKIP and legacy compatibility modes where possible.
• Turn off WPS if you are not knowingly using it.
• Do not name the network in a way that reveals who owns it (first name, surname, address, company).
• Change the router's administration password if it still uses a shared or easily guessed factory default - a strong, unique password printed on your specific unit is a different story from a universal "admin".

If you use Bluetooth:

• Keep your devices' firmware and your phone's system updated - address-privacy improvements ship with updates, and most accessories expose no setting to toggle anyway.
• Turn Bluetooth off when you are not using it - less signal in the air means less of a trace.
• With trackers (AirTag and the like), be aware of how their privacy and "unknown tracker" alerts work.

Waiting for this to fix itself is not a strategy. When Finnish researchers surveyed home networks through the pandemic, WLAN deployment grew by 50.2% while security barely moved: the share of unencrypted and legacy-encrypted networks stayed essentially flat, and WPA3 adoption did not notably increase. Where improvement depends on the user rather than the shipped default, very little happens.

Source: Lindroos, Hakkala, Virtanen, "The COVID-19 pandemic and remote working did not improve WLAN security" (2022)

The common denominator: default settings solve some of the problems for us, but not all of them. Spending a few minutes in the device settings turns "default" from a quiet enemy into an ally.

Study details

For the curious, in a few points:

• Method: my mobile app recorded WiFi and BLE scan metadata exposed by the phone's operating-system APIs. I did not associate with WiFi networks, pair with Bluetooth devices, authenticate, or exchange application data.
• Period and scale: data was collected over a few weeks of walks around Warsaw. The denominators are 48,000+ unique WiFi BSSIDs (access-point addresses) and 42,000+ unique Bluetooth Low Energy broadcast addresses; the WPS chart's denominator is the roughly 19,600 BSSIDs that advertised WPS. These are identifiers observed in scan results, not estimates of physical routers or devices: one WiFi installation may contribute several BSSIDs, and one rotating BLE device may contribute many private addresses.
• Classification: WiFi security and the WPS flag come from what each access point advertises in its beacons (a capability, not a verified vulnerability); Bluetooth address formats are classified heuristically from each address's bit pattern, filtered against known manufacturer prefixes - the Bluetooth specification makes those bits definitive only for addresses already known to be random, so the BLE shares are estimates, not exact counts, and say nothing about a device's actual rotation behavior; the router-brand grouping is inferred from hardware address prefixes and naming patterns. Categories within each chart are mutually exclusive, and percentages may not sum to exactly 100 because of rounding.
• Representativeness: this is a slice from specific routes in Warsaw. Results may differ locally - a different city or a different type of development would give a different picture. These limits (route selection, sampling bias) are well documented for this whole class of study - see Sources.
• Privacy: everything in this article is reported in aggregate only. No individual network, device, or location is identified, published, or shared. The raw data never left my own infrastructure, and it was deleted once the analysis was complete (see the note at the end).
• What I deliberately do not describe: the technical details of the analysis - nothing here is meant to help link a signal to a specific person or place.

This article is about flagging the problem with leaving things on default - it is not a how-to guide for running a similar study.

Sources

The background and recommendations in this text rely on public, widely recognized sources:

• Wi-Fi Alliance - certification and security program for WPA3 (introduced in 2018). wi-fi.org
• CERT/CC - Vulnerability Note VU#723755, "Wi-Fi Protected Setup (WPS) PIN brute force vulnerability" (2011). kb.cert.org
• Bluetooth SIG - Bluetooth technology and privacy: address randomization / LE Privacy (resolvable private addresses). bluetooth.com
• Apple - Platform Security: Bluetooth privacy and randomized device addresses. support.apple.com
• Bluetooth Core Specification - random device address subtypes (resolvable private, non-resolvable private, static). bluetooth.com
• Android Open Source Project - default WiFi MAC address randomization (Android 10+). source.android.com
• "Not All ISPs Equally Secure Home Users" - wardriving study of ISP router defaults in Leeds, UK (SECRYPT 2013). scitepress.org
• Lindroos, Hakkala, Virtanen - "The COVID-19 pandemic and remote working did not improve WLAN security", Procedia Computer Science (2022). pmc.ncbi.nlm.nih.gov
• Cunche, Kaafar, Boreli - "Linking wireless devices using information contained in Wi-Fi probe requests", Pervasive and Mobile Computing (2014) - on devices calling out the names of saved networks. sciencedirect.com
• Oughton, Kusuma, Peyronel, Crowcroft - "Wi-Fi Wardriving Studies Must Account for Important Statistical Issues" (2021) - on selection bias and representativeness in wardriving data. arxiv.org

A final note on the data behind this article: the raw scan records were used solely to produce the aggregate results presented here and for no other purpose. After the analysis was completed, the raw dataset - including all backup copies - was deleted.

Thanks for reading.