Currently, NFC verification seems to be a foolproof way to verify customers, both online and on-site. With more and more identity documents becoming biometric, this technology is being adapted by businesses and government agencies worldwide.
RFID chip reading takes seconds, providing a seamless experience for clients and a reliable way to confirm their identities for companies. Importantly, using the chip in electronic documents is regulated by global standards like ICAO and ISO—a promise that the process will be smooth for any biometric passport or identity card.
In this article, we’ll explore the logical structure of these chips, and highlight potential issues associated with e-document verification.
Want to first get a clear idea of RFID verification in general? Start here: RFID Technology for Identity Verification: A Comprehensive Guide
The basics of the RFID chip logical data structure (LDS)
Before diving deeper, it’s critical to understand how the chip is organized. Technically, it’s similar to a secure computer file system, with folders and files, each serving a specific purpose. In plain English, these are:
The root folder—Master File (MF)
Subfolders—Dedicated Files (DF) representing applications that manage how data is accessed, secured, and transmitted
Files—Elementary Files (EF) holding specific data, including personal details and biometric information, as well as security certificates
Inside an RFID chip, there is a system of folders, subfolders, and files. This diagram is a simplified version illustrating the general idea.
When an RFID reader scans an e-document, it first selects the DF of the relevant application: ePassport for travel documents, eDL for driver’s licenses, and eID for national identity cards. Then, it retrieves data from specific EFs within that DF. Security mechanisms (e.g., BAC, PACE, and EAC) control access to prevent unauthorized reading.
By the way, EFs associated with security mechanisms—for example, EF.CardAccess and EF.CardSecurity—are stored under the MF. However, data groups are always stored in dedicated DFs.
Additionally, each EF has an assigned identifier that helps the document reader to detect, read, and check it.
LDS1 vs. LDS2
ICAO’s Doc 9303 specifies two types of logical structures for RFID chips. LDS1, described above, is a must, and is now used in all e-documents. LDS2, as a next-gen standard, is designed for dynamic data such as visa and residence permit records, entry/exit stamps, driving records, and additional biometric data on the holder. In practice, LDS2-enabled chips contain extra DFs and require stronger encryption and authentication (e.g., Terminal Authentication as a more advanced mechanism for access control).
However, in the coming years, it will hardly be possible to establish a channel for exchanging certificates for Terminal Authentication and data verification between all countries. As a result, LDS2 remains more of a concept than a practical guide for issuers.
What data groups are stored in the RFID chip: The e-passport case
In this section, we break down only LDS1’s DF, since this is mandatory for all e-passports, and includes the data groups checked during RFID verification. If the element is optional, a corresponding data group can contain an empty template.
This table provides the details:
| Data group name | Data group content | Status | Frequency of data group usage |
|---|---|---|---|
| DG1 | Information encoded in the document’s machine-readable zone (MRZ): type of document, name, date of birth, nationality, sex, check digits, etc. | Mandatory | Always |
| DG2 | Holder’s photo | Mandatory | Always |
| DG3 | Fingerprint(s) as an additional identification feature | Optional | Often |
| DG4 | Irises as an additional identification feature | Optional | Rare |
| DG5 | Displayed portrait | Optional | Rare |
| DG6 | Reserved for future use (e.g., additional biometrics) | Never | |
| DG7 | Holder’s signature or usual mark—a scanned image of a handwritten signature or a digitally captured signature—from an electronic pen device | Optional | Often |
| DG8 | Data feature(s), primarily additional facial biometrics | Optional | Never |
| DG9 | Structure feature(s), primarily additional fingerprints | Optional | Never |
| DG10 | Substance feature(s), primarily additional iris templates | Optional | Never |
| DG11 | Additional personal details beyond MRZ data—personal number, place of birth, profession, permanent address, etc. | Optional | Often |
| DG12 | Additional document detail(s)—issuing authority, issuance date, etc. | Optional | Often |
| DG13 | Optional details | Optional | Rare |
| DG14 | Security options—chip authentication public key, security mechanisms used in the document (e.g., Passive Authentication, Active Authentication), cryptographic details | Conditional | Often |
| DG15 | Active authentication public key info | Conditional | Often |
| DG16 | Persons to notify: emergency contact name, phone number, and relationship to the holder | Optional | Never |
The number of data groups varies across different electronic IDs. For example, an electronic driver's license (eDL) has 14 data groups, while an electronic ID (eID) has 21. The content of these data groups also differs. For instance, DG1 in a driver’s license stores the license number, issuing authority, and expiration date, whereas in biometric ID cards, the same group may contain biographic and document-related information.
A key difference is that data groups in electronic ID cards and driver’s licenses are typically more granular, with each group containing only one specific data portion. However, since only a limited number of countries currently issue eIDs and eDLs, this article focuses solely on the detailed data groups of e-passports. If you want a closer look at the DG structure in these documents, refer to the following standards: ISO/IEC 18013-2 and ISO/IEC 18013-3 (for eDLs) and Doc 9303 (for eIDs).
The chip’s LDSs govern the command set available to issuing authorities or inspectors involved in e-document verification. While inspectors can select, search, or read the chip with software, issuers can also append EFs (available only for LDS2 applications).
In practice, all data stored in an e-passport's chip can’t be modified after personalization—it can only be read.
Get posts like this in your inbox with the bi-weekly Regula Blog Digest!
Potential verification hurdles associated with data groups in the RFID chip of e-documents
Seemingly, NFC verification is a well-prescribed and standardized process embraced by many IDV solutions, both hardware and software. However, there are still some peculiarities which can lead to tech issues and verification failures if your current solution doesn’t consider them.
💡In this section, we focus only on DG reading, excluding other mandatory RFID chip checks, such as security mechanisms like PACE or EAC.
Data reading and matching challenges
As with the MRZ in the visual inspection zone, DGs in the chip also contain non-standard or specific cases to handle. For example, DG11 in an e-passport can include the holder’s name or place of birth recorded in a national language, which can also be non-Latin. Examples include the Belgian biometric passport from 2022, which displays the place of birth in Belgian French; the Mexican e-passport from 2021; and the Polish ID card from 2021, where this data appears in Spanish and Polish, respectively.
Countries that use patronymics as second names, such as Kazakhstan, also include them in this data group. As a result, DG11 in the Kazakhstani ID card contains a surname and two “other names,” which may appear in a random order, differing from the name in the visual inspection zone.
Since these data must then be cross-checked with the printed data in English, occasionally, lexical analysis is required to complete it correctly. This enables analyzing the obtained information, transliterating to Latin where applicable, and converts data to a standardized format. Modern IDV solutions, such as Regula Document Reader SDK, easily manage such sessions.
Changes in data storage standards
As Doc 9303 declares, biometric data contained in DG2, DG3, and DG4 must be encoded in accordance with international standards to ensure global interoperability. These standards can be updated over time, providing additional challenges for e-document verification during the transition period.
For example, since August 2023, Doc 9303 has recommended using the ISO/IEC 39794 standard for biometric encoding instead of ISO/IEC 19794:2005, which is now obsolete and doesn’t meet current requirements. Both standards, among other things, regulate the methods for storing biometric data in e-passport chips. The newer approach involves recording detailed biometric attributes in metadata—for instance, facial landmarks and precise eye and hair color for the holder’s portrait.
Document readers and verification systems must be compatible with the new standard by 2026, while passport issuers are required to fully adopt the new format by 2030. This means companies may get to verify e-passports with updated DG2 starting from January 1, 2026. Therefore, the next five years can be challenging due to both versions of RFID chips in circulation.
Regula’s software and hardware solutions already meet the new requirements. What’s more, Regula Document Reader SDK is compatible with most third-party ID readers, helping you stay prepared for this regulatory shift.
Choose Regula as your e-document verification solution
NFC verification remains the most reliable way to confirm a customer’s identity, especially during online onboarding. However, it’s critical to consider all the tricky parts of the process to keep your systems fraud-free yet comfortable for users.
Regula’s NFC verification technology embraces all potential challenges while following the current standards and security protocols. In addition to standard checks, it also performs server-side verification, detecting more sophisticated tricks like chip cloning or alteration of mobile verification results—a crucial feature for remote e-document verification. Also, Regula’s SDK ensures seamless cross-platform performance, supporting a wide range of user verification scenarios.
Learn more about your opportunities with Regula!
