How Offline Finding Works: The Cryptography Behind Find My and Find Hub

Offline finding works by public key cryptography over Bluetooth Low Energy. A lost device broadcasts a public key that changes every few minutes, nearby phones encrypt their own location to that key and upload it, and only the owner, who can recompute the matching private keys, can decrypt the report. Apple's Find My rotates the key about every 15 minutes; Google's Find Hub network rotates its identifier about every 1024 seconds.

That is the short answer, and it is accurate as far as it goes. The long answer is more interesting, because the same design has to do two things that pull against each other. It has to let a stranger's phone help you find your keys without learning whose keys they are, and it has to stop someone else from using the same network to follow a person who never agreed to be found. Apple and Google document the cryptography in their own words, the IETF is turning the anti stalking half into a standard, and academic researchers have spent five years testing where the guarantees hold and where they do not.

This post goes one level below our two explainers on whether a phone is really off, the iPhone and Find My when powered off and whether an Android phone is findable when off. If you want the radio background first, our history of Bluetooth versions from Classic to LE Audio covers how Bluetooth Low Energy advertising works.

Key takeaways

• A lost device does not need to know where it is. It only broadcasts a public key; the finder supplies the location and the encryption.
• Apple's key schedule is published in the Apple Platform Security guide: a P-224 master key pair plus a 256 bit secret, rolled forward by a key derivation function to produce a new key pair roughly every 15 minutes.
• Google's Find Hub Network accessory specification derives a new ephemeral identifier from a 32 byte ephemeral identity key and a time counter, with a rotation period of 1024 seconds and a randomised switch point.
• Finders encrypt to the broadcast key with an ephemeral elliptic curve Diffie Hellman exchange. Apple uses an ECIES construction; Google's specification uses HKDF-SHA256 and AES-EAX-256. Neither operator holds the decryption key.
• Apple files each report under the SHA-256 hash of the broadcast public key. The owner recomputes the keys for the time window it cares about, asks for those hashes, and decrypts locally.
• Google adds network side rules that Apple's guide does not describe: aggregation by default, so a location is shown only after several Android devices have seen the item, plus an at home rule, rate limits and throttling.
• Rotation is a privacy feature for owners and a problem for people being stalked. That tension is why separated trackers rotate their Bluetooth address far less often, and why Apple and Google wrote a joint specification, now in the IETF DULT working group, so either platform can warn about the other's trackers.
• "Findable after power off" is real but bounded. Apple says a supported iPhone can be located for up to 24 hours after it is turned off, or up to 5 hours in power reserve mode. Google says supported phones such as the Pixel 8 series can be located for several hours.

The problem offline finding solves

Before offline finding, a lost device could only report its location if it reached the internet itself. The trick is to borrow someone else's internet connection and someone else's GPS. Apple's Platform Security guide describes the Find My design in exactly those terms: the missing device sends short range Bluetooth signals, nearby Apple devices detect them, and those devices relay the detected location to iCloud. Google's April 2024 security blog post describes the same idea for Android using an everyday example: you leave your keys in a cafe, the keys have no location capability, but nearby Android phones that are part of the network report where they saw the tag.

The design goals both companies publish are almost identical:

1. The finder should not learn whose device it found.
2. The network operator should not learn where anyone's device is.
3. The owner should not learn who found the device.
4. An eavesdropper should not be able to follow the device by its broadcasts.

Apple's guide states that the whole interaction is "end-to-end encrypted, anonymous" and designed to be battery and data efficient. Google's post says the location data is end to end encrypted with a key only the tag owner and the people they share with can access, so "Google cannot decrypt, see, or otherwise use the location data."

Goals 1 to 3 are cryptographic. Goal 4 depends on rotation. And a fifth goal, protecting people from being tracked by a tag someone else planted, cuts against goal 4. Most of the interesting engineering lives in that conflict.

Step 1: how a lost device broadcasts a rotating public key

Apple Find My: P-224 keys rolled every 15 minutes

Apple publishes its key schedule in the Find My security section of the Apple Platform Security guide. In plain terms:

• When the owner turns on offline finding, the device generates an elliptic curve key pair on the NIST P-224 curve, written as d (private) and P (public). It also creates a 256 bit secret SK0 and a counter i that starts at zero.
• Apple says this key pair and secret "are never sent to Apple" and are synced among the owner's other devices only through iCloud Keychain, end to end encrypted.
• For each counter value, the device steps the secret forward with a key derivation function, SKi = KDF(SKi-1, "update"), then derives two large integers from it, (ui, vi) = KDF(SKi, "diversify").
• The short lived private key is di = ui * d + vi modulo the order of the P-224 curve, and the matching public key is Pi = ui * P + vi * G, where G is the curve's generator point.

That last line is the clever part. Because the relation is affine, two different parties can compute two halves of the same key pair. Anyone holding P and the secret could compute every future public key Pi. Only someone holding d as well can compute the private keys di. And without the secret, the sequence of public keys looks unrelated: Apple says the derivation "is designed to prevent the various public keys Pi from being linked to the same device."

Apple chose P-224 for a practical reason it states directly: "the public key representation can fit into a single Bluetooth payload." The x coordinate of a P-224 public key is 28 bytes. A Bluetooth Low Energy legacy advertisement is small, and the 2021 PETS paper by Heinrich, Stute, Kornhuber and Hollick at TU Darmstadt, which reverse engineered the protocol, found that Apple squeezes the key in by putting its first 6 bytes in the random Bluetooth address field and the remaining bytes in the payload. Because the Bluetooth standard requires the first two bits of a random address to be set to 1, those two overwritten bits are carried separately in the payload. The paper reports that Apple later confirmed the reverse engineered format, and lists the advertisement as manufacturer specific data with Apple's company identifier 0x004C and an offline finding type of 0x12.

On timing, the Platform Security guide says: "Approximately every 15 minutes, the public key is replaced by a new one." The PETS paper measured iOS and macOS devices emitting one advertisement every two seconds during each 15 minute window once they lose internet connectivity.

Trackers behave differently once they leave their owner; the unwanted tracking section below explains why a separated tag rotates far less often.

Google Find Hub: ephemeral identifiers every 1024 seconds

Google's design is published in the Find Hub Network (FHN) accessory specification, an extension of the Fast Pair specification on developers.google.com, which at the time of writing shows a last updated date of 20 August 2026.

The root secret is the ephemeral identity key (EIK), a 32 byte key chosen at random by the owner's phone (the specification calls it the Seeker) when it provisions the accessory. The specification says plainly: "The Seeker never reveals it to the backend."

To compute the identifier a beacon broadcasts at a given moment, the accessory:

1. Builds a 32 byte block containing padding, a rotation period exponent K, and its 32 bit time counter in seconds with the lowest K bits cleared, repeated twice with different padding.
2. Encrypts that block with AES-ECB-256 under the EIK. The result is a 256 bit number r'.
3. Reduces it modulo the curve order to get r, then computes the point R = r * G on the chosen curve.
4. Broadcasts Rx, the x coordinate of R, as its ephemeral identifier (EID).

The specification fixes K at 10, "corresponding to 1024 seconds." Clearing the low 10 bits of the clock means every second inside the same 1024 second block produces the same EID, and the owner can recompute any past EID if it knows roughly when the beacon was seen.

Two curves are allowed. SECP160R1 is the default and yields a 20 byte identifier that fits a legacy advertisement. SECP256R1 yields a 32 byte identifier and, in the specification's words, "requires extended advertising."

The specification also covers the radio side:

• The advertisement must use a resolvable or non resolvable private Bluetooth address. Resolvable private addresses are required for LE Audio devices and recommended for others, except locator tags that do not use bonding.
• The Fast Pair advertisement, the Find Hub advertisement and the Bluetooth address "should rotate at the same time," on average every 1024 seconds.
• The exact moment of rotation must be randomised. The recommended approach is to add a random delay of 1 to 204 seconds after the scheduled rotation time, so an observer cannot line up identifier changes across devices.
• After provisioning, a beacon should send Find Hub frames at least once every 2 seconds, at a conducted transmit power of at least 0 dBm. If it also sends ordinary Fast Pair frames, the example interleaving is seven Fast Pair advertisements and one Find Hub advertisement every two seconds.

The Bluetooth layer underneath: private addresses

Both systems sit on a privacy feature that Bluetooth Low Energy has had since Core 4.0. The Bluetooth SIG's explainer on LE Privacy describes it simply: the MAC address in advertising packets is replaced with a random value "that changes at timing intervals determined by the manufacturer," so a chain of receivers along your route sees what looks like a series of different devices. Devices you have paired with get an Identity Resolution Key (IRK) that lets them map those random addresses back to your device; strangers do not. The SIG notes that Core 4.2 refined the scheme.

Offline finding layers its own rotating key on top. For Apple, the address and the key are bound together, because the first bytes of the key are carried in the address field. For Google, the specification requires the address and the encrypted identifier to rotate together. Either way, an address that rotated while the payload stayed fixed, or the reverse, would hand an observer a stable identifier, so both designs change everything at once.

Worked example 1: how many keys a week is

Rotation periods turn into concrete numbers the owner's phone has to handle.

Apple. One key every 15 minutes is 4 per hour, 96 per day and 672 per week. Apple's support page on locating a lost device says Find My shows a last known location "for up to seven days", and the PETS paper reports that Apple's servers store offline finding reports for seven days. So an owner looking back over the full retention window needs to derive about 672 key pairs, compute 672 SHA-256 indexes, and ask the server for any reports filed under those indexes. That is trivial work for a phone, which is exactly why the scheme is practical.

Google. One identifier every 1024 seconds is 86,400 / 1,024 = 84.375 identifiers per day, or about 591 over seven days. Take a beacon whose clock reads 1,000,000 seconds. 1,000,000 mod 1,024 = 576, so clearing the low 10 bits gives 999,424, which is 976 x 1,024. Every reading from 999,424 to 1,000,447 produces the same EID. The next scheduled change is at 1,000,448, and the specification's randomisation pushes the actual switch to somewhere between 1 and 204 seconds after that.

Step 2: how a finder encrypts a report the operator cannot read

The Apple side

Apple's companion page in the Platform Security guide, "Locating missing devices", describes what happens when a stranger's iPhone hears the broadcast. Any Apple device with offline finding enabled can "read the current broadcast key Pi." Then, "using an ECIES construction and the public key Pi from the broadcast, the finder devices encrypt their current location information and relay it to Apple."

ECIES, the Elliptic Curve Integrated Encryption Scheme, is the standard way to encrypt a message to an elliptic curve public key. The PETS 2021 paper recovered the exact steps:

1. The finder generates a fresh ephemeral P-224 key pair for this one report.
2. It performs elliptic curve Diffie Hellman between its ephemeral private key and the broadcast public key Pi, producing a shared secret.
3. It runs the ANSI X9.63 key derivation function with SHA-256 over that secret.
4. It uses the first 16 bytes of the output as an AES key and the last 16 bytes as the initialisation vector.
5. It encrypts its location, an accuracy value and a status field with AES-GCM.

The upload contains the finder's ephemeral public key, the ciphertext and the GCM authentication tag, filed under an index. Apple's guide is specific about the index: it is "the SHA-256 hash of the P-224 public key Pi obtained from the Bluetooth payload." Apple's servers can store and return the blob, but they only ever see a hash of a public key and some ciphertext. As the guide puts it: "Apple never has the decryption key, so Apple can't read the location encrypted by the finder."

Finder anonymity is a separate property, and Apple's guide handles it with transport and logging policy rather than cryptography. It says the traffic finders send "contains no authentication information in the contents or headers," that Apple does not know who the finder is or whose device was found, and that Apple "doesn't log information that would reveal the identity of the finder."

The Google side

The Find Hub specification describes the same pattern in more algebraic detail, under the heading "Encryption of values encrypted with EID". The finder, which Google calls the sighter:

1. Picks a random number s and computes S = s * G.
2. Reconstructs the beacon's point R from the broadcast x coordinate, picking either of the two valid y values.
3. Computes a 256 bit AES key k = HKDF-SHA256((s * R)x), with no salt.
4. Builds a nonce from the lower 80 bits of Rx and the lower 80 bits of Sx.
5. Encrypts the location with AES-EAX-256 under k and that nonce, producing a ciphertext and an authentication tag.
6. Sends the upper 80 bits of Rx, the value Sx, the ciphertext and the tag "to the owner, possibly through an untrusted remote service."

That final phrase is the whole point. The specification treats Google's own backend as an untrusted relay.

On the policy side, Google's April 2024 post adds that reports are contributed "in a manner that does not allow Google to identify the owners of the nearby Android devices," and that the owner sees only a location and timestamp, with no information about the devices that contributed. Google's help page on how Find Hub protects data repeats that Google cannot identify you when your phone shares the location of a detected item, and lists what the network does process in addition to encrypted locations: temporary device identifiers, timestamps of detections and location requests, and information about paired Fast Pair accessories.

Why ECIES with an ephemeral key is the right tool

A fresh ephemeral key per report means reports from one finder cannot be linked, the owner never talks to the finder, and the authenticated ciphertext turns server tampering into a decryption failure rather than a wrong location.

What ECIES does not do is authenticate the broadcaster. Anyone can broadcast any well formed public key, and finders will dutifully encrypt their location to it. That is not a flaw in the encryption; it is a property of an anonymous network, and it is the root of the misuse research covered later.

Step 3: how the owner derives the matching private keys and fetches reports

Apple: recompute, hash, query, decrypt

The owner's device holds d and the secret SK0, synced through iCloud Keychain. Apple's guide describes the recovery flow:

1. Estimate the range of counter values that cover the period being searched.
2. For each counter value in the range, recompute SKi, then ui and vi, then the private key di and public key Pi.
3. Compute SHA-256(Pi) for each, giving a list of server indexes.
4. Query Apple's servers for any reports filed under those indexes and download the ciphertexts.
5. Decrypt each report locally with the matching di.

The guide adds that "location reports from multiple finder devices are combined by the owner's app to generate a more precise location." In Apple's design, combining reports is the owner's job, done on the owner's device after decryption.

There is a subtlety in step 1. The lost device's counter and the owner's estimate have to agree. A device that has been off, or whose clock drifted, may be on a different counter than the owner expects, so the owner searches a range rather than a single value. The "Evil Never Sleeps" authors suggest that AirTags' 24 hour rotation may partly reflect the fact that a tag does not have a precise time source.

Google: EID to time window to decryption

Google's owner side works from the opposite direction. The owner's client holds the EIK. When a report arrives carrying the upper 80 bits of Rx, the specification says the client first determines which beacon time counter produced that identifier, recomputes r and R, and checks that R matches the identifier the sighter provided. Then it reconstructs S from Sx, computes k = HKDF-SHA256((r * S)x), rebuilds the nonce and decrypts with AES-EAX-256.

Google's help page explains how the owner gets access to that key in the first place. Locations are encrypted "using a unique key that only you can access by entering your Android device's PIN, pattern, or password," and the page says this is "backed by the same technology used by Google Password Manager to secure your passwords." That is why Google requires a screen lock before you can use the crowdsourced network for your own items: the lock screen credential is what unlocks the key on a new device.

The specification also defines three short keys derived from the EIK with SHA-256 and truncated to 8 bytes, which are stored on the backend:

Because SHA-256 is one way, holding these keys does not reveal the EIK. The backend can be trusted to ring a lost tag without being able to decrypt where it is.

Worked example 2: the toy key schedule, run end to end

To make the algebra concrete, here is a toy Python model of the published Apple construction. It reproduces the affine key relation from the Platform Security guide, checks that ui * P + vi * G really equals di * G, then runs a finder side ECIES encryption and an owner side decryption. It uses the ANSI X9.63 KDF as a stand in for Apple's internal derivation function, and its report layout is simplified, so it is a teaching model, not Apple's wire format. It talks to no network and no device.

python3 -m venv ~/of-demo && . ~/of-demo/bin/activate
pip install cryptography

# toy_offline_finding.py
# Toy model of the key schedule in Apple's Platform Security guide.
# Educational only: X9.63 KDF stands in for Apple's internal KDF,
# and the report layout is simplified. Not Apple's wire format.
import os, hashlib
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives.kdf.x963kdf import X963KDF
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

# NIST P-224 domain parameters
p = 2**224 - 2**96 + 1
a = p - 3
n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFF16A2E0B8F03E13DD29455C5C2A3D
G = (0xB70E0CBD6BB4BF7F321390B94A03C1D356C21122343280D6115C1D21,
     0xBD376388B5F723FB4C22DFE6CD4375A05A07476444D5819985007E34)

def add(P, Q):
    if P is None: return Q
    if Q is None: return P
    if P[0] == Q[0] and (P[1] + Q[1]) % p == 0: return None
    if P == Q: l = (3 * P[0] * P[0] + a) * pow(2 * P[1], -1, p) % p
    else:      l = (Q[1] - P[1]) * pow(Q[0] - P[0], -1, p) % p
    x = (l * l - P[0] - Q[0]) % p
    return (x, (l * (P[0] - x) - P[1]) % p)

def mul(k, P):
    R = None
    while k:
        if k & 1: R = add(R, P)
        P, k = add(P, P), k >> 1
    return R

def kdf(secret, label, length):
    return X963KDF(hashes.SHA256(), length, label).derive(secret)

# 1. Setup on the owner's device: master key pair {d, P} and secret SK0
d = int.from_bytes(os.urandom(28), "big") % n
P = mul(d, G)
SK = os.urandom(32)

# 2. Roll forward to counter i and derive the short-lived key pair
def derive(i):
    sk = SK
    for _ in range(i):
        sk = kdf(sk, b"update", 32)
    uv = kdf(sk, b"diversify", 72)
    u = int.from_bytes(uv[:36], "big") % n
    v = int.from_bytes(uv[36:], "big") % n
    d_i = (u * d + v) % n
    P_i = add(mul(u, P), mul(v, G))      # public side: u*P + v*G
    assert P_i == mul(d_i, G)            # same point as d_i*G
    return d_i, P_i

i = 96                                   # 96 x 15 minutes = 24 hours
d_i, P_i = derive(i)
x_bytes = P_i[0].to_bytes(28, "big")     # 28 bytes: what goes on air
index = hashlib.sha256(x_bytes).hexdigest()
print("counter", i, "broadcast x:", x_bytes.hex()[:16], "... server index:", index[:16], "...")

# 3. A finder encrypts its location to P_i (ECIES: ephemeral ECDH + KDF + AES-GCM)
pub = ec.EllipticCurvePublicNumbers(P_i[0], P_i[1], ec.SECP224R1()).public_key()
eph = ec.generate_private_key(ec.SECP224R1())
shared = eph.exchange(ec.ECDH(), pub)
eph_pub = eph.public_key().public_bytes(serialization.Encoding.X962,
                                        serialization.PublicFormat.UncompressedPoint)
key_iv = kdf(shared, eph_pub, 32)
report = AESGCM(key_iv[:16]).encrypt(key_iv[16:], b"lat=48.8584,lon=2.2945,acc=12m", None)
print("finder uploads: index + ephemeral key + %d byte ciphertext" % len(report))

# 4. The owner recomputes d_i from d and SK, then decrypts
priv = ec.derive_private_key(d_i, ec.SECP224R1())
shared2 = priv.exchange(ec.ECDH(), ec.EllipticCurvePublicKey.from_encoded_point(ec.SECP224R1(), eph_pub))
key_iv2 = kdf(shared2, eph_pub, 32)
print("owner decrypts:", AESGCM(key_iv2[:16]).decrypt(key_iv2[16:], report, None).decode())

A run looks like this (the hex values change every time because the keys are random):

counter 96 broadcast x: 5219116935f08a5a ... server index: 37801d50a6212ce5 ...
finder uploads: index + ephemeral key + 46 byte ciphertext
owner decrypts: lat=48.8584,lon=2.2945,acc=12m

Three things are worth noticing. The assert passes, which is the affine relation doing its job: the public side and the private side of key 96 were computed by different formulas and still agree. The 46 byte ciphertext is the 30 byte location string plus a 16 byte GCM tag. And the only thing the "server" in this model ever sees is a SHA-256 index, an ephemeral public key and that ciphertext.

What Apple's Platform Security guide says about end to end encryption

It is worth separating what Apple's own documentation commits to from what researchers inferred, because the two are often blended in secondary coverage. The Find My pages of the Apple Platform Security guide, published 18 February 2021 and still current in the online guide, make these specific statements:

• The P-224 key pair is "generated directly on the device."
• The private key pair and the secret "are never sent to Apple" and are synced only among the user's other devices "in an end-to-end encrypted manner using iCloud Keychain."
• Finders encrypt their location using "an ECIES construction and the public key Pi from the broadcast."
• "Apple never has the decryption key, so Apple can't read the location encrypted by the finder."
• Finder traffic "contains no authentication information in the contents or headers," and Apple "retains no information that would allow anyone to correlate the finder and owner."
• The owner device decrypts locally and "shows an approximate location of the missing device in the app."

The same pages also describe defaults and limits. Offline finding is turned on by default when Find My iPhone is enabled and a device is upgraded to iOS 13, iPadOS 13.1 or macOS 10.15 or later. A user can turn it off, and then the device "no longer acts as a finder nor is it detectable by other finder devices." Apple also notes that you cannot play a sound on, or remotely erase, a device that is only reachable through offline finding.

What the guide does not specify is just as useful to know. It does not name the KDF, the symmetric cipher, the exact report layout, the retention period on Apple's servers, or the AirTag rotation schedule. Those details come from the reverse engineering in the PETS 2021 and WiSec 2022 papers, and the MFi accessory specification that third party manufacturers receive is not public. Apple's developer page for the Find My network says manufacturers must enrol in the MFi Program "to access the technical specifications." Treat any detail beyond the guide as researcher findings, dated to the software version they studied.

How Google's Find Hub network encrypts reports, aggregates them and handles busy places

The cryptographic core of Find Hub is the specification described above. What Google adds on top are network rules that limit how a location is released to the owner. Google introduced them in the April 2024 security blog post when the network launched under the name Find My Device; Google has since renamed the app and the network Find Hub, and its help pages use the new name.

Aggregation by default

Google calls this "a first-of-its-kind safety protection." By default, the network "requires multiple nearby Android devices to detect a tag before reporting its location to the tag's owner." The help page on how Find Hub protects data explains the mechanics: the network waits until several Android devices have detected a lost item, then shows the owner an aggregated location calculated from the multiple reports.

The reasoning, in Google's words, is that the network is most valuable "in public settings like cafes and airports, where there are likely many devices nearby," while a tag hidden near a private place, such as someone's home, will rarely be seen by several phones at once. Aggregation makes the network much less useful for following a person to a quiet location, at the cost of making it less useful for finding things left somewhere quiet.

Note where aggregation sits compared with Apple's design. In Apple's guide, multiple reports are combined by the owner's app after decryption. In Google's design, the network decides whether enough independent reports exist before releasing a location at all. That is a network side policy, and Google's help page lists "providing privacy and anti-abuse protections, such as the aggregation feature" among the purposes for which the network processes temporary identifiers and timestamps.

The settings, including "busy places only"

Google's "Be ready to find a lost Android device" help page lists four positions for the network setting:

The April 2024 post described the busy places option as aggregated reporting in "high-traffic areas"; the current help page calls it "With network in busy places only." Both refer to the same default.

At home protection, rate limits and throttling

Three more rules from the April 2024 post:

• At home protection. If you have saved a home address in your Google Account, your phone will not contribute crowdsourced reports when it is near your home. Your own phone can still find your own tag at home.
• Rate limiting. The network limits how many times one Android device can contribute a report for a particular tag.
• Throttling. The network limits how often the owner of a tag can request a fresh location.

Google's argument is that lost items tend to stay put, at the cafe table or in the checked bag, while someone stalking a person wants real time updates. Slowing updates barely hurts the first use and seriously hurts the second.

The post also lists data minimisation steps: encrypted location data is "minimally buffered and frequently overwritten," and if the owner's own nearby devices can find the tag, the network discards crowdsourced reports for it.

What academic analyses found, with dates

Because Apple did not publish full specifications, much of what is publicly known about offline finding comes from researchers who reverse engineered it. The record below lists the peer reviewed work and the vendor milestones it relates to, with dates checked against the paper pages and vendor documentation.

2021: the first full security analysis of Apple's offline finding

Heinrich, Stute, Kornhuber and Hollick reverse engineered the closed protocols and published "Who Can Find My Devices? Security and Privacy of Apple's Crowd-Sourced Bluetooth Location Tracking System" at PETS 2021. Their conclusions split cleanly:

• The cryptographic design held up. The abstract says plainly that "OF's design achieves its privacy goals." The paper also notes the authors were unaware of practical attacks on P-224 when used only for ECDH, which is how offline finding uses it.
• Location data is sensitive when exposed. With access to reports, the team could track devices and recover a user's most visited places with an error "in the order of 10 meters in urban areas." That is a measure of how much the encryption is protecting, not a break of it.
• Two flaws sat outside the core cryptography. One was a design issue that could let the operator correlate the locations of different owners' devices from how reports are requested, a location correlation attack. The other was an implementation issue on macOS that let a malicious local application obtain and decrypt the owner's location reports for the past seven days. The paper says Apple "partially addressed" the issues after disclosure, and records the macOS fix as CVE-2020-9986.

The lesson generalises. End to end encryption protects data on the server, but the keys that decrypt it live on endpoints, and the metadata of who asks for which index can leak relationships even when every byte of content stays encrypted.

2022: what keeps running when an iPhone is off

Classen, Heinrich, Reith and Hollick's "Evil Never Sleeps: When Wireless Malware Stays On After Turning Off iPhones" studied the low power mode that keeps Find My working after shutdown. Their abstract says that on recent iPhones, "Bluetooth, Near Field Communication (NFC), and Ultra-wideband (UWB) keep running after power off," and that all three wireless chips have direct access to the secure element. They demonstrated that modified firmware could be loaded onto the Bluetooth chip and run while the iPhone was off, which reframes "off" as "the main processor is off." The paper does not suggest the cryptography of Find My is weak; it shows that the components doing the broadcasting are their own computers with their own firmware and attack surface. Its findings on the 24 hour limit are covered in the hardware section below.

2025: making an ordinary computer look like a tag

Chen, Ma, Luo and Zeng of George Mason University presented "Tracking You from a Thousand Miles Away! Turning a Bluetooth Device into an Apple AirTag Without Root Privileges" at USENIX Security 2025 in August 2025, and the work received a Distinguished Artifact Award. Their abstract describes nRootTag, a method that makes computers trackable through the Find My network like an AirTag without root privileges, with "a success rate of over 90% within minutes at a cost of only a few US dollars," and notes that a precomputed table can make the key search instant. They report it works against Linux, Windows and Android systems, and against desktops, laptops, smartphones and IoT devices.

At a conceptual level this is the property flagged earlier: finders cannot authenticate who is broadcasting, so anything that can emit a well formed advertisement can borrow the network. The specific contribution was showing how to do that without the elevated privileges normally needed to control a device's Bluetooth address, by searching for keys that fit. We are not reproducing the method. Fix status for this research is reported mainly in secondary coverage, so check Apple's security release notes rather than press summaries.

What about Google's network?

The public academic record on Find Hub is thinner, partly because Google published its accessory specification from the start, so there was less to reverse engineer. Google's April 2024 post says the network went through internal Android red team testing, was added to the Android security vulnerability rewards program, and is open to selected researchers through a private grant program. We did not find a peer reviewed security analysis of Find Hub comparable to the Apple papers above at the time of writing, and we do not cite secondary summaries of unpublished work.

How unwanted tracker alerts work across platforms, and the IETF DULT work

Rotation hides an owner's device from strangers. The same rotation would hide a planted tag from the person carrying it. Unwanted tracking alerts solve this by changing how a tracker behaves once it is separated from its owner, so that a nearby phone can notice it travelling along.

The platform features

Apple's support article on unwanted tracking alerts says AirTag, Find My network accessories and some AirPods models have "unique Bluetooth identifiers that change frequently," and that if one separated from its owner is "seen moving with you over time," you get a notification, or the item itself emits a sound when moved. Tracking Notifications need iOS 14.5 or iPadOS 14.5 or later; alerts for compatible trackers from other makers need iOS 17.5 or iPadOS 17.5 or later. The alert is titled "AirTag Found Moving With You" (or the equivalent for other items), shows a map of where the item was observed with you, and lets you play a sound, use Precision Finding if your iPhone has Ultra Wideband, and get instructions to disable it.

Google's "Find unknown trackers" help page says the feature works on Android 6 and up and covers Find Hub compatible tags, headphones and Apple AirTags. You can run a manual scan from Settings, Safety & Emergency, Unknown tracker alerts, Scan now, which takes about 10 seconds and shows trackers separated from their owners that are currently near you. The page is careful about one point many people get wrong: turning off Bluetooth or location, or turning on airplane mode, "won't prevent the owner of the tracker or device from finding the location of the tracker," because other people's phones are doing the reporting.

On 13 May 2024 Apple and Google announced that they had built a joint industry specification called Detecting Unwanted Location Trackers, shipped it in iOS 17.5 and on Android 6.0 and later, and would continue the work through the IETF.

The DULT working group and its drafts

The IETF's Detecting Unwanted Location Trackers (DULT) working group sits in the Security Area. Its charter describes three subsystems that matter to unwanted tracking, the crowdsourcing network, unwanted tracker detection and alerting, and commits the group to a protocol between tracking accessories and nearby devices, plus guidance for manufacturers and for phone platforms. The charter says the mechanisms "will be designed to not create new vectors for user tracking," that the group will work with gender based violence experts throughout, and that it will not define requirements for interactions with law enforcement.

The working group documents on the Datatracker at the time of writing are:

The accessory protocol draft, written by Apple and Google authors, contains the rule that resolves the rotation conflict. An accessory keeps a near owner state. It moves to separated mode after it has been physically separated from the owner's device for more than 30 minutes, and back to near owner mode within 30 minutes of being reunited. Then:

• In near owner state, the accessory "SHALL rotate its address every 15 minutes," a privacy measure to stop strangers tracking it while it is with its owner.
• In separated state, it "SHALL rotate its address every 24 hours," which "allows a platform's unwanted tracking algorithms to detect that the same accessory is in proximity for some period of time."
• It rotates its address on every transition between the two states.
• It broadcasts a location enabled payload whenever location is available to the owner, or was within the past 24 hours, and sets a near owner bit so platforms can ignore tags that are with their owners.
• The payload uses service data with the 16 bit UUID 0xFCB2, which gives any platform one value to scan for.

Google's Find Hub specification implements a related, stronger control. The backend can relay a request that switches a tag into unwanted tracking protection mode, after which "the beacon should reduce MAC private address rotation frequency to once per 24 hours" while the encrypted identifier keeps rotating as usual. The frame type changes from 0x40 to 0x41 so scanners can tell. Switching the mode requires a one time authentication value built from the unwanted tracking protection key, so a random passer by cannot toggle it.

How power reserve and "findable after power off" work at the hardware level

The phrase "findable when off" sounds like a contradiction until you remember that a phone contains several processors. The application processor runs iOS or Android. The Bluetooth controller, NFC controller and Ultra Wideband chip each run their own firmware. Turning the phone "off" stops the operating system; it does not have to stop every radio.

iPhone

Apple's iPhone User Guide is precise about the limits. With the Find My network setting on, "on a supported iPhone, turning on the Find My network allows you to locate your iPhone for up to 24 hours after it's turned off, or up to 5 hours when it's in power reserve mode." Power reserve is the state the phone enters when the battery runs too low for normal operation.

The "Evil Never Sleeps" paper explains why the window is finite. The Bluetooth chip cannot run the key schedule by itself while iOS is down, so iOS hands it a batch of advertisements before shutdown. The researchers found that "as of iOS 15.3, 96 short interval (15 min) and 0 long interval (24 h) keys are set," so the standalone Bluetooth firmware "can only send Find My advertisements for up to 24 h." Ninety six keys times 15 minutes is exactly 24 hours, which matches Apple's documented limit. The paper also reports that advertisements for the next 24 hours are stored on disk at power off, and that if the phone is powered on but not unlocked after that window, advertising stops until first unlock.

This is the third worked example in miniature: 96 keys x 15 minutes = 1,440 minutes = 24 hours. At one advertisement every two seconds, that window is 43,200 advertisements, all prepared before the phone went dark.

Android

Google's help page is less specific, which is honest given how many hardware makers ship Android. It says that for supported devices, "like the Pixel 8 series," if the phone runs out of battery or is off, the Find Hub network "can still locate the phone for several hours after it's turned off." Two conditions apply: the network setting must be "With network in busy places only" or "With network everywhere," and Bluetooth and Location must be on when the phone shuts down.

The accessory specification says the same thing from the device maker's side: it is "recommended to advertise the FHN frames even when the device is in low power mode," and it acknowledges that for some devices advertising after power off may not be possible because of battery life. In other words, power off finding depends on whether the hardware can keep a Bluetooth controller alive with enough key material, and that differs by model.

Either way, findable after power off is bounded. After the window closes, the owner sees a last known location and a timestamp, and the device was only ever replaying public keys whose private halves stay with the owner.

Step by step: checking your settings and watching rotation yourself

You do not need to take any of this on trust. The steps below check how your own devices are configured and let you watch your own tag or phone rotate its identifiers from a Linux laptop. They only observe Bluetooth advertisements, which any nearby radio already receives; they do not connect to, modify or decrypt anything.

1. Check the iPhone settings

1. Open Settings, tap your name, then Find My, then Find My iPhone.
2. Confirm Find My iPhone is on.
3. Confirm Find My network is on. Apple's guide says this is what lets you locate the phone offline and after power off on supported models.
4. Decide on Send Last Location, which uploads the location when the battery is critically low.
5. For alerts about other people's trackers, keep the iPhone updated to iOS 17.5 or later and allow Find My notifications.

2. Check the Android settings

1. Open Settings, then Google, then All services (if your phone shows tabs), then Personal & device safety, then Find Hub.
2. Confirm "Allow device to be located" is on.
3. Open the Find Hub network option and choose between Off, Without network, With network in busy places only, and With network everywhere, using the table earlier in this post.
4. Make sure the phone has a PIN, pattern or password. Without one, the network still uses your phone to help others, but you cannot use the network to find your own items.
5. For alerts, open Settings, then Safety & Emergency, then Unknown tracker alerts, and confirm alerts are on. Use Scan now if you want a one off check.

3. Watch advertisements from a Linux laptop

Install BlueZ tools and a Python Bluetooth library on a laptop with a Bluetooth adapter:

sudo apt install bluez
python3 -m venv ~/ble-watch && . ~/ble-watch/bin/activate
pip install bleak

First, check the adapter is up and see raw advertising reports. btmon prints every HCI event, including the advertising data and the random address of each sender:

bluetoothctl show            # confirm "Powered: yes"
bluetoothctl power on
sudo btmon | tee ble.log &   # raw HCI trace to a file
bluetoothctl --timeout 60 scan on

Then run a small script that only logs advertisements matching the three formats discussed in this post: Apple offline finding (manufacturer data for company 0x004C starting with type 0x12), Google Find Hub frames (service data 0xFEAA with frame type 0x40 or 0x41), and the DULT location enabled payload (service data 0xFCB2):

# watch_finding_adverts.py: log offline finding advertisements and address changes
import asyncio, time
from bleak import BleakScanner

FEAA = "0000feaa-0000-1000-8000-00805f9b34fb"
FCB2 = "0000fcb2-0000-1000-8000-00805f9b34fb"

def classify(adv):
    md = adv.manufacturer_data.get(0x004C)
    if md and md[0] == 0x12:
        return "apple-offline-finding"
    sd = adv.service_data.get(FEAA)
    if sd and sd[0] in (0x40, 0x41):
        return "find-hub-utp" if sd[0] == 0x41 else "find-hub"
    if FCB2 in adv.service_data:
        return "dult"
    return None

def on_advert(device, adv):
    kind = classify(adv)
    if kind:
        print(time.strftime("%H:%M:%S"), kind, device.address, adv.rssi, "dBm")

async def main(minutes=60):
    async with BleakScanner(detection_callback=on_advert):
        await asyncio.sleep(minutes * 60)

asyncio.run(main())

python watch_finding_adverts.py | tee adverts.log

Put your own iPhone in airplane mode with Bluetooth on, or leave your own tag away from its owner phone, and let the script run for an hour. Then count how many distinct addresses appeared per type:

awk '{print $2, $3}' adverts.log | sort -u | awk '{print $1}' | uniq -c

What you should expect, based on the documentation above: an iPhone that has lost connectivity should show a new address roughly every 15 minutes; a Find Hub device should change address about every 1024 seconds plus a random offset; and a Find Hub tag in unwanted tracking protection mode (find-hub-utp) or a DULT tag in separated state should keep the same address for much longer. Results vary by device, firmware and whether the item believes it is near its owner, so treat the run as an observation, not a test of compliance.

4. If you find a tracker you do not recognise

Follow the platform guidance rather than improvising. On iPhone, tap the alert, play a sound or use Precision Finding, and follow the disable instructions in the alert. On Android, tap the notification to see the map, use Find nearby or Play sound for Find Hub compatible trackers, and record the identifier shown. Google's page advises that if you cannot find the device and feel unsafe, you go to a public location and contact law enforcement, and notes that police may ask for the tracker, its identifier or other information. Apple's article says law enforcement can request available information from Apple about an item found tracking a person unlawfully. Before you disable a tracker, think about your own safety plan first, because removing it changes what its owner sees.

Common mistakes

• Assuming airplane mode hides you from a planted tracker. It does not. The tracker broadcasts; other people's phones report it. Google's help page says this explicitly.
• Assuming the network operator can see where your device is. Both Apple's guide and Google's specification put the decryption key with the owner. The operator stores ciphertext under hashed or truncated identifiers.
• Assuming the operator learns nothing at all. It still processes metadata: temporary identifiers, timestamps of detections and requests, and which indexes an owner asks for. The PETS 2021 location correlation finding came from exactly that kind of metadata.
• Treating "findable after power off" as indefinite. Apple documents up to 24 hours after power off and up to 5 hours in power reserve. Google says several hours on supported models. After that, you see a last known location.
• Forgetting the screen lock on Android. Without a PIN, pattern or password, you cannot use the Find Hub network to find your own items, even though your phone keeps helping others.
• Reading reverse engineered details as vendor guarantees. Rotation intervals for AirTags, server retention periods and exact cipher choices for Apple come from research papers about particular software versions. Re-check them against current documentation before relying on them.
• Equating "rotating identifier" with "untraceable". Signal strength, timing and advertising patterns can still help a nearby observer follow a device over short distances. Rotation stops long term linking, not physical presence detection.

FAQ

How does Find My find a phone that has no internet?

The phone broadcasts a rotating public key over Bluetooth. Any nearby Apple device with offline finding on hears it, encrypts its own location to that key and uploads the result to Apple. You download the encrypted reports and your device decrypts them.

Can Apple or Google see where my lost device is?

Not from the report contents, according to both companies' documentation. Apple says it never has the decryption key. Google says it cannot decrypt, see or use the location data. Both still process some metadata, such as timestamps and temporary identifiers.

How often does an AirTag or iPhone change its Bluetooth key?

Apple's Platform Security guide says the public key changes approximately every 15 minutes. Research on iOS 15 found that a separated AirTag rolls its key every 24 hours so phones can detect one travelling with them, which matches the 24 hour separated rotation in the IETF DULT draft.

How often does a Find Hub tag change its identifier?

Google's Find Hub accessory specification fixes the rotation period at 1024 seconds, about 17 minutes, with a random offset of 1 to 204 seconds. In unwanted tracking protection mode the Bluetooth address rotates only once per 24 hours while the encrypted identifier keeps rotating.

What is aggregation in Google Find Hub?

By default, Find Hub waits until several Android devices have detected a lost item before showing its owner an aggregated location. It makes tracking a person to a private place harder, at the cost of weaker coverage in quiet areas.

Can someone track me with an AirTag if I use Android?

Android 6 and later can alert you to unknown trackers that are moving with you, including AirTags, and you can run a manual scan from Safety & Emergency settings. Apple and Google launched these cross platform alerts on 13 May 2024.

Does turning off Bluetooth stop a tracker from reporting my location?

No. Google's help page says turning off Bluetooth or location, or turning on airplane mode, will not prevent the tracker's owner from finding it, because other phones nearby report it.

Can an iPhone be found when it is turned off?

Apple says a supported iPhone with the Find My network on can be located for up to 24 hours after it is turned off, or up to 5 hours in power reserve mode. Research found this comes from 96 preloaded 15 minute keys.

Can an Android phone be found when it is off?

Google says supported devices such as the Pixel 8 series can be located through the Find Hub network for several hours after they turn off, if the network setting is on and Bluetooth and Location were on at shutdown.

What is the IETF DULT working group?

Detecting Unwanted Location Trackers is the IETF working group standardising how tracking accessories advertise themselves and how any phone can detect one travelling with it, building on the joint Apple and Google specification. Its accessory protocol, finding and threat model drafts are on the IETF Datatracker.

Where Safeguard fits, and where it does not

Safeguard does not scan firmware, manage devices, provide endpoint protection, generate hardware bills of materials, or analyse Bluetooth traffic. Nothing in this post is something Safeguard does for you; the protections described here belong to Apple, Google, the device makers and the IETF. The honest connection is software. Tag companion apps, the backends that relay encrypted reports, and the scanners and test tools that teams build around Bluetooth all depend on open source components: cryptography libraries, Bluetooth stacks such as BlueZ, and client libraries like the two used in the walkthrough above. If your team builds that kind of software, Safeguard can scan the repository, container image or SBOM (safeguard scan --dir ., --image, --sbom), show which projects carry a given component version, and match those versions against vulnerability data, with reachability analysis to rank the code paths you actually call. It cannot tell you whether a phone's Bluetooth firmware or a tag's key schedule is sound.

Fix it without waiting for upstream

Offline finding depends on cryptography and Bluetooth code that someone has to ship and update, and the software teams build around it, from companion apps to report relays and test harnesses, pulls the same open source libraries every other project does. The fit is indirect for phone owners, but for teams that build on these stacks, keeping those dependencies current is the part of this story they control.

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

The first demo is a real Safeguard CLI session. You install the CLI, open the interactive terminal with safeguard, and ask it to fix the lodash CVE in a repository. It reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. A team maintaining a tag companion app or a Bluetooth test harness would use the same flow on a vulnerable dependency in its own repository.

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

The second demo is a real Android session. You send work from your phone to a computer running the CLI, and approve each command on the phone with Allow once, Allow for turn or Deny. It fits a developer who is away from the desk and wants to start a dependency fix on a mobile or backend project without giving up approval of each step.

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 lets you choose which tools Claude can use. An engineer reviewing a Bluetooth related service could then ask which projects contain a particular cryptography library version from the same assistant they use to read a specification, while decisions stay with a person.

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

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

Quick check

Sources

• Apple Platform Security: Find My security
• Apple Platform Security: Locating missing devices
• Apple iPhone User Guide: Add your iPhone to Find My
• Apple iPhone User Guide: Locate a device in Find My on iPhone
• Apple Support: Use Find My to locate your lost Apple device or AirTag
• Apple Support: What to do if you get an alert that an AirTag or other tracker is with you
• Apple Developer: Find My network
• Apple Newsroom: Apple and Google deliver support for unwanted tracking alerts in iOS and Android (13 May 2024)
• Google Online Security Blog: How we built the new Find Hub network with user security and privacy in mind (8 April 2024)
• Google for Developers: Find Hub Network accessory specification
• Android Help: Be ready to find a lost Android device
• Google Help: How Find Hub protects your data
• Android Help: Find, secure, or erase a lost Android device
• Android Help: Find unknown trackers
• IETF: Detecting Unwanted Location Trackers (dult) working group charter
• IETF: draft-ietf-dult-accessory-protocol-00
• IETF: draft-ietf-dult-threat-model-05
• IETF Datatracker: DULT working group documents
• Heinrich et al., Who Can Find My Devices? PoPETs 2021(3)
• Heinrich et al., Who Can Find My Devices? arXiv 2103.02282
• Classen et al., Evil Never Sleeps: When Wireless Malware Stays On After Turning Off iPhones, arXiv 2205.06114 (WiSec 2022)
• Chen et al., Tracking You from a Thousand Miles Away! USENIX Security 2025
• Bluetooth SIG: Bluetooth technology protecting your privacy

Last reviewed: 23 October 2026. Vendor documentation and IETF drafts change; check the linked Apple, Google and IETF pages for the current details.