NFC chip verification
Modern passports (every country) and some national ID cards carry an eMRTD chip following the ICAO 9303 standard. On NFC-capable phones, the mobile SDKs read the chip over its secure channel and submit the data with the verification. The server then runs passive authentication: it re-computes each data group’s hash against the chip’s signed security object, verifies the Document Signer signature, and checks that the signer chains to a trusted issuing state’s certificate (CSCA). The client never decides authenticity; a chip that positively fails authentication is proven tampered and the verification fails with chip_not_authentic.
A chip is authentic only when its signer chains to a trusted issuer. The signing certificate travels inside the chip data the applicant submits, so a valid signature alone proves only that some key signed it. A chip whose issuing country is not on Toden’s trusted issuer list comes back inconclusive: the verification falls back to the document and government database checks, with no chip assurance level, no chip photo and no face match against the chip photo.
A chip-verified document earns the strongest assurance level, chip, when a copied chip is also ruled out: the chip proves it is the original (Active Authentication, below), or it has no such feature and the live selfie matches the photo stored on the chip. Genuine chip data without that proof gets the next level (gov_db or document). Where the ID is also checked against a government database (a Nigerian passport, for example), the selfie is compared with the government’s photo rather than the chip’s, so on that path a chip reaches chip only through Active Authentication.
Native SDKs only. Reading a chip requires low-level NFC access (ISO-DEP) that only native apps get, so chip verification is available in the React Native and Flutter SDKs and is not supported in the web SDK: no browser API can talk to a passport chip. Web integrations that want chip assurance should route users through one of the mobile SDKs. Phones without an NFC radio skip the step automatically, and skipping never fails a verification.
Supported documents
Two things decide whether the chip step appears for an ID:
- The document carries a chip. A passport carries one in every country, while national identity cards depend on whether that country issues an ICAO-compliant chip card. Driver’s licences never carry a readable chip.
- Toden holds the issuing country’s certificate (CSCA). A chip can only be confirmed genuine against the certificate of the country that issued it, so the step is offered only for countries on Toden’s certificate list. The list is built from the certificate lists the German, Dutch and Italian governments publish, and covers 138 countries, including Nigeria, Ghana, Kenya, Egypt, Ethiopia and Senegal. Documents from a country not on it skip the chip step and are checked by their document and, where available, the government database. South Africa does not issue chipped passports yet.
The authoritative list for your account is GET /config, whose ID types each carry supportsNfc: true only when both conditions hold. A chip is also checked against the country its own data names as the issuer, so a chip signed under one country’s certificate that claims to be another country’s document is never treated as genuine.
The table below shows which documents carry a readable chip. The chip step runs only where Toden also holds the issuing country’s certificate, as described above, so a tick for a country not on that list does not mean the chip step is offered there yet.
Some well-known ID cards carry chips that are not ICAO eMRTDs and cannot be read this way, by any vendor: the South African smart ID card, the Emirates ID, Malaysia’s MyKad, and the smart cards of Singapore, Hong Kong, Japan and China all use proprietary chip applications. Those documents still verify through Document Intelligence; they simply cannot reach chip assurance.
Three things to know:
- The chip’s secure channel is unlocked with a key derived from the document’s MRZ (BAC or PACE), so the chip step always runs after the document scan that reads it.
- Chip capability follows each document’s current issuance generation. Older chipless generations still in circulation pass through unaffected: chip presence is a bonus signal, and a chipless card simply completes on the document checks at the assurance tier it can reach.
- Which chip-capable IDs actually offer the step, whether users may skip it manually, and whether the chip portrait is face-matched are all configured per workflow in the builder’s NFC panel.
Data extraction
The system reads and verifies the following data groups:
Two honesty notes, because chip capabilities are widely overstated:
- DG3 (fingerprints) and DG4 (iris) cannot be read by any commercial system. They sit behind Extended Access Control: only government inspection systems holding terminal-authentication certificates issued by each state can decrypt them. A vendor claiming to extract fingerprints or iris scans from a passport chip is describing something the standard does not permit them to do.
- DG7, DG11 and DG12 are optional by standard. Many issuers do not write them at all, so their absence is normal and never a risk signal. The SDK checks the chip’s own table of contents (EF.COM) and reads only the groups the document declares.
Where the results surface
The full result lands on the verification record and the webhook payload as data.nfc:
-
status(verified/not_authentic/data_mismatch/inconclusive/unreadable),chipAuthentic,dataMatch,checkDigitsValidand the parsedmrz. -
sod,dg2,dg7,dg11,dg12sub-objects, each carryinghashValid: whether that group’s bytes match the signed hash in the SOD. Parsed DG11/DG12 fields are included alongside, withhashValidtelling you how much to trust them. -
On document-only verifications,
dg2.faceMatchanddg2.faceMatchConfidencereport the live selfie against the authenticated chip portrait. -
cloneCheck: how a copied chip was ruled out:active_auth(the chip answered our one-time challenge with its own private key),face_bound(the chip has no such key and the selfie matched its photo) ornone. -
sod.signerRevoked:truewhen the issuing country has cancelled the certificate that signed the chip (such a chip is never treated as genuine),falsewhen its cancellation list was checked,nullwhen we hold no current list for that country. Anullchip is still accepted as genuine; see “Passport signer’s cancellation status unknown” below if you would rather review or decline it.
In workflow decisioning you can branch on verification.nfcStatus, verification.nfcAuthentic, verification.nfcDataMatch, verification.nfcFacialMatch, verification.nfcActiveAuth, verification.nfcCloneCheck, verification.nfcSignerCancellationUnknown and verification.assuranceLevel.
Passport signer’s cancellation status unknown
Countries publish lists of the signing certificates they have cancelled, for example after a key leak. We check them, but not every country publishes one, and a list can be unreachable or out of date. When that happens for a chip that is otherwise genuine, verification.nfcSignerCancellationUnknown is true. These chips are accepted by default. To review or decline them instead, open the NFC step’s Rules tab and add the suggested rule “Passport signer’s cancellation status unknown”. The field is false once the list was checked and empty (null) when the chip is not from a trusted issuer at all.
Behaviour and availability
- A missing, unreadable or inconclusive chip never fails a verification; it simply falls back to the document checks. Only a proven-tampered chip (
not_authentic) hard-fails, and that includes a chip that fails Active Authentication: a copy of a genuine chip cannot answer the challenge with the original’s private key. A chip without Active Authentication is not a failure, and nor is a chip whose answer never reached us, a submission that leaves out the chip’s key, or an answer we could not read: none of those proves a copy, so the chip simply does not count towardschip.activeAuth.reasonsays which it was. Sostatus: verified(and theverification.nfcAuthenticdecision field) says the chip’s data is genuine, not that the chip is the original: route onverification.nfcCloneCheckfor that. - The optional detail groups (DG7/DG11/DG12) are read by the React Native SDK today, with Flutter following; the core groups (DG1, DG2, SOD) are read by both mobile SDKs.
- On sandbox keys, a chip payload on a test ID returns a canned authentic result, so you can exercise the full contract at no cost.