An NFC tag is not ready for deployment merely because a writer reports success. The project must define the intended data, write it to the exact tag type, read it back through the target application and only then apply the documented protection state. Reversing that order can permanently lock a wrong or incomplete payload.
This guide focuses on tag preparation after compatibility has been established. Use HF RFID and NFC Compatibility first to match the card or tag technology, protocol and application access. Nothing here claims that an AIDC GO device can encode or lock a particular NFC tag.
Define the application record before touching the tag
Write down the payload type, exact value, character encoding, version and application that must consume it. For an NDEF deployment, decide whether the record is a URI, text, MIME media or another defined type. Android's NFC documentation explains that the first NDEF record influences how the tag dispatch system maps the message to an application.
Separate the tag payload from the physical tag identifier. A manufacturer-programmed UID can help identify the chip, but it is not automatically the asset number or the business record stored in NDEF. If the project maps a tag to an asset, keep that authority and replacement history in the controlled system described in Replacing a Damaged RFID Tag.
Bind the procedure to one exact chip and memory map
The words "NFC tag" do not define memory capacity, lock granularity or password behavior. NXP's NTAG213/215/216 data sheet is one bounded Type 2 Tag example. It lists different user-memory sizes across the three ICs, static and dynamic lock bytes, a capability container and configurable password protection. NXP's product page identifies the same family as NFC Forum Type 2 Tag and ISO/IEC 14443 Type A compliant.
Those details apply to the named NTAG21x parts and data-sheet revision. They must not be transferred to another Type 2 product, a Type 4 card or a tag sold under a generic label. Record the inlay or finished-tag part number, IC identification method, data-sheet revision and memory area used by the encoder.
Follow one write, readback and application test
Consider an editorial sample that should open https://example.com/service/A-2048 in the project's approved application. The issuing tool creates one well-formed URI record, confirms that the encoded message fits the tag and writes it. A second read retrieves the complete NDEF message and compares its record type and payload byte for byte with the approved value.
The team then reads the tag with the target phone and application build. It confirms that the intended application receives the expected URI and that the asset suffix remains A-2048. A browser opening a similar-looking page is not enough if the project requires a named application route.
This is an editorial validation sequence, not a customer test. Android's Ndef.writeNdefMessage() reference says the operation overwrites the NDEF message and can report malformed data, tag loss or I/O failure. A completed API call is evidence for that operation, not proof that another device or business application interprets the record correctly.
Keep the issuing evidence in one table
| Stage | Evidence to retain | What it does not establish alone |
|---|---|---|
| Approved payload | Record type, exact value, encoding and version | It does not establish that the payload fits the selected tag. |
| Tag identity | Finished-tag part, IC type, memory map and UID observation | It does not establish that UID is the business identifier. |
| Write result | Tool/app version, message bytes and operation status | It does not establish that the complete message can be read back. |
| Independent readback | Parsed records plus byte-level comparison with the approved payload | It does not establish that the target application handles the message correctly. |
| Protection result | Exact mechanism, protected range and post-protection read/write checks | It does not establish that another tag family uses the same lock behavior. |
Preserve the rows for the same physical tag. Combining a successful write from one sample with a successful read from another does not prove one controlled issue cycle.
Distinguish permanent lock from access control
Android's Ndef.makeReadOnly() documentation says the operation sets the capability-container state and, where possible, permanently sets lock bits. It is a one-way process and cannot be reverted. The application also exposes whether a tag can be made read-only and whether it is currently writable; those checks belong before and after the operation.
The NTAG21x example shows why the exact mechanism matters. Its capability-container updates and lock bits include irreversible behavior. Separately, its password mechanism can require successful password verification for write access, or for both read and write access, starting at the configured protected page. Password protection is not the same statement as permanent read-only locking, and NXP describes it as a convenient access barrier rather than a substitute for higher-level cryptographic protection.
Do not use "locked" as one undifferentiated status. Record whether the data pages are permanently read-only, whether configuration pages are locked, whether a password protects a range, and which bytes remain writable. Preserve secrets outside screenshots and ordinary logs.
Test failure before making the change irreversible
Before locking, scan a deliberately malformed or outdated sample in a controlled test set. The issuing process should reject it without changing the production tag. Then encode a fresh sample, remove it from the RF field, read it again and exercise the actual application route.
After applying the approved protection, repeat the readback and application test. Attempt one documented write to a sacrificial or explicitly authorized test area only when the procedure and tag support it; a failed write should match the intended protection state. Never probe production credentials or consume irreversible lock bits merely to explore behavior.
If the project needs user authentication rather than static tag data, treat that as a different security design. Reading NDEF, reading protected memory and completing a business authentication are separate outcomes.
Control rework, replacement and batch release
Keep unprotected tags physically separated from released tags. Assign batch, payload version, encoder version, operator or station, tag part and readback result before the protection step. Release the batch only after sampled or full verification matches the documented acceptance rule.
If a payload is wrong after permanent locking, quarantine and replace the tag rather than claiming it can be repaired. If password protection is used, define key custody, retry limits and recovery procedures from the exact chip documentation. A generic promise that the tag is "rewritable" is not a recovery plan.
For a broader application-input discussion after the phone receives the NDEF message, use Barcode Scanner Integration Methods only as a general comparison of application delivery paths, not as proof of NFC support.
Bring the issuing packet to the purchase discussion
Provide the tag manufacturer and part number, IC, memory requirement, NDEF record examples, encoder hardware and application version, target reader/phone and OS build, intended application route, lock or password requirement, batch size and acceptance evidence. Include one unprotected sample and one approved protected sample where policy permits.
Ask for the exact tag data sheet, memory and lock map, supported encoding commands, protection irreversibility, password scope, retry behavior and compatible issuing tools. Use Integration & Support to frame version-specific questions, then contact AIDC GO with the complete tag and application configuration.
The safe sequence is deliberate: approve the payload, identify the tag, write, read back, test the target application, protect, and verify again. A single "write successful" message should never substitute for that chain.