Google Find Hub Accessory Requirements

Concept render

Google's Find Hub accessory specification asks for end-to-end encrypted BLE beaconing, registration in the Nearby Device Console, transmit power of at least 0 dBm and a 24-hour MAC rotation in unwanted-tracking protection mode. The IETF DULT draft adds a 60 Phon sound and a 15-minute near-owner rotation. Figures are as of October 31, 2026.

If you build a tracker for people who use both Android and iPhone, you read two sets of rules. This guide lays out the Android side, the Find Hub Network (FHN) accessory specification, next to the cross-platform IETF DULT draft that Google requires certified devices to meet. It gives a side-by-side checklist, a count of address rotations per day, and a way to estimate the advertising load on a battery from your own SoC numbers. It contains no Duobay price, no measured result and no certification outcome.

This is an engineering summary. Get legal advice for your own product. Specifications change. All figures are as of October 31, 2026, so read the linked originals before you freeze requirements.

What does each document ask of a tracker?

Google describes the FHN accessory specification as "an end-to-end encrypted approach for tracking beaconing Bluetooth Low Energy (BLE) devices" (Google Find Hub spec, as of October 31, 2026). Certified FHN devices must also meet the requirements in the implementation version of the cross-platform specification. The DULT draft is the IETF work on detecting unwanted location trackers (IETF datatracker, as of October 31, 2026).

The DULT draft is Internet-Draft -01, dated 27 October 2026. The table lists only the clauses quoted on this page, so read the full draft. Apple's Find My specifications are available after MFi enrollment (Apple Find My page, as of October 31, 2026), so this table has no Apple column.

How often do addresses rotate?

Firmware cost comes from how many times per day each event happens. The counts below follow from the quoted figures.

Inputs from Google Find Hub spec and IETF DULT draft, as of October 31, 2026.

How do you estimate the advertising load on a battery?

This is an estimate. It needs numbers from your chosen SoC datasheet and then from your own board, and we do not supply them. A made-up current would look like a fact.

I_adv_avg   = Q_evt / T_adv                    (µC ÷ s = µA)
I_avg       = I_sleep + I_adv_avg + I_other    (µA)
battery_h   = C_batt / I_avg                   (µA·h ÷ µA = hours)
ring_charge = I_ring × ring_seconds            (µC, per ring event)

Scaling: each 1 µC you save per advertising event lowers the average current by 1 / T_adv µA, so a shorter interval raises the load in proportion. Recompute with your own Q_evt and the T_adv your firmware uses before you rely on any of this.

For ring events, compute ring_charge once with your measured I_ring and the longest ring your design allows, and decide how many ring events per month your battery promise has to cover. That count is your product decision, so we leave it blank.

Inputs, and which are yours to replace

Figures for your enclosure, your cell and your firmware do not exist in any public document, so measure them on your board.

What pitfalls follow from these numbers?

These items are engineering reasoning from the figures above. None describes an incident at any company.

• A draft that moves. The DULT document is an Internet-Draft, version -01 dated 27 October 2026. Numbers in it can change before any final form. Copy the version into your requirements file with the access date.
• "Should" and "MUST" are different strengths. In the text we read, Google words the 0 dBm floor and the 24 h rotation as "should", and the DULT draft words the 60 Phon sound as "MUST" and the 15-minute rotation as "SHALL". A test plan that treats them the same will either over-test or under-test. Read the wording in the current spec and mark each line as a requirement or a recommendation.
• Rotation depends on state. The DULT draft rotates the address every 15 minutes near the owner, and Google reduces rotation to once per 24 hours in unwanted tracking protection mode. Firmware needs a state machine that knows which state the tag is in and which timer applies.
• Loudness is measured in Phon. The sound requirement is a Phon figure defined by ISO 532-1:2017. A plain sound-level reading from a cheap meter cannot give you Phon. Plan the measurement method and the equipment early, because the enclosure changes the result.
• A transmit power floor against a small cell. A floor of at least 0 dBm raises the charge for every advertising event. That sets a minimum advertising load you cannot trade away. Check the battery estimate before you pick the cell.
• Planning Apple from public text. Apple states that you must enroll in the MFi Program to access the technical specifications. This page therefore says nothing about Apple technical requirements beyond that public statement. Do not plan an Apple schedule from this table.
• A partial table. The table lists only the clauses quoted on this page. Rows marked "Not captured in our notes" are gaps in this page, and the full document may say more. Read the full draft and spec.

What should you test on your own board?

We have not run any of these tests for your product, and this page reports no results. Set each pass line from your product requirements and record the basis for it before you run the test.

The pass line is yours to set from the product requirement. Record the basis for each line next to it.

What should you think through before you choose?

Take this list to your firmware lead, your hardware lead and any supplier who proposes a design.

• Which line in each spec is a requirement and which is a recommendation, and who on the team owns that reading?
• Which version of the DULT draft are we designing to, and what is our plan when the draft changes?
• Which SoC datasheet do our current numbers come from, and have we measured our own board against them?
• Does the smallest cell we can fit still carry the advertising load at 0 dBm and the longest ring we allow?
• How will we measure loudness in Phon for the finished enclosure, and with what equipment?
• Who registers the device in the Nearby Device Console, and under whose company account?
• What does the tag do in each state, and which timer moves it from one to the next?
• What is our Apple path, given that the specifications sit behind MFi enrollment?
• Who owns each certification step, and who pays for it?
• Which numbers in our estimate are measured on our board and which are still datasheet values?

Planning a tracker for both phone ecosystems and want the schedule and battery math checked against your board? Tell us about your device. For how we scope this kind of product, see LTE and GNSS tracker development.

Primary sources

All pages below were accessed on 2026-10-31. Specifications change, so confirm figures on the live pages.

• Google, Find Hub Network accessory specification: https://developers.google.com/nearby/fast-pair/specifications/extensions/fmdn (accessed 2026-10-31)
• IETF, draft-ietf-dult-accessory-protocol: https://datatracker.ietf.org/doc/draft-ietf-dult-accessory-protocol/ (accessed 2026-10-31)
• Apple, Find My overview: https://developer.apple.com/find-my/ (accessed 2026-10-31)