HF RFID and NFC compatibility cannot be decided from the words "13.56 MHz" or "NFC" alone. A useful purchase decision must identify the card or tag, its air-interface technology, the data structure, any access control, the operation the application must complete and the API path available on the candidate device.
This guide is for integrators and project buyers who need a handheld to identify a badge, read an NDEF record, access protected card data or write an specified tag. It explains how to separate those tasks and how to assemble a test that answers the real compatibility question. It does not establish HF or NFC capability for an AIDC GO model without the applicable model document.
Start with the operation, not the frequency label
Write one sentence that describes the required result. "Read the asset number stored in an NDEF text record and compare it with the number printed on the label" is different from "read the card's discovered identifier," and both are different from "authenticate to a protected application and read one file." If writing is required, state which record or memory area changes and who supplies the keys and encoding rules.
Then identify the exact credential or tag. Record the manufacturer, product or chip family, physical form, existing encoding, security state and a sample identifier. A generic name such as access card, library tag or NFC sticker is not enough because products that operate in the same HF band can expose different technologies and data models.
The AIDC GO Products page is a hardware selection entry, not proof of HF/NFC support. Use Integration & Support to request the option list and interface materials for a named model and region before treating it as a candidate.
Separate the compatibility layers
The first layer is the radio and air interface. Android documents NfcA as NFC-A based on ISO/IEC 14443-3A, NfcB as NFC-B based on ISO/IEC 14443-3B, IsoDep as ISO-DEP based on ISO/IEC 14443-4, and NfcV as NFC-V based on ISO/IEC 15693. The Android NFC technology package exposes these as distinct technologies. Seeing one technology in a device specification does not establish the others.
The next layer is the tag or card protocol and memory model. NXP describes MIFARE DESFire EV3 as using an ISO/IEC 14443 Type A interface and ISO/IEC 14443-4 transmission, with application and security features specific to that product. ST describes the ST25DV04K family as ISO/IEC 15693 and NFC Forum Type 5 with memory areas that can be protected. Both are HF products, but they are not interchangeable test objects.
The data layer comes next. The NFC Forum NDEF specification page describes NDEF as a common application-data format. A tag can support an NFC air interface without holding the NDEF record your application expects. Conversely, successfully parsing an NDEF URI does not establish access to a protected non-NDEF file.
Finally, the application must receive and interpret the result. Android's NFC basics distinguishes NDEF dispatch from technology dispatch. Its advanced NFC guidance notes that non-NDEF work can require technology-specific communication and an application protocol stack. Hardware discovery is therefore only one step in an end-to-end business transaction.
Follow one editorial compatibility decision
Consider an editorial facilities project with two physical samples. Sample A is an NFC Forum Type 5 maintenance label containing an NDEF URI that points to an asset record. Sample B is a MIFARE DESFire EV3 staff credential whose protected application must be authenticated before a file is read. The project wants one handheld application to open the maintenance record and separately confirm a staff entitlement.
For Sample A, the team records the exact tag part, confirms the candidate device reports the expected NFC-V technology, reads the NDEF message, checks the URI against the printed asset identity and verifies that the intended application receives it. If the project must update that URI, the write test uses a non-production sample and the documented access state.
For Sample B, discovering the card or reading a low-level identifier is not acceptance. The application owner must provide the application identifier, command flow, key-management responsibility and expected protected response. The candidate device and software path must complete that operation under the relevant Android and application versions. A result from Sample A cannot fill the evidence gap for Sample B.
This is an editorial example, not a customer deployment or AIDC GO device test. It illustrates why a mixed card population needs a result for each named operation and sample.
Record what each observation proves
| Required operation | Evidence to capture | What the result does not establish |
|---|---|---|
| Discover the tag or card | Evidence: Exact sample; reported technology list; device and OS build | Does not establish: It does not establish that the required data is readable or meaningful to the application. |
| Read an NDEF record | Evidence: Record type, payload, read result and receiving application | Does not establish: It does not establish access to protected files or compatibility with a different tag type. |
| Read a low-level identifier | Evidence: Returned bytes, technology, formatting rule and expected identity | Does not establish: It does not establish that the identifier is stable, authorised as the business key or sufficient for authentication. |
| Access protected application data | Evidence: Named card application, command path, key owner, success response and negative case | Does not establish: It does not establish access without the same credentials, security state and software version. |
| Write or update specified data | Evidence: Target memory or record, permissions, before/after content and recovery rule | Does not establish: It does not establish unrestricted write access or safe modification of production credentials. |
Keep the identifier, payload and business record in separate columns. The tag identifier can help distinguish samples, but the application owner decides which value identifies the asset, person or transaction. If a value is reformatted, preserve the byte-order and encoding rule so two applications do not display the same tag differently.
Test the actual application path and access boundary
On Android, collect the technology list exposed for each sample and record whether the application uses NDEF dispatch, technology dispatch, reader mode or a vendor SDK. The Android API can expose a technology without implementing the higher-level business protocol for the application. Where IsoDep.transceive() or another raw exchange is used, the application supplies the protocol commands and error handling.
Build positive and negative cases. A positive case proves the reference sample and credentials can complete the named operation. A negative case might use the same card without valid keys, a similar tag with the wrong data format, an empty NDEF record or an identifier that is not in the business mapping. The application should distinguish "tag not detected," "technology unsupported," "access denied," "payload invalid" and "record not accepted" where those states matter operationally.
Do not test only a loose lab tag. Use the final housing, badge holder, mounting surface and operator movement when they can change presentation. Record antenna position and orientation as observations rather than promising a universal read distance. Use the AIDC Pilot Validation Checklist to place the compatibility cases in the wider project pilot without turning this article into another general checklist.
Quote existing card reuse with the application owner
If a project wants to reuse issued staff or service cards, decide what must be reused before buying a reader. Keeping the same plastic card, using its discovery identifier for a separate lookup and accessing its existing protected application are different proposals. The NFC identifier-to-record guide explains the lookup boundary; a lookup must not quietly replace a required authenticated operation.
First ask the card issuer or application owner whether the proposed operation is permitted and what integration path it supports. Request the exact card family and application, required file or response, software interface, specified key-custody arrangement and the party authorized to provision replacement readers. An issuer may provide a managed interface rather than disclose keys. Do not assume that buying a compatible reader grants rights to use an existing application, or ask suppliers to extract secrets from live cards.
Compare quotes for the same outcome
| Purchase scope | Included responsibility | Evidence before commitment |
|---|---|---|
| Reader and discovery only | Responsibility: Supply the named reader option and documented host interface; the project owns data access and business processing. | Evidence: The exact sample is detected on the quoted build. Treat protected application access and integration as exclusions, not implied deliverables. |
| Authorized protected application reuse | Responsibility: Name the issuer’s authorization, application integration, specified key provisioning and replacement process separately from hardware. | Evidence: An controlled test card completes the required authenticated operation in the intended app, with the agreed denial case and redacted records. |
| A separate identifier or new credential | Responsibility: Quote issuing, mapping, any additional label or card, and the operating change; do not claim reuse of the protected application. | Evidence: The system owner approves this alternative and its authorization model. Show the correct record without altering the original card application. |
The third option is not an automatic fallback when keys are unavailable. It may be suitable for a separate asset lookup but unacceptable for a workflow requiring the existing credential’s authenticated entitlement. If no authorized route meets that requirement, leave reuse unapproved and quote an alternative only after the system owner agrees.
Locate the missing part of the configuration
NXP’s MIFARE DESFire EV3 short data sheet, Rev. 3.1, distinguishes card-level management from application-level access: authority to create or delete an application does not itself give access to its files. Android’s IsoDep API, available from API level 10, provides an exchange path; the application implements the protocol above it. These are specific chip and platform boundaries, not a completed credential integration.
If the project uses a secure access module, identify the module, interface, provisioning and application requirements separately. A slot alone does not establish that keys or issuer authorization are supplied. Confirm the exact reader and card operation; a SAM is not mandatory for every NFC workflow.
Have suppliers itemize any required reader, module, provisioning service, middleware or SDK rights, app integration and ongoing support. Identify one owner for each boundary and price exclusions explicitly. A hardware-only offer and an offer that delivers an authorized application transaction are not comparable merely because both list NFC.
Demonstrate authorized reuse without touching live credentials
Hypothetical procurement example: a maintenance team wants an existing staff card to identify the operator in its work-order app. One offer supplies a discovered identifier; another includes an issuer-specified protected application response and the app mapping. The team must decide whether its requirement is a separate lookup or authenticated reuse before treating either offer as complete.
Use issuer-controlled test cards, test identities and a controlled environment. Demonstrate the required response reaching the correct work-order record, an specified unauthorized test case being denied without accepting a substitute UID, and a replacement reader being provisioned through the agreed process. Record the device, OS, reader firmware and app versions, outcome and responsible parties, not secret keys. Do not change production card keys, permissions or applications for a purchasing demonstration. Reader replacement also does not prove that a lost card has been revoked; that follows the issuer’s own service and policy.
Send the card family, permitted operation, deployment country, host configuration and split of hardware and application responsibilities to Integration & Support. Confirm the actual equipment option and supply scope before ordering; credential issuance and key-management services must have named, confirmed providers.
Bring a bounded compatibility packet to the supplier
Provide the candidate device model and region, Android or other OS version, application package and version, exact card/tag part numbers, required operation for each sample, NDEF or proprietary data definition, key or credential owner, write requirement, physical presentation and expected result. Include non-production samples and a redacted command or interface description where security policy permits.
Ask the supplier to identify the documented HF/NFC hardware option, supported technologies, antenna location, reader/writer limits and the API or SDK applicable to that exact configuration. Ask the application owner to confirm data parsing, authentication, key custody, mapping and business acceptance. Neither party should use a successful tag discovery as a substitute for the other party's evidence.
Then contact AIDC GO with the device options, deployment country, quantity, sample inventory and open interface questions. A defensible compatibility decision names the sample and operation, closes every layer required by that operation and leaves unsupported card types outside the claim.
Readers to test with your tags
