Should a public tag be locked before deployment?
Usually yes, because anyone can rewrite an unlocked tag they can touch. The sequence matters more than the decision itself: write a stable redirect address, deploy, confirm it works in the field, and lock only then, once nothing is left to correct.
The threat is real and cheap
An unlocked tag on a wall can be rewritten in seconds by anyone with a phone and a free application. No skill, no equipment, no trace.
The parallel with printed codes is exact, and covering a printed code with a sticker is a widespread fraud on parking meters, restaurant tables and charging points. Rewriting a tag is easier still, because it leaves the object looking untouched.
For anything in a public place, this moves locking from an option to a default.
The sequence that works
Write a redirect address on a domain you control, rather than the final destination. The tag then holds something that never needs changing.
Deploy unlocked. Confirm in the field, on real phones, at the real location, with the real surface, that everything behaves.
Then lock, on a second pass. The extra visit is the price of not permanently freezing a mistake, and it is a price worth paying on any deployment large enough to matter.
Never lock at the same moment as the first write
A write interrupted partway, locked immediately, is permanent nonsense. Locking should always be a separate operation performed after a successful read back.
When not to lock even in public
When the content genuinely has to change and no redirect is possible, such as a tag holding contact details for an offline location.
When the tag is in a controlled public space with staff present, where substitution would be noticed and the operational cost of frozen tags outweighs the risk.
And during a pilot, where the whole point is to change things. Lock at the end of the pilot, not the start.
What locking does not finish
The physical attacks remain. A locked tag can be covered, removed or replaced, and locking does nothing about any of them.
So a public deployment worth locking is usually also worth mounting properly: under a laminate, behind a fixed cover, or built into the object rather than stuck to it. That combination is what makes substitution difficult rather than merely inelegant.
And keep a record of which identifier is at which location. It is the only way to detect that a tag has been swapped, since a replacement holding identical content is otherwise invisible.
Frequently asked questions
Is locking enough for a public tag?
It closes the rewriting attack and leaves covering, removal and replacement open. Combine it with physical mounting and a record of deployed identifiers.
Can I lock tags remotely after deployment?
No. Locking requires physical proximity like any write, so it means a second visit. That constraint is worth planning into the deployment rather than discovering later.
What if I lock and then need to change the content?
You replace the tag. This is exactly why the content should be a redirect address you control, so the destination can change while the tag never needs to.
Should tags handed to individuals be locked?
Generally not. A card in someone's pocket is not exposed to strangers, and the owner will want to change it. The public exposure is what justifies locking.