Yeah that all makes sense if nxp lie in the data sheet. 
When a manufacturer says something in the datasheet its kinda got to be trusted until proven otherwise. I understood everything and was happy with it but the rfui byte being 05 even according to nxp is wrong 
I wonder if they use it during testing and cbf to change it back.
Struggled for a bit but canāt get taginfo to export data so hereās a new screenshot since resetting the default password. Let me know if there is anything else you want a screenshot of
Okā¦ I did some testing with some bullseye ntag216sā¦
ā¢ The first scan authenticates with DNGR (this was an older bullseye tag that was set up as a NExT using the password DNGR), writes a new password to the default value FF FF FF FF, then writes page E3 to FF 00 00 FF. This all works as expected.
ā¢ The second scan changes the value of E3 to 00 00 00 FF to prove that the CFG byte being set to FF has no effect on page E3. This works as expected.
ā¢ The third scan changes the value of E4 to E4 05 00 00. I leave the RFU byte 1 set to 05 because well, itās just set this way to begin with and I donāt want to change it. This works.
ā¢ The final scan attempts to change E4 back to 00 05 00 00. This fails.
Setting byte 0 of page E4 to 1110 0100 (E4 in hex) results in the entire configuration section locking downā¦ but why? Letās take a look again at the memory breakdown for the ACCESS byte (byte 0 of page E4);
Notice how bit 0 is on the right side of the bit list, not the left side?
Since E4 = 1110 0100 in binary, and when reading binary the LSB (least significant bit) is on the right side, it means when reading the binary in the ātraditionalā left to right way, the first 3 bits starting on the left are actually bits 7, 6, and 5 listed on the memory map, or in other words, PROT, CFGLCK, and RFUI, which are all value 1. Your CFGLCK bit is flipped to 1, and your configuration pages are locked.
Basically, NXP is trying to help people out by reversing the bit numbering order in their documentation in order to allow you to simply read the binary left to right as normal, rather than having to reverse it in your head.
Gotchya, makes sense. Thanks for all the help and investigating the root cause. I suppose I must have fat fingered something when initially writing the hex. Lucky I locked it in read/write mode rather then read only - good lesson to be more careful I suppose.
Cheers!
indeedā¦ we disable the lock bits so it is impossible to lock your memory bytes fully in that way, however you were lucky that in page E3 your AUTH0 byte is FF which means the password itself is meaninglessā¦ but yes, itās fully read/writeable 
