RF engineering guide
Metal Card RFID Technology Types
Metal card RFID technology decides whether a finished card works with a lock, door reader, phone, event scanner, loyalty platform, or authentication system. Unlike plastic or wood, the metal faces, shielding layer, antenna geometry, chip route, thickness, and final finish must be approved together on the real target reader.
Compare every RFID route before choosing the card build.
Start from the real reader, phone, lock, scanner, or data platform. The table keeps chip route, encoding, and approval risk in one place.
| Route | Frequency | Best use | Chip route | Phone fit | Encoding | Approval |
|---|---|---|---|---|---|---|
| LF RFID | 125 kHz | Legacy access control, selected hotel locks, staff ID, and replacement credentials where the installed reader requires LF. | programmable 125 kHz, EM-compatible, or exact system-specific LF chip selected by the reader requirement. | Not phone-readable for normal smartphone NFC use. | Facility code, card number, clone or emulation route, or blank supply depending on the access provider. | Test an encoded finished metal sample on the exact door reader, enrollment reader, or lock. |
| HF / NFC | 13.56 MHz | Modern access, NFC business cards, loyalty, events, hospitality, member ID, and phone-tap programs. | NFC tag, standard HF, high-security AES HF family, or platform-required 13.56 MHz chip matched to the metal construction. | Can be phone-readable when the chip and encoded record are selected for NFC behavior. | NDEF URL, vCard, UID list, access data, member ID, QR or serial matching, and optional locking. | Test target phones, readers, scanners, or locks in the final ferrite-shielded metal body. |
| NFC Tag | 13.56 MHz NFC | Public phone-tap experiences: business cards, profiles, menus, loyalty, product authentication, and event pages. | 144-byte NFC tag (144 B), 504-byte NFC tag (504 B), or 888-byte NFC tag (888 B) selected by memory need and data plan. | The clearest route for broad smartphone tap behavior when the card opens a public URL or record. | NDEF URL, short URL, profile, vCard, campaign URL, optional QR fallback, and a write-lock decision. | Confirm tap zone, record length, redirect behavior, and phone performance in the final metal build. |
| Entry-level HF | 13.56 MHz | Event tickets, simple guest credentials, lightweight loyalty, and platform-specific HF card programs. | Baseline or counter-enabled entry-level HF; the 3DES variant only where the platform specifically requires that route. | Can be read by NFC phones when formatted for Type 2 behavior, but is usually selected around a reader specification. | NDEF, UID reference, one-time ticket data, counters, password protection, or a legacy 3DES route. | Confirm chip generation, memory, authentication, lock bytes, and reader behavior before production. |
| AES-secured HF | 13.56 MHz secure HF | Lightweight secure ticketing, controlled membership, event access, and loyalty needing stronger authentication. | AES-secured lightweight HF or the platform-specified AES-authenticated lightweight HF chip. | Not a generic tap-to-URL choice; phone behavior depends on the app, NDEF setup, and AES flow. | AES keys, authenticated pages, counters, UID mapping, access rights, and app-specific payloads. | Define key ownership, personalization responsibility, app or reader support, and sample validation. |
| Standard HF | 13.56 MHz | Membership access, gyms, clubs, campuses, workplaces, hospitality, venues, and compatible access systems. | The exact standard HF chip must match the installed system; the family name alone is not enough. | Usually selected for readers rather than public phone tap; behavior depends on chip and data model. | UID, memory sectors, access keys, card number, member record, or integrator-defined data. | Confirm chip generation, key handling, metal RF stack, and the real access reader. |
| High-security AES | 13.56 MHz secure HF | Secure enterprise, campus, premium hotel, club, and multi-application credential programs. | high-security AES HF with 2K, 4K, or 8K memory, selected by integrator requirement and application structure. | Not chosen for public NFC marketing; it is generally a secure reader credential route. | Application IDs, files, keys, secure personalization, UID exports, cardholder mapping, and box labels. | The integrator defines keys and encoding, then validates finished samples on the target reader. |
| UHF RFID | 860–960 MHz | Selected long-range identification, EPC-style data, asset flow, event experiments, and product authentication. | EPC Gen2 (ISO/IEC 18000-63) inlay with on-metal antenna construction, selected around range, reader power, and orientation. | Not smartphone NFC; it needs a UHF reader or scanner. | EPC, TID or UID reference, asset ID, batch ID, or project-specific data. | Test range, orientation, nearby materials, reader power, antenna position, and final metal finish stack. |
| Programmable 125 kHz | 125 kHz LF | Compatibility-driven LF access, hotel, ID, and legacy replacement projects. | programmable 125 kHz rewritable LF chip, programmable to EM-style and other legacy formats the reader expects. | Not phone-readable. | Blank, encoded, cloned by the buyer, or access-provider format depending on project rules. | Define encoding ownership, confirm target format, and test on the real reader in a final metal sample. |
| Encoding | Depends on chip route | The production layer connecting metal cards to software, access systems, members, rooms, URLs, or packaging. | Works across NFC tag, standard HF, high-security AES HF, LF, UHF, and other approved chip routes. | Relevant when NFC records, QR fallback, or mobile landing pages are part of the workflow. | UID exports, NDEF records, access data, QR, serials, member names, room zones, box mapping, and CSV reconciliation. | Approve one source file for artwork, data, scan tests, box labels, and the replacement workflow. |
Metal RFID workflow views
Compare the reader, phone, shielding, and encoding route before choosing the finish.
Start with the exact reader or phone behavior, then engineer the metal construction around it. A premium finish comes after the RF path has been proven—not before.
The reader decides the chip; the metal construction decides whether it performs.
Share the exact lock, reader, phone, scanner, existing credential, and expected read behavior before a metal card is specified. The final antenna and shielding stack cannot be assumed from a standard plastic credential.
Keep data, print, and replacement handling connected.
UIDs, access data, NDEF URLs, QR fallback, serials, packaging labels, and replacement-card rules should be reconciled from one approved production file.
Frequently asked questions
Which RFID technology should a metal card use?
Choose from the installed system requirement: NFC tag for public phone tap, standard or high-security HF for compatible access platforms, LF or programmable 125 kHz for 125 kHz systems, and UHF only where long-range reading is genuinely required.
Can metal RFID cards work with existing readers?
Yes, when the chip family, antenna, ferrite or hybrid shielding stack, and final thickness are matched to the reader. A finished working sample must be tested on the real lock, reader, phone, or scanner.
Can metal cards be encoded before delivery?
Yes. UID lists, NDEF records, access data, QR codes, serials, and packaging labels can be reconciled from one approved production file.
Specification
| RFID routes | LF 125 kHz, HF/NFC, NFC tag, standard HF, entry-level HF, AES-secured lightweight HF, high-security AES HF, UHF, programmable 125 kHz |
|---|---|
| Metal construction | Metal faces, ferrite or hybrid shielding, antenna geometry, chip position, core, edge stack |
| Reader inputs | Lock or reader make/model, existing credential, tap position, expected read distance, encoding owner |
| Approval path | Working encoded sample on the real phone, reader, lock, gate, or scanner before artwork release |