Choosing an RFID smart card starts with the application that must work when the card is presented. A card can respond to a reader while the intended application remains unavailable, unprovisioned or protected by keys the system cannot use. Verify the complete interaction before ordering a production batch.
This guide is for credential buyers and developers comparing card systems. Gather the proposed card family, reader model, software version, application requirements and issuing process. Use test credentials under your control; ordinary identification tests should preserve their existing data.
Identify the interface and the application
On a small screen, scroll sideways to read all columns.
| Form | How it connects | Next question |
|---|---|---|
| Contact smart card | Electrical contacts meet the reader contacts. | Which card commands and application does the host support? |
| Contactless smart card | A compatible radio interface exchanges commands. | Which protocol, card family and authenticated application are supported? |
| Dual-interface card | The same chip supports contact and contactless use. | Are the needed application and security functions available through both paths? |
| Multi-technology credential | More than one chip or technology may share one body. | Which component is actually used at each reader? |
A card's shape or printed badge design does not tell you its interface or security model. Ask for the exact construction. In particular, a dual-interface chip and a badge combining separate technologies can look alike while needing different provisioning and migration plans.
NXP's MIFARE DESFire EV3 documentation is one concrete contactless example: it identifies an ISO/IEC 14443 Type A interface, application/file structures and mutual-authentication capabilities. Those are separate fields to verify. Features listed for that family should not be attributed to every contactless card.
Test more than the serial number
Separate four results in a compatibility demonstration: the reader detects the card, selects the intended application, authenticates with the configured method and completes the required operation. Save the result of each stage. A visible UID or serial number only answers the first part of that chain.
Ask the application supplier to show the commands or supported middleware interface used for the real task. For a protected credential, the demonstration should confirm authorized access and a clear failure with a deliberately incorrect test configuration. Avoid accepting a generic “card read” screen as evidence of protected application support.
Write down who provisions the card
Define the application identifier, file layout, access rights and credential-to-person or credential-to-account association. Decide which data belongs on the card and which belongs in the managed application. Keep a versioned card profile so issuing stations produce the same approved construction.
Name the owner of key generation, secure storage, loading, rotation and recovery. Record references to protected key-management procedures rather than copying keys into a worksheet. Determine whether a service provider can issue replacements independently and what access the organization retains if providers change.
NXP's system-level security guidance for MIFARE installations discusses measures such as diversification, key renewal and revocation information. Its practical lesson for procurement is that card security depends on the surrounding system and management of keys. Have the responsible security team approve the actual cryptographic profile and implementation.
For a multifunction credential, identify who owns each application and which party may update or remove it. Test that a change to one service preserves the others. Include the card's memory allocation and version in the acceptance record.
Run a small migration with representative credentials
- Issue a new test credential using the proposed production process and confirm its association with the intended test account.
- Present it at each reader type and verify the complete authorized application operation.
- Test an older supported card, a card without the application and a deliberately unprovisioned test card.
- Interrupt a supported test transaction and confirm the application's documented recovery behavior.
- Replace or revoke the test credential and check the resulting status at the relevant systems.
Use a matrix of card profile, reader model, firmware and application version. Record the actual mode used, especially if the system can fall back to a simpler identifier read. A migration should preserve the required protection as well as convenience.
For physical entry, use the access-control guide to evaluate controllers, permissions, revocation and outages. This card-level check establishes the credential and reader application path; the entrance has additional operating requirements.
Make replacement and support predictable
Save the issuing profile, approved suppliers, test-card set and diagnostic results with the system documentation. Keep a secure process for replacement credentials and remove superseded associations. Decide how support staff recognize a damaged card, an expired entitlement and a reader fault without exposing protected contents.
Review compatibility after firmware changes, altered card profiles, new applications or changed service providers. Repeat the complete operation on representative credentials; a successful identifier read remains only one diagnostic checkpoint.
Keep a working record
Download the editable working record (plain text). It includes purpose, instructions, evidence fields and this guide's source links. Save a separate copy for each evaluation and record unresolved issues with their owner.
Related reading
Researched and updated September 20, 2026. Recheck source documents when equipment, software or applicable requirements change.