4 What the security protects, and what it leaves open on purpose

4.1 Why a tag cannot be protected the way a phone is

A phone has a battery, a chip built to hold secrets, and time. An Ambient IoT device has a scrap of harvested charge and whatever it can finish before that charge runs out.

That shows up as a bill nobody can pay. Two candidate solutions from the study were marked down because working out a hidden identifier makes every device in earshot do the sum, including the ones nobody was looking for (clauses 6.9.3 and 6.30.3 of TR 33.713 TR 33.713).

The specification kept the mechanism and turned the objection into an assumption. Where identifiers are hidden, every device that hears the page works one out and compares, and is assumed to have the energy for it (clause 5.4.3 of TS 33.369 TS 33.369).

Energy even has its own answer on the wire. A device may refuse a command outright, giving as its reason that the energy would run out before it could finish (clause 5.3.2.5 of TS 24.369 TS 24.369).

Neither security document puts a number on any of this. The study declines to give one, because it depends on the hardware (clause 6.35.2 of TR 33.713).

4.2 What must be supported, and what must be used

These are two different questions and TS 33.369 answers them separately. A device has to be able to do a thing; whether a deployment switches it on is another matter entirely.

Integrity is the one thing always standing between a shelf of tags and a command that cannot be taken back. A permanently disabled device never again answers an inventory — the sweep in which the network finds out which tags are there §5.2.2.3.

4.3 Who proves what to whom

Device authentication is always performed for an inventory, the exchange How a tag is actually read, from the request to the answer follows step by step (clause 5.2.1 of TS 33.369). There is no unauthenticated inventory.

The other direction barely exists. No message's job is to prove the network: the device takes the network as authenticated if the integrity check on a command passes (clause 5.2.2 of TS 33.369). An inventory on its own carries no such check, so the tag answers and learns nothing about the asker.

4.4 Nothing counts the messages

The message counter fed into the protection algorithms is all zeros, and so is the bearer field (clause 5.3.3 of TS 33.369).

The reasoning is written down: one command round per device per inventory, and a session key that is fresh each time, so no further freshness parameter is needed (clause 5.3.2 of TS 33.369).

That is a design held up by a rule about how the system is used, not by a mechanism. A second command round under the same session key would replay cleanly, and nothing in the specification stops one.

4.5 The privacy hole worth knowing about

With temporary identifiers switched off, the device puts its permanent identifier into the exchange (clause 5.4.1 of TS 33.369). The architecture gives a tag both kinds of name, a permanent one §5.7.2 and a temporary one §5.7.4.

How a device comes by the permanent one is out of scope §5.7.2.

Switching privacy on is not the end of it either. Identifier privacy is only realised if the command request is encrypted (clause 5.4.3 of TS 33.369) — and encryption is optional.

So an operator can turn privacy on, update identifiers by command, leave encryption off, and hand every new identifier to anyone listening.

4.6 Where to read on

Two things are still being decided. Whether the phone-as-reader work starts at all waits on a checkpoint at the SA plenary in September 2026, recorded in a note in clause 8.2.4 of TR 23.700-30 TR 23.700-30.

And the security specification carries one open note of its own, on updating a temporary identifier: clause 5.4.4 of TS 33.369 says that operation is still to be updated.

The same clause describes what a device does when it and the network have lost track of each other, and says nothing about what happens when that recovery fails too.