Unwanted Tracker Detection Explained: Bluetooth Tags and IETF DULT

Unwanted tracker detection is the feature on iPhone and Android that notices when someone else's Bluetooth item tracker, separated from its owner, keeps showing up near you as you move, then alerts you and lets you make it play a sound. Since May 2024 it works across both platforms for compatible tags. It is useful but slow and incomplete, so a missing alert never proves you are not being tracked.

If you feel unsafe right now, contact your local emergency services first. Apple and Google both advise going to a safe public place and contacting law enforcement if you find a tracker or cannot find one but feel at risk. Specialist support is available too: in the United States, the National Domestic Violence Hotline (call 1.800.799.7233 or text START to 88788) and the Safety Net Project; in the United Kingdom, Refuge's National Domestic Abuse Helpline on 0808 2000 247; in Australia, WESNET's Safety Net Australia. Google's and Apple's tracker help pages link to the Safety Net Project, Refuge and WESNET. Removing or switching off a tracker can be noticed by the person who placed it, so if you are in an abusive situation, talk to an advocate about timing before you act.

This post goes one level deeper than our guides to Bluetooth LE GATT, Wi-Fi probe requests and mobile advertising IDs: how tags and finding networks work, what the IETF Detecting Unwanted Location Trackers (DULT) working group has and has not finished, why alerts arrive late or not at all, and a careful routine for scanning, finding, documenting and reporting a tracker.

Key takeaways

• A Bluetooth item tracker broadcasts short Bluetooth Low Energy (BLE) advertisements. Strangers' phones hear them and report an encrypted location that only the tag's owner can read.
• Apple shipped AirTag on 30 April 2021 with iPhone alerts. Apple and Google submitted a joint industry specification on 2 May 2023 and switched on cross-platform alerts on 13 May 2024, in iOS 17.5 and on Android 6.0 and later.
• The IETF formed the DULT working group around that specification. Its charter was approved on 29 February 2024. As of 24 October 2026 no DULT document is an RFC: the accessory protocol draft (version 00, 3 November 2024) and the finding protocol draft (version 01, 5 June 2025) have both expired, and the threat model (version 05, 6 August 2026) is the only active working group draft.
• The accessory draft asks a tag to advertise a recognisable payload, to switch to "separated mode" after at most 30 minutes away from its owner, to rotate its Bluetooth address every 15 minutes near the owner but only every 24 hours when separated, to ring when moved after 8 to 24 hours apart from its owner, and to support sound, identifier lookup and disablement instructions for non-owners.
• Detection is a judgement made over time. Android says you must physically move with a tracker before it alerts, and sends at most one alert per tracker per day. Apple warns that a tag's identifier may change overnight. Both mean delays and missed cases are built in.
• GPS trackers with a cellular modem, tags from networks that have not adopted the specification, and modified tags may produce no alert at all.
• Turning off Bluetooth, Location or Airplane Mode on your phone does not stop a tracker reporting its location. Both Apple and Google say so explicitly. Only disabling the tracker itself does.

How do Bluetooth item trackers work?

The tag only shouts; strangers' phones do the reporting

A typical item tracker holds a BLE radio, a coin cell, a tiny speaker, and sometimes an accelerometer and an ultra wideband (UWB) radio for close range direction finding. It has no GPS and no mobile data. It just transmits short advertisement packets every second or two.

The location comes from everyone else. The IETF DULT threat model describes the arrangement plainly: tags work as part of a crowdsourced network in which other users' devices, usually phones, report which tags they see and where, so the owner can learn where the tag was last seen. The finding protocol draft breaks this into three roles:

1. The accessory (the tag) broadcasts an advertisement that includes a hint about whether it is separated from its owner.
2. Finder devices, which are ordinary phones belonging to anyone on the network, hear the advertisement and, if the tag is in separated mode, upload a location report to the central service.
3. The owner device asks the central service for its tag's reports and shows them on a map.

How the encryption keeps strangers out (in the good case)

Apple's Platform Security Guide explains the cryptography behind its Find My network. When offline finding is turned on, the owner's device generates an elliptic curve P-224 key pair plus a 256-bit secret and a counter. These never go to Apple; they sync only between the owner's devices through end-to-end encrypted iCloud Keychain. From the secret and counter, the device derives a fresh short-lived public key. The missing device broadcasts that public key in a Bluetooth payload, and a nearby finder encrypts its own location to that key before sending it to Apple. Apple says the public key is replaced roughly every 15 minutes so that no persistent identifier can be followed, that finder traffic carries no authentication information, and that Apple cannot tell who found what.

P-224 was chosen, Apple says, because the public key then fits in a single Bluetooth payload. That detail matters for everything that follows: BLE legacy advertisements are tiny. The DULT threat model notes that a BLE 4.0 advertisement packet carries at most 37 bytes and that the current unwanted tracking format uses 12 of them for the basic protocol.

Google documents a similar approach for its network. Android's help pages, which now call it the Find Hub network (it launched on 8 April 2024 as the Find My Device network), describe it as "a crowdsourced network of Android devices that uses end-to-end encrypted location information." Google's April 2024 launch post said the network covered over a billion Android devices.

Why rotating identifiers cut both ways

If a tag broadcast the same Bluetooth address forever, anyone with a scanner could follow its owner. The DULT threat model lists this as "remote advertisement monitoring" and rates its likelihood as high because off-the-shelf scanning tools are enough. So tags rotate their address.

But rotation also hides a tag from the person it is following. If the identifier changes every 15 minutes, a phone cannot easily tell that the tag it saw at home is the same one it saw at work. The accessory draft resolves this by making rotation depend on state: fast when the tag is with its owner, slow when it is not. That trade-off is the heart of unwanted tracker detection, and it is why the detection window and the alert delay look the way they do.

What is the stalking risk, and how did platforms respond?

A tag is cheap, lasts months on a battery, fits in a bag lining or a car, and reports through other people's phones. The DULT threat model, whose authors include a representative of the National Network to End Domestic Violence (NNEDV), centres on attackers who live with or can easily reach the target, and targets with little technical expertise, money or safe access to their own phone. It also covers the inverse case: an attacker using the target's own tag through a shared account, which is why owners need privacy too.

Apple's statement of 10 February 2022 described both sides: benign alerts from borrowed keys, and "reports of bad actors attempting to misuse AirTag for malicious or criminal purposes." It called misuse rare, based on its discussions with law enforcement, and said every AirTag's serial number is linked to an Apple account that can be provided in response to valid legal process.

Dated timeline

The milestones in the approved charter, a protocol document and an informational document both due in July 2025, have passed without a published RFC. That does not mean the protections are not running; they are, in shipping iOS and Android. It means the formal, vendor neutral standard is still unfinished, and what phones actually do is defined by Apple's and Google's implementations of the industry specification.

What is the IETF DULT working group?

The charter

The Detecting Unwanted Location Trackers working group sits in the IETF Security Area. Its chairs are Erica Olsen, who directs NNEDV's Safety Net Project, and Sean Turner. The charter splits a tracking system into three subsystems whose interfaces matter for unwanted tracking: the crowdsourcing network, unwanted tracker detection, and alerting (including giving information about the tag and helping a non-owner find it).

The charter's goal is to standardise "an application protocol for information exchange between location-tracking accessories and nearby devices," plus what both should do once unwanted tracking is detected. The planned work is an informational description of today's tracker platforms; a standards track protocol with a baseline detection algorithm, advertisement formats for transports such as Bluetooth or NFC, a way to make a tag reveal itself (for example by sound) and a way to fetch images and disablement instructions; privacy and security requirements; manufacturer guidance covering physically modified tags and people without a capable phone; and ways to exclude non-conforming and legacy devices from crowdsourced networks.

Three commitments stand out. The group will work with gender-based violence experts throughout. It will do a threat and security analysis and gather implementation experience before publishing. And it will not define how manufacturers deal with law enforcement. The mechanisms must also not create new ways to track people.

The document set and its status

An expired Internet-Draft is still readable and still the best public description of the intended behaviour, but it is not a standard and can change. Treat every number below as "what the draft said," not as a guarantee about any product.

What does the DULT accessory protocol draft require?

The accessory draft, written by engineers from Apple and Google, is the most concrete text. It applies to location-enabled accessories that are "small and not easily discoverable." It defines easily discoverable as larger than 30 cm in at least one dimension, larger than 18 cm by 13 cm in two dimensions, or larger than 250 cubic centimetres. Below those sizes the requirements are mandatory; for something like a bicycle they are recommended.

Two states: location-enabled, and near-owner versus separated

The draft says a tag must keep track of whether its location is, or has been within the past 24 hours, available to its owner over a network. That is the location-enabled state. It should also keep a second state that records whether it is near one of the owner's devices (near-owner mode) or not (separated mode).

The draft's preferred rule is that a tag moves into separated mode once it has been physically apart from the owner's device for more than 30 minutes. An acceptable alternative adds the condition that the owner has received a newer location update after those 30 minutes. A tag must move back to near-owner mode within 30 minutes of being reunited.

The advertisement format

When location-enabled, the tag advertises a BLE payload that platforms recognise:

The 0xFCB2 service UUID gives phones one simple thing to scan for. In the Bluetooth SIG's public list of member UUIDs, 0xFCB2 is assigned to Apple Inc. The near-owner bit is 1 when the tag is with its owner and 0 when separated, which lets a phone skip tags that are simply travelling with the person who owns them.

The draft says the maximum advertising interval must be 4 seconds and, for the best detection rate, should be 2 seconds or less.

Address rotation

The address must look random to everyone but be predictable to the owner's devices, so that the owner's own phone never raises an alert about the owner's own tag. The rotation policy is the key privacy and safety balance:

• Rotate on every change between near-owner and separated mode.
• In near-owner mode, rotate every 15 minutes, so strangers cannot follow a legitimate owner.
• In separated mode, rotate every 24 hours, so that a victim's phone has time to notice that the same tag keeps appearing.

Any other per-device value in the proprietary data must rotate at the same time as the address.

Sound, motion and finding by a non-owner

The draft requires that once someone has been alerted, they must have a way to physically find the tag. A sound maker is mandatory. It must reach at least 60 phon peak loudness under ISO 532-1:2017, measured 25 cm away in free space. A motion detector, such as an accelerometer, is recommended; if present it must detect an orientation change of plus or minus 10 degrees along any two axes.

With a motion detector, the behaviour in separated mode works like this:

1. After a random wait of between 8 and 24 hours in separated mode, the tag enables its motion detector, sampling every 10 seconds.
2. If it detects motion, it plays a sound and samples every half second, playing a sound for each detected movement.
3. It backs off for 6 hours after 20 seconds of continuous motion or ten sounds.
4. If still separated after the back-off, it starts again. A connection from the owner's device resets the whole cycle.

A non-owner's phone can send Sound_Start and Sound_Stop commands (opcodes 0x0300 and 0x0301) over Bluetooth, but only while the tag is separated. A requested sound lasts 5 to 30 seconds, 12 recommended. Vibration or lights are recommended too, and the threat model asks for them so that people who are Deaf or hard of hearing can find a tag.

Identifier lookup, owner information and disablement

The draft requires a way to identify the tag uniquely, through a printed serial number or a privacy-preserving alternative. The identifier must be readable by NFC tap or over Bluetooth. Over Bluetooth, the Get_Identifier command only works after a physical action on the tag, for example holding a button for 10 seconds, which opens a 5 minute window. Over NFC, the tag hands the phone a URL hosted by the finding network that decrypts the identifier and shows it in a web view.

The network must record verifiable owner identity, such as a phone number or email address, at the time of pairing. A limited, obscured version must be shown alongside the identifier: at least the last four digits of the phone number or a masked email address. The draft says this registry should be kept for at least 25 days after an owner unpairs a tag, then deleted, and should be produced in response to valid law enforcement requests under the network's own procedures.

Finally, every tag must be possible to disable by a physical action, such as a button sequence or removing the battery, so that its future locations can no longer be seen by its owner. The manufacturer must provide text and a visual guide for disablement that the platform can show.

Categories, firmware and the missing platform half

Category values tell a person what kind of thing is following them: 1 for a location tracker, 128 for other, and 129 to 167 for items with finding built in, from luggage and wheelchairs to headphones and laptops. Existing trackers should be updated "on a best-effort basis," which is honest about the biggest gap: tags already in drawers and cars will not all gain the new behaviour. The platform section, meaning what phones must do, was left unwritten, and the detection algorithm was deferred to a separate document that has not appeared.

How do phones detect an unknown tracker moving with you?

What the phone is doing in the background

Neither Apple nor Google publishes its detection algorithm or exact thresholds. Their help pages and the DULT drafts let us describe the shape of it.

1. Listen. The phone runs low duty cycle BLE scans, looking for advertisements in recognised formats: the 0xFCB2 service data, and each platform's own network formats.
2. Filter out the expected. It drops tags whose near-owner bit is set, tags the phone itself owns (it can predict their rotating addresses), and tags the user has marked as known, for example a family member's tag shared with them.
3. Correlate over time and place. For a separated tag, it records when and where it heard each address. Because separated tags keep the same address for up to 24 hours, the phone can see the same tag at several of its own locations.
4. Decide. When the pattern looks like the tag is moving with you, rather than sitting in a café you passed, it raises an alert and stores the sightings on a map.

The DULT threat model lists signals a confidence score could use: how long the tag stays near you, how closely its movement matches yours, signal strength trends, how often it reappears across times and places, the device type, and whether the places are familiar. It proposes graded alerts, from "briefly detected" up to "persistently following you."

Google says Android uses your location, detection times and the tracker's device ID, stored encrypted on the device and not shared with Google or other users.

Why alerts are delayed

Delays come from several design choices stacked together:

• The separation timer. A tag only switches to separated mode after up to 30 minutes apart from its owner. Until then it advertises the near-owner bit and phones are supposed to ignore it.
• The need for movement. Android's help page says that "you need to physically move with the tracker over time" before you get an alert. A tag in a car you drive daily will be noticed sooner than one in a bag you leave at home.
• The audible fallback timer. Under the draft, the tag's own sound only begins after a random 8 to 24 hours of separation, and then only when it is moved.
• Rate limits. Android sends at most one alert per tracker per day. If you are still worried, Google says to run a manual scan.
• Scanning limits. Both iOS and Android restrict background BLE scanning to save power, and 2.4 GHz noise from Wi-Fi and microwave ovens can make scans miss packets, the threat model notes.

A rough example: a tag is left in a car at 22:00 and its owner walks away. By 22:30 at the latest it should be in separated mode, but if the car sits until 08:00 there is nothing for your phone to correlate. Only after you drive to work and on to a second place does your phone have sightings at several of your locations. None of these timings is published as a guarantee; the point is that "hours" is the realistic expectation, not "minutes."

Why some trackers are never flagged

False negatives, real tags that never trigger an alert, come from:

• Non-participating tags. Phones only alert on formats they recognise. Android's help page says unknown tracker alerts currently work with Find Hub network compatible tags, headphones and AirTags. Apple says iOS 17.5 or later alerts on "compatible" Bluetooth trackers, meaning those that follow the industry specification, plus its own Find My accessories. Tags from networks that have not adopted the specification, and older tags that were never updated, can be invisible to both.
• Identifier changes. Apple's support article says that if an item "was with you overnight, its identifier might have changed," which can stop you playing a sound on it. Google says the same: when a tag rotates its random ID, it shows up as a new tracker.
• Owner nearby. If the owner's phone is near the tag, for example someone sharing your car, the tag is in near-owner mode and is filtered out by design.
• Different technology. GPS trackers with their own cellular or satellite connection do not need anyone's phone and usually do not advertise in a format phones look for. The threat model rates them as a high risk and notes that adopting the DULT protocol is optional for their makers.
• Tampering. The threat model lists physically modified tags, modified firmware, impersonation of conforming tags, replayed advertisements and tags switched off and on. We will not describe how any of these is done; the point is that a determined attacker can try, so a physical search and expert help still matter.
• Your phone's settings. No Bluetooth, Location off, Airplane Mode on, or notifications disabled will stop alerts on your phone, even though they do not stop the tracker.

Why some alerts are false alarms

False positives are real too, and Apple's 2022 statement was candid about them: borrowing a friend's keys with a tag attached, or riding in a family member's car with their earbuds inside. The threat model adds another: if a tag's owner turns off Bluetooth on their own phone, the tag may think it is separated and set off alerts for the people around it. It also warns that busy places such as train stations will contain many separated tags.

The threat model suggests letting users mark known tags as trusted, with alerts resuming after a while so trust does not become a permanent blind spot. It also warns that shared ownership can be abused: an attacker could add the target to a tag's shared list so the target's phone stays quiet.

What can you do on iPhone and Android?

iPhone and iPad

Apple's Personal Safety User Guide says unwanted tracking notifications for AirTags and Find My network accessories need iOS 14.5 or iPadOS 14.5 or later, and that alerts for other compatible Bluetooth trackers following the industry specification need iOS 17.5 or later (Apple's support article also lists iPadOS 17.5). To make sure they can reach you, Apple lists:

1. Settings, Privacy & Security, Location Services: turn Location Services on.
2. In Location Services, System Services: the Personal Safety guide says to turn on Find My iPhone; Apple's separate support article says to turn on Significant Locations so you are notified when you arrive somewhere significant, such as home. Turning on both does no harm.
3. Settings, Bluetooth: on.
4. Settings, Notifications, Tracking Notifications: Allow Notifications on.
5. Turn Airplane Mode off.

Alerts are titled by what was detected, such as "AirTag Found Moving With You" or "[Product Name] Found Moving With You." Tapping one shows a map: red dots mark where the item was detected near you and dashed lines show the order. Apple notes the dots do not show when the owner viewed the item's location.

From an alert you can tap Play Sound, or, for an AirTag (and some charging cases) on an iPhone with ultra wideband, Find Nearby, which uses Precision Finding to show distance and direction. To look back at past alerts, open Find My, Items, and scroll to the list of items detected with you. If you find a tag, hold the top of the iPhone near it (for an AirTag, near the white side) to read it over NFC. That opens a web page with the serial number or device ID and the last four digits of the registered owner's phone number or a masked email address, plus a lost-mode message if the owner set one. For compatible third party trackers, Apple says disablement instructions come from that tag's finding network and "have not been certified by Apple."

Android

Google's help page says unknown tracker alerts work on Android 6.0 and later and arrive through Google Play services updates in the background. On Android 12 and later the settings live under Settings, Safety & emergency, Unknown tracker alerts; on Android 11 and earlier under Settings, Google, Personal & device safety, Unknown tracker alerts.

• Automatic alerts need Location turned on.
• Manual scan: Settings, Safety & emergency, Unknown tracker alerts, Scan now. Google says it takes about 10 seconds and lists trackers that are near you now and separated from their owners. On Android 11 and later the manual scan does not need the Location setting; on Android 10 and earlier it uses Location and Bluetooth. Running several scans can improve accuracy.
• From an alert: tap it to see the map of where the tracker travelled with you, then Play sound. Google says playing the sound does not notify the owner. For Find Hub compatible trackers, a Find nearby option shows a shape that fills as you get closer.
• Pause: for Find Hub compatible trackers you cannot find, "I can't find the tracker, Temporarily pause" stops your phone's location being used to locate that tracker for up to 24 hours.
• History: the tracker alerts button on the Unknown tracker alerts screen. Google says alerts are deleted after 48 hours, so screenshot anything you may need later.
• Turning alerts off clears previous alerts and cannot be undone. If you might need them as evidence, do not switch the feature off.

Apple's page also mentions its Tracker Detect app on Google Play for Android devices that cannot get the built-in feature; it looks for trackers compatible with Apple's Find My network within Bluetooth range.

Trackers that do not follow the specification

If you suspect tracking but get no alert, the device may be outside what your phone recognises. Practical options, none of which is a guarantee:

• Run manual scans repeatedly, on Android especially, in the places you suspect: your car, your bag, your home.
• Check the tag maker's own scanning feature, from the official app store, if you know which brand you are worried about.
• Search physically. Apple's guidance names jacket pockets, the outer compartments of bags, and your vehicle. The threat model warns that an attacker may hide more than one tag, for example one inside a car and one on the outside, so do not stop at the first one.
• Consider non-Bluetooth devices. Cellular GPS trackers will not show up in either phone's scan. A mechanic or a specialist advocate may be needed for a car.

How does this connect to finding phones when they are off?

The same networks that find tags also find phones, laptops, earbuds and watches, and that is where the privacy trade-off is easiest to see. Your phone is both a finder for strangers' items and, when lost, an item itself.

Apple says any iPhone, iPad or Mac with offline finding turned on acts as a finder device and can also be found by others, and that Find My can even locate a Mac that is offline and asleep. On Android, Google's help page lists four settings under Find Hub, Find your offline devices:

Google says that by default an Android device stores encrypted recent locations and takes part in the network. Supported devices, such as the Pixel 8 series, can still be located for several hours after they are switched off or the battery dies, if one of the network options is chosen and Bluetooth and Location were on at shutdown. A screen lock is required for the network options.

The trade-off is plain. Your lost device is easier to find because strangers' phones report it, and your phone quietly does the same for others, encrypted and anonymous by design. But a phone that can be found when off can also be followed when off by whoever controls the account. If someone else knows your password, or you share a family account with someone you no longer trust, offline finding helps them too. That is why the threat model asks networks for activity logs showing which account viewed which accessory's location and when, logs an owner cannot easily delete.

Both platforms let you opt your own device out of acting as a finder. Doing so does not stop alerts about trackers following you; those depend on your phone's own scanning, Bluetooth, Location and notifications.

Comparison: tracker types and what phones can see

This table summarises what the vendors' own documentation and the DULT drafts say. "Detected" means the platform documents alerts for that category; it does not mean every unit is caught.

Step by step: scan, find, document, report, and review your own tags

Work through these in order. If at any point you feel unsafe, stop and contact your local emergency services or one of the support organisations listed at the top of this post.

Step 1: make sure your phone can alert you

• iPhone: update to the latest iOS you can (at least 17.5 for cross-platform alerts). Check Location Services, the System Services toggles described above, Bluetooth, Tracking Notifications, and that Airplane Mode is off.
• Android: check that Settings, Safety & emergency, Unknown tracker alerts exists and Allow alerts is on, and that Location is on for automatic alerts. If the menu is missing, update Google Play services and the system.

Step 2: run a manual check

• Android: run Scan now several times: in your car with the engine running, near your bag, near your coat, and once in each room you use most. Note anything listed, with the time.
• iPhone: iOS has no general "scan now" button for third party tags. Review Find My, Items, the list of items detected with you. Precision Finding only works from an alert for supported items.

Step 3 (optional, advanced): a laptop BLE check for spec-format advertisements

This step is for people comfortable with a terminal. It lists nearby devices that broadcast the 0xFCB2 service data described in the DULT accessory draft and shows the network ID byte and the near-owner bit. It is a supplement to the phone features, not a replacement: real products may use other formats, the draft has expired and may change, and addresses rotate. It only listens; it does not connect to or change anything.

# macOS or Linux with Python 3.9+
python3 -m venv ~/dult-scan && source ~/dult-scan/bin/activate
pip install bleak

# dult_listen.py: passive listen for DULT-format advertisements (draft-ietf-dult-accessory-protocol-00)
import asyncio, datetime
from bleak import BleakScanner

DULT_UUID = "0000fcb2-0000-1000-8000-00805f9b34fb"
seen = {}

def on_adv(device, adv):
    data = adv.service_data.get(DULT_UUID)
    if not data:
        return
    network_id = data[0] if len(data) > 0 else None
    near_owner = (data[1] & 0x01) if len(data) > 1 else None
    seen[device.address] = (datetime.datetime.now().isoformat(timespec="seconds"),
                            adv.rssi, network_id, near_owner)

async def main(seconds=60):
    async with BleakScanner(detection_callback=on_adv):
        await asyncio.sleep(seconds)
    for addr, (ts, rssi, net, near) in sorted(seen.items(), key=lambda x: -x[1][1]):
        state = "separated" if near == 0 else "near owner" if near == 1 else "unknown"
        print(f"{ts}  {addr}  rssi={rssi}  network_id={net}  state={state}")

asyncio.run(main())

python3 dult_listen.py

A "separated" entry with a strong signal (an RSSI nearer zero, say minus 50 rather than minus 90) that appears in your car on several drives deserves a physical search. A "near owner" entry is almost certainly a tag travelling with its owner, such as a passenger's. On macOS the address shown is a per-machine identifier, which is normal. Do not try to send commands to a tag from a laptop; use the phone features.

Step 4: make it ring and find it

From the phone alert, use Play Sound (iPhone and Android), and Find Nearby or Find nearby where available. Move slowly and play the sound again if you need to. If nothing plays, Apple and Google both say the tag may be gone, near its owner, or have changed its identifier.

Search systematically. Apple names jacket pockets, outer pockets of bags and vehicles. In a car, the threat model's example is a tag hidden under a seat cushion. Check:

• bags, including linings and zip pockets, and coats you wear often;
• your car: under and between seats, seat back pockets, the boot or trunk and the glovebox;
• children's bags and car seats, and gifts someone gave you recently.

Do not take your car apart. If you believe a device is fitted in a vehicle and you cannot find it, a trusted mechanic or a support organisation that deals with technology abuse can help.

Step 5: document before you disable

Before you change anything, record evidence. Apple's Personal Safety guide explains how to take screenshots and screen recordings, and Google suggests screenshots of the alert and its map because Android deletes alerts after 48 hours.

1. Screenshot the alert and the map of sightings.
2. If you found the tag, read it with NFC (iPhone: top of the phone; Android: back of the phone) and screenshot the page with the serial number or identifier and the partial owner details.
3. Photograph the tag where you found it before moving it, then photograph both sides, including any printed serial number.
4. Write a short log: date, time, where you were, what alerted, where you found the tag, who had access to that place or item.

A simple log format keeps this consistent:

date_time        | where_i_was        | what_happened                          | evidence_file
2026-10-24 08:40 | home -> office     | Android alert, map shows 3 sightings   | IMG_2041.png
2026-10-24 12:15 | office car park    | Played sound, found tag under seat     | IMG_2045.jpg, IMG_2046.jpg
2026-10-24 12:20 | office car park    | NFC read: serial shown, phone ends ...  | IMG_2047.png

The threat model explains why evidence matters: destroying a tag may end the tracking, but it may also destroy proof and, in abusive situations, may escalate things. Google adds that some trackers factory reset when turned off and are no longer linked to their owner, after which law enforcement cannot get owner information from them.

Step 6: decide, with support, whether to disable it

Disabling stops future location updates to the owner. Google notes the owner may still see the last location from before you turned it off. Apple says that once disabled you will also stop getting alerts about that item.

• iPhone: in the alert, tap Instructions to Disable and follow the steps.
• Android: tap Next steps after finding the tracker; Google links to each tag maker's disable instructions.
• Physical: under the DULT draft, every compliant tag must have a physical disablement method, often removing the battery.

If you are not in immediate danger and are dealing with someone who may react, consider keeping the tag intact and taking it to the police or an advocate instead. Google says outright that you can turn the tracker off or keep it on if you are worried that turning it off could be unsafe.

Step 7: report it

Apple says that if an Apple product is involved, law enforcement can work with Apple to request information, and you may need to hand over the item and its serial number. Its February 2022 statement said every AirTag's serial number is tied to an Apple account that Apple can provide in response to a subpoena or valid law enforcement request. The DULT draft asks all networks to keep owner records for at least 25 days after unpairing and to answer valid legal requests. Stalking and tracking a person without consent are crimes in many places, and Apple's own setup message says so.

Contact local police through their non-emergency route if you are safe, or emergency services if you are not. A domestic abuse or technology safety service can help you prepare.

Step 8: review your own tags and sharing

Unwanted tracking is not only about strangers' tags. The threat model describes an attacker using the target's own tag, or being added to its shared list.

• Open your finding app and list every tag and device on your account. Remove any you do not recognise.
• For each tag, check who else it is shared with, and remove anyone you no longer trust. Apple's Personal Safety guide has topics on stopping sharing an AirTag and stopping sharing a lost AirTag's location.
• Change your account password and turn on two-factor authentication if anyone else may know your credentials. On iPhone, Apple's Safety Check reviews sharing and access in one place.
• Review tags you have marked as trusted, so an old exception does not hide a new problem.

Common mistakes

• Assuming no alert means no tracker. Alerts depend on compatible tags, your settings, movement over time and identifier rotation. Use manual scans and a physical search if you have reason to worry.
• Turning off Bluetooth or Location to "stop" a tracker. Both Apple and Google say this does not stop the tracker reporting its location through other people's phones. It only stops your own phone warning you.
• Switching off Android's tracker alerts to clear them. Google says this deletes previous alerts permanently.
• Ignoring cars and bags. These are the places Apple and Google both name, and the threat model notes they are harder to search than a pocket.
• Stopping at one tag. The threat model warns attackers may use several, inside and outside a car or at different places you visit.
• Destroying the tag first. You lose the serial number, the owner lookup and possibly the case. Document first and get advice.
• Leaving a tag shared with someone you no longer trust. Shared ownership can silence alerts on your own phone. Review sharing after any relationship change.
• Installing random "tracker detector" apps. Stick to the features built into iOS and Android, Apple's own app for older Android, or an app from the tag maker you are checking for.

Where Safeguard fits

Safeguard does not scan for Bluetooth trackers, does not read your phone's alerts, and has no role in finding or disabling a tag; nothing in the steps above depends on it, and for anyone worried about being tracked, the phone features and support organisations are what matter. The fit is indirect and sits with the teams who build this technology. Tracker companion apps, finding network back ends, identifier lookup web pages and the firmware build pipelines for tags are software built from open source dependencies. Safeguard scans repositories, container images and SBOM files, builds an inventory of the components they contain, and matches them against vulnerability databases, so a team shipping a companion app or a lookup service can see which libraries and versions actually ship and which have known vulnerabilities. It does not analyse radio behaviour, test whether a tag meets the DULT drafts, or assess hardware.

FAQ

How do I know if an AirTag or Bluetooth tracker is following me?

With iOS 17.5 or later, or Android 6.0 or later with alerts on, you are notified when a compatible tag separated from its owner keeps moving with you. Android also offers a manual scan. Without an alert, search your bag, coat and car by hand.

How long does it take for an iPhone or Android phone to alert me?

Neither company publishes a time. Android needs you to move with the tracker first and sends one alert per tracker per day. Expect hours rather than minutes.

Can an Android phone detect an AirTag?

Yes. Google began rolling out unknown tracker alerts for AirTags to Android 6.0 and later in July 2023, and since May 2024 Android alerts on any tag compatible with the joint industry specification. Older Android devices can use Apple's Tracker Detect app from Google Play.

Does turning off Bluetooth stop someone tracking me with a tag?

No. The tag reports its location through other people's phones, so your settings do not affect it. Apple and Google both say you need to disable the tracker itself. Turning off Bluetooth or Location on your phone only stops your own phone warning you.

What is IETF DULT?

Detecting Unwanted Location Trackers is an IETF working group, chartered on 29 February 2024, that is standardising how tracking tags advertise, how nearby phones detect them and how non-owners can find and disable them. As of October 2026 it has no published RFC; its threat model draft is active and its accessory and finding drafts have expired.

Will playing a sound on an unknown tracker alert the owner?

Google says playing the sound from an Android alert does not notify the owner. Apple does not make a specific statement about this in the pages we reviewed. Disabling a tag does stop the owner getting new locations, which a determined owner may notice.

What information can I get from a tracker I find?

Hold it to your phone's NFC reader. For compatible tags you can see a serial number or device ID and partial owner details, such as the last four digits of a phone number or a masked email address, plus any lost-mode message. The DULT draft requires networks to provide this obscured owner information.

Should I destroy a tracker I find?

Not straight away. Photograph it, read its identifier and keep it if that is safe. Destroying it can remove evidence and, the DULT threat model warns, may escalate an abusive situation.

Do GPS trackers trigger these alerts?

Generally not. They do not rely on nearby phones and usually do not broadcast the formats phones look for. The DULT threat model rates them high risk and can only encourage their makers to adopt the protocol.

Fix it without waiting for upstream

Tracker companion apps, finding network services and the web pages that show a found tag's identifier are ordinary software assembled from open source packages, and a vulnerable library in a service that handles location data is a real risk to the people whose locations pass through it. Safeguard's fit here is with the teams that build and run that software, not with anyone searching for a tag, and the fork and patch route described below is early access.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos are for engineering teams, not for anyone checking whether they are being tracked. The first is a real Safeguard CLI session: it asks the assistant to fix a lodash CVE in a repository, reads the finding and advisory, asks before each command, edits package.json to a fixed version, and runs npm install and npm test with approval, pushing nothing. The same flow applies if a scan of a tracker companion app or an identifier lookup service shows an outdated dependency.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code and then scans from the terminal. It suits a team that wants an inventory of the packages inside a location service before a privacy review, scanning on its own hardware so source code does not leave the building.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It helps when you want to ask an assistant which of your projects carry a particular library version while you work through a release checklist.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and follow the CLI documentation.

Quick check

Sources

• IETF Datatracker: Detecting Unwanted Location Trackers (dult) working group, charter and milestones
• IETF Datatracker: DULT working group documents
• IETF Datatracker: DULT group history (created 16 June 2023, charter approved 29 February 2024)
• IETF: draft-ietf-dult-accessory-protocol-00, Detecting Unwanted Location Trackers Accessory Protocol (3 November 2024, expired) and text
• IETF: draft-ietf-dult-threat-model-05, DULT Threat Model (6 August 2026) and text
• IETF: draft-ietf-dult-finding-01, Finding Tracking Tags (5 June 2025, expired)
• IETF: draft-detecting-unwanted-location-trackers, individual draft (latest revision 20 December 2023, expired) and text of version 01
• Apple Personal Safety User Guide: Detect unwanted trackers
• Apple Personal Safety User Guide: Document suspicious or harmful activity
• Apple Personal Safety User Guide: Safety considerations
• Apple Support: What to do if you get an alert that an AirTag, set of AirPods, Find My network accessory, or compatible Bluetooth location-tracking device is with you
• Apple Platform Security Guide: Find My security
• Apple Newsroom: Apple introduces AirTag (20 April 2021)
• Apple Newsroom: An update on AirTag and unwanted tracking (10 February 2022)
• Apple Newsroom: Apple and Google lead initiative for an industry specification to address unwanted tracking (2 May 2023)
• Apple Newsroom: Apple and Google deliver support for unwanted tracking alerts in iOS and Android (13 May 2024)
• Android Help: Find unknown trackers
• Android Help: Make sure you can find a lost Android device (Find Hub and offline finding settings)
• Google blog: Unknown tracker alerts on Android (27 July 2023)
• Google blog: 5 ways to use the new Find My Device on Android (8 April 2024)
• Bluetooth SIG: Core Specification
• Bluetooth SIG assigned numbers: member UUIDs (0xFCB2)
• National Domestic Violence Hotline (United States)
• NNEDV Safety Net Project: resources for survivors
• Refuge: I need help now (United Kingdom)
• WESNET Safety Net Australia: resources

Last reviewed: 24 October 2026. Phone features and the IETF DULT drafts change; check the linked Apple, Google and IETF pages for the current version. If you feel unsafe, contact your local emergency services.