ePassport NFC Verification: ICAO 9303 Chip Checks

A photo of a passport can be edited, printed or generated, but the chip inside an ePassport carries data digitally signed by the issuing State, and checking that signature is one of the strongest remote identity proofing signals available. ePassport NFC verification means reading the contactless chip with a phone or reader, opening it with the access protocol defined by ICAO Doc 9303, and validating the issuer's signature back to the State's Country Signing Certificate Authority (CSCA). This guide explains the ICAO 9303 mechanisms (BAC, PACE, Passive, Active and Chip Authentication), how CSCA trust lists work, and how to build a mobile NFC flow that a KYC or digital identity assessor will accept. It is for identity proofing architects, KYC product owners and fraud teams. It goes deeper than the NIST SP 800-63A-4 Identity Proofing Guide, which covers the wider proofing framework.

Key takeaways

Passive Authentication is the check that matters most. It proves the chip data was signed by a Document Signer whose certificate chains to the issuing State's CSCA; without it, NFC reading adds little over an image.
Trust is a list you manage. You need current CSCA certificates (for example from the ICAO Master List or bilateral sources) and revocation data, refreshed on a schedule, with your own trust policy.
Cloning needs a separate check. Passive Authentication does not stop a copied chip; Active Authentication or Chip Authentication proves the chip holds a private key that cannot be read out.
PACE is the modern access protocol. BSI TR-03110 describes PACE as the replacement for Basic Access Control, and Doc 9303 Part 11 says PACE shall be used where both chip and reader support it; support both, because older passports remain in circulation.
Chip checks prove the document, not the person. Pair them with a face comparison against the chip photo, with liveness, to bind the document to the person presenting it.

What it is and who it applies to

ICAO Doc 9303, Machine Readable Travel Documents, is the specification for passports and other travel documents used by ICAO member States. ICAO's publication page lists 13 parts; the ones that matter for chip reading are Part 10 (Logical Data Structure for storage of biometrics and other data in the contactless IC), Part 11 (Security Mechanisms for MRTDs) and Part 12 (Public Key Infrastructure for MRTDs). Part 13 covers Visible Digital Seals.

Who uses chip verification:

Border and government inspection systems: the original audience for Doc 9303.
Regulated KYC: banks, payment firms, crypto platforms and gambling operators onboarding customers remotely. See the Identity Proofing and KYC Guide.
Digital identity providers: UK Good Practice Guide 45 (GPG 45) gives evidence protected by cryptographic security features a strength score of 3, and cites biometric passports that meet the ICAO specifications as an example of score 4 evidence where all digital information is cryptographically protected and the issuer can be identified.
US federal and NIST-aligned services: NIST SP 800-63A-4 lists cryptographic verification of the source and integrity of digital evidence as a validation method, and requires SUPERIOR evidence to carry cryptographically protected data validated by verifying the issuer's digital signature.

Structure and key requirements

Data on the chip

The chip holds a set of data groups defined in Part 10 and a Document Security Object (SOD). The data groups most relevant to proofing are DG1 (the MRZ data) and DG2 (the stored face image; Part 11 names the MRZ and the face image as the mandatory minimum data), DG14 (Chip Authentication public key information, where supported) and DG15 (the Active Authentication public key, where supported). Part 11 describes the SOD as digitally signed by the issuing State and containing hash representations of the data groups; the signature is checked with the Document Signer public key.

Security mechanisms

Mechanism	What it does	Threat it addresses	Proofing relevance
Basic Access Control (BAC)	Derives access keys from a SHA-1 hash of MRZ data (document number, date of birth and date of expiry, with their check digits) so the reader must see the data page first	Casual skimming and eavesdropping	Needed to read older passports; Part 11 notes PACE gives higher entropy session keys
PACE	Password Authenticated Connection Establishment using MRZ data or the Card Access Number (CAN) to set up a stronger secure channel	Skimming and eavesdropping, with stronger keys than BAC	Preferred when the chip supports it
Passive Authentication	Verifies the SOD signature, the Document Signer certificate chain to the CSCA, and data group hashes	Altered or forged chip data	Core integrity and authenticity check
Active Authentication	Chip signs a reader challenge with a private key whose public key is in DG15	Cloning of chip data onto another chip	Anti-cloning evidence
Chip Authentication	Key agreement using the chip's key (DG14), proving the chip is genuine and establishing strong secure messaging	Cloning and weak session keys	Anti-cloning evidence, part of Extended Access Control
Terminal Authentication	Reader proves it holds a certificate authorised by the issuing State	Unauthorised access to sensitive data (for example fingerprints)	Usually not available to private sector readers; not needed for face and MRZ data

BSI Technical Guideline TR-03110 (Advanced Security Mechanisms for Machine Readable Travel Documents and eIDAS Token) specifies PACE, Extended Access Control (Terminal Authentication plus Chip Authentication) and further mechanisms used by European documents. BSI describes Chip Authentication as verifying that the chip is genuine and enforcing strong encryption and integrity protection for transmitted data.

The PKI behind Passive Authentication

Doc 9303 Part 12 sets out the trust model. Each issuing State establishes a single CSCA as its national trust point. The CSCA issues Document Signer certificates, and a Document Signer signs the data stored on each passport. Part 12 recommends that a Document Signer private key signs documents for a short period (it cites three months), with the certificate valid for that period plus the life of the longest-valid passport signed. All CSCAs must publish Certificate Revocation Lists, at least every 90 days. Part 12 also states that a failed electronic check means electronic verification failed, not that the document is invalid; other inspection methods may then apply.

Identity and NHI requirements

A chip verification service depends on several machine identities and trust stores, and these are where operational failures usually start.

CSCA trust store: the set of CSCA certificates you accept. The ICAO Master List is a digitally signed list of CSCA certificates from ICAO PKD members, signed with an ICAO Master List Signer certificate that is itself signed by the United Nations CSCA. ICAO says the March 2026 version contains 547 certificates, is updated at three-monthly intervals as appropriate, and that each receiving entity must set its own policy for trusting the certificates. Part 12 adds that trust in an initial CSCA key must be established out of band.
Revocation data: CSCA CRLs must be fetched and checked against each Document Signer certificate. Treat a stale CRL as a failure condition for high-assurance decisions. See the Certificate Revocation Guide.
Server-side verification keys and credentials: if the mobile SDK sends the SOD and data groups to a backend for validation, the backend's API credentials, signing keys for results and the trust store itself are high-value non-human identities. Store them in a secrets manager, rotate them and limit who can change the trust store.
Result integrity: sign or MAC the verification result returned to the relying application so it cannot be forged by a tampered client. Never accept "chip verified: true" from the device without server-side checking.
Terminal certificates: where an organisation is authorised for Extended Access Control, Terminal Authentication certificates are issued under the document issuer's PKI and must be protected like any private key.

See the Machine Identity, PKI and Certificate Lifecycle Guide for the lifecycle discipline that applies to these keys.

Implementation steps

Capture the MRZ: the app reads the data page MRZ by camera (OCR) to obtain the document number, date of birth and date of expiry needed for BAC or PACE. Validate MRZ check digits before attempting NFC.
Guide the NFC read: show the user where to place the phone (the chip is often in the back cover or data page). On iOS the app needs the NFC tag reading capability and the ISO 7816 application identifier entitlement listing the eMRTD application; on Android the IsoDep technology class handles ISO 14443-4 communication.
Open the chip: attempt PACE first where the chip advertises it, then fall back to BAC. Log which protocol succeeded.
Read data groups: read the SOD, DG1, DG2 and, where present, DG14 and DG15. Do not read data groups you do not need.
Run anti-cloning checks: perform Chip Authentication or Active Authentication when the chip supports it, and record the result. Absence of support on an older document is not fraud, but it lowers assurance.
Validate on the server: send the raw SOD and data groups to the backend. Verify each data group hash against the SOD, verify the SOD signature, build the path from the Document Signer certificate to a trusted CSCA, and check revocation.
Cross-check visual and chip data: compare DG1 with the OCR of the printed data page. Any mismatch is a strong fraud signal.
Bind the person: compare a live selfie with the DG2 face image, with presentation attack detection. See the Biometric Liveness and Presentation Attack Detection Guide.
Check validity: confirm the document has not expired and, where you have access, check lost and stolen sources; GPG 45 cites Interpol as an example of a database of cancelled evidence.
Record the decision: store the outcome of each check and the trust store version used, not the full chip contents, unless retention is justified.

Choosing a verification path

Situation	Recommended approach	Trade-off
High-assurance onboarding (regulated KYC, digital identity scheme)	NFC with Passive Authentication, anti-cloning check and face match with liveness	Requires NFC capable phone and a well maintained trust store
Phone without NFC or chip unreadable	Image based document checks plus liveness, at a lower assurance level, or a different evidence route	More exposure to forged and generated document images
Small organisation without PKI skills	Use an identity verification provider that performs server-side Passive Authentication and reports the trust source	Ask for evidence of trust store management and revocation checks
Large organisation running its own stack	Own trust store built from the ICAO Master List and bilateral sources, with change control	Operational ownership of updates, CRLs and non-conforming certificates

Test with genuine specimen documents from several issuing States and generations, and keep a feature flag so the NFC step can be made optional per country if a specific document type causes failures.

Evidence and assessment

Assessors for identity schemes and auditors for KYC programmes will look for proof that the chip check is real, server-side and current.

Per-transaction evidence: protocol used (BAC or PACE), Passive Authentication result with the CSCA and Document Signer identifiers, anti-cloning result, DG1 to OCR comparison, face match score and liveness result, and the trust store version.
Trust store evidence: source of each CSCA certificate, date imported, who approved it, CRL freshness and the process for handling a non-conforming certificate (the ICAO Master List page warns that the list may contain certificates that do not conform to the standards).
Policy evidence: documented decision rules for chips without Active or Chip Authentication, for unknown CSCAs and for expired CRLs.
Testing evidence: results of tests with altered data groups, broken signatures and cloned chip data, showing the system rejects them.

Metrics

Metric	Why it matters
NFC read success rate by country and device model	Shows usability problems before they push users to weaker routes
Passive Authentication pass rate and failure reasons	Distinguishes trust store gaps from forgery attempts
Share of chips with an anti-cloning check completed	Shows real assurance level across the customer base
Age of the oldest CRL in use	Detects stale revocation data
DG1 to OCR mismatch rate	A direct fraud indicator

Mapping to other frameworks

Requirement	Where it appears
Cryptographic validation of evidence	NIST SP 800-63A-4 Section 2.4.2.2; SUPERIOR evidence requirements
Evidence strength scoring for ePassports	UK GPG 45 (score 3 for cryptographic features, score 4 example for ICAO-compliant biometric passports)
Identity proofing control	NIST SP 800-53 Rev. 5 IA-12; NIST CSF 2.0 PR.AA-02
PKI certificates and key management	NIST SP 800-53 Rev. 5 SC-17, SC-12
Integrity of transmitted data	NIST SP 800-53 Rev. 5 SC-8
European document mechanisms	BSI TR-03110 (PACE, EAC, Chip and Terminal Authentication)
Wallet and credential context	See the EUDI Wallet Architecture and Reference Framework Guide and Mobile Driving Licence (mDL) Guide

Common pitfalls

Trusting the device: doing Passive Authentication only inside the mobile app lets a modified app report success. Validate on the server.
Reading without validating: extracting DG1 and DG2 but skipping the SOD signature and certificate path check turns the chip into an easily spoofed data source.
Stale trust stores: importing a Master List once and never updating it causes false failures for new CSCAs and misses revocations.
Ignoring cloning: treating Passive Authentication as proof the chip is genuine, when a copy of signed data passes it too.
Silent fallback: letting users who fail NFC drop to image checks at the same assurance level invites attackers to fail NFC on purpose.
Over-retention: storing full chip images and data groups indefinitely creates a high-value data store. Keep results and hashes unless law requires more.

Practitioner checklist

Support PACE and BAC and log which protocol each read used.
Perform Passive Authentication on the server, including data group hashes, SOD signature, certificate path and revocation.
Run Chip Authentication or Active Authentication wherever the chip supports it and record the result.
Build the CSCA trust store from the ICAO Master List and other trusted sources, with documented approval and a refresh schedule.
Monitor CRL freshness and treat stale revocation data as a failure for high-assurance decisions.
Compare chip DG1 with the printed MRZ and bind the person with a liveness-checked face match against DG2.
Define rules for chips without anti-cloning support and for unknown CSCAs, and stop silent fallback to weaker checks.
Protect verification API keys, result signing keys and trust store write access as privileged non-human identities.

ePassport NFC Verification: Reading and Trusting the Chip for Identity Proofing