The following material will have a look into upcoming changes to TLS certificates that have been recently announced (and will be due soon), as well as what their impact will be for the Open Banking / Open Finance ecosystem and the Verification Of Payee (VOP).
Background
When certificates are used by web servers to prove their identity towards browsers/users and secure the data transfer through HTTPS, their purpose is “Server Authentication”. This is a regular procedure meant to help users ensure they are interacting with a trustworthy counter-party.
So far, it was common practice that TLS certificates for Server Authentication were issued by public Certificate Authorities (CAs), such as Let’s Encrypt, DigiCert, Sectigo, not only for “Server Authentication” but also for the purpose of “Client Authentication” (see as an example in the image below).
Client Authentication is typically used in highly sensitive contexts when not only the server needs to authenticate towards the client, but also when the client needs to prove its identity and authenticate itself towards the server via cryptographic certificates (which results in a mutual TLS (mTLS) connection).
The purpose of a certificate is defined in its Extended Key Usage (EKU) section – for “Server Authentication” via the field id-kp-serverAuth with OID 1.3.6.1.5.5.7.3.1, for “Client Authentication” via the field id-kp-clientAuth with OID 1.3.6.1.5.5.7.3.2.
The CA/Browser Forum decided in October 2024 to stop supporting public TLS x.509 certificates for Server Authentication that are issued for the additional purpose of Client Authentication.
The reasons for this decision are centred on more security and less complexity:
- If the private key of a Server Authentication certificate might get compromised in the future, then it cannot be misused for Client Authentication with the same certificate (and the same identity), as this will not be supported anymore.
- There will be a clear separation of purposes for certificates with less EKU values supported, resulting in easier certificate validations.
How will this happen?
After the CA/B Forum announced this change, issuers of TLS certificates (the CAs) and web browser developers have responded to this with a phased approach to drive this change to the market:
What happens next?
In a first phase, CAs will not issue Server Authentication certificates that contain the additional purpose of Client Authentication anymore. For a certain transition period they might still issue double-purpose certificates but only on demand.
The second phase (and what may be problematic in specific use cases) is that web browsers will not accept Server Authentication certificates that contain the EKU for Client Authentication too. In these situations, the browsers will reject connections to web servers directly.
Timeline for Google Chrome:
- Until the middle of May 2026: all major CAs will stop issuing public TLS certificates that include the Client Authentication EKU.
- June 15, 2026: Google Chrome will accept newly issued public TLS certificates only when they contain the Server Authentication EKU. Certificates containing both EKUs and which are issued before that date will still be accepted.
- March 15, 2027: Google Chrome will accept certificates only if they have the Server Authentication EKU and do not contain the Client Authentication EKU for all public TLS certificates.
More details can be found directly in the Chrome Root Program Policy. As of April 2026, Banfico is not aware of the timeline of other browsers.
Impact on PSD2 Open Banking and Verification Of Payee (VOP)
There is good news for most of you: there is no direct impact expected on PSD2 Open Banking or VOP APIs.
PSD2 Open Banking and EPC VOP communication is based on a machine-to-machine exchange of messages via APIs. Although they require an mTLS secured channel for communication, the involved certificates to establish this type of connection are validated by the sending client and the receiving server systems, not by any web browser.
The server-side validations by ASPSP/PSP, as well as the client-side validations by TPP/PSP, must ensure they accept the certificates as defined by the ETSI standard.
What this means is that even though the PSD2 QWAC used for Open Banking and VOP contains both Client and Server Authentication in the EKU, they are still compliant with the latest ETSI TS 119 496 standard that defines PSD2 QWAC/ QSealC certificates for Open Banking usage (see Note 3 in section 5.3 in the aforementioned document). In this case, the client software must ensure that these certificates are still accepted.
Public TLS certificates that are not PSD2 QWAC are expected to serve only the purpose of Server Authentication soon, as a result of the transition CAs are going through now.
The low impact of this change on VOP certificates has also been confirmed by the European Payments Council, which stated that VOP API communication is not expected to be affected, as it does not rely on browser-based TLS Client Authentication.
An overview of the impacts for the different usages of QWAC certificates is available in the following table:
| QWAC using EKU with | |||
|---|---|---|---|
| Client Authentication only | Client Authentication AND Server Authentication |
||
| Applied for Client Authentication (mTLS) |
in a browser | not affected | should not be affected → better test |
| in an API client | not affected | not affected | |
| Applied for Server Authentication (TLS) |
accessed via a browser | n.a. | not possible in the future |
| accessed via API client | n.a. | not affected | |
Areas to watch out for: Open Banking compliance API fallback flows, and Developer Portals
Although the CA Browsers Forum change discussed here has a low impact on PSD2/ VOP use cases, two areas warrant specific attention:
- Some ASPSP/PSP developer portals require mTLS secured browser connections for accessing API documentation details. This means TPP developers must configure their PSD2 QWAC in their local certificate store / keychain for Client Authentication. Although we expect Client Authentication in browsers not to be affected, it is worth having a look into it to ensure proper functioning (this is the use case marked in yellow in the table above).
- Some Open Banking compliance implementations include a contingency mechanism for when a primary dedicated interface (the API) is unavailable. If this fallback solution is offered to TPP via a modified version of e-banking that enforces mTLS-based TPP connections and if the server side is secured by a PSD2 QWAC containing both Client and Server Authentication, then the connection might be rejected by scraping solutions based on headless browser technologies (e.g. Chromium). Here, the ASPSP/PSP must ensure that the server side uses dedicated public TLS certificates that only have the EKU for Server Authentication (this is the use case marked in red in the table above).
The market is still adjusting to the changes, but if you want to be prepared, Banfico recommends:
- Reviewing the technical architecture of your API fallback and developer portal flows
- Confirming whether browser-based mTLS with public TLS certificates is used at any point
- If yes, assessing if the usage of QWAC from the client application will still be supported
- Ensuring that no server sided TLS certificates are used that contain the EKU for client authentication
- Engaging your technical team or third-party provider to validate the fallback solution implementation
Fallback flows are often less well-documented than primary interfaces, so it’s better to validate now than uncover issues close to the June 2026 deadline.
If you have any questions about how these changes apply to your implementation, please reach out to your compliance or technical contact.
Action point for all PSPs: review your certificate usage
Even where PSD2 Open Banking/VOP is not affected, we recommend taking this opportunity to review your certificate estate:
- Check whether any of your flows use Client Authentication certificates issued by public CAs in a browser-based context
- If yes, plan migration to a private PKI or dedicated PKI hierarchy ahead of June 2026
- Confirm how your certificates were acquired and whether they are scoped to machine-to-machine use only
- Engage your CA or PKI provider early, as migration lead times can be significant
At Banfico, we will continue monitoring this matter and will issue further guidance if any formal scheme changes or news regarding the public TLS certificate changes are announced.
In the meantime, if you have any questions, do not hesitate to reach out to us at vop@banfico.com.