Why is Microsoft Requiring Security Identifiers (SIDs) on Certificates for NPS Authentication?
In a move aimed at bolstering Windows network security, Microsoft has introduced a new requirement for all certificates used in Network Policy Server (NPS) EAP-TLS authentication: the inclusion of a Security Identifier (SID) as an attribute in the client certificates. This change directly addresses previously reported privilege escalation vulnerabilities and will become mandatory by September 2025.
What Prompted this Change?
This update is a direct response to vulnerabilities disclosed in CVE-2022-34691, CVE-2022-26931, and CVE-2022-26923, which affected Windows Domain Controllers. These CVEs revealed pathways for privilege escalation within Windows environments that relied on certificate-based authentication.
Although the vulnerabilities were reported back in 2022, it wasn’t until a recent Windows Server update that Microsoft began enforcing a stricter certificate validation process. While the change has broader implications across Windows infrastructure, here we specifically focus on its impact on NPS environments that use both Active Directory and Entra ID. From now on, client certificates must include the SID field to establish strong trust, or authentication requests will be denied.
What Makes the SID Field so Important?
A SID is a unique, immutable value used by Windows systems to identify users, groups, and other entities within a domain. Once an SID is assigned to an account, it will never be reused—even if the account is deleted or renamed. This makes it an extremely reliable identifier and a strong defense against spoofing attempts.
By tying certificate authentication to the SID, Microsoft ensures that certificates can’t be used to impersonate other users or entities, effectively eliminating one of the primary exploits behind the CVEs mentioned earlier.
You can learn more about SIDs from Microsoft’s official documentation here.
How Do I Include SIDs on Client Certificates?
There are two primary ways to update client certificates with SIDs:
Automated Certificate Reissuance
If your PKI platform supports automation, you can reissue all client certificates with the SID value pulled directly from Active Directory. This is the recommended method since it ensures consistent and error-free updates.
Your PKI provider should support:
- SID extraction from AD
- Automatic certificate issuance
Manual PowerShell Update (For Legacy Environments)
If the above-mentioned automation isn’t an option, trust needs to be established manually by putting the respective Root CA information on each user’s device. This process is said to take care of the strong mapping and requires PowerShell scripting.
Domain administrators can either run the following command on each user’s terminal or can also mass update all the AD users with programming, which in turn requires the Development team’s time and effort.
set-aduser 'DomainUser' -replace @{altSecurityIdentities= "X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>1200000000AC11000000002B"}
Note: Issuer values like CN=CONTOSO-DC-CA and serial numbers should be adjusted to match your Root CA settings.
This command adds the Root CA information to the AD user’s certificate store, establishing strong trust between the NPS and the user’s certificate.
Who Needs to Pay Attention?
This change will impact any organization using NPS (in a hybrid environment – Active Directory and Entra ID) for RADIUS authentication. If you rely on EAP-TLS authentication for your NPS and don’t update your certificates with SIDs, your authentications will begin failing once the Microsoft mandatory enforcement begins.
How SecureW2 has Prepared
SecureW2 has built a new CSR Attribute Extraction Policy specifically for Intune-based enrollments using on-prem Active Directory, to support Microsoft’s SID requirement. This allows us to automatically extract device and user attributes, including SIDs from the CSR, and include them in issued certificates.
Here’s what you need to do:
- New to SecureW2? Start by Creating an Intermediate CA for issuing trust certificates to all your Intune devices. Add a custom Certificate Template under PKI > Certificate Authorities > Certificate Templates to ensure all your client certificates have the same format, by automatically including the SID attribute
- Already using our Intune SCEP enrollment? You can skip the CA step and go straight to updating your certificate template. Then re-enroll all your Intune-managed devices with the new client certificates.
We’ve added the following extension under the URI field of our default templates:
${/csr/san/uniformresourceidentifier}
This pulls the SID value from Intune and includes it in the client certificate without much effort.
SecureW2’s flexible templating system also future-proofs you against any Microsoft enhancements—allowing you to support various attributes sent via RFC822, UPN, DNS, URI, or others.
Here’s an example of a client certificate with the SID attribute included:
Final Thoughts: Simplify Authentications with a Modern RADIUS
Microsoft requires Security Identifiers (SIDs) in certificates used for NPS’ EAP-TLS authentication to close critical security gaps exposed by past vulnerabilities. By binding all client certificates to their respective immutable SIDs, organizations gain a more reliable and tamper-proof method of verifying identity, significantly reducing the risk of privilege escalation.
Transitioning to these requirements involves a modern PKI that can support the necessary automation. SecureW2 has proactively aligned its Dynamic PKI with these changes by developing a CSR Attribute Extraction Policy, automating the integration of SIDs into client certificates during enrollment, particularly for those managing devices via Intune.
However, this change has prompted many organizations to move away from NPS and Active Directory entirely and consider SecureW2’s RADIUS service. Our Cloud RADIUS is a completely managed service, with an available SLA of 99.999%. It works directly with all major cloud identity and device management to validate users and devices in real-time, and dynamically authorize them access. If you’re one of those organizations looking for a cloud-native RADIUS solution, reach out to us.
