Learn more about implementing strong mapping in Microsoft Intune certificates.

Updated 11/25/24: Strong mapping for SCEP certificates has now been fully rolled out, with support available on Windows, iOS, macOS, and Android operating systems.

With the May 10, 2022 Windows update (KB5014754), changes were made to the Active Directory Kerberos Key Distribution (KDC) behavior in Windows Server 2008 and later versions to mitigate elevation of privilege vulnerabilities associated with certificate spoofing. Windows will enforce these changes on February 11, 2025. If a certificate can't be strongly mapped, authentication will be denied. The option to revert to Compatibility mode will be available until September 10, 2025, after which the StrongCertificateBindingEnforcement registry value will no longer be supported. 

We’ve received feedback from customers wanting to understand how this impacts certificates delivered by Intune. In February 2024, we initiated the rollout of strong mapping for SCEP certificates in Intune. However, based on customer feedback, we paused the rollout. Instead, we're now introducing support for a SID variable in SCEP profiles to give more control to customers to choose if they would like to have the SID in the certificate for strong mapping, particularly in scenarios where they authenticate against KDC for certificate-based authentication.

This feature has rolled out in the October (2410) service release for Windows, iOS, and Mac with Android support in the November (2411) service release. The variable, OnPremisesSecurityIdentifier, allows customers to test against their infrastructure and roll out at their own pace to ensure other applications or systems they may use support the new certificate format.

Enablement of certificate strong mapping in Active Directory

To address security concerns related to certificate spoofing, Windows introduced changes to the KDC that requires certificates for a user or computer object to be strongly mapped to Active Directory. These changes ensure a more robust validation process during certificate-based authentication.

Various mapping options are allowed, including manual mapping and automatic mapping using the object identifier (OID) extension with the device or user security identifier (SID) for online certificate templates from Active Directory Certificate Services (AD CS).

In case of manual and offline certificates, which is what Intune uses to deliver certificates to devices, a new mapping has been introduced which is a Subject Alternative Name (SAN) tag-based URI with the following format.

URL=tag:microsoft.com,2022-09-14:sid:<value>

When a user or device presents a certificate for authentication in Active Directory, the KDC will check if the required mappings are present to verify if the certificate is strongly mapped and issued to the specific user or device.

Adding SID to SCEP certificates for ADCS/KDC changes

To address the ADCS/KDC changes, we’re introducing the capability for admins to include the On-premises Security Identifier (SID) in SCEP certificates. Admins can either edit existing SCEP profiles or create new ones to incorporate the OnPremisesSecurityIdentifier variable with a URI tag as shown below. Note that URI is the only supported attribute for OnPremisesSecurityIdentifier.

A screenshot of the SID variable added to the SCEP profile in Microsoft Intune admin center.

Once you’ve added it to the SCEP profile, Intune will append the SID value along with the tag “tag:microsoft.com,2022-09-14” to the SAN attribute of the certificate. The SAN now includes the object's SID formatted as \"tag:microsoft.com,2022-09-14:sid:<OnPremisesSecurityIdentifier>\". This URI is included in the SCEP payload and sent through the mobile device management (MDM) channel. 

Example screenshot of a certificate that has been issued with a SAN URI.

For user certificates, the variable resolves to the user SID, while for device certificates, it resolves to the device SID. Additionally, the KDC logic for evaluating how certificates are mapped has been updated to check a URI based on a Subject Alternative Name (SAN) tag that works with SCEP. This solution works with Windows Server 2019 and above. 

Recommendations for safe implementation

Testing

It's essential to thoroughly test new configurations on a select group of devices before rolling them out broadly. Create a profile with the variable \"OnPremisesSecurityIdentifier\" and apply it to this group. Ensure compatibility with applications, Intune-integrated conditional access, NAC solutions, and any certificate-based authentication in your networking infrastructure.

Phased certificate renewal

Renew certificates in phases by creating a new SCEP profile and gradually targeting it to groups of users or devices. This approach helps to avoid overwhelming your certificate authority and minimize disruptions.

Note: If you notice the tag \"tag:microsoft.com,2022-09-14:sid:<value>\" in the certificates already issued within your organization, your tenant received the initial KDC change in February 2024. For any certificates that don’t include this SID, they must be reissued before February 2025 to ensure they contain the SID and authentication isn‘t denied. Alternatively, you can enable compatibility mode by adjusting the registry settings to allow for automatic certificate renewal. Specifically, you will need to change the registry key StrongCertificateBindingEnforcement to 1, as defined in the KB5014754.This registry change must be completed before February 2025, and all certificates should be renewed before September 2025 to avoid any disruption.

Implementation for PKCS certificates

The implementation of strong mapping in PKCS certificates is now available via certificate connector updates in the version 6.2406.0.1001. For information about the latest version and how to update the certificate connector, review Certificate connector for Microsoft Intune and Update certificate connector for KB5014754 requirements.

For the PKCS changes to take effect, you need to update the connector, make the below registry change, and then restart the connector service in that order.

Important: Before you modify the registry key, review these articles on how to change the registry key and how to back up and restore the registry:

\n
• How to back up and restore the registry in Windows - Microsoft Support
\n
• How to add, modify, or delete registry subkeys and values by using a .reg file - Microsoft Support
\n

Modify the value for the following registry key:

[HKLM\\Software\\Microsoft\\MicrosoftIntune\\PFXCertificateConnector]:(dword)EnableSidSecurityExtension

Value: 1

After modifying the registry key, restart the connector services in order for the changes to take effect. If you would like to revert the changes, restore the registry changes and create new profile such that certificates are re-issued without the SID attribute.

Known issue: For Windows, when issuing the PKCS certificate you may see the following exception:

Strong mapping prerequisites for Intune

The changes introduced by Intune apply to Microsoft Entra hybrid joined users and devices that authenticate against Active Directory using Intune-issued certificates. For strong mapping to work for these users and devices, the following prerequisites must be met:

\n
• User and device SID must be synchronized with Microsoft Entra ID. For more information, read How objects and credentials are synchronized in a Microsoft Entra Domain Services managed domain.
\n
• For device certificates, only Microsoft Entra hybrid joined devices will have SID information, so strong mapping changes are applicable only to Windows devices that are Microsoft Entra hybrid joined. For other device types, like iOS or Android, strong mapping is not supported for device certificates, and user certificates should be used instead.
  
  
\n

Strong mapping is supported for:

\n
• Windows 10
\n
• Windows 11
\n
• Windows Server 2019 and later
\n
• iOS
\n
• macOS
\n

Note: Android support is expected to rollout in November 2024.

SID support for third-party CA and NAC partners

We are working closely with partners to ensure readiness for all third-party certification authorities (CA) and network access control (NAC) solutions.  

The following CA partners have been verified to be compatible with the SID inclusion from Intune: 

\n
• Cogito Group
\n
• DigiCert
\n
• EasyScep
\n
• EJBCA
\n
• Entrust
\n
• EverTrust
\n
• HID Global
\n
• IDnomic
\n
• Keyfactor Command
\n
• KeyTalk
\n
• Keytos
\n
• Nexus Certificate Manager
\n
• SCEPman
\n
• Sectigo
\n
• Venafi
\n
• Securew2 
\n

If you're using NAC solutions with Intune, it's important to check compatibility with the SID included in certificates. We're working closely with various NAC partners to ensure smooth integration. Here's the current status: 

\n
• Portnox – Completed
\n
• Cisco – In progress\n
  \n
  • \n

    ISE 3.2 P7 – Released in October 2024

    \n
  \n
  • \n

    ISE 3.3 P4 – Planned for October 2024

    \n
  \n
  • \n

    ISE 3.4 P1 – Planned for November 2024

    \n
  \n
  • \n

    ISE 3.1 P10 – Planned for January 2025

    \n
  \n
  \n
\n
• Citrix – In progress
\n
• F5 – In progress
\n
• Ivanti – In progress
\n
• Forescout – In progress
\n
• Aruba Clearpass – Completed, Intune extension version 6.3.3  
\n

We recommend thorough testing of any applications, Intune-integrated CAs, NAC solutions and networking infrastructure where clients may utilize certificates for authentication to ensure optimal functionality. 

If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam.

Post updates:

03/18/24: Based on customer feedback, we paused the rollout for this update. More information can be found above.

10/10/24: Added steps to implement SID in SCEP and PKCS certificates, along with information on SID support for third-party CA and NAC partners.
10/29/24: Updated status of NAC partners.
11/14/24: Updated to include a PKCS known issue with resolution (KB5046616).
11/25/24: Strong mapping for SCEP certificates has now been fully rolled out, with support available on Windows, iOS, macOS, and Android operating systems.

Updated 11/25/24: Strong mapping for SCEP certificates has now been fully rolled out, with support available on Windows, iOS, macOS, and Android operating systems.

With the May 10, 2022 Windows update (KB5014754), changes were made to the Active Directory Kerberos Key Distribution (KDC) behavior in Windows Server 2008 and later versions to mitigate elevation of privilege vulnerabilities associated with certificate spoofing. Windows will enforce these changes on February 11, 2025. If a certificate can't be strongly mapped, authentication will be denied. The option to revert to Compatibility mode will be available until September 10, 2025, after which the StrongCertificateBindingEnforcement registry value will no longer be supported. 

We’ve received feedback from customers wanting to understand how this impacts certificates delivered by Intune. In February 2024, we initiated the rollout of strong mapping for SCEP certificates in Intune. However, based on customer feedback, we paused the rollout. Instead, we're now introducing support for a SID variable in SCEP profiles to give more control to customers to choose if they would like to have the SID in the certificate for strong mapping, particularly in scenarios where they authenticate against KDC for certificate-based authentication.

This feature has rolled out in the October (2410) service release for Windows, iOS, and Mac with Android support in the November (2411) service release. The variable, OnPremisesSecurityIdentifier, allows customers to test against their infrastructure and roll out at their own pace to ensure other applications or systems they may use support the new certificate format.

Enablement of certificate strong mapping in Active Directory

To address security concerns related to certificate spoofing, Windows introduced changes to the KDC that requires certificates for a user or computer object to be strongly mapped to Active Directory. These changes ensure a more robust validation process during certificate-based authentication.

Various mapping options are allowed, including manual mapping and automatic mapping using the object identifier (OID) extension with the device or user security identifier (SID) for online certificate templates from Active Directory Certificate Services (AD CS).

In case of manual and offline certificates, which is what Intune uses to deliver certificates to devices, a new mapping has been introduced which is a Subject Alternative Name (SAN) tag-based URI with the following format.

URL=tag:microsoft.com,2022-09-14:sid:<value>

When a user or device presents a certificate for authentication in Active Directory, the KDC will check if the required mappings are present to verify if the certificate is strongly mapped and issued to the specific user or device.

Adding SID to SCEP certificates for ADCS/KDC changes

To address the ADCS/KDC changes, we’re introducing the capability for admins to include the On-premises Security Identifier (SID) in SCEP certificates. Admins can either edit existing SCEP profiles or create new ones to incorporate the OnPremisesSecurityIdentifier variable with a URI tag as shown below. Note that URI is the only supported attribute for OnPremisesSecurityIdentifier.

Once you’ve added it to the SCEP profile, Intune will append the SID value along with the tag “tag:microsoft.com,2022-09-14” to the SAN attribute of the certificate. The SAN now includes the object's SID formatted as \"tag:microsoft.com,2022-09-14:sid:<OnPremisesSecurityIdentifier>\". This URI is included in the SCEP payload and sent through the mobile device management (MDM) channel. 

For user certificates, the variable resolves to the user SID, while for device certificates, it resolves to the device SID. Additionally, the KDC logic for evaluating how certificates are mapped has been updated to check a URI based on a Subject Alternative Name (SAN) tag that works with SCEP. This solution works with Windows Server 2019 and above. 

Recommendations for safe implementation

Testing

It's essential to thoroughly test new configurations on a select group of devices before rolling them out broadly. Create a profile with the variable \"OnPremisesSecurityIdentifier\" and apply it to this group. Ensure compatibility with applications, Intune-integrated conditional access, NAC solutions, and any certificate-based authentication in your networking infrastructure.

Phased certificate renewal

Renew certificates in phases by creating a new SCEP profile and gradually targeting it to groups of users or devices. This approach helps to avoid overwhelming your certificate authority and minimize disruptions.

Note: If you notice the tag \"tag:microsoft.com,2022-09-14:sid:<value>\" in the certificates already issued within your organization, your tenant received the initial KDC change in February 2024. For any certificates that don’t include this SID, they must be reissued before February 2025 to ensure they contain the SID and authentication isn‘t denied. Alternatively, you can enable compatibility mode by adjusting the registry settings to allow for automatic certificate renewal. Specifically, you will need to change the registry key StrongCertificateBindingEnforcement to 1, as defined in the KB5014754.This registry change must be completed before February 2025, and all certificates should be renewed before September 2025 to avoid any disruption.

Implementation for PKCS certificates

The implementation of strong mapping in PKCS certificates is now available via certificate connector updates in the version 6.2406.0.1001. For information about the latest version and how to update the certificate connector, review Certificate connector for Microsoft Intune and Update certificate connector for KB5014754 requirements.

For the PKCS changes to take effect, you need to update the connector, make the below registry change, and then restart the connector service in that order.

Important: Before you modify the registry key, review these articles on how to change the registry key and how to back up and restore the registry:

\n
• How to back up and restore the registry in Windows - Microsoft Support
\n
• How to add, modify, or delete registry subkeys and values by using a .reg file - Microsoft Support
\n

Modify the value for the following registry key:

[HKLM\\Software\\Microsoft\\MicrosoftIntune\\PFXCertificateConnector]:(dword)EnableSidSecurityExtension

Value: 1

After modifying the registry key, restart the connector services in order for the changes to take effect. If you would like to revert the changes, restore the registry changes and create new profile such that certificates are re-issued without the SID attribute.

Known issue: For Windows, when issuing the PKCS certificate you may see the following exception:

Strong mapping prerequisites for Intune

The changes introduced by Intune apply to Microsoft Entra hybrid joined users and devices that authenticate against Active Directory using Intune-issued certificates. For strong mapping to work for these users and devices, the following prerequisites must be met:

\n
• User and device SID must be synchronized with Microsoft Entra ID. For more information, read How objects and credentials are synchronized in a Microsoft Entra Domain Services managed domain.
\n
• For device certificates, only Microsoft Entra hybrid joined devices will have SID information, so strong mapping changes are applicable only to Windows devices that are Microsoft Entra hybrid joined. For other device types, like iOS or Android, strong mapping is not supported for device certificates, and user certificates should be used instead.
  
  
\n

Strong mapping is supported for:

\n
• Windows 10
\n
• Windows 11
\n
• Windows Server 2019 and later
\n
• iOS
\n
• macOS
\n

Note: Android support is expected to rollout in November 2024.

SID support for third-party CA and NAC partners

We are working closely with partners to ensure readiness for all third-party certification authorities (CA) and network access control (NAC) solutions.  

The following CA partners have been verified to be compatible with the SID inclusion from Intune: 

\n
• Cogito Group
\n
• DigiCert
\n
• EasyScep
\n
• EJBCA
\n
• Entrust
\n
• EverTrust
\n
• HID Global
\n
• IDnomic
\n
• Keyfactor Command
\n
• KeyTalk
\n
• Keytos
\n
• Nexus Certificate Manager
\n
• SCEPman
\n
• Sectigo
\n
• Venafi
\n
• Securew2 
\n

If you're using NAC solutions with Intune, it's important to check compatibility with the SID included in certificates. We're working closely with various NAC partners to ensure smooth integration. Here's the current status: 

\n
• Portnox – Completed
\n
• Cisco – In progress\n
  \n
  • \n

    ISE 3.2 P7 – Released in October 2024

    \n
  \n
  • \n

    ISE 3.3 P4 – Planned for October 2024

    \n
  \n
  • \n

    ISE 3.4 P1 – Planned for November 2024

    \n
  \n
  • \n

    ISE 3.1 P10 – Planned for January 2025

    \n
  \n
  \n
\n
• Citrix – In progress
\n
• F5 – In progress
\n
• Ivanti – In progress
\n
• Forescout – In progress
\n
• Aruba Clearpass – Completed, Intune extension version 6.3.3  
\n

We recommend thorough testing of any applications, Intune-integrated CAs, NAC solutions and networking infrastructure where clients may utilize certificates for authentication to ensure optimal functionality. 

If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam.

Post updates:

03/18/24: Based on customer feedback, we paused the rollout for this update. More information can be found above.

10/10/24: Added steps to implement SID in SCEP and PKCS certificates, along with information on SID support for third-party CA and NAC partners.
10/29/24: Updated status of NAC partners.
11/14/24: Updated to include a PKCS known issue with resolution (KB5046616).
11/25/24: Strong mapping for SCEP certificates has now been fully rolled out, with support available on Windows, iOS, macOS, and Android operating systems.

Learn more about implementing strong mapping in Microsoft Intune certificates.

I'm having trouble saving the URI with the value tag:microsoft.com,2022-09-14:sid:{{OnPremisesSecurityIdentifier}} in the profile.

{{OnPremisesSecurityIdentifier}} is not recognized

I get the error: 
A value is required for Value. Value can include allowed variables combined with static text. UPN and Email address should include an @, for example: “{{AAD_Device_ID}}@contoso.com”. DNS cannot end with a symbol or contain an @ sign, e.g. “{{DeviceName}}.contoso.com” or “{{DeviceName}}”.

The variable {{OnPremisesSecurityIdentifier}} is different to other variables. It cannot be used everywhere, so an error occurs if you don't use it exactly as specified in the blog article.

In your case, I believe you included the prefix \"tag:microsoft.com,2022-09-14:sid:\" in the configuration? It must be only \"{{OnPremisesSecurityIdentifier}}\", otherwise it cannot be saved. The prefix will appear magically (i.e. Intune will add it) in the CSR and hence in the certificate. Compare whether you have entered it exactly as in the screenshot!

I was wrong, because I am configuring a PKCS Policy in Intune, NOT a SCEP Policy. For PKCS this {{OnPremisesSecurityIdentifier}} is not valid.
Strong Certificate Mapping Enforcement February 2025 | Richard M. Hicks Consulting, Inc.
Now everything is working. 

hi all

updates processed well! No issue… wel a small one. Since this when try to Connect to wifi (with intune deployed profiel) always went okay. But now Windows keeps asking to Connect The wifi:

continue connecting?

Corporate Wifi 
Secured 
Continue connecting? 
If you expect to find Corporate Wifi in this location, go ahead and connect. Otherwise, it may be a different network with the same name. 
Show certificate details 
Connect or  Cancel

Why is this happening

This is usually because the server certificate name and root certificate its linked to aren't specified in the profile or are incorrect.

I deploy an xml as wifi profile for this. It has always worked. but now its broken. The message said: Issued to Server dc and issued By server CA.

Which server certificates names, root cert do i need to add?

Could anybody please explain to me how the strong certificate mappings can work for MACHINE certificates for NON hybrid machines (ones that exists in AD only as \"ghost\" objects for Radius group authentication)

If that is removed then we are in for a BIG mess

Sent in a pm to you both

We fell into this category as well. You'll have to come up with a custom solution to store the serial number of the certificate in reverse byte order on the altSecurityIdentities attribute of the AD object as outlined in KB5014754. It'll look something like this:

X509:<I>DC=com,DC=domainname,CN=CA-Name<SR>ReverseByteOrderofSN

I wrote a powershell script to do this using the PSPKI module and Intune Graph API.

Hi Patrick, 

We're in the same boat as Seb, much appreciated if you could share your script. Thanks Jelle

I might be misunderstanding you but this just works already. ADCS Certificates issued the traditional way have been getting the new OID added since May 2022 (I think). NPS already respects this.

Have you checked your current device certificates to see if they already have the OID?

FWIW, products like Cisco ISE need to be updated to support this Intune SAN URI. I did not see any concerns about the certificate extension found in RPC-issued certs.

Strong mapping is only required if the certificate authenticates a user or device against AD. NPS does it this way and thus requires the strong mapping, but all other NACs that I know do not require a mapping of certificates to AD entities and thus require no strong mapping and also neither a SAN URI nor SID extension. IMHO, NPS' approach is not well suited for modern environments with (some) cloud-only devices or users.

Therefore, I think ISE & Co. do not need to add support for the strong mapping. Having a valid certificate is enough to get into the network in their case, without an explicit mapping to an AD entity. You still have the certificate properties for auditing and can revoke a certificate if a specific user or device shouldn't get into the network anymore. This way, you also don't need to put the CA certificate in the NTAuth Store anymore, so they cannot be used for AD authentication. NPS requires the NTAuth and this exposes one more potential attack vector, as a stolen certificate does not only grant access to the network, but can also be used to impersonate an AD user or device.

We have an issue where the PKCS certificates are issued with the SID on already installed clients. But when a certificate is issued during pre-provision the certificate is missing the SID. This causes alot of issues since we are rolling out and the devices need to be able to connect to Wifi/LAN and VPN during this process.

We encountered similar issues with SCEP certificates and Autopilot pre-provisioning with Entra hybrid joined devices. During provisioning phase, the computer object gets created with ODJ, but the device only gets a certificate without AD object SID in SAN URI even if the SCEP certificate profile includes the configuration. The device thus cannot establishish a connection/trust relationship to AD through Microsoft NPS because of 802.1X certificate strong mapping requirement and it has no SID which is required for Intune strong mapping enabled SCEP certificate deployment.

I do know that Entra hybrid join requirements for Autopilot deployment state that the device must have \"access to an Active Directory domain controller of the domain being joined\", but this was never an issue using 802.1X EAP-TLS before strong mapping enforcement AFAIK. At the moment, compatibility mode seems to be the only way to resolve this temporarily until September 2025.

Interested to hear, if you get some resolution for the issues from MS support.

Well we submitted a support ticket with the Intune Support team and since Intune is able to request a certificate without errors the ticket was archived by Microsoft since it's a Windows Server Issue most likely. I hoped they could escalate the ticket to Windows support team but that wasn't possible. So now I'm trying to figure out how to submit a support ticket to the Windows team instead. So no resolution yet.

Hi @dkenz, Please open a support case to help troubleshoot this. We've had similar reports, but they've been due to configuration issues. Further investigation is almost always valid though.

Hi Jason, I have checked the configuration over and over and everything looks fine. Both the documented required changes for the Intune connector, and other depending configurations. We are still waiting for assistance on our support ticket. Hopefully we can get assisted soon.

Are you able to clarify this statement:

\"Additionally, the KDC logic for evaluating how certificates are mapped has been updated to check a URI based on a Subject Alternative Name (SAN) tag that works with SCEP. This solution works with Windows Server 2019 and above.\"

Does the DC need to be 2019 or later for the SAN URI to be recognised or should it work on 2016 DCs as well? 

I can confirm we are having issues with all 2016 servers since the Feb 2025 updates, NPS is no longer working on these servers, error with Strong Certificate mapping. We have the strong certificate mapping setup in Intune and SCEPman. All 2019 servers or above with the Feb 2025 updates are NOT impacted. How do we get it working on 2016 servers? I understand we can use the compatibility mode registry key until September 2025.

Our NPS Servers are 2019 and I am being impacted. I've still to 100% confirm they're not missing a patch somewhere along the line, but they're definitely not accepting user certs with the SAN URI. They're fine with certificates that have the extension.

Did you find that NPS on 2019 was accepting the SAN URI just fine?

So for orgs using PKCS the only things that are needed to be done are updating the cert connector to the version stated, adding the reg key and then after that any new/renewing certs are good to go but ones that need to be renewed a new PKCS would need pushing from Intune to force the certs out machines.

As it doesn't mention it I assume you do not need to add the OnPremSecurityIdentifier into the PKCS profile like you do with the SCEP option?

On some test devices we have done this on I can see in the user cert on the device after updating the Intune connector there is the 1.3.6.1.4.311.25.2 attribute now there is that all that needs to be in place to be ready and is there any real world test we can do to ensure its going to work come Feb when the changes come into effect? Sheetal__09 

barberj66 
Hi

Have you done the changealready? Experienced any issues with the part that you mentioned about \"ones that need to be renewed a new PKCS would need pushing from Intune to force the certs out machines\"?

If so, can you elaborate how you handled/fixed it?
We are just about to perform the adjustment but this was the last Input from the comments which I'm concerned about.
Other than that, the change for PKCS sounds fairly easy.

We have been told by Microsoft Support that strong mapping IS supported for device certificates on Android. Please can this page be updated to reflect this. It currently says \"For other device types, like iOS or Android, strong mapping is not supported for device certificates\". 

After logging another ticket with Microsoft Support, they are now saying that strong mapping IS NOT supported for device based certificates on Android. Please Ignore last message.

Your Android devices are in your AD?

Hi, when can we expect Android support?  It's now 25th November, so I would expect this week at some stage?

Hi rmc86 

With strong mapping for SCEP certificates being fully rolled out, we're just checking in to confirm if the changes have applied in your environment?

Thanks!

We're going to be working on it next week.

How does this affect device based certs being deployed via PKCS for Entra joined devices? Will the certs no longer be valid after this as there is no SID to pass over from on-prem AD? Will we have to move to user based certs instead?

Yes device certs cant be used for cert based auth when authenticating against local AD. Yes, user based certs is the way.

Is that a future statement? Like they \"will\" not be ? Because up to now they certainly CAN be used just fine!

Has the update for the Intune certificate connector been enabled to be installed automatically? The docs say the connector will update on its own if connectivity is available to the endpoints, our connector servers are on 6.2301.1.0 so have been updating on their own up until this point but there is no further update happened to them yet. 

I know I can manually install the connector again but if its going to come on its own I'd rather leave it to update on its own. Sheetal__09 

Not yet; we haven't enabled the automatic installation of the update yet. While we plan to push it for auto-upgrade soon, we're currently waiting for feedback from customers on how it's performing.