XSIID password enabled

How do I enable the password protection for XSIID Ntag i2c?
I’m using NFC Tool Pro but it won’t work I have another NXP Ntag 213 and it can be password protected etc.

why on earth would you want to do that?

1 Like

If you password protect the tag it can still be read by anyone, it just can’t be written to without the password. If you then forget the password you’re stuck with a read only implant.


Another angle:

If you don’t password protect the tag, it can be password protected by anyone and you can not write to it anymore.

1 Like

You can lock it open. Then it can’t be locked by others but can freely be used like it’s unlocked.

I keep my XSIID write locked, I don’t think it’s necessary, but I like having it locked anyways

I haven’t forgotten the password yet, but most of my passwords look like more confusing versions of my username, so maybe I’ve just gotten used to memorizing passwords

Not to mention, doesn’t really matter to me why you want to do it, here’s how to do it should you choose to do so:

I also highly recommend you check out the datasheet: https://www.nxp.com/docs/en/data-sheet/NT3H2111_2211.pdf
Try to understand it and double check my commands if you like. While I’m 90% sure these should work, it’s a pretty good idea to get in the habit of double checking commands you send to something inside your body

You’ll need an app such as NFC Shell, or some other method to send raw hex commands (Which you should always be very cautious of, here there be monsters)

The first thing you’ll do is come up with a hex password you want, any 8 digit hexadecimal code should work.
Then you can write this password to your chip, being very very careful to do so correctly, though at this point you can reset the password if you set it wrong:
The command you’ll use to set the password is:

Once you’re sure you’ve done that correctly, I would recommend disabling the incorrect password attempt limiter, otherwise you may risk bricking your chip if you forget your password. At the same time, you’ll set whether you want to password protect both read and write, or just writing. I recommend only protecting writing to cut down on annoyance. This should be the default value anyways, but just to be safe you can set this with this command:

Now you’re pretty much done, you just need to decide what portion of the chip you want password protected. I lock the whole chip, and unlock it when I want to write to it, so that’s what I’m outlining here:
Initial lock command:
A2E300000000 (Locks entire chip from the very beginning)

To unlock, you’ll have to issue:
1B[Your Password]
A2E3000000E2 (Unlocks everything up to the password config sectors, unlocking past this could mean that anyone could change your password.)

To re-lock issue:
1B[Your Password]


giphy (13)


Make it longer and chuck some numbers in the mix and now you’re getting somewhere

The culmination of an attempt to find out “What’s the longest password I could remember”

Well, somewhere around the halfway point of committing a 300 digit numerical password to memory, I discovered the sweet spot is 30-45 characters and alphanumeric




I can’t remember names of the people I meet, important dates, or much of anything, but if you need a arbitrary string of digits remembered for the rest of my days, I’m your guy


Actually, you can change the PROT bit to require password to read too. The PROT bit set to 0 means password auth is required to write, but PROT set to 1 means you need password auth to read any of the designated protected memory pages as well.

This only applies to lock bits, which are already “locked open”, but if someone were to change the AUTH byte and password value then you could effectively be “locked out” of your chip and need to commit to some serious brute forcing… assuming the attacker didn’t also enable the failed password counter self-destruct feature as well.


If you set a password but then set auth0 to start the locking at the password config bits, that should prevent someone from changing your password, while still leaving the actual data portion open for use

Essentially “locking it open”

1 Like

yes indeed… just being careful to be clear :slight_smile: