All posts
Engineering 1 March 2026 · 11 min read

NFC Passport Chips: The Identity Signal Nobody Fakes

Your passport has a computer inside it. A contactless chip, signed by your government, containing your name, date of birth, document number, and a cryptographic proof that none of it has been tampered with. We built a companion app that reads it. Here's why that changes everything about identity verification.

There's a Computer in Your Passport

Open your passport to the data page. See that little gold rectangle near the bottom? That's an ISO 14443 contactless smart card — the same technology as a transit card or a contactless credit card. Except this one was programmed by your government, carries your biometric data, and is cryptographically signed so that nobody can change a single byte without the forgery being detectable.

The standard is ICAO 9303, published by the International Civil Aviation Organization. It defines everything: the chip type, the data structures, the encryption, the certificate chain. Every ePassport issued since 2006 (and most since 2004) follows this standard. That's over 150 countries. Over a billion passports in circulation. All speaking the same protocol.

Most KYC providers ignore this chip entirely. They take a photo of the data page, run OCR, and call it a day. That's like having a notarized document and only reading the photocopy. The original, cryptographically signed data is sitting right there, millimeters away, waiting to be read. We decided to read it.

BAC: The Handshake

You can't just tap any NFC reader against a passport and start pulling data. The chip is encrypted. To read it, you need to prove that you're already holding the physical document — a chicken-and-egg that's elegant in its simplicity.

The protocol is called Basic Access Control (BAC). It works like this:

01

Read the MRZ

The two lines of machine-readable text at the bottom of your passport's data page. OCR or manual entry gives us the document number, date of birth, and expiry date.

02

Derive the key

Those three fields — document number, DOB, expiry — plus their ICAO check digits, are concatenated into a BAC key seed. This seed is hashed to produce the symmetric encryption key.

03

Mutual authentication

The reader sends a challenge encrypted with the derived key. The chip verifies it, responds with its own challenge, and a session key is established. All subsequent communication is encrypted.

Why this matters: BAC ensures that only someone with physical access to the passport can read the chip. You need to see the MRZ to derive the key. No MRZ, no access. A pickpocket with an NFC reader in a crowded train gets nothing.

In our flow, we already have the MRZ data from the document photo the user uploaded. The companion app receives the document number, DOB, and expiry via a deep link, computes the BAC key seed, and authenticates with the chip. The user just holds their phone to their passport for a few seconds.

What's on the Chip

Once BAC authentication succeeds, the chip exposes a set of Data Groups (DGs) — standardized files containing the holder's information. ICAO 9303 defines 16 possible data groups, but only two are mandatory:

Data Group Contents Status
DG1 MRZ data — name, DOB, nationality, document number, sex, expiry Mandatory
DG2 Face image (JPEG or JPEG2000, typically 15–30KB) Mandatory
DG3 Fingerprint minutiae Optional, restricted
DG7 Signature or handwriting image Optional
DG14 Iris biometrics Optional, restricted
SOD Security Object — cryptographic hashes + digital signature Mandatory

We currently read DG1 (identity data) and SOD (the cryptographic proof). DG2 face image extraction is in progress. DG3 and DG14 (fingerprints and iris) require Extended Access Control (EAC), which involves a more complex certificate exchange with the issuing country — that's a future milestone.

But DG1 + SOD alone is already transformative. DG1 gives us the same data as the printed MRZ, but read directly from the chip — no OCR errors, no image quality issues, no ambiguous characters. And SOD proves it hasn't been tampered with.

The Cryptography That Makes It Unfakeable

The SOD (Security Object of the Document) is the key to everything. Here's what it contains:

A

Hashes of every Data Group

The SOD stores a SHA-256 (or SHA-1 on older chips) hash of each data group. After reading DG1 from the chip, we hash it ourselves and compare. If they match, the data is exactly what was written at issuance.

B

Digital signature from the issuing country

The hash collection is signed by the country's Document Signer (DS) certificate, which chains up to the Country Signing Certificate Authority (CSCA). This is PKI at the nation-state level.

To forge this, an attacker would need to either break SHA-256 or obtain a country's private signing key. Neither of these is happening any time soon. You can buy a convincing fake passport on a darknet market for a few thousand dollars. You cannot buy a cryptographically valid chip.

Verification chain
CSCA (Country Signing CA)
  → DS Certificate (Document Signer)
    → SOD signature (proves hashes are authentic)
      → DG1 hash (proves identity data is authentic)
        → Your name, DOB, document number

We currently validate the hash chain (SOD hash vs actual DG1 hash). Full CSCA chain validation — verifying the DS certificate against the country's root CA — is on our roadmap. Even without CSCA, the hash validation alone catches any chip data modification, which is the most common attack vector.

What about chip cloning? A cloned chip would pass hash validation but fail Active Authentication (AA) — a challenge-response protocol that proves the chip's private key is present in hardware. AA is our next NFC milestone. For now, the combination of physical possession (BAC) + hash validation + cross-referencing against the photographed document makes cloning attacks impractical.

Why This Matters for KYC

Every identity verification system fights the same war: is this document real, and does it belong to this person? We have face matching, anti-spoofing, depth estimation, document fraud detection, rPPG pulse analysis. All of these are probabilistic signals. They produce scores. Confidence intervals. Fuzzy boundaries.

NFC chip data is deterministic. The hash either matches or it doesn't. The data either came from the chip or it didn't. There's no threshold to tune, no false positive rate to manage, no ambient lighting condition that degrades accuracy. It's binary. Cryptographic. Unforgeable.

No OCR errors — DG1 gives us the exact MRZ data as stored at issuance. No misread O/0, no I/1 confusion, no truncated names.

No document forgery — a photoshopped passport page won't have a matching chip. The chip data was written at the factory and hasn't changed since.

Cross-reference — we compare NFC chip data against our OCR-extracted data. If the chip says "JOHN SMITH" born 1990-03-15 but the document photo OCR says "JANE DOE" born 1985-07-22, that's an instant red flag.

Physical presence proof — BAC requires the MRZ. The user already uploaded a photo of the document. But the NFC read proves they physically held the passport against their phone. You can't NFC-read a photocopy.

In a pipeline full of probabilistic signals, NFC is the closest thing to certainty you can get without physically being in the room with the person.

The Companion App

NFC passport reading requires native platform access — you can't do it from a web browser. So we built a lightweight companion app for Android (iOS support in progress).

The flow is seamless:

1

Deep link from the KYC webapp

After uploading their document and selfie, the user is offered an optional "Verify with NFC" step. Tapping it opens the companion app via a deep link containing the session ID and the MRZ-derived fields needed for BAC.

2

Hold passport to phone

The app instructs the user to hold their passport against the back of their phone. A progress indicator shows each stage: detecting chip, authenticating, reading identity data, validating signatures.

3

Submit to API

The app sends DG1, SOD, and the raw MRZ to our API. The backend runs the consistency check, stores the encrypted chip data, and feeds the result into the trust engine. The entire process takes 5–10 seconds.

Under the hood, the app uses JMRTD (Java Machine Readable Travel Documents) — the reference implementation for ICAO 9303 — to handle the BAC handshake, chip communication, and data parsing. The native module runs on a background thread so the UI stays responsive even during the multi-second chip read.

Common failure: tag lost. Passport NFC antennas are embedded in the cover or data page. Phone NFC antennas vary by manufacturer. If the user moves the phone during the read, the connection drops and they need to retry. Our app handles this gracefully with a "hold still" prompt and automatic retry detection.

How NFC Feeds Our Trust Engine

FaceVault's trust engine computes a 0–100 trust score from multiple signals: face matching, anti-spoofing, document fraud detection. NFC data plugs into this as a modifier — it can boost or penalize the score based on what the chip reveals.

+

Full match — significant trust boost

CSCA validated + chip data matches the photographed document on all fields (name, DOB, document number). This is the strongest possible confirmation that the document is genuine and unmodified.

+

Partial match — moderate boost

CSCA validated but not all fields match (often due to OCR errors on the photographed document, not chip issues). Still a positive signal — the chip is genuine even if our OCR wasn't perfect.

+

No CSCA — small boost

Chip was read and hash validation passed, but we couldn't verify the country's signing certificate. Still better than no NFC at all — the data came from a real chip.

×

Contradiction — hard veto

CSCA validated but chip data contradicts the submitted document (different name, different DOB, different document number). This triggers an automatic reject regardless of all other signals. If a government-signed chip disagrees with the document photo, the photo is fake. Period.

The consistency check compares three fields: full name (using Jaccard token similarity to handle ordering differences), date of birth, and document number. The result is a 0–1 score that the trust engine uses alongside CSCA validation status to determine the modifier.

NFC is optional. Not every user has a passport (some verify with national IDs that don't have chips), and not every phone has NFC hardware. But when it's available, it's the single most powerful upgrade to verification confidence we've ever shipped.

What's Next

01

Full CSCA validation

Verify the Document Signer certificate against the issuing country's root CSCA certificate. This closes the trust chain from chip data all the way up to the government's root of trust.

02

Active Authentication

A challenge-response protocol that proves the chip hasn't been cloned. The chip signs a random challenge with its private key — a key that never leaves the hardware. This is the definitive anti-cloning measure.

03

DG2 face image extraction

Read the face image stored on the chip and compare it against the selfie. This gives us a government-enrolled reference photo — potentially more reliable than the printed passport photo, which degrades over time.

04

iOS companion app

Apple's Core NFC framework supports ISO 7816 tags (which ePassports use) since iOS 13. The protocol layer is identical — it's the platform integration and App Store review process that takes time.

The passport chip is the most underutilized signal in identity verification. It's been sitting there for two decades, cryptographically signed, waiting for someone to read it. We're reading it now. And with each milestone — CSCA, Active Auth, DG2 — the signal gets stronger.

References & Further Reading

ICAO 9303 Part 11 — Security Mechanisms for MRTDs

JMRTD — Java Machine Readable Travel Documents — the open-source library we use for chip communication

From 3 Signals to 10: How We Rebuilt Document Fraud Detection — the fraud pipeline NFC enhances

How FaceVault Verifies a Face in Under 30 Seconds — the full ML pipeline