# Major Releases

{% hint style="warning" %}
This feature does not introduce any API changes. However, if fidentity is used in a **WebView**, please verify that the feature works as expected. 
{% endhint %}

## **FaceAuth: Sign with a smile**

**Release dates:**

* **Stage Release:** 17.02.2026
* **Production Release:** 22.04.2026

**Feature describtion**

As a fallback to WebAuthn (passkey storage in the user’s password manager on the device), we are introducing FaceAuth.

This feature allows the QES process to be completed without storing a passkey. To ensure that the same user is involved, facial recognition as well as a cryptographically secure device binding is used as authentication factors. This feature is audited and approved for QES.

**Process**

If registration with a passkey fails, the user can choose to skip passkey registration. During the standard liveness check, which includes zoom, head turn, and smile, a facial profile is created. Before signing, an additional “Smile” step is performed to verify that the person authenticating matches the registered user.

**Integration**

<mark style="color:$danger;">Please review the changes carefully as major a releases may impact your integration.</mark>

* **WebView integrations:** WebView integrations may be affected and should therefore be carefully validated.
* **Non-WebView customers:** For customers who do not use a WebView, the feature integrates seamlessly into the existing system and does not introduce any integration risks or changes.
* **API changes:** This feature does not introduce any API changes.

**Requirements**

* The user must use the same device and browser for both registration and authentication.
* The facial match score during registration must be sufficiently high.
* The registration and authentication methods must match. Mixed flows are not supported (e.g. Passkey registration followed by FaceAuth authentication, or vice versa).

**Exception Handling**&#x20;

If one or more requirements cannot be fulfilled, users are offered the same two options as in WebAuthn exception scenarios:

* start a new identification
* abort the process