POSTIDENT System
Introduction of Optional Access Restriction for User and System Accounts to Permitted Source IP Ranges (Whitelist)
As of this release, it is optionally possible to restrict access to our interfaces (SCR and SFTP) and user interfaces (POSTIDENT information portal, POSTIDENT test app) for user and system accounts to a whitelist of permitted source IP ranges. If no permitted source IP ranges are configured, access from all IPs remains possible.
Users with the role "User Administration" can configure the permitted source IP ranges individually for each user or system account in CIDR notation within the POSTIDENT information portal. To do so, select the respective user or system account under the "User Administration" menu item, switch to edit mode, and click the "Add Source IP" button in the new section "Permitted Source IPs (Whitelist)". Source IPs that should no longer be permitted can be removed using the "Remove Source IP" button or modified by editing the configured IP range. To apply the configuration, you must confirm each change by clicking "Save changes".
Alternatively, you may instruct the service team to maintain the source IPs for each user or system account.
Introduction of Passkeys as a Second Factor for User Account Identification
Passkeys are now supported as a second factor for identification of information portal users, in addition to one-time passwords.
Passkeys can also be used as a second factor when resetting passwords.
POSTIDENT by AutoID
More Granular Result Processing for Face Verification
As part of Face Verification, we verify that the ID document and the user match by comparing the ID photo with an image captured from the user during the process. Previously, this check produced a binary result (passed | failed). A failed Face Verification resulted in a final rejection of the identification (declined / 11 Fraud suspicion / 111 Person does not match photo).
To prevent users from being incorrectly rejected in borderline cases between "passed" and "failed", while still ensuring that fraudulent attempts do not succeed, we are introducing a ternary result for Face Verification (passed | inconclusive | failed).
In the case of an inconclusive result, the identification is not finally rejected, allowing the user to perform additional identification attempts within the same case. For this purpose, the new sub-status reason 837 is introducedStatus Substatus Substatus reason Change incomplete 87 Problem with person 837 Face verification inconclusive NEW: Substatus reason
When this sub-status occurs, the user is informed via the POSTIDENT app and/or email that the identification was not successful and is provided with information on the reason and the option to retry within the existing case.
POSTIDENT by post office
- Extension of the POSTIDENT Test App
As of this release, it is possible to simulate sub-status reason 122 "ID document officially blocked", introduced with Release 29.0, in the POSTIDENT test app.
In addition, the simulation has been extended to include the document- and card-specific identifier (DKK) announced in the Release Notes 32.0.
POSTIDENT E-Signing
- Improved User Experience Through Early Detection of Invalid Device Usage
For regulatory reasons, it is not permitted that, in cases with multiple signatories, at least two signatories use the same device (smartphone or tablet). Previously, this invalid configuration was only detected at the end of the process.
To improve the user experience, a validation is now performed at the beginning of the identification process. If another signatory in the same signing case has already used the same device for identification, the user will receive a clear and informative error message at an early stage.
POSTIDENT Apps and SDK
POSTIDENT Android App
General
Standardization of navigation and usability for the "Accessibility Statement" and FAQs.
POSTIDENT iOS App
POSTIDENT by video chat
Minor UX improvements when entering ID data (address, city, postal code, and phone number).
Overview of current versions:
| SDK | Version | Date of release | End of official support | New features |
|---|---|---|---|---|
| iOS | 2.17.1 | 27.04.2026 | 27.10.2026 | POSTIDENT by post office
POSTIDENT by eID function
POSTIDENT by AutoID
|
| iOS | 2.18.3 | 10.06.2026 | 10.12.2026 | SDKUIConfigBuilder Class Re enabled We have re enabled the SDKUIConfigBuilder class, allowing you to individually configure the animation behavior during SDK startup and adapt it to your app's requirements. Support for iOS Versions
General Improvements
POSTIDENT via Online ID Function
POSTIDENT by post office
Notice Regarding SSL/TLS Security in the POSTIDENT SDK: We are providing updated certificate and hash value information for the existing SSL/TLS pinning method for the last time. This is due to a planned certificate change in the autumn. From 2027 onwards, we will significantly simplify security: Regular updates of certificate hash values will no longer be required, substantially reducing your maintenance effort. Current adjustments (transition phase) For the POSTIDENT SDK, we are providing updated hash values for the previously used SSL/TLS pinning method for the last time. This adjustment is necessary because the POSTIDENT certificates will be renewed in the autumn.
Future migration to CA certificate pinning From April 2027, the previously used SSL/TLS pinning will be completely replaced by CA certificate pinning at DPDHL level. Your benefits from this change:
To continue using POSTIDENT SDKs, it is necessary to switch to the respective current SDK version no later than April 2027. |
| iOS | 2.19 | exp. CW 30 2026 | Initialization of the Host App in Light or Dark Mode When initializing the SDK, it will now be possible to enforce either Light Mode or Dark Mode via a flag. This can be particularly useful in scenarios where the host app uses a Dark Mode-like design by default. E-Signing For regulatory reasons, it is not permitted that, in cases with multiple signatories, at least two signatories use the same device (smartphone or tablet). Previously, this invalid configuration was only detected at the end of the process. | |
| Android | 2.17 | 01.04.2026 | 01.10.2026 | Android 16 Support "Edge-to-Edge"
POSTIDENT by AutoID
SDK Dependency Version Compatibility The POSTIDENT SDK relies on a set of well-established third-party libraries. While these dependencies are declared internally, they are resolved together with the consuming application's dependency graph at build time. To ensure correct behavior, applications integrating this SDK must use compatible versions of the required libraries. Gradle will automatically select the highest compatible version present in the dependency graph. Using significantly older versions than those listed below may lead to build-time resolution failures or unexpected runtime behavior. The SDK is regularly tested against the versions specified below.
|
| Android | 2.18 | 12.06.2026 | 12.12.2026 | Stability improvements
Modernized app design
Notice Regarding SSL/TLS Security in the POSTIDENT SDK: We are providing updated certificate and hash value information for the existing SSL/TLS pinning method for the last time. This is due to a planned certificate change in the autumn. From 2027 onwards, we will significantly simplify security: Regular updates of certificate hash values will no longer be required, substantially reducing your maintenance effort. Current adjustments (transition phase) For the POSTIDENT SDK, we are providing updated hash values for the previously used SSL/TLS pinning method for the last time. This adjustment is necessary because the POSTIDENT certificates will be renewed in the autumn.
Future migration to CA certificate pinning From April 2027, the previously used SSL/TLS pinning will be completely replaced by CA certificate pinning at DPDHL level. Your benefits from this change:
To continue using POSTIDENT SDKs, it is necessary to switch to the respective current SDK version no later than April 2027. |
| Android | 2.19 | exp. CW 30 2026 | UX Improvements
E-Signing For regulatory reasons, it is not permitted that, in cases with multiple signatories, at least two signatories use the same device (smartphone or tablet). Previously, this invalid configuration was only detected at the end of the process. Dependency Version Compatibility OKHttp 4.x The POSTIDENT SDK still uses OkHttp internally, but the SDK now publishes a shaded implementation of OkHttp and Okio so that consuming applications do not need to align their own OkHttp versions with the SDK. This is intentionally done to support customer applications that already use a different OkHttp version or need to upgrade OkHttp on their own schedule. In other words: you can use the OkHttp version that best fits your application without having to force the SDK to the same version. The shaded HTTP client is packaged inside the SDK artifacts, relocated away from the standard okhttp3 / okio package names, and is not exposed as a regular transitive dependency anymore. Integrators should continue to depend only on the published SDK artifacts and should not reference shaded OkHttp classes directly. |
Release 34.0:
Rollout of Release 34.0 is scheduled for 01.09.2026.


