Introducing a new Issuer/SID AltSecID

If you work in smartcard federated authentication environments, here’s a much-anticipated security feature for you. Starting with the September 9, 2025 Windows security update, a new Alternate Security Identity (AltSecID) is made for just-in-time certificate deployments in Windows Server 2022 and later.

What are weak and strong mappings in Active Directory?

All certificate names must be correctly mapped onto the intended user account in Active Directory (AD). If there’s a likelihood that they aren’t, we call these mappings weak. Weak mappings give rise to security vulnerabilities and demand hardening measures such as Certificate-based authentication changes on Windows domain controllers.

As part of our May 2022 updates, Microsoft added the Security Identifier (SID) in certificate strong mapping to allow automatic certificate deployments that are compliant with the strong mapping requirements. Unfortunately, this feature is not compatible with deployments that require an explicit mapping between a certificate and a user in Active Directory when the UseSubjectAltName setting is configured. Disabling UseSubjectAltName blocks the use of user principal names (UPNs) and SIDs in the certificate. This article explains how to disable the subject alternative name (SAN) to use explicit mappings: How to disable the SAN for UPN mapping - Windows Server. To solve this problem, Microsoft is adding the new Issuer/SID AltSecID to allow the SID-in-certificate to be used in deployments that require explicit mappings.

Key features and benefits of Issuer/SID AltSecID

This new AltSecID provides two primary features:

1. Compliance with strong certificate mapping enforcement. The Issuer/SID AltSecID is recognized as a form of strong mapping because the SID serves as a unique identifier within Active Directory. This method is compliant with the enforcement mode of certificate-based authentication changes on Windows domain controllers.
2. Support for complex PKI deployments. Large enterprise or government public key infrastructure (PKI) deployments often restrict Active Directory from reading the SAN field in certificates. As such, they prevent domain controllers (DCs) from utilizing the SID-in-certificate feature. To enable SID-in-certificate, modifications to these configurations would be necessary. The new AltSecID allows the use of SID-in-certificate for strong mapping while maintaining existing deployment practices.

How to deploy the new Issuer/SID AltSecID

Domain administrators can manually assign Issuer/SID AltSecIDs to users in Active Directory through the altSecurityIdentities attribute. The Issuer/SID AltSecID follows this format:

X509:<I>Issuer<SID>Sid

It contains two components:

1. Issuer: A tag that contains the name of the Certificate Authority that is issuing the certificate. This is the same “Issuer” tag as the “Issuer/SerialNumber” AltSecID.
2. SID: A tag that contains the SID of the user’s account in Active Directory.

When a user presents a certificate to a Windows domain controller (DC) for authentication, the DC evaluates all potential AltSecIDs that could map the certificate to the user. The DC then verifies whether the AltSecID exists within the user's altSecurityIdentities attribute in Active Directory. If the user's account includes the "Issuer/SID" AltSecID in the altSecurityIdentities attribute, the DC verifies both of the following:

1. The SID in the Issuer/SID AltSecID matches the SID in the certificate.
2. The SID in the Issuer/SID AltSecID matches the SID in the user’s account in Active Directory.

If both conditions are true, the DC considers the mapping to be valid and marks the mapping as strong.

Example

For user domainuser:

DistinguishedName : CN=domainuser,CN=Users,DC=contoso,DC=com

Name              : domainuser

ObjectClass       : user

SamAccountName    : domainuser

SID               : S-1-5-21-3115709231-3062884184-850958272-1104

And for certificate issuer:

CN=CONTOSO-DC-CA,DC=contoso,DC=com

The new AltSecID string on the “domainuser” object in AD will be:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SID>S-1-5-21-3115709231-3062884184-850958272-1104

Then any certificate that has the S-1-5-21-3115709231-3062884184-850958272-1104 SID in the SID-in-certificate extension may be used to authenticate the domainuser account in Active Directory in compliance to the changes highlighted in Certificate-based authentication changes on Windows domain controllers.

Here’s a sample cmdlet you can use:

set-aduser domainuser -replace @{altSecurityIdentities='X509:<I> DC=com,DC=contoso,CN=CONTOSO-DC-CA<SID>S-1-5-21-3115709231-3062884184-850958272-1104'}

Consider adding the Issuer/SID AtlSecID strong mapping on Active Directory to meet compliance standards for complex PKI deployments in Windows Server 2022 and later. We hope this helps your automatic certificate deployments going forward.

Continue the conversation. Find best practices. Bookmark the Windows Tech Community, then follow us on LinkedIn or @MSWindowsITPro for updates. Looking for support? Visit Windows on Microsoft Q&A.