Concept renderThe IETF DULT draft, version 01, asks a tracker to rotate its address every 15 minutes near the owner and every 24 hours when separated, play a sound of at least 60 Phon when separated, and let a non-owner read its identifier by NFC tap or a button-gated Bluetooth LE command.
A tracker can be misused to follow a person who does not know it is there. Platforms and standards groups are writing down what a tracker should do to prevent that. This guide reads the IETF draft and turns its requirements into a checklist for a firmware and product lead. It is safety-by-design material. It contains nothing about turning alerts down or around, and it reports no Duobay test results.
This is an engineering summary of public drafts. It is not legal advice. The draft is not a final RFC, so read the original text before you design against it.
What is the DULT draft, and how firm is it?
The Detecting Unwanted Location Trackers accessory protocol is an active IETF Internet-Draft, draft-ietf-dult-accessory-protocol-01. It is dated 27 Oct 2026, expires 30 Apr 2027 and has intended status Informational (IETF, as of October 31, 2026). Apple and Google announced the joint specification in May 2023 and submitted it to the IETF (Apple newsroom, as of October 31, 2026). A companion threat model draft (draft-05, updated 2026-08-06) is also in progress (IETF datatracker, as of October 31, 2026).
Only parts of the long accessory draft were reviewed for this page. The quoted requirements below were checked against the raw text. Other sections were not reviewed.
What does each requirement mean for hardware and firmware?
The table pairs each requirement with the design work it creates. The right column is our engineering reading of the quoted text. The draft does not say it.
| Requirement | What the source says | What it means for the design | Source |
|---|---|---|---|
| Address rotation, near-owner state | The accessory SHALL rotate its address every 15 minutes. | A timer and a random or keyed address generator in firmware. 24 hours x 60 minutes / 15 minutes = 96 rotations per day while near the owner. | DULT accessory draft, as of October 31, 2026 |
| Address rotation, separated state | The accessory SHALL rotate its address every 24 hours. | A second schedule, plus a clean state change between the two schedules. 1 rotation per day while separated. | DULT accessory draft, as of October 31, 2026 |
| Sound maker | The accessory MUST include a sound maker that plays in separated state, with minimum 60 Phon peak loudness. | A speaker or buzzer, a driver, an acoustic path through the enclosure and a line on the bill of materials. Phon is a perceptual unit, so the enclosure decides whether you meet it. | DULT accessory draft, as of October 31, 2026 |
| When the sound plays | Either periodically or when motion is detected, while in separated state. | If you choose motion, you need a motion sensor and a wake path to the sound driver. The draft text we quote here does not fix how long the sound plays, so treat the duration as your own design choice and check the draft text before you size the battery. | DULT accessory draft, as of October 31, 2026 |
| Identifier retrieval for an unknown tag | Readable through NFC tap or Bluetooth LE. The Bluetooth LE route MUST have a physical mechanism, for example a button, required to enable the Get_Identifier opcode. | Either an NFC antenna and tag interface, or a button (or similar physical control) wired to firmware that gates the opcode. Both change the enclosure and the board. | DULT accessory draft, as of October 31, 2026 |
| Finding an unknown tag | Once a user has been notified of an unknown accessory traveling with them, it is REQUIRED they have the means to physically locate it. | A design question for the whole product: how does a person who does not own the tag find it? The sound alert is one input to that answer. | DULT accessory draft, as of October 31, 2026 |
| Firmware integrity | Accessories MUST verify the integrity and origin of firmware. This is from the companion threat model draft (draft-05, updated 2026-08-06). | A signed image and a verified boot path, and an update flow that keeps the check. This ties into your OTA design. | DULT threat model draft, as of October 31, 2026 |
How do you budget the cost of the sound alert?
The draft requires a sound in separated state. The sound is a recurring load on the battery. This formula turns your own assumptions into a daily charge figure.
Q_day (mAh) = n × t × I / 3600
n = sound alerts per day while separated
t = seconds per alert
I = average current while the sound plays, in mA
3600 = seconds per hourUnits: n is a count, t is in seconds, I is in milliamps, and Q_day is in milliamp-hours per day. Dividing by 3600 converts milliamp-seconds to milliamp-hours.
Worked check: hold n and I fixed. Q_day is proportional to t, so doubling the alert duration doubles the daily charge for the sound. Add Q_day to the rest of your power budget, then compare with the battery capacity you plan to ship.
| Variable | Meaning | Status | What to do |
|---|---|---|---|
| n | Sound alerts per day while separated | Your assumption | Depends on your choice of periodic or motion trigger and on how the tag is moved. Measure it on a prototype. |
| t | Duration of one alert, in seconds | Your assumption | Take the value your firmware plays. Check the draft text for any limit on duration. |
| I | Average current while the sound plays, in mA | Vendor did not publish it for your part | Vendor figures are not published for your enclosure and driver. Measure it on your board. |
For the speaker current I, the vendor figure for your part and enclosure is not something this page can supply. It is a value to measure on your own board. We supply no example numbers for n or I, because a made-up number would look like a fact.
What are the common design traps?
These follow from the quoted requirements. They are engineering reasoning. None describes an incident at any company.
- Choosing the speaker after the enclosure is frozen. The sound requirement is acoustic, and Phon is perceptual. The enclosure and port design affect what the user hears. A late speaker change can force a housing change.
- Treating rotation as one timer. The draft gives 15 minutes in one state and 24 hours in the other. Firmware that has one rotation timer, or that does not reset it cleanly on a state change, will not match both.
- A sealed design with no button and no NFC. The draft asks for identifier retrieval by NFC tap or by Bluetooth LE with a physical mechanism such as a button. A housing with neither route has no way to meet this line.
- Sizing the battery without the alert load. The sound runs in separated state, periodically or on motion. An alert load that is missing from the power budget shows up as shorter runtime in the field. The formula below turns the range into a number you can plan against.
- Shipping against a moving target. The accessory draft is version 01, dated 27 Oct 2026, with an expiry of 30 Apr 2027. Requirements can still change. Track the draft and keep a record of which version your design follows.
- Leaving firmware updates unauthenticated. The companion threat model draft says accessories must verify the integrity and origin of firmware. An update path that skips this check conflicts with that line.
What should you test on your own board?
We have not run any of these tests, and this page reports no results. The pass line for each is yours to set from your product requirements, and you should record the basis for it before you run the test.
| What to measure | How to instrument or capture | Raw data to record |
|---|---|---|
| Loudness of the sound in the real enclosure | Play the alert in the finished housing, sealed as shipped, with a calibrated sound level meter at a distance and angle you fix in advance. Repeat with the board alone to see the enclosure effect. | Meter model and calibration record, distance, angle, room description, raw level readings, speaker part number, drive settings, photo of the setup. |
| Perceptual loudness against the 60 Phon line | Phon is a perceptual unit, so ask an acoustics lab or follow the method in the draft and its references to convert your measurements. Read the draft text for the exact condition. | Frequency content of the alert, raw spectrum capture, conversion method and who ran it, version of the draft used. |
| Battery cost of the separated-state alert schedule | Put a current meter or power analyzer on the battery rail. Record idle, one alert and a full day of your chosen schedule, periodic or motion triggered. | Current traces with timestamps, n, t, battery capacity, temperature, firmware build. |
| Address rotation timing and state change | Capture advertising with a Bluetooth sniffer across both schedules, and force transitions between near-owner and separated state several times. | Sniffer logs with timestamps, observed address change times, state at each change, firmware build. |
| NFC read range or button-gated Bluetooth LE retrieval | Try the retrieval from a phone against the real housing. For the button route, confirm the opcode is refused until the physical control is used. | Phone models and OS versions, distances, enclosure material, logs of accepted and refused requests. |
| Behavior with real iOS and Android alerts | Test against the platform alerting you intend to support, using the platforms’ current developer documentation and review process. We have not run this for you. | Device and OS versions, what each platform showed and when, screenshots, firmware build. |
| Firmware integrity check | Try to boot an altered image and an image from the wrong signer on a prototype, and confirm both are refused. | Image hashes, signer identities, boot log lines, result of each attempt. |
What should you think through before you choose a design?
Take this list to your team and to any supplier who proposes a tracker design.
- Which version of the draft does our design follow, and who watches for changes before launch?
- Where will the speaker sit, what is the acoustic path to the outside, and who measures loudness in the finished housing?
- Is the alert periodic, motion triggered, or both, and what does each choice cost in battery?
- Do we use NFC, a button-gated Bluetooth LE route, or both, and what does it do to the enclosure?
- How does someone who does not own the tag find it after an alert?
- Does our firmware have separate schedules for the two rotation intervals, and a tested state change between them?
- Do we verify firmware integrity and origin at boot and at every update?
- Which parts of this list have we measured on a prototype, and which are still guesses?
- Do we make any compatibility or certification claim, and what evidence supports it?
Questions about unwanted-tracking rules
Is the DULT draft a final standard?
No. The accessory protocol is an active IETF Internet-Draft, version 01, dated 27 Oct 2026, with an expiry of 30 Apr 2027 and intended status Informational (source, as of October 31, 2026). Draft status means requirements can still change.
Who wrote the draft?
The draft is authored by Apple and Google staff. The two companies announced the joint specification in May 2023 and submitted it to the IETF (Apple newsroom, as of October 31, 2026).
Does following this page make a tracker compatible with iOS and Android alerts?
No claim of that kind is made here. This page summarizes what the draft asks for. Compatibility depends on the platforms and on testing your own product against them. Duobay has not run those tests for you.
Why does a tracker need a motion sensor?
The draft allows the separated-state sound to play periodically or when motion is detected. A motion trigger needs a sensor and a wake path. A periodic trigger does not. The choice moves cost between the bill of materials and the battery.
Can Duobay build this into my tracker?
We do tracker firmware, electronics and enclosure work, and we do not publish prices. A Gate 0 Feasibility study covers the architecture and a costed bill of materials. Tell us about your tracker.
If you are planning a tracker and want the requirements above worked into the architecture, tell us about your tracker. You can also read about our LTE and GNSS tracker development and how our firmware work hands source code to you. For a general next step, start here.
Sources
All pages accessed October 31, 2026. Drafts change, so re-read them before you decide. This is an engineering summary and is not legal advice.
- IETF, Detecting Unwanted Location Trackers Accessory Protocol, draft-ietf-dult-accessory-protocol-01: https://www.ietf.org/archive/id/draft-ietf-dult-accessory-protocol-01.txt (accessed 2026-10-31)
- IETF datatracker, draft-ietf-dult-threat-model: https://datatracker.ietf.org/doc/draft-ietf-dult-threat-model/ (accessed 2026-10-31)
- Apple Newsroom, Apple and Google partner on an industry specification to address unwanted tracking: https://www.apple.com/newsroom/2023/05/apple-google-partner-on-an-industry-specification-to-address-unwanted-tracking/ (accessed 2026-10-31)
Planning a tracker? Tell us what it needs to do. A Duobay engineer replies within 1 business day. Send a project brief →