How do you set a password on a tag, and what does it protect?
Setting a password takes two steps: writing the key into the chip, and configuring which memory it protects and from which operation. The second step is the one people miss, and a password configured to protect nothing is the most common outcome of doing this in a hurry.
Two steps, not one
The first step writes the key into a configuration page. This is the part tools present prominently and the part people think of as setting a password.
The second step configures what the key actually guards: from which page of memory protection applies, and whether it covers writing only or reading as well.
Both are required. A key written without a scope is a key protecting an empty range, which means the tag remains fully writable by anyone while appearing to be protected.
What the scope setting controls
Two things, and their names differ by chip family so the datasheet is the authority.
The starting page, which is where protection begins. Everything from that page to the end of memory is covered, and everything before it is not. Setting it too high leaves your content unprotected, and setting it to zero protects the whole tag including areas readers may need.
The access condition, which chooses whether the password is required for writing only, the usual choice, or for reading as well.
Verifying it works
Do not trust the tool's confirmation. Test the protection with a second device that does not hold the key.
Try to write to the tag from a phone with no password configured. If the write succeeds, the scope is wrong and the password is decorative. If it fails, the protection is real.
This takes a minute and it is the only way to distinguish a working configuration from a plausible looking one. A password nobody has tested is not a password.
Managing keys across a batch
One key for a whole batch is simple and means one compromise affects everything. Individual keys are safer and require a record mapping tag to key, which is a database you must not lose.
For most deployments a single key per batch is the sane compromise, since the threat is a passer by rewriting a poster rather than a targeted attack.
Whichever you choose, store the key somewhere that outlives the person who set it. A password known only to someone who has left is functionally a locked tag, with the added indignity of having been avoidable.
Frequently asked questions
Does a password stop people reading the tag?
Only if you configure it to, and on chips that support read protection. The default on most is write protection alone, which is usually what you want since the content is meant to be read.
What happens if someone guesses the password?
They can rewrite the tag. Keys are short on typical consumer chips, and some families limit failed attempts, which is a setting worth enabling where it exists.
Can I remove a password later?
Yes, with the current key. That reversibility is the whole advantage of a password over locking.
Is the password stored on the tag in the clear?
It lives in a configuration page that is normally not readable, and the protection is a chip access rule rather than encryption. Treat it as a modest obstacle rather than a strong secret.