Smart cards in PCs: Standards, terminology, and real-world compatibility

Introduction

The term "smart card" is used in very different ways in retail and IT. Sometimes it refers to a traditional chip card with contact pads, sometimes to a contactless RFID/NFC card for short-range wireless systems, and sometimes to a USB token with built-in security features. Adding to the confusion are labels such as PIV, NXP, FIPS, or FIDO: which of these are actual standards, which are certifications or vendors, and how do they relate to each other?

Let's start with a simplified overview:

smartcard-venndiagram_en.png

Of course, this diagram does not fully capture the complexity of the SmartCard landscape, which has evolved over time.

Therefor, the following article will put structure into the terminology and explain which cards work with which readers and use cases - and what to look for when buying and setting up a smart card solution.

Concept map

We distinguish between the following levels:

Level Typical Terms What This Actually Means
Physical Interface ISO/IEC 7816 (contact), ISO/IEC 14443 (proximity), ISO/IEC 15693 (vicinity), NFC, RFID How the card or tag physically communicates with the reader: contact pads or wireless (short-range RF).
Reader–PC Connection USB CCID, PC/SC How the reader is recognized by the PC and how applications access smart cards under Windows.
Card Profiles / Applications (“Card Edge”) PIV, GIDS, OpenPGP Card, EMV, DESFire Which files, objects, and commands the card exposes, and which use cases it supports.
Host Integration / APIs Microsoft Minidriver, CSP/KSP, PKCS#11, PKCS#15 (Smart Card/PKI); WebAuthn/CTAP (FIDO2, browser login) Which software interfaces applications actually use (Windows Crypto APIs, PKCS libraries, browser authentication).
Certificates & Trust Model X.509, PKI, CA, revocation How identities and trust relationships are represented and validated (certificates, CA chain, revocation, policies).
Card Platform & Lifecycle Java Card, GlobalPlatform Whether applets can be installed on the card and how card content is managed and personalized.

Separate overviews on the differences between the various standards can be found in these articles:

Important to note: A product can support several "standards" simultaneously without this being contradictory, as these standards operate at different levels.

A dual-interface Java Card, for example, can support ISO/IEC 7816 (contact) and ISO/IEC 14443 (contactless), contain a PKI/PIV profile and additionally offer FIDO2 functions – depending on the card and the interface available on the PC or laptop (contact vs. contactless).

Physical and wireless interfaces

ISO/IEC 7816 (contact smart cards)

ISO/IEC 7816 is the central family of standards for contact-based smart cards with metal contacts ("gold chip").

Sub-sections of the standard include, amongst others:

  • Part 1: Cards with contacts—Physical characteristics
  • Part 2: Cards with contacts—Dimensions and location of the contacts
  • Part 3: Cards with contacts—Electrical interface and transmission protocols
  • Part 4: Organization, security and commands for interchange
  • Part 8: Commands and mechanisms for security operations
  • Part 9: Commands for card management
  • Part 13: Commands for application management in a multi-application environment
  • Part 15: Cryptographic information application

In plain language: ISO/IEC 7816 describes how a contact chip card functions electrically, how it "boots up", how it exchanges commands (APDUs) and how files, keys and management commands are structured.

On the Windows side, contact-based cards typically run via the Windows Smart Card Stack (PC/SC ecosystem).

ISO/IEC 14443, NFC and RFID (contactless)

ISO/IEC 14443 is a family of standards for contactless proximity cards. These cards are read at very short distances (typically 10 cm or less) and are found in many security-related applications, such as payment cards, ID cards and access control systems. ISO/IEC 14443 requires a contactless reader with a corresponding radio front-end.

NFC is closely related to, but not identical with, ISO/IEC 14443. NFC refers to a broader set of technologies and specifications with defined operating modes such as Reader/Writer, Card Emulation and Peer-to-Peer. Many ISO/IEC 14443 products are NFC-compatible, but not every 14443 product is necessarily marketed as "NFC". In any case, NFC or ISO/IEC 14443 cards are not compatible with a purely contact-based reader.

RFID is the umbrella term for radio-frequency identification. This encompasses various standards and frequency ranges; NFC is only one part of this. A product description containing "RFID" alone therefore often does not indicate whether it refers to ISO/IEC 14443, ISO/IEC 15693 or something else.

ISO/IEC 15693 (Vicinity)

ISO/IEC 15693 describes contactless Vicinity cards and tags. Unlike ISO/IEC 14443 (Proximity), 15693 is designed for longer ranges and is frequently used in applications such as inventory management, asset tracking or industrial labelling. Some contactless readers support ISO/IEC 15693 in addition to ISO/IEC 14443 – but many others do not.

Risk of confusion

In some contactless products, "ISO/IEC 7816-4" is mentioned in the context of APDU/file structure compatibility, not in the context of the physical contact pads. This means that "ISO/IEC 7816" in a text may refer to the command/data model layer, even though the card physically communicates via ISO/IEC 14443/NFC.

A simple distinguishing feature: if a chip card does not have a gold-plated chip, then it is not compatible with a contact card reader according to ISO/IEC 7816, regardless of how its internal data structure is organised.

PC connection via USB CCID and PC/SC

USB CCID (Chip Card Interface Device) describes how a smart card reader identifies itself to the PC as a USB device and can therefore be recognised in many systems without special drivers. PC/SC (Personal Computer/Smart Card) is the software interface in Windows through which applications communicate with the reader and the inserted smart card, for example to read certificates or perform cryptographic operations on the card.

Card profiles, host integration, solutions and certificates

Once the physical interface is suitable and the connection to the PC has been established, we reach the level with the greatest diversity: what is stored on the card, how can it communicate with the operating system, and how is trust ultimately established? The order of the following points does not strictly follow the sequence in the table above. Instead, it is based on the typical use case of a classic card reader in accordance with ISO/IEC 7816 (read: the most important terms come first).

PIV and GIDS

PIV (Personal Identity Verification) and GIDS (Generic Identity Device Specification) are application or card profiles, which define how certificates, keys and commands are structured on a smart card.

They store certificates and private keys and perform signature/decryption operations on the card without the private key having to be read from the PC as a "file".

Windows includes a generic Inbox Class minidriver for such cards and can detect compatible cards via defined discovery steps (e.g. via AID-Select). As a result, PIV/GIDS cards work out-of-the-box in Windows environments – unlike proprietary card profiles, which necessarily require manufacturer-specific middleware.

The following differences exist between these two solutions:

Topic PIV GIDS
Origin / Governance U.S. government standard (FIPS 201 and NIST SP 800-73). Microsoft specification (“Generic Identity Device Specification”).
Objective Standardized, interoperable identity credential (certificates, keys, identity objects), primarily designed for government and public-sector identities. Generic card profile enabling smart cards to be used and provisioned in Windows without requiring a manufacturer-specific minidriver.
Windows Detection Windows first searches for the PIV application (PIV AID). If found, the card is treated as a PIV card. If no PIV application is found, Windows searches for the GIDS AID. If found, the card is treated as a GIDS card. If neither PIV nor GIDS AID is present, Windows may still handle the card using GIDS-style fallback behavior, depending on the implementation.

PIV is therefore widely used as a clearly defined profile and enjoys good, native support in Windows. Solutions based on GIDS, on the other hand, are more closely aligned with Microsoft's own specifications.

Further information:

X.509

X.509 is a standard format for digital certificates. An X.509 certificate typically contains a public key, identity details (e.g. name, email, UPN) and a signature from a certification authority (CA) confirming this association.

An X.509 certificate can be stored on a smart card, whilst the private key remains securely on the card and never leaves the chip; applications use the certificate for identification and have cryptographic operations (signing/decryption) performed by the token.

PKI

PKI (Public Key Infrastructure) is the organisational and technical framework for managing digital identities and cryptographic keys via X.509 certificates. A PKI typically comprises certification authorities (CAs), policies and processes for issuing, renewing and revoking certificates, as well as the chain of trust through which systems verify the authenticity of a certificate.

PKCS#11, PKCS#15, Microsoft CSP/KSP, Minidriver

These terms cover how operating systems and applications utilise cryptographic operations on the card:

  • Microsoft CSP/KSP and Minidriver: Windows-specific provider models that can enable "seamless" integration into Windows workflows (already described above under PIV and GIDS).
  • PKCS#11: widely used API for cryptographic tokens (often relevant in Linux tools as well).
  • PKCS#15: Data/object structuring for cards (PINs, keys, certificates).

PKCS (Public-Key Cryptography Standards) methods were established already back in 1991 – of these, numbers 11 and 15 are the most relevant for smart cards.

See also:

Java Card and GlobalPlatform

Java Card describes cards capable of hosting applets. GlobalPlatform describes, amongst other things, the management of these applets (installation, lifecycle, security domains).

These are powerful platforms for implementing custom software solutions and security architectures – not simply plug-and-play cards.

OpenPGP Card

An OpenPGP Card is an application profile with a more narrow workflow: signing, decryption, authentication with GPG keys via OpenPGP/GnuPG. This constitutes a separate stack or tool landscape within the smart card sector.

EMV

EMV is a payment/bank card ecosystem (chip cards in the payment environment). EMV cards are "smart", but they are not suitable as generic authentication tokens for PC operating systems.

NXP, MIFARE, DESFire, NTAG and others

Many product names combine manufacturer branding, wireless standards and higher protocol layers in a single term.

  • MIFARE is a product brand of NXP, typically used in the contactless ISO/IEC 14443/NFC environment.
  • NTAG is an NXP NFC tag family.
  • MIFARE DESFire is a contactless product family (widely used in access control and ticketing applications).

None of these product names is inherently compatible with a pure ISO/IEC 7816 contact card reader – they are all contactless product families within the ISO/IEC 14443/NFC environment. They are only compatible with ISO/IEC 7816 if they are dual-interface cards – i.e. cards that also have a contact chip compliant with ISO/IEC 7816, preferably with a profile compliant with PIV or GIDS.

FIDO, FIDO2 and Passkeys

FIDO2 authenticators are typically available as USB, NFC or Bluetooth devices. A "FIDO SmartCard" can be many things, such as a dual-interface card with an additional FIDO function, but the FIDO label alone does not indicate whether such a card can be used in a traditional contact smart card deployment in accordance with ISO/IEC 7816. See the section at the end of the article:

Buying guide for smart cards

What types of cards can I use with an ISO/IEC 7816 contact card reader?

Our SCHENKER CONNECT 15 (E26) includes an ISO/IEC 7816 card reader. The following table provides information on the types of cards this card reader can handle.

Common Trade Name Hardware-Compatible with an ISO/IEC 7816 Contact Reader? Typical Windows Compatibility Practical Assessment
Contact PIV Card Yes Often very good, depending on minidriver and middleware support. Frequently the best choice for enterprise environments.
Contact OpenPGP Card Yes Good for GnuPG/OpenPGP workflows, but not automatically suitable for Windows logon. Very good if OpenPGP is the intended use case.
Dual-Interface PKI/FIDO Card (explicitly specifying ISO 7816 contact + ISO 14443 contactless) Yes, in contact mode Depends on the card profile and Windows integration stack. May work well; validate each feature (PKI, FIDO2, etc.) individually.
Contactless MIFARE / DESFire / NTAG / ISO 14443 / NFC-only Card No No (without a compatible contactless reader). Not suitable for use with a contact-only reader.
USB/NFC/BLE FIDO Security Key Not via a separate contact reader Used directly via USB/NFC/BLE with browser/OS support. Different device class; not a classic smart card.
“Blank” Java Card / GlobalPlatform Card Possibly (if it has a contact interface), but not usable out of the box Requires applets, personalization, and appropriate tooling. Intended for advanced or custom deployments only.

Isn't it enough simply to buy a card with a gold chip?

You can often tell straight away from product photos whether a card has a gold chip or not.

  • If a smart card does not have a "gold chip", it is definitely not a contact-based card in accordance with ISO/IEC 7816.
  • If, on the other hand, it does have one, then the card is obviously physically contact-based and thus most likely ISO/IEC 7816-compatible.

However, the specific workflows in which it will actually function depend on various factors:

  • which application profile the card actually supports (e.g. PIV, OpenPGP, proprietary PKI),
  • whether Windows has a suitable minidriver/middleware/provider for it,
  • and how your organisation provisions certificates, PINs and keys.

Therefore, the answer is: no – the gold chip alone does not guarantee that a smart card is compatible with the card reader in accordance with ISO/IEC 7816, nor that the card fits your organisation's application profile. You should therefore also filter for terms such as "7816", "PIV" or "Windows smart card logon".

Tools and software solutions for Windows

To handle smart cards on Windows, the general idea is this:

  • The card reader is addressed via the Windows Smart Card stack.
  • Applications access the system via PC/SC-related APIs or the Windows Crypto Provider models.
  • Card-specific functionality is provided via minidrivers, middleware or PKCS#11.

The following tools are commonly used in this context. The table contains links to the manufacturers' websites for some of the tools.

Tool Typical Usage Restrictions / Notes
certutil -scinfo Initial diagnostics: detect reader and card, display certificates and key containers, identify common configuration errors. Diagnostic purposes only; not intended for full provisioning or lifecycle management.
certreq, Certificates MMC, Enterprise PKI Workflows Certificate enrollment and deployment, installation, smart card logon scenarios in managed environments. Depends on proper card support (minidriver/CSP/KSP) and PKI infrastructure.
OpenSC Universal open-source toolkit for inventory, PKCS#11 access, PKCS#15 management, and various card operations. Compatibility varies by card family and firmware; functionality depends on card profile support.
OpenSC piv-tool Managing objects and keys on PIV cards; useful for testing and low-level PIV operations. Not intended as an end-user workflow; mainly for testing and development scenarios.
OpenSC pkcs15-init / pkcs15-tool Managing PKCS#15 structures, PINs, keys, and certificates on supported cards. Only relevant if the card and deployment model actually use PKCS#15.
GnuPG gpg-card / gpg --card-status Management and use of OpenPGP smart cards within GnuPG workflows. Not a generic solution for all card types; specific to OpenPGP-compatible cards.
GlobalPlatformPro Java Card management: loading applets and managing the GlobalPlatform lifecycle. Advanced use only; requires GlobalPlatform-capable cards and appropriate keys.
Manufacturer Minidriver / Middleware Windows integration for standardized or proprietary vendor PKI cards; often includes support and management tools. Typically ties the deployment to a specific vendor ecosystem.

Recommendations and practical examples

Now, we would now like to further explain a few practical use-cases for smart card technologies on PCs.

Quick test and diagnostics

Using certutil -scinfo, you can check whether the reader and card are recognised, which certificates/containers are present, and whether PIN prompts work. This is the quickest way to verify that the "reader/card is OK in principle" – without any servers or infrastructure.

Smart card for Windows logon and Office 365

Windows logon refers to logging in to a Windows client in a traditional domain environment or in modern variants such as Hybrid Join or Entra Join, typically in conjunction with a PKI and appropriate policies.

Services such as Microsoft Office 365, Teams or SharePoint also benefit from a smart card solution in the Windows logon process within such an environment, provided that login is managed centrally via Microsoft Entra ID.

In such setups, certificate- or smart card-based authentication via Entra Certificate-Based Authentication (CBA) can form part of the sign-in process, and the Microsoft 365 services subsequently receive their access authorisation via the resulting sign-in tokens.

Microsoft describes this application in the following articles:

Can I use smart cards for Windows login outside of a domain environment?

By design, smart card login in Windows is tightly coupled to domain or EntraID setups. Microsoft does not support smart card login for individual end users without a corporate connection – neither for offline accounts nor for personal Microsoft accounts (such as yourname@live.com).

SSH login with keys on the smart card

OpenSSH can use client keys on smart cards via PKCS#11, e.g. with OpenSC as a PKCS#11 module. This allows you to log in to any SSH destination without the private key ever leaving the token. SSH is commonly used for logging into Linux terminals, including NAS devices, Raspberry Pi and Virtual Private Servers (VPS).

Signing/decrypting S/MIME emails

Windows supports S/MIME for Exchange accounts; if the required certificate is stored on a smart card, Windows will prompt you to insert the card (and enter your PIN if necessary) when reading encrypted emails.

Mozilla Thunderbird can also use S/MIME and utilise certificates/private keys from a smart card. In practice, this is done via a PKCS#11 module (e.g. OpenSC), which you integrate into Thunderbird as a "Security Device" (see instructions).

VPN with certificate on smartcard/token (depending on the VPN client)

Some VPN clients support hardware tokens via PKCS#11. OpenVPN Connect, for example, can use certificates from PKCS#11 hardware tokens, which can be easily demonstrated if an OpenVPN destination already exists (or a test server is available).

Client certificates in the browser (mTLS)

Using a test web server that requires client certificates, you can clearly demonstrate the principle of "client certificate stored on the smartcard" (browser prompts for selection/PIN). See this article as an entry-point.

Can I use the online ID function of the German identity card with an ISO/IEC 7816 reader? (No.)

An exclusively contact-based smart card reader is not suitable for the online ID function (eID) of the German identity card (Personalausweis). The eID function explicitly requires a contactless reader compliant with ISO/IEC 14443 (NFC), such as those built into many smartphones. See also:

  • Bund.de > AusweisApp > USB Card Readers

Smart card's history and future use

Historical developments

The modern smart card, chip card or IC card has its roots in several, parallel lines of inventions. Patents by Helmut Gröttrup and Jürgen Dethloff relating to forgery-proof identification switches and contactless transmission in the 1960s are regarded as important foundations.

The year 1979 marked a milestone for the "credit card format" we are familiar with today: Giesecke+Devrient produced a chip card in ID-1 format in accordance with ISO/IEC 7810 (later also specified in ISO 7816-2 for chip cards), featuring a memory chip supplied by Siemens. At least in Germany, the term "chip card" first appeared in the public domain in 1981.

The evolution from simple memory cards to "smarter" processor-based smart cards came about through, among other things, the "Siemens Computer Card" (1987, unveiled at CeBIT); from 1988 onwards, it was used as an access credential for the German C-Netz network and is thus regarded as the precursor to the SIM card.

Further information:

What are passkeys/FIDO2 and how do they differ from smart cards?

FIDO2 passkeys describe a modern security standard for password-free login via USB, NFC, Bluetooth or Windows Hello. FIDO stands for "Fast IDentity Online".

FIDO2 consists of:

  • WebAuthn (browser/OS API)
  • CTAP (Client to Authenticator Protocol)

A classic smart card reader communicates with the card via APDU (Application Protocol Data Unit, defined in ISO/IEC 7816): the reader sends APDU commands to the card and receives APDU responses in return. Such a card reader does not include an implementation for CTAP and is therefore not recognised by the browser or operating system as a "FIDO authenticator".

However, some hardware tokens (USB tokens) combine PIV (certificates/PKI) and FIDO2 (WebAuthn/passkeys) in a single device.

The most important difference lies in phishing resistance: FIDO2/WebAuthn generates and uses keys per service/website and binds them to the domain name. A key for example.com, for instance, cannot be used on examp1e.com.

With traditional smart card infrastructures, phishing defence depends on additional security layers (TLS verification, UI prompts, policies) – unlike with FIDO2, it was not directly embedded into the protocol.

Further information:

Will traditional smart cards still be relevant in the future?

The trend in the mass market is clearly moving towards passkeys/FIDO2 (often via Windows Hello or USB/NFC keys), because this works without additional infrastructure and is more convenient for users. Microsoft explicitly positions passkeys as a future-proof alternative to passwords and is further expanding passkey support in Windows.

At the same time, contact-based smart cards compliant with the ISO/IEC 7816 standard remain relevant in the B2B and compliance sectors, as they form part of established PKI processes in many organisations (smart card logon, certificates, signatures, VPN, S/MIME). These infrastructures are not going to be replaced overnight but might find themselves to become modernised gradually.

A coexistence and hybrid model is the most likely scenario for the future. In the consumer and SMB sectors, passkeys, Windows Hello and FIDO2 keys are continuing to gain ground because they work without additional infrastructure and are available on virtually every modern device. For many users, this is the most convenient and, at the same time, phishing-resistant option for reducing or completely replacing passwords in everyday use.

In enterprise and regulated environments, however, smartcards and certificates remain relevant due to the already established infrastructure of PKI-based processes for login, signing, encryption, VPN and compliance verification.

At the same time, hybrid tokens are gaining in importance, combining multiple technologies in a single device, such as PIV/PKI and FIDO2. This allows organisations to migrate in parallel without changing the hardware in the user"s possession.