A chip choice determines what evidence a product scan can deliver. Opening a registered product page and authenticating a security tag are different operations, even if the customer sees similar branding afterwards.
Updated 5 September 2026: this article explains the distinction between NTAG213 and NTAG424 DNA. For Hashentic's currently supported chip options—EM4425, NTAG424 DNA and NTAG215—see the supported-chip guide. NTAG213 is discussed here as a technical comparison, not as an independently confirmed Hashentic integration.
Static access and dynamic authentication
NTAG213 is a Type 2 NFC chip that can carry a product URL. NXP specifies 144 bytes of user memory; the related NTAG215 provides 504 bytes. Both offer password-based memory protection. See the NTAG213/215/216 datasheet.
NTAG424 DNA is a Type 4 NFC chip with AES-128 and configurable dynamic authentication messages. Its file-based memory includes a 256-byte NDEF file within a 416-byte total. That total is not an unrestricted 416-byte URL field. See the NTAG424 DNA datasheet.
| Question | NTAG213 product link | Configured NTAG424 DNA verification |
|---|---|---|
| What opens the page? | A stored NFC URL | An NFC URL with dynamic authentication data |
| What does the backend check? | Whatever identifier or record the application uses | Cryptographic message data and configured replay checks |
| Does a memory password authenticate each web visit? | No | This flow uses a separate cryptographic mechanism |
| Can the URL alone prove product condition? | No | No |
A password can restrict memory operations without turning a readable URL into a fresh proof of tag authenticity. Conversely, a secure chip must be configured and connected to a verifier before its capabilities become a useful product workflow.
What Hashentic does with secure NFC
In the NTAG424 DNA path, Hashentic validates the CMAC, checks the tag-to-product binding and compares the read counter with the stored value. Previously accepted or older message data can be rejected. NXP explains dynamic-message configuration in its features and hints application note.
This browser flow should not be described as a universal interactive challenge-response exchange with the phone. The backend receives the authentication data exposed through the configured NDEF link and validates it.
Hashentic also supports EM4425 through a different dynamic-message format, with cryptographic response and Security Token checks. Its NTAG215 flow provides identifier lookup and access to product information. These methods can use a consistent visual design while displaying different kinds of result.
Choose around the required claim
A care-label project may only need durable access to instructions. A brand protection project may need evidence that a configured security tag produced the current message. A returns workflow may also need order information and physical inspection.
Define the intended claim before comparing quotes:
- What must the customer or staff member learn from the scan?
- Will the tag remain attached during the relevant product lifecycle?
- What happens when the tag is missing, damaged or moved?
- Who manages keys, identifiers, destination domains and support?
- Which phone and finished-label combinations have been tested?
There is no universal retail-price threshold that selects the correct chip. Ask for comparable costs covering the label, attachment, provisioning, verification service and exception handling. A chip choice alone does not establish regulatory compliance or a product's safety.
Plan migration before printing or encoding
A product page can change without changing the chip already installed on an item. Its underlying hardware capabilities cannot be upgraded by editing that page. If stronger authentication may be needed later, decide whether future production will use a different label and how existing items will be identified.
During a transition, keep the verification method visible. Do not present an identifier lookup as a successful cryptographic tag check merely because the page now uses the same design.
For sealed packaging, evaluate the particular tamper-detection variant, inlay and opening behaviour as a separate requirement. A chip-family name alone is not evidence that a package has remained sealed, and generic NFC support does not confirm an integrated tamper workflow.
Start with the supported-chip overview, then run the NFC pilot checklist on your actual product. Request a demo with the claim you need the scan to support.
