Microsoft’s Certificate Strong Mapping Deadline: Must Knows for September 2025 Patch Tuesday and NDES SCEP

Microsoft will permanently remove certificate strong mapping bypass options on September 10, 2025 with the roll-out of the Patch Tuesday updates on that date, marking the end of a three-year security transition that began with KB5014754 in May 2022.

Must Knows

• Domain Controllers running Server 2016 and below do not support Strong Mapping with Offline (Intune / Jamf Certificates) Upgrade these domain controllers to 2019 or above.
• Look out also for UPN mismatches I’ve seen this in a few environments.
• Continue searching for Event 39 and other events before deadline to minimize impact

Should I be concerned? (Event Id’s on domain controllers)

Unless you’re seeing Event ID 39 on your domain controllers you probably have little to worry about.

Other less likely Event ID’s are 40, (48 For Windows Server 2008 R2 SP1 and Windows Server 2008 SP2
or 41, (49 For Windows Server 2008 R2 SP1 and Windows Server 2008 SP2)

If you and your team have done absolutely nothing to Domain controllers in last few years to deal with this and you’ve had no issues its unlikely you have anything to prepare for in September as you should have seen issues by now if you haven’t put registry keys in to ignore strong mapping. Patches released to Domain controllers in Feb 2025 meant that strong mapping got enforced unless you added some reg keys to bypass strong mapping or unless your environment is not patched.

More info on those EventID’s

ID 39 No strong certificate mappings could be found, and the certificate did not have the new security identifier (SID) extension that the KDC could validate. – This is the most likely Event showing that no mapping exists.

ID 40 The certificate was issued to the user before the user existed in Active Directory and no strong mapping could be found. (quite rare to get this scenario)

ID 41 The Key Distribution Center (KDC) encountered a user certificate that was valid but contained a different SID than the user to which it mapped. As a result, the request involving the certificate failed.
(Again quite rare would mean you have mismatches in AD)

Some scenarios – your environment is one of the following

Scenario 1) Purely on Premise devices are managed on premise and certificates delivered by our internal PKI –

Microsoft released KB5014754 in May 2022. If your certificate authority received this update, all templates in your environment automatically received the new OID mentioned in the back to basics section below. The only certificates that could be affected are user or computer certificates issued before May 2022 that are still in use.

Most environments in this scenario are already compliant. Just ensure there are no Event ID 39 entries. The main risk is if users or computers have certificates from your PKI that were issued before 2022 (i.e., if you have 3-5 year certificate expiry periods).

Check and mitigation – Worth double checking Event ID’s to make sure and follow steps if events seen.

Scenario 2) On Premise Identities that sync with Entra and Intune and or Jamf devices that utilize NDES to get Certificates –

This is the most likely scenario where you could still have Event ID 39, with users still not getting certificates that are strong mapped.

Check domain controllers for event ID’s and follow mitigation steps at end of this post

If you are reading this post and are on the journey of mitigation**—you added the registry keys previously to Domain Controllers and you are still going through updates to certificates, etc.—**this post is mainly for you.

Event ID 39 serves as the definitive indicator for organizational risk: any domain controller logging Event ID 39 reveals certificates that will fail authentication when enforcement begins. With approximately one month remaining until the deadline

This specific event occurs when the Key Distribution Center encounters valid certificates that cannot be mapped securely to user accounts, lacking both explicit strong mappings and the required Security Identifier (SID) extensions.

Scenario 3) Fully cloud all identities purely entra you get your certs from public pki –

Sit back relax and enjoy you have nothing to prepare, certificates don’t need to map back to on premise as you have no on premise.

Timeline of Certificate Strong Mapping and enforcement

May 2022 – – Microsoft’s Monthly Update (KB5014754) automatically added an extension to certificate authority templates (OID 1.3.6.1.4.1.311.25.2). Domain controllers could now provide Event ID 39 warnings so we could identify certificates that are not strong mapped.

September 2024 – – Microsoft enabled the ability to add strong mapping in Intune (However, 2016 DCs and below cannot read the URL tag it uses – more on this in the troubleshooting section below).

Jan 2025 – Apple management system Jamf provided advice and KBs on adding strong mapping for Apple certificates.

Feb 2025 – Microsoft pushed domain controllers to full enforcement via Patch Tuesday. Admins could add a registry key (StrongCertificateBindingEnforcement on DCs) to bypass enforcement of strong mapping and continue receiving Event ID 39 warnings that mapping is not present.

You may have added a reg key for this
HKLM:\System\CurrentControlSet\Services\KDC StrongCertificateBindingEnforcement Dword Value = 1

Sept 2025 – Full enforcement, doesn’t matter if you have regkeys in place on DC’s, they will be ignored, so you must aim to be fully ready with strong mapped certs and attempt to get no warnings on your DC events by this date.

Back to basics

What is strong mapping or strong mapped certificates?

Strong mapping is Microsoft’s term for requiring certificates to contain specific attributes that directly tie them to Active Directory user accounts, rather than relying on weaker validation methods.

Traditional certificate authentication has relied on relatively loose validation—often just matching a username or similar identifier. Strong mapping tightens this significantly by requiring certificates to include specific attributes, such as attributes in the Subject Alternative Names (SANs), that link the certificate to a particular Active Directory account.

The fundamental security problem Microsoft is solving

Before strong mapping, certificates could authenticate using “weak” methods like matching the certificate’s subject name to a username. This created serious security vulnerabilities—an attacker could potentially create a certificate with the right subject name and gain unauthorized access. Strong mapping prevents this by requiring cryptographic secure identifiers that can’t be easily forged.

What Microsoft’s 2022 update actually did

When Microsoft released KB5014754 in May 2022, they quietly updated certificate authority templates to automatically include a new extension with OID 1.3.6.1.4.1.311.25.2. This extension does something very specific:

It embeds the user’s Security Identifier (SID) directly into the certificate.

Think of it like this – before 2022, certificates were like ID cards that just had your name on them. Anyone could potentially create a fake ID with the same name. After the update, certificates became like ID cards with your unique Social Security number embedded in them – much harder to fake.

Here’s what happens behind the scenes:

1. User requests a certificate from a Windows Certificate Authority
2. The CA looks up the user’s SID in Active Directory (their unique security identifier)
3. The CA automatically embeds that SID into the certificate using the new OID extension
4. When the certificate is used for authentication, domain controllers can verify the SID matches the user

Behind the scenes: What happens when users with existing certificates try to authenticate

1. User attempts authentication – John.Doe connects to WiFi, VPN, or other network resource using his certificate
2. Authentication request reaches domain controller – The RADIUS server (or authentication system) forwards John’s certificate to the domain controller for validation
3. Domain controller performs strong mapping check – The DC examines the certificate looking for:
   • Security Identifier (SID) extension with OID 1.3.6.1.4.1.311.25.2
   • Explicit strong mapping in Active Directory’s altSecurityIdentities attribute
   • Other approved strong mapping methods
4. Validation result determines access:
   • Strong mapping found → Authentication succeeds
   • No strong mapping found → Domain controller logs Event ID 39 and (currently) allows access with a warning (you put the registry workaround in)
   • After September 2025 → No strong mapping = authentication fails completely

Intune and Jamf (Apple) certificates using your PKI

In the case of custom created and offline certificates, which is what Intune and Jamf for Apple use to deliver certificates to devices, a new mapping was introduced which is a Subject Alternative Name (SAN) tag-based URI with the following format

URL=tag:microsoft.com,2022-09-14:sid:<value> and it links each cert back to the on premise SID

JAMF for Apple

Check and remediate

Going back to basics, you have until mid-September 2025 before this gets enforced, so if you’re still scrambling to get ready:

Events are everything – I’m in environments with 50,000 users where I could see every single user would have failed come September and not been able to connect to WiFi or VPN. Those numbers are now down to 2 a week as I clean up the last remaining random issues with UPN mismatches or devices not receiving certificates.

Utilize Powershell to check for event 39 or other events

Check for Event ID 39 on local DC

Get-EventLog -LogName System | Where-Object { $_.EventID -eq 39 }

More detailed check with date range

Get-EventLog -LogName System -After (Get-Date).AddDays(-7) | Where-Object { $_.EventID -eq 39 } | Format-List

Check specific timeframe

Get-WinEvent -FilterHashtable @{LogName=’System’; ID=39; StartTime=(Get-Date).AddDays(-30)}

Or if you have SCCM (ConfigMgr) Use CMPIVOT against all domain controllers

I’m running a CMPivot to look for last 12hours of error 39 against all DC’s

WinEvent(‘System’, 12h) | where ID == 39

Server 2016

Unfortunately, Microsoft Server 2016 domain controllers do not support strong mapping for offline certificates (i.e., through NDES, Intune, or Jamf).

This means if you have:

• Server 2016 DCs in your environment
• AND certificates delivered through Intune/Jamf using the SAN URI format

Your certificates will not authenticate properly, even with correct strong mapping.

Support tip: Implementing strong mapping in Microsoft Intune certificates | Microsoft Community Hub

Workaround options:

• Upgrade domain controllers to Server 2019 or newer
• The registry bypass only lasts until September 2025

Last Cleanups for user certs that need renewing, being stubborn etc

For stubborn certificates that won’t update properly, I created this script: tim-beer/NDES-and-Certs

This script is designed for NDES SCEP certificates in my environment. It scans devices for any user certificates that:

• Originated from your PKI
• Are associated with the user account
• Do not contain the Microsoft strong mapping tag (URL format)

What it does:

• Identifies certificates lacking strong mapping extensions
• Useful for cleanup operations before the September deadline

This has been useful over 50k devices just cleaning up some final stubborn ones where I see the events still coming in, the script looks for non strong mapped removes it and asks for an Intune Resync

References

Richard Hicks all round cert and auth guru

Strong Certificate Mapping for Intune PKCS and SCEP Certificates | Richard M. Hicks Consulting, Inc.

Strong Certificate Mapping Enforcement February 2025 | Richard M. Hicks Consulting, Inc.

Microsoft

Support tip: Implementing strong mapping in Microsoft Intune certificates | Microsoft Community Hub

KB5014754: Certificate-based authentication changes on Windows domain controllers – Microsoft Support

Apple Jamf

Supporting Microsoft Active Directory Strong Certificate Mapping Requirements – Technical Articles | Jam