Microsoft Entra Private Network Connector Overview and Deployment Strategies

When deploying Microsoft Entra Private Access, administrators must install at least one Entra Private Network Connector to facilitate communication between Global Secure Access clients and on-premises resources. The Entra Private Network connector is a software agent that communicates outbound only. It requires no inbound connectivity, reducing public network exposure and minimizing the organization’s attack surface.

Entra Private Network Connector

The Entra Private Network connector is essentially the old Azure Application Proxy, updated to support all TCP and UDP-based communication. You can download the connector by opening the Entra admin center, navigating to Global Secure Access > Connect > Connectors, and clicking the Download connector service link.

Cloud Appliances

To enable access to cloud-hosted resources, the Entra Private Network connector can be installed on a VM in those environments. However, the Entra Private Network connector is also available as an appliance in public preview for the following cloud providers.

Resource Requirements

The following recommendations pertain to VM resources for the Entra Private Network connector server.

  • Windows Server 2016 or later. However, Windows Server 2016 reaches end of life in January 2027, so Windows Server 2022 and later are recommended. The Desktop edition is required, but it can technically be installed on Server Core with the Application Compatibility Feature on Demand for Server Core. However, Microsoft may not formally support this option.
  • Minimum 4 CPU cores and 8GB RAM. Monitor resource utilization during migration. Provision additional CPU and/or memory when utilization consistently exceeds 70% during peak times. Scaling out (adding servers) is preferred over scaling up (adding CPU and RAM).
  • Domain Join. Domain join is optional but recommended. Domain join is required to support single sign-on (SSO).

Connector Groups

A Connector Group is a logical grouping of Entra Private Network connectors. A Connector Group functions as a single unit for high availability and load balancing. Connectors are deployed in the same region as the tenant by default.

Default Group

When you install the Entra Private Network connector, it is placed into the Default connector group. However, this may not always be desirable. For example, the organization may have multiple data centers in different geographies. They may also have resources hosted in different Active Directory forests or perhaps located in isolated network locations. Using a common connector group may be suboptimal or not work at all.

Custom Groups

Administrators can define custom connector groups as needed. Custom connector groups ensure that connectors always have access to the resources nearest to them. They can be deployed in different locations and assigned to other Azure regions to ensure optimal traffic routing and reduced latency. Today, administrators can create connector groups in the North America, Europe, Australia, Asia, and Japan regions.

Create a Connector Group

Open the Microsoft Entra admin center and perform the following steps to create a new Entra Private Network connector group.

  1. Navigate to Global Secure Access > Connect > Connectors and Sensors.
  2. Click on New Connector Group.
  3. In the Name field, enter a descriptive name for the connector group.
  4. From the Connectors drop-down list, select one or more Entra Private Network connectors to assign to the group. Optionally, you can leave this field blank and assign connectors later.
  5. Click Save.

Connector Group Assignment

Once you have created a new connector group, you can assign Quick Access or individual Enterprise applications to it as follows.

Quick Access

To assign a new connector group to the Quick Access application, open the Entra admin console, navigate to Global Secure Access > Applications > Quick Access, and select the Network access properties tab. Select the new connector group from the Connector Group drop-down list.

Enterprise Applications

To assign a new connector group to an individual Enterprise application, navigate to Global Secure Access > Applications > Enterprise applications. Select an application, then select Network access properties. Select the new connector group from the Connector Group drop-down list.

Deployment Strategy

The following are best practices for deploying the Entra Private Network connector.

Redundancy

Always deploy at least two Entra Private Network connectors to ensure high availability and eliminate single points of failure.

Location

Install the Entra Private Network connector on servers closest to the applications they serve. Deploy connectors in all locations where applications are accessed, including on-premises networks and Infrastructure-as-a-Service (IaaS) resources.

Default Connector Group

Avoid using the default connector group for application assignment. Always use custom connector groups for application access. This ensures that new connectors do not process production traffic immediately after installation, which can cause unexpected behavior if the connector is not optimally deployed for the published resource or is not connected to the back-end application.

Deleting Connectors

Entra Private Network connectors cannot be removed from the management console. If you uninstall a connector, its status will show as inactive. After 10 days of inactivity, it will be automatically removed.

Reassigning Connectors

Administrators can reassign connectors to different connector groups at any time. However, existing connections on that connector server from the prior group assignment will remain until they age out. Administrators can restart the connector service or reboot the server to address this issue.

Restart-Service -Name WAPCSvc -PassThru

Connector Updates

The Entra Private Network connector will automatically install major updates when they become available. However, not all updates are applied automatically. Don’t be alarmed if you see discrepancies between release versions across multiple connector servers in the admin console. Administrators can always perform software updates manually to ensure uniform connector versions in their environment, if desired.

Diagnostics

Beginning with Entra Private Network connector v1.5.4287.0, the agent installation also includes the diagnostic utility ConnectorDiagnosticsTool.exe, which is in the C:\Program Files\Microsoft Entra Private Network Connector\ folder on the connector server. Running the tool initiates a series of tests to perform a health check of the connector service, including certificate status, connectivity, enabled TLS versions, service status, and more.

Note: Entra Private Network connector v1.5.4522.0 and later includes a graphical output, as shown above. Previous versions featured text-based output only.

Summary

Microsoft Entra Private Network Connectors are lightweight, outbound-only agents that enable secure access to on-premises and cloud resources through Entra Private Access. Best practices emphasize deploying at least two connectors per location for redundancy, placing them close to target applications, using custom connector groups for high availability, load balancing, and optimal routing, and assigning them to Quick Access or enterprise applications while avoiding the default group. Ensure that VMs are appropriately sized for the expected connector traffic, and consider using marketplace appliances for Azure, AWS, and GCP. If you’ve previously deployed the Entra Private Network connector, ensure that it is running the latest release to take advantage of new diagnostics for troubleshooting.

Additional Information

Microsoft Entra Private Network Connectors

Microsoft Entra Private Network Connector groups

Preventing Port Exhaustion on Entra Private Network Connector Servers

Microsoft Entra Private Access Intelligent Local Access

Always On VPN vs. Entra Private Access: Choosing the Right Access Model for Your Organization

Windows Server 2016 End of Life January 2027: Plan Your AD CS Migration Now

Happy New Year, everyone! As the calendar rolls over to 2026, it’s time to start planning the migration of workloads hosted on Windows Server 2016. Mainstream support ended for Windows Server 2016 on January 11, 2022, after which it entered extended support. However, extended support for Windows Server 2016 ends on January 12, 2027, at which point it will be end of life and no longer supported. Running production workloads on Windows Server 2016 beyond this date exposes organizations to significant security risk, as it no longer receives security updates, leaving these systems vulnerable to exploits.

Active Directory Certificate Services

Many organizations are still running critical infrastructure on Windows Server 2016. Administrators often delay upgrading Microsoft Active Directory Certificate Services (AD CS) due to its complexity. However, a well-planned AD CS migration not only reduces risk but also provides an opportunity to modernize cryptography, certificate templates, and operational practices.

Certificate Authorities

Administrators must carefully migrate Certificate Authorities (CAs) running on Windows Server 2016 to minimize downtime. In environments where ongoing CA maintenance has been limited, migrating the CA database can be especially challenging. If the CA is installed on a domain controller, now is a good time to consider separating these services to ensure reliable operation. Also, it’s a good idea to evaluate the CA’s configuration and security posture during migration to enhance security and improve service resilience.

NDES Servers

Microsoft Network Device Enrollment Services (NDES) servers, commonly deployed to facilitate certificate enrollment via Microsoft Intune, pose a unique challenge during migration. Unfortunately, configuring NDES is exceedingly complex and error-prone. NDES relies on a delicate combination of specialized IIS configuration, AD service accounts, custom certificate templates, and CA permissions, making even minor changes risky without proper planning. Not surprisingly, administrators are often hesitant to touch these systems as they are notoriously difficult to troubleshoot when problems arise.

Pro Tip: We spend an entire day covering NDES configuration in the Mastering Enterprise PKI Certificates with Microsoft Intune training course. The next session is March 10-12, 2026. Register now!

Intune Certificate Connectors

Don’t overlook Windows Server 2016 servers with the Intune Certificate Connector installed. Fortunately, this is one of the more manageable workloads to migrate. All that’s required is to install new connectors on supported servers and delete the old ones.

Summary

With extended support for Windows Server 2016 ending on January 12, 2027, organizations running production workloads—especially critical infrastructure such as Active Directory Certificate Services (AD CS), Certificate Authorities (CAs), and NDES servers—face significant security risks from unpatched vulnerabilities once the OS reaches end-of-life. Careful migration planning to newer versions such as Windows Server 2022 or 2025 is essential to minimize downtime, improve security posture, and ensure long-term resilience.

Start Planning Now

Don’t leave these mission-critical infrastructure services to the last minute! Begin planning your migration today. If you’d like expert guidance, I have many years of experience migrating these workloads. I have developed specialized tools and techniques to ensure a smooth, secure, and successful transition. Fill out the form below to schedule a free one-hour consultation to assess your Windows Server 2016 AD CS workloads, identify migration risks, and outline next steps.

Additional Information

Windows Server 2016 Lifecycle Policy

PKI Fundamentals with Microsoft Active Directory Certificate Services (AD CS) Online Training Course

Mastering Enterprise PKI Certificates with Microsoft Intune Online Training Course

Windows Secure Boot UEFI Certificates Expiring June 2026

For IT administrators responsible for managing Windows devices, a crucial certificate update milestone is coming in June 2026 that could result in degraded security for systems that are not updated. Specifically, the Microsoft certificates that manage UEFI Secure Boot trust will expire, potentially allowing untrusted or malicious software to load on affected machines during system boot.

Secure Boot

Windows Secure Boot is a UEFI firmware security feature that ensures a computer boots only with trusted, digitally signed operating system loaders and drivers, preventing malicious code (such as rootkits or compromised bootloaders) from loading during startup. Introduced with Windows 8, it verifies the cryptographic signatures of boot components against a database of authorized keys, blocking unauthorized or tampered software to protect system integrity from the earliest stages of boot.

Chain of Trust

The UEFI Platform Key (PK) is the ultimate root of trust in Secure Boot. It is a single public key owned by the device manufacturer and stored in firmware. The PK certificate signs the Key Exchange Key (KEK) and grants authority to modify the other Secure Boot databases, such as the allowed database (DB) and the disallowed database (DBX). The DB and DBX contain certificates and signatures for authorized and unauthorized software, respectively.

Microsoft Secure Boot Certificate Expiration

Two crucial Microsoft Secure Boot certificates are set to expire in June 2026. They are:

  • Microsoft Corporation KEK CA 2011 (stored in KEK)
  • Microsoft UEFI CA 2011 (stored in DB)

In addition, another critical Microsoft Secure Boot certificate expires in October 2026.

  • Microsoft Windows Production PCA 2011 (stored in DB)

When these certificates expire, devices may fail to recognize trusted bootloaders, and future Secure Boot policies may not be applied. Updating the certificates ensures continued protection against malicious rootkits and ensures Windows firmware compliance

View Certificate Information

Ideally, administrators could use PowerShell to view these UEFI Secure Boot certificates. Sadly, the output of the Get-SecureBootUEFI PowerShell command is not particularly helpful and does not display any pertinent certificate details.

Get-SecureBootUEFI -Name KEK

PowerShell Script

To address this limitation, I’ve created a PowerShell script that allows administrators to view all UEFI certificates, including PK, KEK, and DB certificates, and optionally save them as base64-encoded files. The script is available on GitHub and in the PowerShell gallery.

Install-Script -Name Get-UEFICertificate -Scope CurrentUser

View UEFI Certificates

After downloading the Get-UEFICertificate PowerShell script, run the following command to view the KEK database.

Get-UEFICertificate -Type KEK

In this example, the only KEK certificate is the expiring Microsoft Corporation KEK CA 2011 certificate. Running the command and specifying the DB type shows only the expiring Microsoft Windows Product PCA 2011 certificate.

Note: UEFI also includes hashes of specific executables in the DB and DBX databases. By default, this script focuses on UEFI certificates and omits hash calculations for brevity. Use the -IncludeHashes switch to view this information.

Updating Microsoft UEFI Certificates

With the October 2025 updates, Microsoft introduced new registry keys to enable and monitor the update status of these UEFI Secure Boot certificates.

Status

To begin, administrators can check the status of the update process by reading the value of the UEFICA2023Status registry key.

Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\ -Name UEFICA2023Status | Select-Object UEFICA2023Status

Update

To initiate the update process, set the value of AvailableUpdates to 0x5944.

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot’ -Name ‘AvailableUpdates’ -Value 0x5944

Next, start the Secure-Boot-Update scheduled task.

Start-ScheduledTask -TaskName ‘\Microsoft\Windows\PI\Secure-Boot-Update’

Once complete, the UEFICA2023Status indicates InProgress.

After a reboot, start the Secure-Boot-Update scheduled task once more. The UEFICA2023Status should indicate that it has been updated (may require one more reboot!).

Updated Certificates

After the update process completes, run the Get-UEFICertificate PowerShell script to confirm that new certificates have been added to UEFI Secure Boot.

Updated Microsoft KEK Certificates

Updated Microsoft DB Certificates

Summary

With multiple Microsoft Secure Boot CA certificates expiring in 2026, organizations need to ensure devices are updated to maintain a valid UEFI trust chain. This guide shows how to view existing firmware certificates, apply Microsoft’s Secure Boot CA 2023 updates, and confirm that new KEK and DB certificates have been installed. Completing this process now will ensure devices remain protected from tampered or malicious boot components as the 2026 expiration dates approach.

Additional Information

Windows Secure Boot certificate expiration and CA updates

Registry key updates for Secure Boot: Windows devices with IT-managed updates

Get-UEFICertificate PowerShell Script on GitHub

Get-UEFICertificate PowerShell Script in the PowerShell Gallery