NFC Giving Plate Security: A Church Overview

Security questions about giving plates usually arrive one of two ways. Either a board member asks what happens if someone tampers with them, or somebody on the tech team scans a plate with a free NFC app, sees the word writable, and sends a worried email to the whole staff.

Both are the right instinct. This page answers both, and it does it without asking you to take our word for anything: the last word on every claim below is a test you can run yourself, on any plate, from any supplier.

Security at a glance

What is actually stored on the plate?

One web address, and nothing else. An NFC giving plate holds a URL, usually your church’s giving page. There is no card number, no bank detail, no donor record, and no battery. The chip is inert until a phone powers it from a couple of centimeters away, and the only thing it can do is recite that address.

That single fact settles most of the security conversation before it starts. A plate cannot leak a donor list it does not have, and it cannot be skimmed for card numbers it never sees.

So locking a plate is not protecting private data. There is no private data. Locking protects the destination, which is the part worth protecting. Locked means the chip’s memory has been switched to read-only, so the address stored on it cannot be overwritten. Anyone can still tap the plate and open the link. Nobody can change where it points.

Why a scanner app may call a locked plate writable

Because the lock and the label live in two different places on the chip, and setting one does not automatically set the other.

Most church plates use an NXP NTAG21x chip. On those chips, page 02h holds the static lock bits, the actual mechanism that makes memory read-only. Page 03h holds something separate called the capability container, a small set of bytes that describes the tag to whatever is reading it. In the default state its access byte reads 00h, meaning read and write. An encoder can also write 0Fh there to advertise read-only. (NXP’s NTAG213/215/216 data sheet documents both, in sections 8.5.2 and 8.5.4.)

Here is the gap. Those are two separate write operations. A production encoder can set the lock bits, genuinely making the tag read-only, without also flipping the capability container to advertise it. Every subsequent write attempt fails, exactly as intended, but a reader app that only checks the descriptive byte still displays writable.

“Not password protected” is a different reading with the same shape. A password is one way to restrict writes on these chips. Permanently locking the memory is another, and a stronger one, because there is no password to guess or leak. A plate can be completely read-only and still report no password, because it never needed one.

How to verify a plate yourself in 60 seconds

Stop reading the status and try to change the plate. This works on any NFC plate from any vendor, and it is the check we would want a church to run on ours.

1. Install the free NFC Tools app (iOS or Android). Use a spare plate if you have one, or a mounted plate you can reach.
2. Open the Read tab and tap the plate. Note the URL it reports. Confirm it is your real giving address, character for character.
3. Switch to the Write tab, add a URL record, and type something harmless and obviously different, for example https://example.com.
4. Press Write and hold the phone to the plate.
5. Read the plate again.

On a locked plate the write fails, usually with a message about the tag being read-only or not writable, and step 5 still returns your giving URL. That is your answer, and it outranks anything the status screen said.

If the write succeeds, the plate genuinely is not locked. That is worth knowing on day one rather than in a year, and it is fixable: write your correct URL back, then set a password or ask your supplier about locked replacements.

The one realistic risk, and how to handle it

The realistic risk is physical, not digital. Nobody rewrites a tag by walking past it. Writing takes an app, a deliberate command, and a phone held against the plate for a moment. On a locked plate it fails even then.

The thing that could genuinely happen is substitution. Someone peels a plate off a pew or chair and sticks their own sticker over it, pointing at a page that looks like yours. No chip was hacked. The furniture was.

A printed QR code carries the identical risk, and churches have run those for years without incident. The defense is equally ordinary: mount plates so they do not come off easily, and glance at them during the walk-through you already do. Once a quarter, tap a few yourself and confirm they open your real giving page. That habit catches substitution, a supplier error, and a giving page that quietly moved, which in practice is the failure we see most.

Worth saying plainly, because it is the fear underneath the question: even on a completely unlocked plate, reading it reveals nothing but a public web address you print in your bulletin. There is no donor list on the chip and no payment to intercept. The money never touches the plate. It moves on your giving platform’s own secure page, the same one your members already use, which is covered in more depth in our full write-up on tap-to-give safety.

Locking is permanent, so pick the URL first

This is the part most security pages leave out, and it is the one that costs churches money. On NTAG21x chips the static lock bits are one-way. NXP’s data sheet puts it in a single sentence: if a bit is set to logic 1, it cannot be changed back to logic 0.

Read that as a purchasing instruction. A locked plate is a permanent decision about a web address, made once, by whoever encodes it. If your giving page moves next spring, and you encoded that page directly, your options are new hardware or a redirect you scramble to set up.

So encode a redirect you control, not the giving page itself. Lock the plate to an address that is yours to re-point, then aim that address wherever your giving lives today. You get the read-only chip and a destination you can change in thirty seconds, which is the combination you actually want.

You can do this without buying anything. If your church already has a domain, most website hosts and registrars will let you create a path like give.yourchurch.org/sunday and redirect it. Encode that, lock it, and you are set. We will happily encode a URL you own rather than one of ours.

If nobody on staff wants to own that, we run a redirect dashboard at go.tap.giving that does the same job with a login and tap analytics. It is included free on orders of 400 plates or more, and $50 a year below that. Either route solves the same problem, and the one that matters is that some layer sits between a permanently locked chip and a giving page that might move.

How Tap.Giving plates ship

Locked is our default, and it is what almost every church chooses. We encode the URL you give us, set the chip memory read-only, and ship. No password to manage, and nothing for a visitor with an NFC phone to overwrite.

If you do choose unlocked, password protect the plates the week they arrive. In NFC Tools it is Other, then Set Password, then touch each plate. The step-by-step version, plus the rest of the locked and unlocked detail, sits on our NFC questions page.

Every plate also carries a printed QR code as a fallback, which is worth knowing for this conversation: it points at the same address, and it is not rewritable at all.

What to tell your board

Borrow these if it helps. They are all checkable, which is the point.

• The plates hold a web address and nothing else, so there is no donor or card data on them to steal.
• They ship read-only, and we confirmed it by trying to overwrite one and watching it fail.
• Payments happen on our existing giving platform, exactly as they do today, and the plate never touches money.
• The realistic risk is somebody physically swapping a plate, so we check them on the quarterly walk-through.

That is a shorter and more honest security posture than most church software carries, and it holds up because there is so little on the chip to argue about.

FAQ