Resolving PKCS Certificate Mapping Issues in Windows Autopilot Hybrid Join Deployments

Microsoft Windows Autopilot streamlines device provisioning through Intune, allowing IT administrators to preconfigure new Windows devices with minimal hands-on effort. However, when combined with Hybrid Entra Join and PKCS certificate deployment, specific challenges arise—particularly with certificate mapping and authentication.

Hybrid Entra Join

During autopilot provisioning, administrators may also choose to join the device to their on-premises Active Directory domain, a deployment model called Hybrid Entra join. Hybrid Entra join presents some unique challenges when using Autopilot to remotely provision devices. Specifically, the user must have connectivity to a domain controller to perform the first logon, as they do not have a user profile on the endpoint.

Device Tunnel

To support offline Hybrid Entra join during Autopilot provisioning, administrators can deploy the Always On VPN device tunnel to provide pre-logon connectivity to domain controllers. A device tunnel connection enables users to log on to their newly provisioned device remotely.

Requirements

The following prerequisites must be met to support the Always On VPN device tunnel.

  • The endpoint must be running Windows Enterprise edition.
  • An Always On VPN device tunnel profile must be assigned to the device.
  • A machine certificate must be deployed to the endpoint that includes the Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2).

Note: If you plan to use the subscription step-up upgrade from Windows Professional to Windows Enterprise, the device tunnel will not connect automatically after provisioning is complete, which prevents the user from logging in. More details and a workaround for this issue can be found here.

Strong Certificate Mapping

Microsoft knowledge base article KB5014754, released in May of 2022, introduced changes to domain controllers to require strong certificate mapping when using certificates to authenticate to Active Directory (AD). It was initially deployed in compatibility mode, only warning administrators when certificates are used for authentication that aren’t strongly mapped. However, full enforcement is mandatory beginning with the September 2025 security updates. This requirement introduces some challenges when issuing certificates to the device using PKCS during Autopilot provisioning.

Intune PKCS Certificates

When using PKCS certificates and the Intune Certificate Connector, the endpoint’s on-premises AD security identifier (SID) is not added to the issued certificate during Autopilot. Interestingly, this does not happen when using SCEP certificates. If the device certificate is not strongly mapped, the Always On VPN device tunnel will still authenticate successfully because Always On VPN does not use AD to authenticate device connections. Instead, Always On VPN simply verifies the certificate (e.g., that it is not expired or revoked) and allows authentication if the certificate passes the validation.

However, enterprise Wi-Fi access may fail without strongly mapped certificates if device authentication is required. Also, there may be other scenarios where a device authentication certificate without strong mapping may cause authentication to fail.

Workarounds

There are a few ways to work around this limitation. Consider the following options.

Native Entra ID Join

The simplest way to avoid the challenges of PKCS certificates and Hybrid Entra join is to avoid it altogether in favor of native Entra join. However, this may not be an option for everyone.

Use SCEP

For some reason, certificates issued with SCEP do not suffer from this limitation. In my testing, SCEP certificates are always strongly mapped. However, deploying SCEP certificates is much more complex than using PKCS. (Pro tip: Cloud PKI for Intune uses SCEP and requires no configuration! It’s definitely something to consider.)

Short-Lived Certificates

Another option is to deploy temporary, short-lived certificates (valid for only a few days) using PKCS to ensure the Always On VPN device tunnel works, and then deploy a permanent, long-term certificate post-deployment that includes the strong mapping. To do this, administrators can leverage dynamic group assignments in Intune. For example, the administrator can assign the short-lived certificate to an Autopilot Provisioning devices group and later assign a long-term certificate to the Hybrid Joined devices group.

Here’s an example of the dynamic group membership configuration.

Autopilot Provisioning Devices:

(device.devicePhysicalIDs -any (_ -contains “[ZTDId]”)) -and (device.deviceTrustType -ne “ServerAD”)

Hybrid Entra Join Devices:

(device.deviceTrustType -eq “ServerAD”)

In this configuration, the initial PKCS certificate is deployed without the strong mapping when the endpoint is enrolled to Autopilot but has not yet joined the domain. During this time, the endpoint will only be a member of the Autopilot Provisioning Devices group and will receive the short-lived, temporary certificate. Later, once the endpoint has successfully joined the domain, the device will move from the provisioning group to the Hybrid Entra Join Devices group. When this happens, a permanent, strongly mapped long-term certificate is enrolled on the device.

Manual Certificate Mapping

Certificates can be manually mapped via the altSecurityIdentities property of the computer object in AD. Obviously, this doesn’t scale well, so my good friend Steve Prentice published a PowerShell script to automate this process. You can find more details and the script here.

Summary

Windows Autopilot streamlines device provisioning with Intune, but Hybrid Entra Join introduces challenges when PKCS certificates lack strong mapping during initial deployment, potentially disrupting VPN and Wi-Fi authentication. Administrators can avoid this by switching to native Entra join or by using workarounds such as switching to SCEP, using short-lived certificates, or manually mapping certificates.

Additional Information

KB5014754 – Certificate-based authentication changes on Windows domain controllers

How To: Map a user to a certificate via all methods available in the altSecurityIdentities attribute

Hybrid Autopilot: Automating altSecurityIdentities

Configure Microsoft Entra hybrid join

Overview: Cloud PKI for Microsoft Intune

PKI Fundamentals with Microsoft AD CS Training Course

I’m excited to announce that I’ve partnered once again with the fine folks at the ViaMonstra Online Academy to deliver a new live training course entitled PKI Fundamentals with Microsoft Active Directory Certificate Services (AD CS). The event consists of six weekly live webinars beginning on Thursday, January 15, 2026, at 3:00 PM CST.

Why AD CS Training?

Digital certificates are strong, phishing-resistant credentials that are an excellent choice for authentication to critical workloads like Always On VPN and enterprise Wi-Fi. However, managing certificate services infrastructure can be daunting. This course provides administrators with a fundamental understanding of enterprise PKI with Microsoft AD CS.

Course Overview

The event format for this course consists of six weekly live sessions on Thursdays starting on January 15, 2026. The classes are two hours long, running from 3:00 PM CST to 5:00 PM CST each day. During the course, we’ll cover the following topics.

  • PKI concepts and certificate use cases
  • Designing and deploying certificate authorities (CAs)
  • Configuring templates and enrollment
  • Managing revocation and maintenance

Who Should Attend

Organizations planning to use certificate authentication for enterprise VPN and Wi-Fi workloads will benefit from this training course. Also, those considering a new AD CS deployment will find this training beneficial. In addition, administrators managing an existing production AD CS environment will gain valuable insight.

Enroll Now

Registration for this training class is available now. The cost is $295.00—an incredible bargain! Don’t miss out on this fantastic opportunity to gain foundational AD CS skills. Click the registration link below and reserve your spot today!

Additional Information

Public Key Infrastructure (PKI)

Enterprise PKI

Cloud PKI for Microsoft Intune

Certificate Connector for Microsoft Intune Agent Certificate Renewal Failure

The Certificate Connector for Microsoft Intune is a vital component that allows administrators to issue and manage enterprise PKI certificates to endpoints managed by Microsoft Intune. The connector is installed on a Windows server with access to the on-premises Certificate Authority (CA). It is registered with Intune and can be used by any PKCS or SCEP device configuration profiles defined by Intune administrators.

Agent Certificate

When you install the Certificate Connector for Intune, a certificate issued by the Microsoft Intune ImportPFX Connector CA is automatically enrolled into the local computer certificate store of the server where the connector is installed. This certificate authenticates the connector to Intune and is valid for one year from the date of issuance. This certificate is automatically renewed in most cases. However, some configurations prevent this from happening.

Failed To Renew

Administrators may find event log errors with event ID 2 from the CertificateConnectors source in the Microsoft-Intune-CertificateConnectors operational event log with the following information.

Pki Create Service:

Failed to renew agent certificate

System.Security.Cryptography.CryptographicException: Access is denied.

Root Cause

Agent certificate renewal fails when the Certificate Connector for Intune is running under a service account that is not a member of the local administrators security group. You will not encounter this error if the connector services are running in the SYSTEM context, however.

Resolution

There are a few different ways to resolve this issue. Here are some options to consider.

Grant Admin Rights

Adding the service account under which the connector service runs will allow the agent certificate to renew automatically. However, this may not be desirable from a security perspective. To address this, administrators may temporarily grant local administrative access to renew the agent certificate, then revoke this permission once the certificate has been successfully renewed. However, this is a manual process that doesn’t scale well and requires annual administrative intervention.

Reinstall

Uninstalling and reinstalling the Certificate Connector for Intune will force a new certificate enrollment during the registration process. You can delete the old certificate after completing the installation.

Switch to SYSTEM

Changing from a service account to SYSTEM will also resolve this issue. However, it is not recommended to make these changes directly on the services themselves. Instead, administrators should remove and reinstall the Certificate Connector for Intune, selecting the SYSTEM option rather than the service account method.

Note: Using the SYSTEM account for the Certificate Connector for Intune should be avoided when using PKCS. Details here.

Summary

The Certificate Connector for Intune agent certificate renewal fails when the service is configured to run as a service account without local administrative rights. The best way to resolve this is to add the service account to the local administrators group on the server where the connector is installed. However, this isn’t always ideal. Although running the connector in the SYSTEM context is acceptable when using SCEP, it should be avoided when using PKCS. Administrators will have to accept the risk of the service account having local administrative rights or accept that they’ll have to reinstall the connector annually.

Additional Information

Certificate Connector for Intune Service Account and PKCS

Strong Certificate Mapping for Intune PKCS and SCEP Certificates

Intune Strong Certificate Mapping Error

Intune PKCS and SCEP Certificate Validity Period

Certificate Connector for Intune Failure

Certificate Connector for Intune Configuration Failed

Troubleshooting Intune Failed PKCS Request