Map collection, inference and sharing
In the context of proximity technology, tracking without consent means collecting information about a person's movement, presence or device behaviour within a physical space without a valid legal basis and without the individual's informed agreement. For UK organisations using beacons, Wi-Fi access points, NFC readers or indoor positioning systems, this is not an abstract risk but a practical compliance question that arises the moment a deployment moves beyond simple one-way broadcasting.
A Bluetooth beacon that only transmits a packet does not, by itself, track anyone. The tracking capability appears when a receiving system—such as a gateway, a scanner or an app—logs the presence, identifier or signal strength of a device that has picked up that transmission. At that point, data is being collected, and UK GDPR and the Data Protection Act 2018 apply. The Privacy and Electronic Communications Regulations (UK) add further requirements around electronic communications data, which can include MAC addresses and device identifiers picked up by network equipment.
The Information Commissioner's Office (ICO) treats a MAC address as personal data when it can be linked to an individual, even indirectly. Modern smartphones randomise their MAC addresses when scanning for Wi-Fi and Bluetooth, which reduces the risk of persistent tracking but does not eliminate the legal question. If a system records a randomised MAC address alongside a timestamp and location, the ICO's guidance requires organisations to assess whether that data could, in combination with other information, identify an individual. The assessment depends on the specific deployment, not on a blanket assumption.
Consent under UK GDPR must be freely given, specific, informed and unambiguous. Pre-ticked boxes, bundled consent clauses buried in general terms and conditions, or making a service conditional on accepting tracking that is not necessary for that service all fail the standard. For proximity deployments, this means the consent mechanism must clearly explain what is being collected, why, and for how long—before any collection begins.
Operational safeguards for handling the data
Where tracking without consent commonly occurs
The highest-risk scenarios are not usually deliberate surveillance but systems designed for one purpose that quietly collect more than intended. A common example is a Wi-Fi access point or beacon gateway deployed for footfall counting. The hardware vendor may describe the output as "anonymous aggregate data," but the underlying process involves logging individual device probes or beacon detections. If those logs are retained, exported to a third-party analytics platform, or combined with CCTV or loyalty-card data, the original anonymisation claim may not hold up under scrutiny.
Another frequent scenario involves event or venue apps that request location permissions at install time. If the app uses those permissions to log beacon encounters and transmit them to a server, but the permission request did not clearly state that location would be tracked within the venue, the consent is unlikely to meet the UK GDPR standard. The user may have believed they were granting permission for a map feature, not ongoing presence logging.
Footfall counting and aggregated analytics
Some proximity systems are marketed as consent-free because they only produce aggregate counts—how many devices were detected in a zone during a period. The practical question is what happens at the point of collection. If individual device identifiers pass through the system, even briefly, before aggregation, the organisation needs a lawful basis for that processing. On-site aggregation, where the gateway discards identifiers immediately and only transmits a count, presents a different risk profile from a system that sends raw detection logs to a cloud platform for later aggregation.
When evaluating a footfall system, ask the supplier precisely where aggregation occurs, whether any raw identifiers leave the device, what the default retention period is for any intermediate data, and whether the system can be configured to discard identifiers at the edge. Document the answers. If the supplier cannot or will not confirm these points, that is a meaningful limitation to factor into the procurement decision.
Passive scanning versus active interaction
There is an important distinction between a visitor actively tapping an NFC tag or scanning a QR code—where the interaction itself signals engagement—and a system passively detecting their device without any action on their part. Passive detection is where consent risks are most acute, because the individual has no opportunity to opt in or out at the moment of collection. Active interactions do not automatically solve the consent problem either, but they provide a natural point at which to present a clear privacy notice and obtain agreement.
Proving the controls work in practice
Mistakes that lead to non-compliant tracking
- Assuming MAC randomisation makes tracking safe. Randomisation reduces persistence but does not remove the need for a lawful basis. A randomised address observed repeatedly within a single session can still constitute tracking of a device's movement through a space.
- Relying on a supplier's "anonymised" label without verification. The legal status of anonymised data depends on the method and context, not the vendor's marketing. Check whether re-identification is reasonably likely given the other data the organisation holds or could access.
- Bundling location tracking into a generic app permission. A single location-permission prompt that covers maps, push notifications and beacon tracking does not meet the specificity requirement. Each distinct purpose needs its own clear explanation.
- Collecting "just in case" data during a pilot. Pilots often gather more data than the production system will need, on the basis that it might be useful later. Under UK GDPR, data collection must be necessary for a specified purpose, not speculative.
- Ignoring third-party SDKs. An app may collect beacon data for one stated purpose, but an embedded analytics or advertising SDK within that app may be receiving the same data for a different purpose. The data controller remains responsible.
Limitations of current approaches
No proximity technology can guarantee that tracking without consent is impossible in all circumstances. Device-side randomisation is controlled by the operating system vendor and can change with updates. On-site aggregation depends on the gateway firmware behaving as documented and not logging to local storage. Physical tamper-proofing of gateways does not prevent a firmware update from altering data-handling behaviour. These limitations mean that compliance is an ongoing operational concern, not a one-time procurement checkbox.
It is also worth recognising that some legitimate operational needs—such as real-time capacity monitoring for fire safety—may appear to conflict with consent requirements. In practice, these situations often involve a different lawful basis, such as legitimate interests, rather than consent. However, legitimate interests requires a documented balancing test, and the outcome is not guaranteed to favour the organisation. The ICO's guidance on legitimate interests assessments should be consulted directly, as the result depends heavily on the specific context, the nature of the space and the reasonable expectations of visitors.
Key checks before deploying any detection system
- Map the data flow. Identify every point where a device identifier is generated, stored, transmitted or processed. If you cannot complete this map, you cannot assess the risk.
- Confirm where aggregation happens. Edge aggregation, where identifiers are discarded on the gateway before any network transmission, materially reduces the data-protection risk compared to cloud-side aggregation.
- Document the lawful basis for each processing activity. "We need the data" is not a basis. Specify whether you are relying on consent, legitimate interests or another basis, and record the reasoning.
- Review the privacy notice. Does it clearly describe location-based detection in the specific venue, or does it use vague language about "improving your experience" that could apply to anything?
- Audit supplier contracts. Confirm whether the supplier acts as a processor or a separate controller, what sub-processors are involved, and where data is stored geographically.
- Test the system's actual behaviour. During a pilot, monitor network traffic from gateways to confirm that only the expected aggregated data is being transmitted, not raw detection logs.
- Plan for device and firmware changes. Build a process for re-evaluating compliance when gateway firmware is updated, when the app adds a new SDK, or when the operating system changes its randomisation behaviour.
For organisations at the evaluation stage, the practical next step is to request a data-flow diagram from each shortlisted supplier and compare them side by side. The differences in where identifiers are handled, retained and discarded are often more significant than the differences in hardware specifications or claimed accuracy. If a supplier cannot provide this information, that gap is itself a finding worth weighing in the selection process.