The KB article from Microsoft classifies certificate-to-AD-account mapping techniques as "strong" or "weak"; "weak" techniques will be disabled by default at some point in the future for various authentication scenarios (including domain logon of VDAs).

UPN in SubjectAltName, as used by FAS, is classified as "weak".

However, upgrading the Microsoft CA results in issued certificates which contain a new "SID" extension (OID 1.3.6.1.4.1.311.25.2) - the extension specifies the SID of the user's AD account. UPN-to-AD-account mapping with an additional SID claim is considered "strong".

Therefore, for customers using a Microsoft CA (the only CA type currently supported), it is believed KB5014754 will have no impact, provided the CAs are upgraded.

Customers using a non-microsoft CA will need to check with their CA vendor, to ensure that user certificates contain the new extension.

Further information

Microsoft provides two broad techniques for mapping certificates to AD accounts:

UPN in SAN (SubjectAltName) - if the UPN is present in the certificate's SAN, the UPN in the certificate is matched to an AD account's UPN. FAS uses this technique.
AltSecId - this is an AD attribute of the user account which specifies which certificate(s) correspond to the account. Generally speaking, this technique is not suitable for FAS because it relies on static elements of a certificate, such as its serial number.
Technique (2) is used if the certificate does not contain a UPN in the SAN, or if technique (1) is disabled by policy (it is enabled by default).

Even after the changes described by this KB, technique (1) is still triggered by the presence of a UPN in the certificate's SAN, however, the user's SID must also be present in the certificate.

The SID extension is created by an upgraded Microsoft CA provided the following radio button is selected in the template:

The above screenshot shows the out-of-the-box settings for the FAS template i.e. "UPN in SAN" and "Build from AD information", therefore FAS certificates will have a UPN and SID which is a strong account mapping.

If for some reason the customer has selected the "Supply in the request" radio button, the certificate will not contain the SID extension, because FAS doesn't currently supply this in the certificate request.

From 2402 FAS sends the SID extension in the request.

To resolve any issues caused by the registry key workaround expiring do the following:

1. Edit the citrix smartcard certificate and confirm the "supply in the request" button is not selected

2. Upgrade FAS to 2402 or later

Microsoft released Patch KB5014754 on May 10th 2022. This patch added a new SID extension to certificates. A workaround for any issues caused by this new change was to create a registry key called StrongCertificateBindingEnforcement. However, that registry key stopped support on September 9, 2025 Which may cause issues for older FAS environments which were using this workaround.