You are comparing two smart card quotes. Both suppliers promise “fully certified” cards — yet one is 40% cheaper. Which do you trust? Open the spec sheets and you are hit with a wall of acronyms: EAL4+, EMVCo L1, FIPS 140-3, ISO/IEC 7816-4, CC EAL. For a procurement or security lead, these marks are not decoration. They are the difference between a card that clears a bank’s terminal audit, passes federal acceptance, or survives a nation-scale issuance program — and one that gets rejected at the worst possible moment. This guide decodes the certifications buyers actually meet, what each one proves, when your program legally or commercially needs it, and how to read a supplier’s claims without getting fooled.
Common Criteria and EAL Levels: What “EAL4+” Really Means
Common Criteria (CC) is the international standard (ISO/IEC 15408) for evaluating the security of an IT product. A smart card chip’s resistance to tampering, side-channel attacks, and fault injection is assessed and awarded an Evaluation Assurance Level (EAL) from EAL1 to EAL7. For commercial smart cards you will typically see EAL4+ or EAL5+; higher levels mean a more rigorous, costly evaluation — not automatically a “more secure” chip in everyday use.
What it proves: the chip’s security claims were independently verified by an accredited lab against a published protection profile. What it does NOT prove: that the finished card — antenna, encapsulation, operating system, personalization — is equally robust. A CC-certified chip inside a poorly built card is still a weak card. When you need it: government, defense, and high-assurance enterprise programs frequently mandate a minimum EAL. Read the target of evaluation carefully — some certificates cover only the chip, others the full operating system.
See our Smart Card Operating Systems: Java Card, MULTOS, and What Buyers Should Know guide for how the OS layer inherits — or breaks — CC assurance.
EMVCo Type Approval: The Gatekeeper for Payment Cards
If your cards will be used for payment — debit, credit, prepaid, or transit open-loop — EMVCo approval is non-negotiable. EMVCo (jointly owned by Visa, Mastercard, American Express, Discover, JCB, and UnionPay) runs the type-approval schemes that certify a card, applet, or terminal conforms to the EMV specifications.
The levels matter: EMVCo L1 covers the physical, electrical, and analog layer; L2 covers the application and kernel software; L3 covers terminal interoperability. A supplier claiming “EMV-ready” without a published approval number is a red flag. When you need it: any program where cards touch a payment network or a bank-issued wallet. Approved cards reduce the risk of transaction failures, chargebacks, and reader rejection.
Our EMV Payment Card Personalization: What B2B Issuers Must Specify guide explains what issuers must lock down before personalization begins.
FIPS 140-3 and FIPS 201-3: The U.S. Federal Baseline
Two U.S. federal marks come up constantly. FIPS 140-3 validates the cryptographic module inside the card — the engine that protects keys and PINs. A FIPS 140-3 validated module is required for U.S. federal systems and many regulated industries. FIPS 201-3 defines the Personal Identity Verification (PIV) card itself — the credential format U.S. government employees and contractors carry.
What to watch: FIPS 140-3 is about the crypto engine; FIPS 201-3 is about the overall PIV credential. A card can be FIPS 201-3 compliant using a FIPS 140-3 validated module — but the two are not interchangeable claims. When you need it: U.S. federal, state, and many healthcare and finance buyers. Outside the U.S., map these to your own national scheme (for example, a national eID program). Reference the NIST Cryptographic Module Validation Program and IDmanagement.gov for the current requirements.
Our PIV and PKI Smart Cards: A Buyer’s Guide to FIPS 201-3 Compliant Credentials breaks down the full credential stack.
ISO/IEC 7816 and 14443: The Interoperability Baseline
Even if no regulator forces it, ISO/IEC 7816 (contact) and ISO/IEC 14443 (contactless) are the baseline every serious program should require. They define the electrical, mechanical, and protocol layers that let a card talk to a reader. A card that does not conform will fail in the field — wrong operating distance, corrupted APDUs, or total silence at the reader.
These are conformance standards, not security certifications: they prove the card works, not that it is safe. Treat them as table stakes — a supplier should provide test reports from an accredited lab showing 7816/14443 conformance as a condition of the purchase order. The underlying work is maintained by ISO/IEC JTC 1/SC 17 (cards and personal identification).
How to Read a Supplier’s Certification Claims (Avoid the Greenwashing)
Certification language is where buyers lose money. Watch for three tricks:
- “Compliant” vs “Certified”. “Compliant” is a supplier’s self-assessment; “certified” or “approved” should reference a real certificate number and issuing lab or scheme.
- Scope hiding. A chip may be CC-certified, but the card or OS is not. Ask which exact component the certificate covers.
- Expired or outdated. Certificates lapse and standards revise (FIPS 140-2 → 140-3). Confirm the document is current.
Always ask for the certificate PDF, the scheme ID, and the valid-until date before signing. A credible supplier answers within days, not weeks. Manufacturing discipline is the other half of the story — see our How Smart Cards Are Made article for why build quality matters as much as the paper certificate.
Which Certifications Does Your Program Actually Need?
A simple decision frame:
- Government / national ID / military: Common Criteria EAL4+ (or higher), FIPS 201-3 plus FIPS 140-3 (U.S.), and ISO 7816/14443 conformance.
- Bank-issued payment: EMVCo L1 + L2 approval mandatory; FIPS 140-3 for the crypto module.
- Enterprise logical / physical access: ISO 7816/14443 conformance plus a CC-EAL chip for high-assurance zones; EMVCo only if payment-enabled.
- Transit / closed-loop: ISO 14443 conformance; EMVCo only for open-loop bank schemes.
Over-specifying wastes budget; under-specifying risks rejection. Match the mark to the risk, not the marketing. For secure-element and OS-level assurance, the GlobalPlatform specifications are the industry reference many schemes build upon.
Buying smart cards is buying assurance, not plastic. Before your next RFQ, assemble a one-page certification matrix — map each requirement above to a supplier deliverable and request the actual certificates. If you want to see how conformance and build quality translate into a real card, request a sample batch and we will document the full certification package alongside it.
