What an NFC Tag Can and Cannot Protect
NFC tags are passive devices: they hold a small amount of data and have no onboard power, processing capacity, or encryption engine. When a reader powers the tag, it returns whatever is stored on its memory chip. That fundamental simplicity is what makes NFC tags cheap, reliable and easy to deploy, but it also defines the boundaries of their security.
Security for an NFC tag is not a product feature you switch on. It is a set of constraints you work within, and every deployment decision either respects those constraints or creates a risk. The practical question is not whether a tag is secure in an absolute sense, but whether the specific risk in your environment is acceptable for the data you are putting on the tag.
What the tag actually exposes
When someone taps an NFC tag with a phone or a dedicated reader, they receive the tag's identifier and its stored payload, typically a URL. The tag does not authenticate the reader. It does not check who is asking, log the interaction, or decide whether to respond. If the tag is within range and powered by the reader's radio field, it answers.
This means the data on the tag is effectively public. Anyone physically close enough to tap it can read it. For a museum exhibit label that links to a public web page, that openness is the point. For a staff-only access URL or an internal identifier, it is a problem.
Tag types and their security-relevant differences
Not all NFC tags are identical, and the chip family does matter for security planning. The common NTAG series (NTAG213, NTAG215, NTAG216) offers different memory sizes but shares the same basic access model: read access is unrestricted by default, and write access can be restricted or locked. MIFARE variants add proprietary authentication commands and sector-based access controls, but they require a reader that speaks the MIFARE protocol and introduce integration complexity that most proximity marketing and wayfinding deployments do not need.
For most UK retail, museum and event use cases, the security question comes down to what is written on the tag, who can change it, and what happens if someone does.
Security by Use Case
Retail product and shelf labels
In a retail environment, NFC tags on shelves or products typically point to a product page, a promotional landing page or a stock-checking endpoint. The primary security concern here is not confidentiality, since the URL is meant to be public, but integrity. If someone overwrites the tag with a different URL, customers who tap it land on an unintended page. Whether that is a nuisance or a liability depends on what the replacement URL serves.
The practical mitigation is to use a dynamic QR or short URL that is controlled server-side. Even if the tag's stored URL is changed, the original short link can be revoked or redirected. The tag becomes a pointer to a managed resource rather than a fixed destination.
Museum and exhibit information
Museums face a slightly different profile. Exhibit tags usually link to audio guides, image galleries or catalogue entries. The content is public, so read access is not a concern. The risk is vandalism: someone rewriting tags to point to unrelated websites. Because museum environments involve many tags spread across large floor areas, physical tampering can be difficult to spot without regular checks.
Using dynamic URLs gives the museum a central point of control. If a tag is overwritten, the original link can be disabled and a replacement tag programmed. The operational question is how quickly staff can detect and respond, which depends on inspection routines rather than tag technology.
Event badges and access control
Event organisers sometimes use NFC badges for access control or lead retrieval. In these cases, the tag may carry an identifier that ties back to a registration record. The security consideration shifts from public-facing content to identifier exposure. If the identifier is a simple sequential number or a readable name, anyone with a reader can harvest badge data in a crowded room.
Best practice is to ensure the on-tag identifier is meaningless without the backend system that maps it to a registrant. A random UUID stored on the tag reveals nothing useful on its own. The security then depends on the backend access controls, not the tag itself.
Staff and operational tags
When NFC tags are used for internal purposes, such as triggering maintenance modes on equipment or linking to staff-only resources, the risk profile changes. A tag on a stockroom door that points to an internal inventory URL exposes that URL to anyone who taps it. In these scenarios, the tag should either carry no sensitive path directly, or the linked resource should require separate authentication after the tap.
Deployment Checks and Common Mistakes
Assuming the tag controls access
The most persistent mistake is treating the NFC tag as an access control mechanism. A tag cannot enforce who reads it or what they do with the data. If a resource needs to be restricted, the restriction belongs on the server side, enforced by authentication, not on the tag.
Storing sensitive paths or credentials on the tag
Writing direct URLs with query parameters that include session tokens, user identifiers or internal system paths onto a tag is a straightforward error that still appears in deployments. Anyone who reads the tag sees the full URL, including any appended parameters. If the URL contains anything that should not be public, it should not be on the tag.
Ignoring physical tampering
Tags can be peeled off and replaced, or overwritten in situ with a consumer phone and a free tagging app. For high-trust environments, such as payment terminals or official certification marks, NFC tags alone are not sufficient. Additional measures such as tamper-evident labels, visual inspection routines or secondary verification are necessary.
Overlooking cloneability
An NFC tag's content can be copied to a blank tag in seconds with standard equipment. If the system relies on the tag's presence as proof of legitimacy, a cloned tag defeats that assumption. This matters for anti-counterfeiting applications, where NFC is sometimes suggested as a verification tool. A basic NTAG tag provides no clone resistance. Specialised tags with unique, unclonable identifiers exist, but they are a different product category with different costs and reader requirements.
Key checks before deployment
- Is the on-tag data safe to be public? If someone reads the tag with no context, what do they learn? If the answer is anything sensitive, restructure the URL or move the sensitive element server-side.
- Does the linked resource enforce its own access control? The tag should never be the only barrier between a visitor and restricted content.
- Can the tag be overwritten? By default, most common tags are writable. Whether you leave them writable or restrict write access is a separate decision covered in the next article, but you should make that decision deliberately, not by default.
- What happens if the tag is cloned or replaced? If the system breaks or makes incorrect decisions when a cloned tag is presented, the architecture needs to account for that before going live.
- Is there a routine for checking tag integrity? For deployments with many tags in public spaces, define who checks them, how often and what they are looking for. A tag that has been overwritten may look identical to a legitimate one.
NFC tag security is not about making the tag itself secure. It is about understanding what the tag can and cannot protect, then designing the rest of the system accordingly. The tag delivers a string of data to anyone who asks. Everything beyond that, including access control, integrity verification and audit logging, happens elsewhere.
Operational security is broader than the tag
Security depends on the complete route from physical tag to device, URL or app, backend and content owner. Locking a tag can prevent casual rewriting but cannot prevent someone covering it with another tag or sign. Add physical inspection, destination-domain control, redirect monitoring, change ownership and a rapid withdrawal process.
