Most RFID implementation problems that surface after go-live aren’t hardware problems. The tags are reading, the readers are positioned correctly, the system is technically functional. The problems are in the RFID data architecture: records that can’t be reconciled, asset histories that are incomplete, information that exists in the RFID system but isn’t accessible to the people who need it.
Data architecture decisions made at the scoping stage are harder to unpick than hardware decisions. You can swap a tag. Restructuring how an entire system stores, accesses, and integrates data is a different order of problem.
What to store on the tag, and what to store in the database
The most common misconception about RFID tags is that they function like a mobile database, carrying the full record of the asset they’re attached to. In practice, good RFID data architecture doesn’t work that way.
Most passive UHF tags carry a small amount of writable memory, typically enough for a unique identifier and a limited amount of static data. That identifier is the link between the physical asset and its record in a central database. Every time the tag is read, the system looks up that ID and retrieves or updates the corresponding record. The tag is the key; the database is where the information lives.
Storing dynamic data on the tag itself creates problems that aren’t immediately obvious at the scoping stage. Data held on a tag can only be accessed by someone with a reader in range of that tag. It can’t be backed up. If the tag is damaged or replaced, that data is gone. And if multiple systems or users are writing to the same tag, there’s a very real risk of data conflicts or corruption.
As a rule, only use the tag to store the unique ID. You could add static data that genuinely needs to travel with the asset. Everything else belongs in the database.
There are exceptions. Some applications require data to be readable without access to a central system, for example assets deployed in remote locations or crossing international borders where system connectivity can’t be guaranteed. In those cases, a limited amount of additional static data on the tag can be justified. But these are design decisions that should be made deliberately, not defaults that get adopted because the tag has memory available.
One procedural point worth building into your deployment plan: assign the tag ID to the asset record in your system before the tag is permanently fixed to the asset. It sounds straightforward, but double-tagging an asset or linking the wrong tag ID to the wrong record are data integrity problems that are surprisingly easy to create and genuinely difficult to unpick after the fact.
EPC memory structure
Understanding Understanding RFID data architecture starts with how memory is organised on a passive UHF tag. It helps clarify why the on-tag vs database distinction matters.
EPC Gen2 tags (the RAIN RFID standard) organise memory into four banks. The EPC bank holds the Electronic Product Code, the unique identifier that most systems use as the primary key to look up the asset record. The TID bank contains a manufacturer-assigned identifier that is permanently locked at production and cannot be overwritten, making it useful as a tamper-evident reference. The User bank is the writable area where additional data can be stored if needed. The Reserved bank holds access and kill passwords.
In most commercial applications, the EPC bank is all that gets used. The EPC itself is configurable in length, typically 96 bits, which is enough to encode a unique identifier for billions of individual assets. Some applications extend this, but 96 bits is sufficient for the vast majority of use cases.
The TID bank is underused but worth knowing about. Because it’s set by the manufacturer and can’t be altered, it provides a reliable way to detect whether a tag has been swapped or substituted, which matters in any application where asset identity integrity is important.
User memory varies considerably between tag models, from a few bytes to several kilobytes on extended-memory variants. Having memory available doesn’t mean it should be used, but knowing what your chosen tag supports is useful when the exceptions discussed above apply.
Data security
RFID tags are not inherently secure. A standard passive UHF tag will respond to any reader operating at the right frequency, which means an unauthorised reader could in principle interrogate your tags if it gets close enough. For most commercial asset tracking applications, this is a low risk scenario. But it’s worth understanding before assuming it doesn’t apply to you.
The main security controls available at the tag level are access passwords and the kill command. An access password can be set to restrict read or write access to the tag’s memory banks, preventing unauthorised systems from reading or overwriting data. The kill command permanently disables a tag, which is useful in some applications but irreversible. Both are features of the EPC Gen2 standard and are supported by most RAIN RFID tags.
For most applications, the more significant security consideration is the database rather than the tag. Controlling who can access, modify, or export the asset records held in the central system is where most of the security architecture should be focused. Standard database security practices apply: access controls, audit trails, validated integrations, and regular backups.
If your application involves sensitive data, high-value assets where substitution fraud is a risk, or regulatory requirements around data integrity, these are conversations to have at the system design stage, not after deployment.
Digital Product Passports: a coming requirement worth planning for now
Digital Product Passports (DPPs) are an emerging regulatory requirement that will affect manufacturers and product supply chains across a range of sectors. The core principle is that physical products should carry, or be linked to, a digital record containing information about their materials, components, repairability, and end-of-life handling. The aim is to support circular economy objectives by making product lifecycle data accessible to regulators, businesses, and consumers throughout the supply chain.
RFID, and RAIN RFID in particular, is one of the primary carrier technologies being considered for DPP implementation. The ability to link a physical product to a digital record via a unique tag ID maps directly onto the DPP model.
If you are scoping an RFID system now for an application that involves manufactured products moving through a supply chain, it is worth asking whether DPP requirements are likely to apply to your sector and within what timeframe. Building a system architecture that can accommodate DPP data requirements from the outset is considerably easier than retrofitting it later. The tag ID and database structure decisions covered earlier in this post are directly relevant: a system designed around a robust unique identifier linked to a central record is already aligned with the DPP model.
The regulatory detail is still being finalised across sectors and geographies, but the direction of travel is clear. If DPPs are on your horizon, factor them into your scoping conversations now.
System integration
An RFID system that doesn’t connect to your existing business systems is only doing part of the job. The value of knowing where an asset is, when it was last inspected, or that a shipment has passed a checkpoint is multiplied when that information flows automatically into the systems your business already runs on, whether that’s an ERP, a WMS, a maintenance platform, or a compliance management system.
Integration is a scoping conversation, not an afterthought. The data structure decisions covered in this post, particularly how assets are identified and how records are organised in the central database, directly affect how cleanly the RFID system can talk to other platforms. A unique asset ID that maps neatly onto an existing ERP record is a straightforward integration. A system where asset identity has been encoded inconsistently is a much harder problem to fix.
We’ve covered RFID system integration in detail separately. Read our guide to RFID system integration.
Getting RFID data architecture right
The hardware decisions in an RFID system are visible and testable. You can trial a tag, reposition a reader, adjust antenna orientation. Data architecture decisions are less tangible but their consequences are harder to fix.
Getting the RFID data architecture fundamentals right at the scoping stage – what the tag stores, how the database is structured, how security is handled, and how the system connects to the rest of your business – sets the foundation for a system that does what it’s supposed to do and can grow with your requirements.
If you’re scoping an RFID system and want to talk through the data architecture, we’re happy to help. Get in touch.