Thales ID-card

This article is about the new ID-card manufacturer Thales cards. If you would like information about the currently in use IDEMIA test cards, you can find it here.

The manufacturer of ID1 format documents (i.e., ID-cards) changed in November 2025: instead of the current card manufacturer IDEMIA, Thales began producing Estonian ID-cards.

The Information System Authority (RIA) has prioritized the smooth implementation of the new ID-cards into the eID ecosystem as part of the planned changes. However, the updates will inevitably lead to the need for some technical adjustments. In order for the new ID-cards to work in information systems and e-services, RIA invites all interested parties to test the new ID-cards in their systems and services.

    • End users must install the latest version of the ID software for electronic use of the new ID cards. The applications of the new version of the ID software support both Idemia and Thales ID-cards and include the necessary new drivers.
    • With the new Thales cards, a new trust service provider, Zetes, has began offering trust services. This means that systems using the ID card for authentication and/or signing will need to support two trust services.
    • With the arrival of the new card manufacturer, new ID cards were added to the eID ecosystem, and a 5-year transition period has began. During this period, both the current IDEMIA and the new Thales ID cards will be used in parallel.

    Changes to the ID card:

    • New chip
    • Suspension of ID-card certificates is not possible
    • Once the ID-card has been received, the PIN2 code must be changed, it is not possible to digitally sign with the ID-card before changing the PIN2
    • PUK code can be viewed from the Police and Border Guard Board self-service, using alternative eID tools (Mobile-ID, Smart-ID)
    • Other key features remain the same / no significant changes
    • Public documentation for the Thales ID-card is available here.

    Changes to the ID software:

    • The Thales mini-driver was added to the Windows ID software installation package;
    • The drivers for macOS and Ubuntu were updated to support Thales ID cards;
    • Web eID and DigiDoc applications (RIA DigiDoc mobile application and DigiDoc4 application) were updated to support Thales ID cards;
    • Digital signing in the DigiDoc applications is not possible until user chages the PIN2 code;
    • In the DigiDoc applications, the PUK code cannot be changed on the Thales card.

    End users can get the Thales ID card-compatible ID-software by updating their ID software or downloading it from the id.ee website.

  • Customer card solutions, identity verification without PIN1-code

    Customer card systems that use the ID-card only to retrieve personal data (personal identification code), and the user does not need to verify their identity using the PIN1-code. This includes various commercial companies, access control systems, and ticketing systems.

    There are several ways to retrieve the personal identification code from the ID-card — either by reading the personal data file or by reading the required information from the certificate. The necessary information for enhancing customer card applications is available in the Developer Guides, which can be found here.

    Sample code for reading the ID card personal data file for loyalty card solution developers can be found here.

    E-services, identity verification with the ID-card PIN1-code

    To implement identity verification with an ID-card in your e-service, there are two options: use the built-in browser certificate authentication (TLS client certificate authentication or TLS-CCA) or the new Web eID solution for online authentication and signing with the ID-card.

    The Information System Authority recommends using the Web eID solution for identity verification with an ID-card in e-services, as it makes the use of the ID-card in the web browser more reliable, user-friendly, and resolves several issues present in the TLS-CCA solution. More information on how to implement the Web eID solution in your e-service can be found here.

    Please note! Due to the addition of a new trust service provider (Zetes), it is necessary to add support for the Zetes certification chain to e-services, and use the Zetes OCSP service to check the validity of the new (Thales) ID-card certificates.

    Zetes test certificate chain certificates:

    Zetes live-certificate chain certificates: https://repository.eidpki.ee/crt/

    Zetese OCSP service addresses: 

    E-services that use the Web eID solution:

    The service must add the new trusted intermediate certificates (CA certificates) to the Web eID authentication token validation library configuration. More detailed information on the required changes can be found in the „Web eID solution users“ section.

    E-services that use the TLS-CCA solution:

    The service must configure the trust chain of the new ID1 card and make the necessary changes to verify the validity of the user certificate.

    Advanced instructions for IIS, Nginx ja Apache web servers can be found here.

    Identity verification with an ID-card in Windows domains and on individual machines

    Many companies and institutions use centrally managed computer networks where user authentication via ID-card has been implemented. The most common methods are logging into a Windows domain or authenticating to a server via RDP. In both cases, a user authentication certificate (protected by PIN1) is used to identify the user and associate them with their account.

    To use it, you need to add the Zetes root and intermediate certificates and use the Zetes OCSP service to check the validity of the certificates.

    Advanced instructions for configuring Windows domain can be found here.

    Encryption solutions

    The Estonian ID-card authentication certificate also supports its use for data encryption and decryption. Software supporting Thales card encryption and decryption has been made public for DigiDoc4 and RIA DigiDoc mobile application users. This chapter focuses on encryption solutions within information systems.

    Due to the addition of a new trust service provider (Zetes), support for Zetes' LDAP service must be added to e-services. Please note that for encryption, personal certificates must be retrieved from the LDAP services of both trust service providers.

    Zetese LDAP service address: 

    A certificate and public key for the test user Jaak-Kristjan Jõeorg (personal identification code 38001085718) have been added to the Zetes test-LDAP service. Sample LDAP query:

    ldapsearch -H ldaps://ldap-test.eidpki.ee -x -b "dc=ESTEID,c=EE,dc=eidpki,dc=ee" "serialNumber=PNOEE-38001085718"
    ldapsearch -H ldaps://ldap-test.eidpki.ee -x -b "dc=ESTEID,c=EE,dc=eidpki,dc=ee" "cn= JÕEORG,JAAK-KRISTJAN,38001085718"

    Please note! You can test certificate retrieval from LDAP. Encryption/decryption for the given certificate must be tested separately. The test-LDAP contains only one test user. The information system tester must take into account that when requesting a certificate by the personal identification code „Jaak-Kristjan Jõeorg“, they will receive a certificate for a test user, which will likely not match the test card in use. If this certificate is used for encryption, decryption with the test card will not be possible.

    Digital signing with an ID-card

    Due to the addition of a new trust service provider, e-services must include support for Zetes' certificate chain and use Zetes' OCSP service to check the validity of Thales ID-card certificates.

    Zetes test certificate chain certificates:

    Zetes live-certificate chain certificates: https://repository.eidpki.ee/crt/

    Zetese OCSP service address: 

    Users of the libraries and services provided by the Information System Authority can find more detailed information in the following sections.

    We would like to point out that there was a change in the Thales ID card chip profile in September, due to which end users must change their ID card PIN2 in the DigiDoc applications after receiving their new ID card. It is not possible to digitally sign with an ID card before changing PIN2 code.

    This change affects e-services where Web eID solution is not used for digital signing with an ID card. In such e-services, the system must detect if the end user has changed the PIN2 code on their ID card in order to enable the signing, in case the PIN2 code has not been changed then e-service will need to display information to the user about the need to change the PIN2 code, such as: "Signing with an ID-card isn't possible yet. PIN2 code must be changed in DigiDoc4 application in order to sign."

    In case your e-service is affected by the change then we recommend ordering a test card with a new profile.

    More detailed information on how to detect if the PIN2 has been changed on the Thales ID card can be found in the updated Thales Developer Guide.

    Clients of the State Authentication Service (TARA)

    The State Authentication Service is a service provided by the Information System Authority (RIA), which integrates with authentication methods offered by third parties and makes the necessary (data) queries for authentication. More information about the State Authentication Service can be found here.

    Clients of the State Authentication Service do not need to take any action in relation to the addition of the new ID-card, as the necessary changes have been made by the RIA authentication services.

    Clients of the authentication services, i.e., end users (authenticators), will need to install the latest version of the ID-software to use the new ID-cards.

    Clients of the State SSO Service (GovSSO)

    The State SSO (single-sign-on) service (GovSSO) is a service provided by the Information System Authority (RIA), which allows an organization to integrate support for both national and cross-border European Union authentication methods, along with session management, into its e-service. More information about the State SSO service can be found here.

    Clients of the State Authentication Service do not need to take any action, as the necessary changes have been made by the RIA authentication services.

    Clients of the authentication services, i.e., end users (authenticators), will need to install the latest version of the ID-software to use the new ID-cards.

    Clients of the Digital Signature Gateway Service (SiGa) 

    The Digital Signature Gateway Service is a service provided by the Information System Authority that enables the creation of signed envelopes. More information about the Digital Signature Gateway Service can be found here.

    Clients of the Digital Signature Gateway Service must ensure that the ID-card signing solution used (information about Web eID can be found in the corresponding chapter) also works with the new Thales card.

    Integrators who have installed the SiGa software themselves must download the latest version of the software and verify the functionality of their service.

    Clients of the Validation Service (SiVa)

    The Validation Service is a service provided by the Information System Authority that allows the validation of historically signed and less common format digitally signed documents. More information about the Validation Service can be found here.

    Users of the Validation Service are not expected to make any changes.

    Users of the Web eID Solution

    The Web eID solution allows Estonian digital documents to be used for secure authentication and signing on the web. More information about the Web eID solution can be found here.

    E-service providers using the Web eID solution must add new trusted intermediate certificates (CA certificates) to the Web eID authentication certificate validation library configuration.

    Detailed instructions for adding Thales ID-card support:

    DigiDoc4j integrators

    DigiDoc4j is a Java library for creating and validating digital signatures. More information about the DigiDoc4j library can be found here.

    If automatic trust list loading is used, DigiDoc4j library users are generally not expected to make any changes. However, it is recommended to test if all operations work as expected with the Thales card.

    In case the DigiDoc4j integrator uses their own solution for certificate trust or uses a custom solution for loading trust lists, they must ensure that the new trust service certificates are trusted and loaded correctly.

    Users of the Libdigidocpp library

    Libdigidocpp is a C++ library for creating and validating digital signatures. More information about the libdigidocpp library can be found here.

    If automatic trust list (TL) loading is used, Libdigidocpp library users are generally not expected to make any changes.

    However, it is recommended to test if all operations work as expected with the Thales card.

  • Testing

    To develop and test Thales ID card support, we recommend ordering a Thales test card. Currently, Thales test cards are issued by the Information System Authority. To order a test card, please send your contact details to [email protected]. Please include the following contact information:

    • Company name;
    • Names of the e-services and information systems to be tested;
    • First and last name of the contact person;
    • Email address of the contact person;
    • Desired number of Thales test cards;
    • Do you want test card with new profile.

    Preparation for Testing

    1.  Install ID software with Thales test card support

    To successfully use the Thales test card in the ID software, you must install ID software that supports the Thales test card. This software includes the necessary drivers for the Thales test card and the DigiDoc4 test application configured to work with test services.

    If the ID software is already installed on the computer used for testing, it must be uninstalled before installing the ID software with Thales test card support.

    Please note! Please note that actions cannot be performed with personalized ID cards issued by the Police and Border Guard Board (PPA) in the ID software that supports the Thales test card. Therefore, we recommend uninstalling the ID software with test card support after testing is completed.

    Windows

    macOS

    • Download the software. ID software with Thales test card support for macOS 13, macOS 14, and macOS 15 can be downloaded here: https://installer.id.ee/media/id2025/macOS/
    • Install the downloaded DigiDoc4 application and Open eID package.

    Please note! You can authenticate and sign documents online with the test card only in Chrome and Firefox browsers.

    Ubuntu

    If ID software has not been previously installed on the computer used for testing, you must first install OpenSC from the repository before installing the ID software with Thales test card support. This can be done with the command 'sudo apt install opensc opensc-pkcs11'. After installing OpenSC, the command 'pkcs11-register' must be run from the command line.

    To install previously downloaded ID software:

    • Extract the downloaded zip package.
    • Navigate to the appropriate Ubuntu version directory from the command line.
    • To install the software, run the command 'sudo apt install ./*.deb'

    2. Upload the test card certificates to the Zetes test environment

    To successfully authenticate and sign with a test card in a test environment, upload the test card's identification and signing certificate to the Zetes OCSP test service database https://ocsp-test.eidpki.ee/ui/ and set the status to "good" when uploading the certificate.

    3. Test authentication and signing with the test card

    After installing the ID software with Thales test card support, you should try authentication and signing with the test card on the test.web-eid.eu page.

    The PIN1 is 1234, PIN2 is 12345 and PUK is 12345678

    What tests should be done?

    When testing services, keep in mind that with the introduction of a new card manufacturer, multiple ID cards from different manufacturers are now used in the ID card ecosystem, and all systems should work uniformly with all the ID cards in use. Therefore, we recommend performing all tests with all the ID cards used in Estonia.

    Below are the most commonly used test cases for services. Depending on the specific functionality offered by the e-service, additional tests may be required.

    Identity verification with the ID card

    To test identity verification with the ID card in the e-service, at least the following tests should be performed:

    1. Successful identity verification with the ID card

    2. Identity verification with revoked certificates on the ID card

    • To change the status of the ID card certificate, upload the ID card certificate to the OCSP test service database at https://ocsp-test.eidpki.ee/ui/ and set the certificate's status to „revoked” or „unknown”.

    It is recommended to complete successful identity verification tests on all browsers supported by the ID software, using at least one Windows, macOS, and Ubuntu machine.

    ID card authentication in Windows domains and on individual machines

    To test ID card-based login to the network/computer, the following tests should be performed at a minimum:

    1. Successful login/identity verification with the ID card
    2. Identity verification attempt with revoked certificates on the ID card
      • To change the status of the ID card certificate, upload the ID card certificate to the OCSP test service database at https://ocsp-test.eidpki.ee/ui/ and set the certificate's status to „revoked” or „unknown”.

    Digital signing with the ID card and signature validity checking

    To test digital signing with the ID card and signature validity checking, at least the following test should be performed:

    • Creation and signing of an ASiC-E container with the ID card
      • Validation of the created container in the DigiDoc4 client or RIA DigiDoc mobile application
      • Validation of the created container with the SiVa service

    Client card solutions

    It is challenging to define more detailed test cases for client card solutions as the systems are highly varied. It is important to perform the main positive use cases with the ID card and the most common possible error scenarios.

  • Known flaws of the Thales card

    • The Thales pre-live ID-card has a printed test person's date of birth that does not match the date in the personal file and that is not the date of birth encoded in the personal identification code.

    What to do if signing with a test card in the DigiDoc4 application fails?

    If you receive the error message ‘Failed to verify OCSP Responder certificate’ when signing with a test card in the DigiDoc4 application, you need to update the configuration of the DigiDoc4 application. To update the configuration, click the “Refresh configuration” button under the DigiDoc4 application settings. Once the update check is complete, try signing again with the test card.

    What to do if the test card is no longer working?

    1. Check the software and drivers

    • Make sure the latest ID software (e.g., RIA DigiDoc) and test card drivers are installed on your computer.
    • Update the ID software or test card drivers.

    2. Try a different USB port or card reader

    • Connect the card reader to a different USB port on your computer or, if possible, use a different card reader to rule out a problem with the card reader or USB port.

    3. Check if the card is detected at all

    • Open the ID software (e.g., the „Settings“ or „Card Info“ view in the DigiDoc4 application) and check if the test card's certificates are displayed correctly.
    • If the card does not appear in the software's card notifications/card info view, the card's chip or card reader may not be functioning properly.

    4. Test in a different computer or operating system

    • If possible, try the test card in another computer or operating system (e.g., Windows, macOS, or Linux).
    • This can help identify whether the problem is specific to the computer/operating system or likely caused by the card itself.

    5. Check if the card's chip is physically damaged

    • Inspect both sides of the card to identify any mechanical damage, such as scratches or swelling on the chip or its back.
    • If there are signs of physical damage on the card, this may be the reason why it is not working.

    If the previous checks do not resolve the issue, the card is likely defective and should be returned for further inspection.

    Before returning the card, write down the following details:

    • What actions with the test card were performed before the failure was detected
    • (e.g., software update, card was in the card reader for a long time, etc.)

    The environment in which the card was tested:

    • The operating system and its version (e.g., Windows 10/11, macOS 12, etc.).
    • The version of the ID software used.
    • The exact brand and model of the card reader.
    • Any other important circumstances describing the situation in which the card was used.
    • Based on this information, the card manufacturer or technical support can more quickly identify the potential cause of the failure and provide further instructions if necessary.

    I want to provide feedback, where should I send it?