Hashentic now includes EM4425 (em|echo-V) in its supported NFC options, alongside NTAG424 DNA and NTAG215. This expands the choice of tags that can connect a product to its record and customer page.
The three chips do different jobs. EM4425 and NTAG424 DNA provide cryptographic data that Hashentic verifies. NTAG215 provides access through a registered identifier. Choose the required evidence first, then the chip and finished label.
This guide describes the supported workflows as reviewed on 5 September 2026. EM4425 is new to this Hashentic overview; that does not mean the chip itself was released in 2026.
What the EM4425 support adds
EM Microelectronic's EM4425 product documentation describes NFC Type 5 communication over ISO/IEC 15693 and AES-128 web authentication. Authentication capabilities depend on the selected variant and configuration.
Hashentic's implementation covers NFC tag personalization, a dynamic verification link and server-side validation. The backend checks the tag identity, its cryptographic response and a changing Security Token. Previously accepted or older token values are rejected by the verification flow.
The Security Token is not a simple count of customer visits. Hashentic uses it to detect reuse of authentication data. Reporting and customer analytics should use recorded events rather than treating the token value as a scan total.
For the customer, the intended interaction remains straightforward: bring a compatible phone near the configured tag and open the product experience. Test the actual phones and labels used in your market; a supported NFC standard does not guarantee identical behaviour on every device.
The supported chips at a glance
| Chip | NFC interface | Role in Hashentic |
|---|---|---|
| EM4425 | Type 5 / ISO/IEC 15693 | Cryptographic response and Security Token verification |
| NTAG424 DNA | Type 4 / ISO/IEC 14443-A | Dynamic CMAC validation and read-counter checks |
| NTAG215 | Type 2 / ISO/IEC 14443-A | Identifier lookup and product-information access |
See the supported-chip overview for a concise selection guide and manufacturer links.
Where NTAG424 DNA fits
NTAG424 DNA remains a supported option for secure NFC verification. Its dynamic messaging mechanism supplies data that Hashentic can authenticate, with the read counter helping the backend detect repeated messages. NXP documents the configuration in its NTAG424 DNA application note.
EM4425 does not make an existing NTAG424 DNA deployment obsolete. The two use different phone interfaces and different message formats. Evaluate the finished inlay, manufacturing setup, phone behaviour and lifecycle requirements before selecting one for a new product.
Do not transfer configuration instructions from one chip to the other. Both require the correct keys, data layout and verification endpoint for their own method.
Where NTAG215 fits
NTAG215 is useful when the label's job is to open instructions, product details or another customer page. NXP specifies a Type 2 chip with 504 bytes of user memory and password-based memory protection in its NTAG21x product information.
That password protection is different from a fresh cryptographic message sent to a web service. Hashentic's NTAG215 path looks up the identifier; it does not provide the same dynamic tag proof as its EM4425 or NTAG424 DNA paths.
The page should say what was checked. Finding a registered record can be useful without implying that the physical item has been authenticated. A common page design can serve several tag types while preserving that distinction in the result.
EM4425: distinguish NFC from RAIN UHF
The em|echo-V family overview describes both NFC and RAIN RFID capabilities. The chip's radio capabilities and a deployed inventory solution are separate parts of a project.
The Hashentic support described here covers NFC personalization and web verification. UHF warehouse reading requires suitable readers, antennas, inlays, event capture and integration with the relevant systems. This release description does not claim that an end-to-end UHF inventory workflow has been deployed.
If both customer NFC and warehouse UHF are required, include both teams in the pilot. Define how the identifiers map to the same item and which system owns each lifecycle event. A successful phone tap is only one acceptance test.
Plan the complete label and its lifecycle
Start with the finished product, not a bare chip on a desk. Material, antenna design, placement and packaging all affect the interaction. A tag that works before filling, sealing or sewing may behave differently afterwards.
Prepare a short acceptance checklist:
- Select the exact chip variant, inlay and required authentication mode.
- Confirm the writer and personalization procedure for that chip.
- Test a fresh read, an unreadable label and a reused verification link where applicable.
- Check that the result distinguishes product lookup from cryptographic verification.
- Define what happens after opening, servicing, relabelling or tag failure.
- Test target phones and the final packaged product together.
For all three chips, a product record and a tag result do not independently prove the product's contents, condition or ownership. Attachment design and operational checks determine how closely the tag's identity remains tied to the physical item.
Chip choice also does not by itself establish digital product passport compliance. Prepare the product data separately using the DPP data-model guide.
Compare options using your own samples
Use our NFC pilot checklist to document tests and exceptions. If you are also selecting a platform, the Hashentic and alternatives comparison explains questions to bring to each provider.
Request a demonstration with your product samples, target phones and intended verification result. That gives the team a concrete basis for choosing EM4425, NTAG424 DNA or NTAG215 and agreeing the required integration work.
