13.56 MHz

Entry-level HF Metal RFID Cards

entry-level HF is the light end of the 13.56 MHz family: a small-memory chip built for event tickets, short-lived guest credentials, and simple loyalty programs. The counter-enabled generation adds counters and password protection over the original; the 3DES variant exists for platforms that specifically require its 3DES authentication. None of them carry the sector-key structure of sector-based HF — that simplicity is the point.

Entry-level HF route brief

Frequency	13.56 MHz
Best use	Event tickets, simple guest credentials, lightweight loyalty, and platform-specific HF card programs.
Chip route	Baseline or counter-enabled entry-level HF; the 3DES variant only where the platform specifically requires that route.
Phone behavior	Can be read by NFC phones when formatted for Type 2 behavior, but is usually selected around a reader specification.
Encoding	NDEF, UID reference, one-time ticket data, counters, password protection, or a legacy 3DES route.
Approval check	Confirm chip generation, memory, authentication, lock bytes, and reader behavior before production.

Visual references

Brushed metal NFC card tapping a smartphone

Champagne-gold metal NFC card beside a smartphone

Gunmetal metal RFID card at a secure reader

Copper metal RFID credential on a contactless reader

Brushed metal RFID card on an LF reader test bench

Gunmetal metal credential in front of UHF gate antennas

Metal RFID card encoding and QA workstation

Simple by design — confirm the platform wants simple.

entry-level HF suits high-volume, low-risk credentials where the platform validates against its own database rather than trusting data on the card. If the system expects sector-based memory or high-security AES HF applications, an entry-level HF card will enroll and then fail in service. The chip generation, lock bytes, and any password protection are confirmed in writing before production.

Approve a working sample in the real environment.

Confirm chip generation, memory, authentication, lock bytes, and reader behavior before production.

Best uses

Event tickets, simple guest credentials, lightweight loyalty, and platform-specific HF card programs.
Metal card programs that can validate a finished encoded sample on the target reader
Projects that need print, serial, QR, packaging, and data handling reconciled in one approved brief

Frequently asked questions

When is entry-level HF the right metal card chip?

For tickets, short-lived guest credentials, and light loyalty programs where the platform checks its own database and the card mainly carries an ID. It is deliberately simpler and lighter than sector-based or AES-authenticated HF.

What is the difference between the entry-level HF generations?

The baseline is the simplest; the counter-enabled generation adds counters and password protection; the 3DES variant adds stronger authentication and is chosen only when a platform specifically requires that route. The platform's specification decides — not preference.

Why confirm lock bytes before production?

Lock bytes make parts of the chip permanently read-only. Set correctly they protect the ticket data; set wrongly they brick a feature the platform needed — so the lock state is agreed and tested on samples before the batch.

Specification

Format	CR80 85.6 x 54 mm by default; custom outlines after RF review
Thickness	0.3 mm to 0.8 mm depending on construction
Minimum order	None — single samples to production runs
Production time	About one week after artwork and sample approval
RF construction	Antenna, ferrite or hybrid shielding, chip, metal faces, and edge stack specified together
Chip routes	NFC tag, standard HF, high-security AES HF, LF compatibility, and selected UHF by reader test
Marking options	Laser etch, deep engraving, UV print, white ink, enamel fill, QR, serial, and controlled cut-through
Approval flow	Finish sample, encoded working sample, reader check, pre-production approval
Frequency	13.56 MHz
Chip route	Baseline or counter-enabled entry-level HF; the 3DES variant only where the platform specifically requires that route.
Phone behavior	Can be read by NFC phones when formatted for Type 2 behavior, but is usually selected around a reader specification.
Encoding	NDEF, UID reference, one-time ticket data, counters, password protection, or a legacy 3DES route.
Approval check	Confirm chip generation, memory, authentication, lock bytes, and reader behavior before production.