MIFARE Classic 1K / 4K

Family and part numbers

Few chips have been pronounced dead as often, or as publicly — and fewer still have been so cheerfully unbothered by the obituaries. MIFARE Classic has a broken cipher and a well-signposted migration path, and it is nonetheless still riding in hotel key cards, office badges and student IDs the world over. This encyclopedia treats it as what it actually is: a legacy workhorse you will keep meeting in the field for years, and one whose every quirk rewards being understood before you specify it. NXP ships MIFARE Classic under a small cluster of part numbers that look confusing at first but resolve into two capacity tiers (1K and 4K), two silicon generations (pre-EV1 and EV1), and a Mini variant that most modern programs have already migrated off. Getting the part number right at procurement time matters because counterfeit and clone silicon is widespread in the 13.56 MHz HF market. The bill-of-materials line that says 'MIFARE Classic 1K' can silently land as Fudan FM11RF08 or Huahong SHC1102 from an unauthorised distributor, and while the air-interface compatibility is often adequate, edge-case behaviour around UID writability, authentication timing and counterfeit detection can diverge in ways that audit teams and access-control integrators notice later.

• MIFARE Classic 1K — NXP part number MF1S50 (or MF1ICS50 on older silicon). 1024 bytes of user-accessible EEPROM organized as 16 sectors of 4 blocks each. The volume chip for hotel key cards, building access, student ID, and low-end loyalty.
• MIFARE Classic 4K — MF1S70 / MF1ICS70. 4096 bytes organized as 32 small sectors (4 blocks each) plus 8 large sectors (16 blocks each). Used when a single card carries multiple independent applications (building access + canteen payment + printer quota).
• MIFARE Classic EV1 — MF1S50yyX/V1 and MF1S70yyX/V1. Refresh launched 2014 with improved EMC, Common Criteria EAL4 certification on the hardware (not the CRYPTO1 cipher), and a 7-byte UID option. Functionally identical API; protocol backwards-compatible with pre-EV1 Classic.
• MIFARE Classic Mini: MF1ICS20. 320-byte cut-down variant. 5 sectors. Rare in current deployments; most vendors have migrated this tier to MIFARE Plus S or NTAG213 depending on application.
• Clones and compatibles: Fudan FM11RF08, Shanghai Huahong SHC1102, and numerous 'MIFARE-compatible' Chinese die designs exist. Most implement CRYPTO1 and the 14443-A layer compatibly, with UID read-only enforcement varying by silicon. UID-changeable clones (sometimes sold as 'Chinese magic cards' or 'UID-writable') are pentest tools and are rejected by most commercial access systems that UID-whitelist their cards.
• Counterfeit watch: authentic NXP Classic returns SAK = 0x08 (Classic 1K) or 0x18 (Classic 4K) and ATQA = 0x0004 / 0x0002 respectively. Block 0 manufacturer data begins with the NXP mask ID byte 0x04 on 7-byte UID silicon. Incoming-inspection should sample-read these three values against a known-good reference.
• Distribution channel: authentic NXP silicon flows through Arrow, Avnet, Digi-Key, Mouser and authorised regional distributors; 'too-good-to-be-true' Shenzhen spot-market pricing (US$0.06–0.08 per MF1S50 inlay vs a typical US$0.11–0.18 authorised-channel price) almost always signals Fudan or Huahong die in an NXP-printed tape-and-reel. For any hotel, enterprise or government deployment, require the supplier to provide the authorised-distributor invoice chain and NXP lot codes on the packing list.
• Chip-level lot codes. Every authentic NXP wafer carries a 4-character date code and 6-digit lot code laser-marked on the chip back; genuine MIFARE Classic EV1 silicon from 2023 onwards carries an ECC signature readable via the proprietary READ_SIG command (offered by NXP as a hardware anti-cloning signal that clone silicon cannot forge without NXP's private signing key). Deployments that need strong anti-counterfeit provenance should verify the ECC signature at personalisation rather than relying on SAK/ATQA alone.

Memory architecture

The sector-and-block memory layout is the feature that made MIFARE Classic durable in the market even after CRYPTO1 was broken. Per-sector keys let a single card host multiple independently-administered applications (a hotel's room-access sector, a chain's loyalty stamp sector, a franchise printer-quota sector) without any of those tenants needing to trust the others. Understanding the memory map matters because every deployment decision downstream (which sector to use for UID mirroring, which keys to rotate, which blocks to lock with Key B for write-protection) maps back to this structure, and getting the map wrong at personalisation is one of the most expensive mistakes to correct later because it requires reissuing cards.

• 1K memory layout — 16 sectors, sector index 0-15. Each sector = 4 blocks × 16 bytes = 64 bytes. Sector 0, block 0 is the Manufacturer Block (UID + NXP data, permanently locked). Blocks 1-2 of every sector are data blocks. Block 3 of every sector is the Sector Trailer (Key A + access bits + Key B).
• 4K memory layout: sectors 0-31 are small sectors (4 blocks × 16 bytes = 64 bytes each); sectors 32-39 are large sectors (16 blocks × 16 bytes = 256 bytes each). Total user-accessible = 3,840 bytes data + Sector Trailers. Large sectors are the right home for value-block-heavy applications (transit rides, canteen points).
• Sector Trailer format: bytes 0-5 = Key A (6 bytes, write-only after personalization), bytes 6-9 = access bits (3 bytes + inverted copy for tamper detection), bytes 10-15 = Key B (6 bytes, readable depending on access-bit configuration). Per-sector keys mean losing or compromising one sector's key does not expose the rest of the card.
• Value Blocks: a special block format holding a 4-byte value (twice inverted for redundancy) plus a 1-byte address. Supports atomic Increment, Decrement, Restore, Transfer operations. Useful for loyalty stamp counters and stored-value wallets where the increment/decrement must be transactional.
• Data Blocks: general-purpose 16-byte blocks. Read via Read(block_addr) after authentication. Write via Write(block_addr, 16 bytes). Reads and writes are plaintext over the air but only after successful CRYPTO1 authentication for the containing sector.
• Personalization workflow: virgin Classic cards ship with Key A = Key B = 0xFFFFFFFFFFFF (factory default), access bits = 0xFF 0x07 0x80 (the 'transport' configuration). Site personalization writes the operator's sector keys and access bits to replace the defaults; from that point forward only authenticated readers can access that sector.
• Non-user-accessible storage. Classic has no scratch RAM; all state lives in EEPROM. Data retention ≥ 10 years; write endurance ≥ 100,000 cycles per byte (NXP datasheet).
• Block-0 writability — on authentic NXP silicon, block 0 (the manufacturer/UID block) is permanently locked at wafer sort and cannot be overwritten under any key. On Chinese-magic cards (FUID, CUID, ZUID, UFUID variants), block 0 is writable either unconditionally or via a proprietary backdoor command (0x40/0x43). Access-control deployments that UID-whitelist against a known card fleet must treat these magic cards as a cloning-class threat and cannot rely on UID uniqueness alone.
• Access-bits format: the 3 bytes of access bits plus their inverse form a 6-byte bit pattern encoding C1, C2, C3 for each of the 4 blocks in the sector. There are 8 possible per-block configurations and 16,384 theoretically valid sector-trailer combinations, but only ~8 are practically used in deployment (transport default, read-all-A, write-with-B-only, value-block-pair, etc). NXP AN1304 documents the common configurations; getting the access-bits wrong can leave a card in a state where no key can ever write to it again, which is the single most common personalisation error for new operators.
• Value-block address byte. The 1-byte address field in a Value Block (byte 12, mirrored at byte 14) is an operator-defined address that Increment/Decrement/Restore reference. Typical use is storing the block address of the value block itself, so that a compromised block can self-identify; any reader receiving a Value Block whose address byte doesn't match its own block number should reject it as tampered.

CRYPTO1 cipher and 3-pass authentication

CRYPTO1 is the element of MIFARE Classic that now dominates its design conversation. Not because the cipher works, but because its breakage is the single most important fact about deploying Classic today. Anyone specifying, maintaining or auditing a Classic-based system needs a working mental model of how CRYPTO1 is attacked, because the attacks are not theoretical: they are implemented in free open-source tools that run on USD$50 hardware, and they recover sector keys from cards in seconds. The 2026 question is no longer 'is CRYPTO1 broken' but 'does our threat model tolerate cards that are trivially cloneable', and the answer drives migration decisions more than any other single factor in HF chip planning.

• CRYPTO1 — NXP-proprietary stream cipher with a 48-bit state and 48-bit key. Published for the first time via reverse engineering (Nohl, Plötz) in 2007-2008, with full cryptographic breaks published 2008-2009 (nested-authentication attack) and strengthened in 2014-2015 (darkside / hardnested).
• Authentication handshake — 3-pass nested protocol. (1) Reader sends Authentication-A (0x60) or Authentication-B (0x61) with target block. (2) Tag replies with nT, a 32-bit nonce. (3) Reader computes the expected tag-authentication-response using the sector key and sends it, along with its own nonce nR. (4) Tag verifies, generates the combined authentication-response using both nonces, and replies.
• From 2008 onwards CRYPTO1 is considered practically broken. Nested attack recovers subsequent sector keys in seconds after the first key is known. Darkside attack recovers the first key in <1 minute on an unprepared card. hardnested attack works on EV1 hardware that fixes the nested weakness. Open-source tools (mfcuk, mfoc, libnfc, proxmark3 scripts) implement all three and are widely available.
• Security posture for 2026 — Classic is unsuitable for any application where cloning has meaningful cost. Migrate to MIFARE Plus (AES-128 with CRYPTO1 compatibility mode) for drop-in reader compatibility, or to DESFire EV3 (AES/3DES, file-level access control) for greenfield deployments.
• Mitigations that do not work. UID-based verification alone is insufficient because UID-changeable clones exist. Anti-cloning is only provided by actually authenticating with AES-grade keys; CRYPTO1 cannot be retrofitted to be secure.
• Mitigations that do work. Issuing cards in mixed modes on MIFARE Plus so that reader fleets can be upgraded gradually; monitoring for anomalous authentication patterns server-side; short-validity card cycling. None of these make Classic itself secure. They bound the blast radius.
• Attack-time benchmarks: darkside attack on a fully default-keyed card: 30–90 seconds on a Proxmark3 RDV4. hardnested attack on EV1 silicon once one key is known: 2–10 minutes to recover the 15 remaining sector keys on a 1K. Full card dump including value blocks: under 15 minutes for an attacker with physical proximity for 5+ seconds. These numbers have only improved since 2015 as open-source tooling has been optimised.
• MIFARE SAM AV3 pairing — enterprise deployments that need to keep Classic on the card side for legacy reader compatibility often pair the issuance workflow with a MIFARE SAM AV3 in the encoder (Secure Access Module, hardware HSM with key-diversification and offline authentication). This doesn't fix CRYPTO1 in the card, but it prevents raw sector keys from ever leaving the SAM, removing the 'stolen laptop with keys in a text file' failure mode that produces many real-world breaches.
• Detection vs prevention: server-side anomaly detection (same card at two locations within an impossible travel window, repeated authentication failures on the same UID, sudden large-value transactions on stored-value sectors) is the most cost-effective layer to add to an existing Classic deployment. It doesn't stop cloning, but it bounds the operational impact from unlimited to single-digit incidents.

ISO 14443-A Part 3 compliance

MIFARE Classic predates ISO/IEC 14443 Part 4 (the T=CL transmission protocol layer used by DESFire and by contactless payment cards) and never adopted it. Classic implements Parts 1-3 only — physical characteristics, RF signaling and initialisation/anti-collision — and wraps its own proprietary command set directly over the Part 3 layer. This decision has practical consequences for reader implementation (any Classic-capable reader has to include NXP's proprietary CRYPTO1 stack, not just a generic 14443 kernel) and for card-to-card coexistence (Classic cards sharing an antenna field with Type-4 cards route cleanly because Parts 1-3 are standard, even though Classic then diverges into proprietary territory).

• Classic implements ISO/IEC 14443 Parts 1-3 — physical characteristics, RF signal interface, and initialization/anti-collision. It does NOT implement Part 4 (T=CL transmission protocol). Readers interact via raw 14443-A commands wrapped in sector authentication.
• ATQA / SAK / UID: ATQA = 0x0004 (Classic 1K) or 0x0002 (Classic 4K). SAK = 0x08 (1K) or 0x18 (4K). UID returned via the anti-collision loop before any CRYPTO1 authentication; readers can use this to identify a card prior to key-based access, but UID alone is not an authentication.
• 4-byte vs 7-byte UID. Pre-2013 Classic silicon used a 4-byte UID (32 bits of entropy). Post-2013 silicon (Classic EV1 and later production batches) uses a 7-byte UID (56 bits of entropy). Deployments that enrolled UID-based whitelists on 4-byte UIDs encountered collisions in installed bases over 100k cards; 7-byte UID migration resolved this.
• RF operating range — 0-10 cm for typical reader/antenna combinations. Power budget determined by the reader's field; the chip itself is passive with no internal power source. Effective range in practice is determined by antenna geometry on both sides and by card material (metal inserts, wet surfaces reduce range).
• Interoperability: every 14443-A-capable reader shipped since 2000 can initialize a Classic card. Whether it can authenticate and read depends on whether the reader exposes the CRYPTO1 stack; virtually all access-control and transit readers do.
• Typical reader part numbers. ACR122U (USB PC/SC, desktop, supports CRYPTO1 via pseudo-APDU), ACR1252U (USB + BLE, higher throughput), HID OMNIKEY 5022/5422, Feitian bR500, Identiv SCM uTrust 4701 F, and PN532/PN5180 module-level NFC readers commonly used in embedded designs. Android phones with a PN7xx or similar NFC controller can read 14443-A UIDs natively but cannot perform CRYPTO1 authentication because the proprietary cipher is not exposed through the Android NFC API. This is why consumer NFC apps can read a Classic UID but not unlock its sectors.
• Collision handling for multi-card populations. Part 3's anti-collision loop uses a binary search over the 4-byte (or 7-byte) UID. A reader in a field with 8+ cards typically resolves all UIDs within 100-200 ms. Gate readers that expect single-card presentation should reject multi-card responses (commonly reported as collision error 0x03 or higher); tap-point readers that accept multi-card presentation (library self-checkout, laundry tunnels) iterate the anti-collision loop until all UIDs have been enumerated.

Antenna, physical, and environmental

The chip itself is only half the story. The antenna tuning, substrate and environmental exposure determine whether the card works at the tap point every time or only sometimes. Classic's electrical parameters have been frozen long enough that the antenna libraries in every major inlay converter (Smartrac/Avery Dennison, Invengo, LAB ID, Identiv, Xindeco) ship with well-characterised designs for standard form factors. The failure modes in the field are almost never about chip behaviour; they are about substrate choice, environmental exposure, and operator mistakes at lamination or laser-engraving stages that detune the antenna. When a card fails at the tap point, the chip is rarely the guilty party; the laminator, the foil-stamp artwork, and the RFQ that quietly skipped the environment question do most of the damage.

• Chip impedance at 13.56 MHz — approximately 17 pF effective capacitance + series ESR around 50 ohms at the chip pad. Standard ISO ID-1 PVC inlays use a 3.5-turn rectangular antenna tuned to resonate with this capacitance.
• Form factors: ID-1 card (85.6 × 54 × 0.76 mm), keyfob, wristband silicone/PPS, sticker (38 mm circular for HF is common). The chip is identical across form factors; the antenna is retuned for each substrate.
• Operating temperature — -25 °C to +70 °C for the standard MF1S50 and MF1S70. Storage range -40 °C to +85 °C. For laundry-resistant deployments (up to 90 °C tunnel wash) choose a Classic-on-silicone wristband or PPS-encapsulated tag rather than a PVC card.
• Durability: ISO 10373 bend, torsion, and impact tests. 100k bending cycles without chip failure when embedded in 0.76 mm PVC. ISO 14443 RF durability typically exceeds 100k read cycles.
• Incompatibility with metal: like all 13.56 MHz HF chips, Classic requires a ferrite spacer of 0.3+ mm to function on metal surfaces. Without the ferrite the antenna Q-factor collapses and the chip cannot power up.
• Laundry and sterilisation exposure. Classic-on-silicone wristbands and PPS (polyphenylene sulfide) tags tolerate 200+ wash cycles at 90°C in industrial laundry tunnels, and up to 1000 autoclave cycles at 134°C for sterile-environment deployments (hospital linen, operating-theatre reusables). PVC cards survive none of these. They warp at 75°C and delaminate after 30-50 dishwasher cycles. Match the form factor to the environment at the RFQ stage, not at the pilot.
• Detuning by print and lamination. Metallic foil stamping that crosses the antenna loop drops read range by 40-60%; heavy metallic-pigment offset inks (silver, gold, copper) over the antenna drop range 15-30%. Artwork should specify the chip footprint as a no-print keep-out zone, and the supplier should retune the antenna after any lamination change (thickness, adhesive type, polymer).
• ESD and field exposure. Classic silicon is rated to JEDEC JESD22-A114 Human Body Model 2 kV and IEC 61000-4-2 contact discharge 4 kV. Real-world ESD events at gate readers (dry winter lobbies, 8-12 kV static carried on shoes) occasionally damage cards at the antenna bond pads; deployments in arid climates often add a passive ESD-clamp coil to the card design.

Commercial deployments and application fit

Despite the CRYPTO1 break, MIFARE Classic remains in volume production because the installed base of readers, locks, turnstiles and personalisation stations is enormous and slow to migrate. A 2026 deployment specifying Classic is almost always doing so for a specific compatibility reason. A legacy hotel-lock firmware that only supports Classic, a budget-constrained student-ID programme where the threat model genuinely tolerates cloning, or a phased migration where Classic-compatible Plus cards are being rolled in slowly. Outside those specific cases, new deployments should skip directly to Plus or DESFire; the chip-cost delta is pennies and the security delta is decades.

• Hotel key cards: the dominant HF chip for hotel locks deployed 2005-2020 (Saflok, Onity, Assa Abloy, Kaba). New builds since ~2018 increasingly migrate to DESFire EV3 because of the CRYPTO1 break; Classic remains in legacy deployments and in budget-focused new installations where the operator accepts the cloning risk.
• Public transit: MIFARE Classic was the backbone of dozens of city transit cards (London Oyster 1st-gen, NL OV-chipkaart 1st-gen, HK Octopus legacy, many East-European systems). All major transit operators have now migrated to MIFARE Plus or DESFire; Classic is primarily a compatibility layer in 2026.
• Corporate access control: commonly deployed 2000-2015. HID Mobile Access, Assa Abloy HID Signo, and similar next-generation readers still accept Classic as a legacy credential type; new rollouts specify Plus or DESFire or mobile-credential BLE.
• Student ID and membership cards. Classic remains price-competitive for low-threat-model uses where cloning is unlikely to have financial impact. Universities with library-checkout + printer-quota workflows on Classic cards continue renewing the fleet in place.
• Loyalty and stored-value. Value Blocks are used for canteen-point stored-value and loyalty stamp counters. For programs where the stored value is nominal (small balance, replenished centrally), Classic is acceptable; for higher-balance wallets, migrate to DESFire EV3 with AES-protected files.
• Where Classic is NOT the right choice. Financial-grade payment, building access for high-security premises, any greenfield deployment where the procurement team has the option to specify Plus / DESFire. The marginal chip cost delta is a few cents; the security delta is an order of magnitude.
• Migration partners: NXP's recommended migration path is MIFARE Plus EV2 (drop-in CRYPTO1 compatibility mode + AES security level) or DESFire EV3 (full file-system-based AES). Plus allows one-step reader-firmware updates on existing installed bases.
• Government and regulated deployments. Several national ID and transit programmes that originally launched on Classic (early Netherlands OV-chipkaart, Korea T-money, Taiwan EasyCard, China 'Yikatong' city cards, the UK's defunct first-generation Oyster) have since migrated to DESFire or proprietary AES-based chips. Any 2026 greenfield government deployment specifying Classic should be flagged in procurement as a security-policy anomaly needing explicit sign-off from the programme's CISO.
• Event and festival access. Classic-on-silicone wristbands remain common at festivals, conferences and cruise-ship all-inclusive passes because the threat model (a 3-day event, printed UID whitelist, observable-fraud detection at gates) tolerates known crypto weaknesses. For these deployments the right question is not 'is CRYPTO1 secure' but 'does a cloned wristband cause measurable harm in a 72-hour window', and the answer is usually no.
• Value-block stored-value today. Payment-grade stored-value on Classic is no longer acceptable anywhere that touches real money; PCI-DSS and PSD2 obligations in the EU, combined with CPSS-IOSCO guidance for closed-loop prepaid, effectively rule it out. Classic Value Blocks are still acceptable for non-cash point-counters (gym access credits, library fine balances, children's arcade token balances) where an incident is an operational inconvenience rather than a financial loss.

NXP and ISO reference documents

The reference material for MIFARE Classic is scattered across NXP's public documentation, NXP's under-NDA product data sheets, ISO standards (14443-3 and related) and a substantial academic literature on CRYPTO1 cryptanalysis. Anyone maintaining a Classic deployment should have the short list below bookmarked, because specifications change version-to-version in ways that matter (7-byte UID introduction, EV1 silicon hardnested mitigation, OEM anti-cloning signature features) and relying on second-hand summaries on forum posts or Wikipedia is a common source of deployment misconfigurations.

• NXP MF1S50 / MF1S70 Product Data Sheet. The canonical reference. Block diagram, memory map, command set, electrical characterization, timings. Publicly available from NXP under NDA for the detailed version; a public short version exists.
• NXP AN10922 — MIFARE Classic default keys and anti-cloning guidance. Acknowledges the known CRYPTO1 weaknesses and documents the recommended migration paths.
• ISO/IEC 14443-3:2018 — the air-interface standard Classic implements. Parts 1-3 define the physical layer, RF signaling, initialization and anti-collision; Classic does not use Part 4.
• NXP AN1305 — MIFARE Classic to MIFARE Plus migration guide. Describes Plus's SL1 / SL3 security-level mechanism and the key-rollover flow that lets an installed reader fleet upgrade without re-issuing cards.
• Radboud University MIFARE Classic security analysis (2008). The first public end-to-end cryptanalysis of CRYPTO1. Establishes the theoretical and practical basis for the nested, darkside, and hardnested attacks.
• Proxmark3 community scripts for Classic. Practical reference for UID cloning, key recovery and sector dumping, used by pentest teams to validate Classic-based access-control installations.
• NXP MIFARE Application Directory (MAD) specification — AN10787. Defines the optional sector-0 directory structure used for multi-application cards, with application identifiers administered by NXP. Relevant for transit-plus-loyalty deployments that want to host multiple independent applications on one Classic card without collision.

Command set and typical personalisation flow

Classic's proprietary command set is small and uniform across 1K and 4K. A full personalisation sequence for a new card fleet is maybe 12 distinct commands, and most deployment errors are at the access-bits level rather than the command level. Integrators writing issuance scripts for ACR122U, HID OMNIKEY 5022 or Feitian bR500 encoders typically find that the command set is the easy part; the hard part is auditing that the access-bits configuration they wrote actually matches the policy they intended to implement.

• Core commands: Request (0x26 for REQA, 0x52 for WUPA), Anticollision (0x93 for cascade level 1, 0x95 for cascade level 2 on 7-byte UIDs), Select (0x93/0x95 with UID), Authentication A (0x60, followed by sector key) and Authentication B (0x61), Read (0x30 + block), Write (0xA0 + block + 16 bytes), Increment (0xC1), Decrement (0xC0), Transfer (0xB0), Restore (0xC2), Halt (0x50).
• Authentication bytes on the wire — 0x60 or 0x61 (opcode), block number (1 byte), CRC (2 bytes). The card responds with a 4-byte nonce nT. The reader then replies with its nonce nR (4 bytes) plus the 4-byte authentication response aR computed from the sector key. The card finally sends its authentication response aT (4 bytes). After step 3, the link is encrypted under CRYPTO1.
• Personalisation recipe for a virgin card. (1) anti-collide and select UID, (2) authenticate every target sector with factory default key 0xFFFFFFFFFFFF, (3) write operator Key A and Key B into the sector trailer with custom access bits, (4) verify each sector by authenticating with the new keys, (5) lock block-0 read via Key B if the deployment needs anti-UID-leak at the reader side. Get step 3 wrong and the sector becomes inaccessible forever on authentic NXP silicon.
• Transport configuration: NXP ships cards with access bits 0xFF 0x07 0x80 0x69. This permits all operations with Key A or Key B (both 0xFFFFFFFFFFFF). Deployments must replace this configuration at first-use personalisation; leaving cards in transport state at gate readers is functionally equivalent to no security at all.
• SAM-assisted issuance: with a MIFARE SAM AV3, the encoder calls SAM_Authenticate_MFP and SAM_ChangeKeyMIFARE rather than handling raw keys in the encoder's memory. Keys are derived per-card from a master key stored in the SAM, so compromising an encoder does not compromise the key tree. NXP publishes the SAM command set in AN10957 and AN12343.
• PCSC wrapping: on PC/SC readers (ACR122U, OMNIKEY, Feitian), Classic commands are wrapped in PCSC pseudo-APDUs with CLA=0xFF. Example authenticate: FF 86 00 00 05 01 00 <block> 60 <key_slot>. Example read: FF B0 00 <block> 10. Integrators moving from raw PN532 to PC/SC have to remap their command stream; the underlying card behaviour is identical but the host-side API differs.

Specifications at a glance

FAQ