Direct answer: An EPC read identifies the value a tag reports; it does not prove that the physical tag is genuine. An Access password governs certain tag operations, but the GS1 Gen2 standard expressly does not treat an Access-command sequence as cryptographic authentication. If origin or genuine-tag evidence is required, specify a tag chip and cryptographic suite, a reader and application path that actually execute the authentication exchange, controlled keys and a defined business decision. Do not assume an inventory-capable handheld already supports that chain.
This is a purchase and acceptance question for an existing UHF identification project. The Access-password and locking guide concerns permitted reads and writes; the EPC-format guide concerns translating tag data into a business identifier. Neither is a genuine-tag proof.
Name the assertion before buying a secure tag
Ask what the project actually needs to decide. “Is this EPC in our asset database?” is a record lookup. “Was the identifier correctly issued to this asset?” is a commissioning and mapping check. “Can this chip demonstrate possession of a protected secret through an approved protocol?” is an authentication question. A successful answer to the last question still does not prove that the tag is physically attached to the right asset or that the asset itself is authentic.
The GS1 EPC UHF Gen2 standard, Release 3.0.1, distinguishes core Access from optional security commands and cryptographic suites. Its section 6.3.2.11.1 says an Access-password sequence is not cryptographically secure and does not authenticate either party. Section 6.3.2.11.2 describes Authenticate and other security commands, but a tag may support zero cryptographic suites. A standards reference alone therefore cannot establish that a particular chip, reader firmware or SDK exposes authentication.
As one bounded chip example, NXP describes UCODE DNA, part SL3S5002N0FUD, as supporting an AES-based authentication approach associated with Gen2 v2.0 Annex N and ISO/IEC 29167-10. That page describes the NXP chip, not an AIDC GO reader or a ready-made asset-verification service. Record the exact chip and label construction proposed; “UHF Gen2” alone is insufficient.
Keep the evidence layers separate
| Observed result | What it supports | What it cannot establish alone |
|---|---|---|
| EPC read | Supports: a reader obtained an identifier from a responding tag. | Does not establish: original chip, correct asset attachment or authorized issue. |
| Access success | Supports: an allowed state transition or operation under the selected tag policy. | Does not establish: cryptographic tag authenticity. |
| Authentication result | Supports: the defined protocol result for the specific chip, suite, key and reader path. | Does not establish: correct asset mapping or business acceptance. |
| Business acceptance | Supports: the application’s stated policy accepted this observation for a task. | Does not establish: that a missing or bypassed authentication check somehow occurred. |
Keep the raw EPC, chip or TID information if the approved design uses it, authentication request and result, reader identity, software version, task and final application decision as distinct fields. Do not put production keys or reusable secrets in ordinary logs. A display that only shows “scan successful” hides which layer was actually tested.
Work through a controlled asset-release example
Editorial example, not a customer deployment or device test: A depot has an asset record TOOL-042 mapped to EPC EPC-A. At release, a clerk reads EPC-A. The database finds the asset record, but this alone cannot distinguish an approved original tag from another tag programmed to report the same EPC. The purchase requirement says that the selected chip must also pass the project’s documented tag-authentication exchange before the release application may accept the item.
On a controlled reference sample, the application records the EPC, the selected authentication profile, a fresh challenge or equivalent protocol input as required by that profile, the SDK’s result and the business decision. If the EPC matches but authentication fails or is unavailable, the item moves to a defined inspection queue; the operator must not relabel “EPC found” as “genuine tag confirmed.” If authentication passes but the EPC maps to a different asset, the mapping discrepancy remains open. If the reader returns only EPC data, the project cannot silently infer that the authentication step ran.
What counts as a passing cryptographic result depends on the chosen chip, suite and system design. This article supplies no challenge bytes, keys or universal API sequence. Key provisioning, renewal, loss and authorized recovery need a documented owner. The commissioning guide covers issue and binding; an authentication result cannot repair a tag assigned to the wrong record.
Demand an end-to-end supplier demonstration
Request the finished inlay or tag part, chip identification and applicable revision, supported cryptographic suite, reader model, firmware and SDK/API version, supported region, key-provisioning responsibility, application error codes and policy for failed or offline checks. Verify whether the specific reader path performs the exchange locally, delegates it to an authorized service or exposes only raw data. “Supports Gen2” or “has a UHF module” is not an authentication implementation statement.
Use sacrificial approved samples with one correctly provisioned tag, an EPC-matching but non-authentic control where the security design permits such a sample, a wrong business mapping, and an unavailable authentication service or key. Observe the reader output and application decision separately. Define in advance whether an unavailable check blocks release, queues review or follows another approved policy; do not make a failed check silently pass. Record test configuration and results without publishing secrets or claiming a universal detection rate.
For hardware evaluation, the RFID mobile-computer range and RFID sled range show possible form factors, not verified authentication support. Provide the exact chip, software and acceptance requirement through Integration Support, then contact AIDC GO for model-specific documents and a scoped trial. No AIDC GO model, cryptographic suite, key service or compatibility is asserted here.
Sources and scope
GS1 EPC UHF Gen2, Release 3.0.1, ratified February 2026, sections 6.3.2.11.1–11.2, and NXP UCODE DNA SL3S5002N0FUD product information were read on 2026-09-23. The NXP part is a third-party chip illustration. Exact finished-tag construction, reader/SDK exposure, key operation and AIDC GO product support remain unverified. All asset identifiers and decisions above are editorial assumptions.