An asset tag may need to remain readable during every inventory while its identifier must not be changed by an ordinary workflow. “Password-protected” is too vague to buy against: the project has to name the memory area, the permitted read and write actions, the authorized maintenance path and whether a decision is reversible. A password value alone does not encrypt the tag, hide every EPC or prove that a copied identifier cannot appear elsewhere.
This guide concerns access policy after the tag's identity and memory purpose have been chosen. Tag commissioning covers allocation, encoding and binding; EPC, TID and User memory covers which value a business task uses. NFC tag locking is a different chip family and workflow, addressed in the NFC issuing guide.
Separate the controls before selecting a lock state
The GS1 EPC UHF Gen2 standard, Release 3.0.1 distinguishes Access, Lock, permanent lock status and Kill. An Access password participates in moving a suitable tag into its secured state for protected operations. The Lock action controls permitted writes or password access for defined memory locations; its mask selects which settings are changed. A permanent setting removes a later ability to reverse that specific lock decision. Kill is a separate command intended to permanently disable a tag, not an inventory protection setting.
The Lock action table is especially important when reading a supplier's “permalock” claim. A memory location may be permanently writable, meaning the write permission cannot later be locked, or permanently unwritable. Both are permanent states; they have opposite outcomes. Reversible settings may instead allow a later authorized change in the secured state. The standard also distinguishes Lock from BlockPermalock for certain User-memory blocks. Do not infer a complete tag feature set from those protocol definitions: the exact chip may omit a memory area or supported action, and the reader/SDK may not expose the required command.
Password custody is its own design question. Define who sets the Access password, whether and how the password memory is protected, how authorized tools obtain credentials, and what the application logs without exposing secrets. The project should not claim “encrypted inventory” merely because a password is configured. A normal EPC read, write authorization, chip authentication and business acceptance are separate results.
Work through an asset tag that must still be inventoried
Consider an editorial maintenance fleet with asset PUMP-204. Its approved EPC is read during routine inventory. The normal operator application must not change the EPC; a named maintenance workflow may need to replace a damaged tag or correct an encoding error. The asset database remains authoritative for ownership, service status and the tag-to-asset relationship. This is an illustrative policy, not a tested AIDC GO deployment or an instruction to alter a live tag.
First decide whether maintenance is allowed to rewrite the same physical tag. If yes, a reversible write restriction may be appropriate only if the selected tag, reader and software can demonstrate the required authorized state transition and readback. If policy instead forbids future EPC changes on that tag, an approved irreversible write restriction may be appropriate—but only after the correct value has been independently read and the replacement policy is clear. If the workflow must permanently allow writes, the standard describes that as a distinct permanent choice; do not call it “permanently read-only.” In every case, test that routine inventory still returns the intended EPC and the application still maps it to PUMP-204.
Use controlled samples representing a normal operator, an authorized maintenance operator, a wrong credential and an already-locked tag. Record the starting tag part and state, target memory location, requested action, reader and SDK version, command result, later attempted read or write and application mapping response. A success reply to a Lock command supports that the operation was accepted in that session; it is not by itself proof of the later read/write policy, and neither result proves the tag belongs to the correct asset. Do not run irreversible settings on production tags merely to learn how a menu behaves.
Decide what a failed operation actually means
Suppose routine inventory reads the EPC but an ordinary write is rejected. That observation is compatible with the desired policy, but it does not identify the exact lock state without a documented status or controlled verification. A maintenance write that fails could reflect an incorrect password, unsupported operation, wrong target tag, address or chip behavior. Preserve the error and initial state instead of repeatedly sending writes. A tag that no longer responds after a destructive operation must not be relabeled as “secure” without investigating the specific cause.
If the tag is permanently protected and the encoded value is wrong, use an approved replacement path that preserves the old and new tag relationship. If a maintenance tool can update it, repeat an independent readback and compare the asset mapping before release. The damaged-tag replacement guide handles that business relationship; access control alone cannot repair a wrong mapping.
Bring the exact configuration to the acceptance test
The acceptance record should name the finished tag and chip, deployment region, bank and address range, intended inventory value, password state, proposed reversible or permanent action, reader model, firmware and SDK, credential custodian, application roles and replacement rule. Test on sacrificial tags and the actual software path. Preserve ordinary reads, authorized and unauthorized write outcomes, and a later re-read of the same physical tag. Secrets belong in controlled credential handling, not screenshots or ordinary test logs.
Explore the RFID mobile-computer category or RFID sled category for the physical form factor, then use Integration Support to obtain exact read/write/lock documentation for the proposed configuration. A UHF inventory claim on a category page does not prove Access, Lock, BlockPermalock, Kill or a particular tag's security behavior. Discuss the specific policy and sample evidence when you contact AIDC GO.