Your Expiration Date and Document Number Are Just as Important as Your ID Number

We are generally cautious about sharing our citizenship numbers. In contrast, we may feel more comfortable sharing the document number and expiration date of our passport or ID card when making flight reservations, hotel bookings, visa applications, going through human resources processes, or filing support requests.

However, these two pieces of information are not merely administrative details found on the document. Because they are linked to an individual and their official document, they constitute personal data. In electronic passports, they can also be used to derive Basic Access Control (BAC) keys along with the date of birth. For this reason, their security value is much higher than we might initially think.

The expiration date and document number are not the same as the citizenship number; however, in the wrong hands, they can become an identity and security component requiring a similar level of attention.

Let’s clarify the concepts first

The comparison in this article does not imply that the citizenship number is used in BAC calculations. In the MRZ-based key derivation process for BAC, the following information from the document is used, not the citizenship number:

• Document number and check digit,
• Date of birth and check digit,
• Expiration date and check digit.

The citizenship number is a permanent number that identifies an individual within the national registry system. The document number, on the other hand, identifies a specific passport or ID document and may change when the document is renewed. The expiration date is also directly tied to that document’s lifecycle.

These are different data fields; however, the fact that they are “different” does not mean they are “insignificant.” The value of a piece of data is measured not only by what it conveys when read by a human but also by how it is used as input for a process by a system.

What is BAC, and why does it use these fields?

Basic Access Control (BAC) is a mechanism designed to control access to the contactless chip in machine-readable travel documents. Its primary purpose is to make it difficult to perform random contactless reads while the passport is closed or without the document holder’s knowledge.

The reader system first optically scans the MRZ field on the passport’s data page or retrieves the necessary information from an operator. According to ICAO Doc 9303 Part 11, the BAC consists of MRZ_informationconsists of the document number, date of birth, and expiration date combined with their own check digits.

MRZ_information =
    Doküman Numarası + Kontrol Basamağı
  + Doğum Tarihi + Kontrol Basamağı
  + Son Geçerlilik Tarihi + Kontrol Basamağı

The SHA-1 hash of this byte sequence is calculated, and the most significant 16 bytes of the hash are used as the key seed. Two separate Document Basic Access Keys are derived from this seed:

Kseed = SHA-1(MRZ_information)[0..15]

KEnc = KDF(Kseed, 1)   // şifreleme için
KMAC = KDF(Kseed, 2)   // mesaj bütünlüğü için

KEncone for encrypting data transmitted over a secure channel; KMAC and to verify the integrity and authenticity of messages. This makes it difficult for a system that cannot read the visible fields on the passport to establish a valid BAC session with the chip.

Why isn’t the expiration date just an ordinary date?

The phrase “valid until 2031” may seem low-risk when viewed on its own. However, when this date is paired with a specific document number and date of birth, it takes on three distinct roles:

1. Personal data: It is associated with an official document belonging to a specific or identifiable individual.
2. Document lifecycle data: Indicates whether the document is active, expired, or due for renewal.
3. Cryptographic protocol input: It contributes to the generation of the BAC key seed.

This third role makes the expiration date technically unique. The field is not, by itself, a password or cryptographic key. However, when combined with other MRZ fields, it becomes part of the initial material for the access control mechanism.

Why does the document number require as much attention as the citizenship number?

The document number is often shared with the assumption that “it’s already printed on the passport.” However, this number:

• Uniquely identifies a specific official document,
• Can be matched with travel and identity verification records,
• Can be used as a search key in reservations, visas, border crossings, or customer records,
• Is the most variable component of the BAC derivation input, along with the date of issue and expiration date,
• Can facilitate establishing correlations between document images, emails, support records, and application logs.

While a citizenship number generally remains constant throughout a person’s life, a document number changes when the document is renewed. Therefore, the legal and operational characteristics of the two fields are not the same. Nevertheless, both serve as strong identifiers in terms of preventing unauthorized sharing, identity fraud, and cross-system matching.

Can someone who knows this data immediately read the passport chip?

No. It is important to set the correct boundaries without sensationalizing the issue.

• Knowing these three fields does not mean that the digital signatures in the passport have been compromised.
• The Document Signer or CSCA private keys are not derived from this information.
• BAC alone does not prove the validity of the chip data; separate controls, such as Passive Authentication, are required.
• It does not provide remote access over unlimited distances; a suitable reader and physical proximity are required for contactless chip communication.
• It is influenced by the protocols supported by the document and its security configuration.

However, if the MRZ data of a passport using BAC is fully compromised, the first access barrier—which relies on the confidentiality of this data—no longer provides the same level of protection. The risk increases when the fields are compromised collectively rather than individually.

Why is BAC a limited security mechanism?

ICAO Doc 9303 explicitly states that the security of BAC depends on the limited randomness of the printed MRZ data. Birth and expiration dates fall within narrow and predictable ranges. The method of generating document numbers may also not always be fully random.

Consequently, BAC keys do not possess the same security properties as randomly generated, high-entropy keys. ICAO explains that this limitation stems from BAC’s symmetric, MRZ-based design and that PACE was developed to overcome this problem.

What does PACE change?

Password Authenticated Connection Establishment (PACE) ensures that strong session keys are established using asymmetric cryptography, even if a low-entropy password or MRZ information is used. In documents using PACE, MRZ information or the Card Access Number (CAN) can be used at the start of the protocol; however, the strength of the established session keys is not solely dependent on the entropy of this information.

This does not mean that MRZ fields no longer need to be protected. These same fields still contain personal data, document identifiers, and inputs for various business processes. PACE merely addresses a specific cryptographic weakness in the access protocol with a stronger design.

Does every electronic ID card use BAC?

No. BAC should be evaluated specifically in the context of ICAO-compliant machine-readable travel documents. National electronic ID cards may use PACE, CAN, PIN, terminal authentication, or other country-specific protocols.

Therefore, one should not generalize by stating that “the expiration date is the key for all contactless ID cards.” The correct statement is:

In ePassport/eMRTD documents that use BAC, the document number, date of birth, and expiration date are the inputs for the BAC key derivation process.

Assessment under the KVKK

Law No. 6698 defines personal data as any information relating to an identified or identifiable natural person. The Personal Data Protection Authority also explicitly lists the date of birth among examples of personal data.

The document number constitutes personal data because it is associated with an official document belonging to a specific individual. The expiration date may not, on its own, identify a specific individual; however, when linked to the document number, the individual’s record, or an image of the document, it qualifies as personal data.

As a general rule, these fields do not fall under any of the categories of special-category personal data covered by Article 6 of the KVKK. However, the fact that they are not special-category data does not mean they can be protected with minimal security measures. The data controller is obligated to implement technical and administrative measures appropriate to the risk and the context of the processing.

Assessment under the GDPR

GDPR Article 4 defines personal data as information relating to an identified or identifiable natural person. A document number is an explicit identifier; birth and expiration dates also fall under this scope when linked to an individual or a document record.

On their own, these are generally not “special category data” under GDPR Article 9. Nevertheless, they require strong security controls due to risks such as identity fraud, unauthorized document inquiries, and the matching of different records.

From the perspective of both the KVKK and the GDPR, the fundamental question is not merely “Is this data personal data?” The following questions must also be answered:

• For what specific and legitimate purpose is the data being collected?
• Is it truly necessary to collect all the fields for this purpose?
• What is the legal basis for the processing?
• Has the data subject been adequately informed?
• With whom and in which countries is the data shared?
• How long is it stored?
• Is it securely deleted when the retention period ends?

The real risk often begins before the chip

An advanced RFID attack is not required for these areas to be compromised. More common sources of risk include:

• Sending a passport photo via a messaging app,
• Storing a document uploaded for a visa or travel application longer than necessary,
• Document numbers and dates being written in plain text in app logs,
• Attaching a screenshot or a copy of a document to a support request,
• Using real customer data in test environments,
• Sending form fields to analytics or error-tracking services,
• Allowing employees with broad permissions to export bulk records.

Therefore, the threat model is not limited to the question, “Could someone get close to my passport with an NFC reader?” The entire digital lifecycle of document data must be examined.

How should organizations protect these areas?

Data minimization

If a process requires only verification of a document’s validity, it should be evaluated whether the verification result can be retained instead of storing the full date. The full document number should not be displayed in the user interface or in reports; it should be masked where necessary.

Log and Audit Trail Security

Form bodies, API payloads, and OCR outputs should not be logged by default. In necessary technical logs, the document number should be tokenized in a way that makes it untraceable, or only the last few characters should be displayed.

Field- or Record-Level Encryption

Database disk encryption alone should not be considered sufficient. For high-risk document fields, encryption at the application or field level should be evaluated, with keys managed by a separate KMS/HSM system.

Access control and separation of duties

The reservation service, support team, analytics system, and authentication service should not have access to the same raw document data. Service and user permissions should be segregated according to their purposes; bulk queries should also be monitored.

Retention Periods and Secure Deletion

The justification “it may be needed in the future” is not sufficient for indefinite retention. Legal and operational retention periods must be defined; data—including backups and derived copies—must be deleted at the end of its lifecycle.

Synthetic test data instead of real data

Real passport or ID records should not be used in development and test environments. Synthetic document data that complies with MRZ rules but does not belong to a real person should be preferred.

What can individuals do?

• Share a copy of your passport or ID only when it is truly necessary.
• If possible, add a watermark to the document copy that includes the purpose of sharing, the recipient, and the date.
• If not required, mask the document number, MRZ, and expiration date.
• Do not send the document as an unsecured email attachment or through an unmoderated messaging group.
• Ask the organization requesting the document why it needs it, how long it will be retained, and with whom it will be shared.
• Verify that sharing links are not publicly accessible and are time-limited.

Conclusion: Value is determined by what the data does within the system

Protecting the citizenship number while disregarding the document number and expiration date is a flawed security approach. These fields not only identify the individual and their official document; in electronic passports using BAC, they also contribute to the derivation of chip access keys along with the date of birth.

Therefore, the correct question should not be limited to “Is this field sensitive personal data?” The real question is:

When combined with other data, what identification, access, or security operations does this information enable?

The expiration date is not a password. Nor is the document number the same as the national ID number. However, both are high-value personal data within their respective contexts and deserve to be protected just as conscientiously as the national ID number.

This article is intended for general technical and legal information purposes; it does not constitute legal advice for specific data processing activities.

Official Sources

• ICAO Doc 9303 Part 11 — Security Mechanisms for MRTDs
• ICAO Doc 9303 document collection
• Personal Data Protection Authority — Personal Data
• Summary of Decision No. 2024/275 of the Personal Data Protection Board
• European Union — General Data Protection Regulation