Writing fails with a protection error
Three different refusals wear similar wording. Locked is permanent. Password protected is recoverable if you hold the key. Unformatted is not a protection failure at all, and reading the tag rather than the message tells you which one you have.
Three refusals, three verdicts
Locked. Lock bits have been set, which is a permanent hardware change. Nothing reverses it.
Password protected. The chip requires a key before it accepts a write. Recoverable if you have the key, and a dead end if you do not.
Not formatted. The tag has no NDEF structure yet, so a tool expecting one may refuse. This is not protection and it is fixed by formatting.
Error wording varies between applications and does not map cleanly onto these three. Two tools can describe the same tag differently, which is why the message is a poor diagnostic.
Read the tag, not the message
Read the tag with a tool that shows technical data. It reports the writability state directly, and that report is the same whichever application produced the error.
If it says read only, you have lock bits. If it says protected or asks for a key, you have a password. If it reports no NDEF structure, you have an unformatted tag.
If it reports a technology but no NFC Forum tag type, you have a chip phones do not read as a tag, which is a different problem entirely and not a protection one.
One read replaces guessing at error text, and it takes seconds.
If it is locked
Stop trying. Locking is permanent and repeated attempts change nothing.
Check whether the content already on it is correct. A locked tag holding the right content is not a loss, it is a tag you cannot change, and for a stable redirect address that may be perfectly acceptable.
If the content is wrong, the tag is finished. Set it aside rather than returning it to stock, where someone will pick it up again.
And check the rest of the batch before writing more, because if one arrived locked others may have.
If it is password protected
Try the key if you set one, or if a batch was configured by someone in your team.
Check whether protection was actually switched on with a known default rather than a chosen key. Setting a key and enabling protection are two separate steps, and a tag protected with an unchanged default is recoverable.
If nobody has the key, the tag reads normally and cannot be rewritten. What remains possible depends on whether your system can work from a tag it can read but not change.
Do not spend long on it. A tag costs cents and the labour of chasing a key across a team costs more than replacing the tag.
Frequently asked questions
Why do two apps report different errors?
Because error wording is chosen by each application rather than defined by the standard. Read the tag's reported state instead of interpreting the text.
Can I force a write past protection?
No. Both lock bits and password protection are enforced by the chip, so no application can override them.
Is an unformatted tag broken?
No. It simply has no NDEF structure yet, and formatting prepares it. This is the one refusal in this group that is a normal step rather than a fault.
Does a failed write damage the tag?
No. A refused write leaves the tag exactly as it was, which is why the previous content is still readable afterwards.