Configure Windows Extended Protection in Exchange Server

Overview

Windows Extended Protection enhances the existing authentication in Windows Server and mitigates authentication relay or man-in-the-middle (MitM) attacks. This mitigation is accomplished by using security information that is implemented through channel-binding information specified through a Channel Binding Token (CBT) which is primarily used for TLS connections.

Extended Protection is enabled by default when installing Exchange Server 2019 CU14 (or later). For more information, see Released: 2024 H1 Cumulative Update for Exchange Server.

On older versions of Exchange Server (for example, Exchange Server 2016), Extended Protection can be enabled by the help of the ExchangeExtendedProtectionManagement.ps1 script on some or all Exchange servers.

Terminology used in this documentation

Virtual Directory or vDir

Is used by Exchange Server to allow access to web applications such as Exchange ActiveSync, Outlook on the Web, and the AutoDiscover service. Several virtual directory settings can be configured by an admin, including authentication, security, and reporting settings. Extended Protection is one such authentication setting.

Extended Protection setting

Controls the behavior for checking of Channel Binding Tokens or CBT. Possible values for this setting are listed in the following table:

Value	Description
None	Specifies that IIS doesn't perform CBT checking.
Allow	Specifies that CBT checking is enabled, but not required. This setting allows secure communication with clients that support Extended Protection, and still supports clients that aren't capable of using Extended Protection.
Require	This value specifies that CBT checking is required. This setting blocks clients that don't support Extended Protection.

SSL Flags

Configuration of SSL settings is required to ensure that clients connect to IIS virtual directories in a specific way with client certificates. To enable Extended Protection, the required SSL flags are SSL and SSL128.

SSL Offloading

Terminates the connection on a device between the client and the Exchange Server and then uses a nonencrypted connection to connect to the Exchange Server.

SSL Bridging

Describes a process where a device, located at the edge of a network, decrypts SSL traffic, and then re-encrypts it before sending it on to the Web server.

Modern Hybrid or Hybrid Agent

This is the name of a method of configuring Exchange hybrid that removes some of the configuration requirements for classic hybrid (for example, inbound network connections through your firewall) to enable Exchange hybrid features. You can learn more about this feature here.

Public Folders

Are designed for shared access and to help make content in a deep hierarchy easier to browse. You can learn more about Public Folders here.

Prerequisites for enabling Extended Protection on Exchange Server

Exchange server versions that support Extended Protection

Extended Protection is supported on Exchange Server 2013, 2016 and 2019 starting with the August 2022 Exchange Server Security Update (SU) releases.

If your organization has Exchange Server 2016 or Exchange Server 2019 installed, they must be running either the September 2021 Quarterly Exchange Cumulative Updates or the 2022 H1 Cumulative Update. You must have at least the August 2022 or later Security Update installed before you continue with the configuration of Extended Protection.

If your organization has Exchange Server 2013 installed, Exchange Server must be on CU23 with the August 2022 or later Security Update installed.

Outlook Anywhere configuration requirements

SSL offloading for Outlook Anywhere is enabled by default and must be disabled before Extended Protection is enabled. Follow the steps as described in Example 3.

NTLM version requirements

NTLMv1 is weak and doesn't provide protection against man-in-the-middle (MitM) attacks. It should be considered as vulnerable and no longer be used.

NTLMv1 can't be used together with Extended Protection. If you enforce a client to use NTLMv1 instead of NTLMv2 and you have Extended Protection enabled on your Exchange servers, this configuration leads to password prompts on the client side without a way to authenticate successfully against the Exchange server.

If you experience password prompts on your clients once Extended Protection is enabled, you should check the following registry key and value on your client and on the Exchange Server side:

Registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

Registry value: LmCompatibilityLevel

It's recommended to set it to a value of 5, which is Send NTLMv2 response only. Refuse LM & NTLM. It must be set at least to a value of 3 which is Send NTLMv2 response only.

If you delete the value, the operating system enforces the system default. On Windows Server 2008 R2 and later, we treat it as if it's set to 3.

If you want to manage the setting centrally, you can do so by using Group Policy:

Policy location: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

More information: Network security: LAN Manager authentication level

TLS requirements

Before enabling Extended Protection, you must ensure that all TLS configurations are consistent across all Exchange servers. For example, if one of the servers uses TLS 1.2, you must ensure that all the servers in the organization are configured using TLS 1.2. Any variation in TLS version use across servers can cause client or server to server connections to fail.

In addition to this requirement, the value of SchUseStrongCrypto registry value must be set to a value of 1 across all the Exchange servers within the organization.

If this value isn't explicitly set to 1, the default value of this key can be interpreted as 0 or 1 depending on the .NET version in use by the Exchange Server binaries and there is a chance that you experience connection issues in server to server communication. This can happen, especially if different versions of Exchange Server (for example, Exchange Server 2016 and Exchange Server 2019) are in use.

The same applies to the SystemDefaultTlsVersions registry value, which must also be explicitly set to a value of 1.

If these registry values aren't configured as expected, this misconfiguration can cause TLS mismatch in server to server or client to server communication and as a result, could lead to connectivity issues.

Refer to this Exchange Server TLS configuration best practices guide to configure the required TLS settings on your Exchange servers.

Third-party software compatibility

Before enabling Extended Protection, it is essential to conduct tests on all third-party products within your Exchange Server environment to ensure they function correctly. If you are uncertain about whether Extended Protection is supported, you should reach out to the vendor for confirmation.

We have seen, for example, anti-virus solutions, which were sending connections through a local proxy server in order to protect the client machine. Such a scenario would prevent communication to the Exchange server and would need to be disabled as it's considered as a man-in-the-middle (MitM) connection, which will be blocked by Extended Protection.

Scenarios that could affect client connectivity when Extended Protection was enabled

SSL Offloading scenarios

Extended Protection isn't supported in environments that use SSL Offloading. SSL termination during SSL Offloading causes Extended Protection to fail. To enable Extended Protection in your Exchange environment, you must not be using SSL offloading with your Load Balancers.

SSL Bridging scenarios

Extended Protection is supported in environments that use SSL Bridging under certain conditions. To enable Extended Protection in your Exchange environment using SSL Bridging, you must use the same SSL certificate on Exchange and your Load Balancers. Using different certificates cause Extended Protection Channel Binding Token check to fail and as a result, prevent clients from connecting to the Exchange server.

Extended Protection and Public Folder scenarios

The following section covers Public Folder scenarios, which could lead to failures when Extended Protection is enabled.

Extended Protection can't be enabled on Exchange Server 2013 servers with Public Folders in a coexistence environment

To enable Extended Protection on Exchange Server 2013, ensure that you don't have any Public Folders that are hosted on Exchange Server 2013. If you have coexistence of Exchange Server 2013 with Exchange Server 2016 or Exchange Server 2019, you must migrate your Public Folders to Exchange Server 2016 or Exchange Server 2019 before enabling Extended Protection. After Extended Protection was enabled and there are Public Folders on Exchange Server 2013, they'll no longer appear to end users!

Extended Protection can't be enabled on Exchange Server 2016 CU22 or Exchange Server 2019 CU11 or older that hosts a Public Folder hierarchy

If you have an environment containing Exchange Server 2016 CU22 or Exchange Server 2019 CU11 or older and are utilizing Public Folders, you must confirm the version of the server that hosts the Public Folder hierarchy before enabling Extended Protection!

Make sure that the server, which hosts the Public Folder hierarchy is upgraded to Exchange Server 2016 CU23 or Exchange Server 2019 CU12 (or later) with the latest Security Updates installed. Move the Public Folder hierarchy to an Exchange Server that runs a required version if you can't upgrade the Exchange server to a supported version.

The following table can be used to clarify:

Exchange version	CU installed	SU installed	Hosts PF mailboxes	Is EP supported?
Exchange 2013	CU23	Aug 2022 (or higher)	No	Yes
Exchange 2016	CU22	Aug 2022 (or higher)	No hierarchy mailboxes	Yes
Exchange 2016	CU23 (2022 H1) or later	Aug 2022 (or higher)	Any	Yes
Exchange 2019	CU11	Aug 2022 (or higher)	No hierarchy mailboxes	Yes
Exchange 2019	CU12 (2022 H1) or later	Aug 2022 (or higher)	Any	Yes
Any other version	Any other CU	Any other SU	Any	No

Extended Protection and Modern Hybrid configuration

The following section covers Exchange Server Modern Hybrid scenarios, which could lead to failures when Extended Protection is enabled.

Extended Protection can't be fully configured on Exchange Servers that are published using Hybrid Agent

In a Modern Hybrid configuration, Exchange servers are published via a Hybrid Agent, which proxies the Exchange Online calls to the Exchange server.

Enabling Extended Protection on Exchange Servers that are published via Hybrid Agent, can lead to disruption of hybrid features like mailbox moves and free/busy calls if not done correctly. It's therefore important to identify all the Exchange servers, which are published by the help of a Hybrid Agent and to not enable Extended Protection on the Front-End EWS virtual directory on them.

Identifying Exchange servers that are published using Hybrid Agent

In case that you don't have a list of servers, which were published via Hybrid Agent, you can use the following steps to identify them. These steps aren't required if you're running a classic Exchange Server Hybrid deployment.

1. Log into a machine where the Hybrid Agent is installed and open the PowerShell module of the Hybrid Agent. Run Get-HybridApplication to identify the TargetUri used by the Hybrid Agent.
2. The TargetUri parameter gives you the Fqdn of the Exchange server, which is configured to be used by the Hybrid Agent.
   • Deduce the Exchange server identity using the Fqdn and make a note of the Exchange server name.
   • If you're using a Load Balancer URL in TargetUri, you need to identify all the Exchange servers, which have the Client Access role installed, and which can be reached behind the Load Balancer URL.

We recommend the following steps to safeguard Exchange servers, which were published via Hybrid Agent:

1. For Exchange servers published via the Hybrid Agent, inbound connections should be restricted by a firewall to allow connections only from the machine on which the Hybrid Agent is installed. This doesn't affect outbound communications from Exchange servers to Exchange Online.
2. No mailboxes should be hosted on the Exchange servers, which were published via Hybrid Agent. Existing mailboxes should be migrated to other mailbox servers.

Enabling Extended Protection

Extended Protection is automatically enabled during Exchange Server 2019 CU14 (or later) setup. On older versions of Exchange Server, which support Extended Protection, it can be enabled via a script provided by Microsoft (recommended) or manually through IIS Manager.

To correctly configure Extended Protection, each virtual directory on all Exchange servers in the organization (excluding Edge Transport servers) must be set to prescribed value of Extended Protection and sslFlags.

The following table summarizes the settings needed for each virtual directory on the supported versions of Exchange Server.

IIS Website	Virtual Directory	Recommended Value	Recommended sslFlags
Default Website	API	Required	Ssl,Ssl128
Default Website	AutoDiscover	Off	Ssl,Ssl128
Default Website	ECP	Required	Ssl,Ssl128
Default Website	EWS	Accept (UI) / Allow (Script)	Ssl,Ssl128
Default Website	MAPI	Required	Ssl,Ssl128
Default Website	Microsoft-Server-ActiveSync	Accept (UI) / Allow (Script)	Ssl,Ssl128
Default Website	Microsoft-Server-ActiveSync/Proxy	Accept (UI) / Allow (Script)	Ssl,Ssl128
Default Website	OAB	Accept (UI) / Allow (Script)	Ssl,Ssl128
Default Website	OWA	Required	Ssl,Ssl128
Default Website	PowerShell	Off	SslNegotiateCert
Default Website	RPC	Required	Ssl,Ssl128
Exchange Backend	API	Required	Ssl,Ssl128
Exchange Backend	AutoDiscover	Off	Ssl,Ssl128
Exchange Backend	ECP	Required	Ssl,Ssl128
Exchange Backend	EWS	Required	Ssl,Ssl128
Exchange Backend	Microsoft-Server-ActiveSync	Required	Ssl,Ssl128
Exchange Backend	Microsoft-Server-ActiveSync/Proxy	Required	Ssl,Ssl128
Exchange Backend	OAB	Required	Ssl,Ssl128
Exchange Backend	OWA	Required	Ssl,Ssl128
Exchange Backend	PowerShell	Required	Ssl,SslNegotiateCert,Ssl128
Exchange Backend	RPC	Required	Ssl,Ssl128
Exchange Backend	PushNotifications	Required	Ssl,Ssl128
Exchange Backend	RPCWithCert	Required	Ssl,Ssl128
Exchange Backend	MAPI/emsmdb	Required	Ssl,Ssl128
Exchange Backend	MAPI/nspi	Required	Ssl,Ssl128

Enabling Extended Protection by using Exchange Server 2019 CU14 (or later) installer

With Exchange Server 2019 CU14 and later, the Exchange Server 2019 Cumulative Update (CU) installer automatically enables Extended Protection on the Mailbox server where setup is executed. This happens for any new installation or when upgrading an existing Exchange Server installation to the latest version.

There are two new parameters that can be used in unattended setup mode to control the Extended Protection enabled by default behavior.

The parameters can be used to skip the automatic activation of Extended Protection (/DoNotEnableEP) or to not enabled Extended Protection on the Front-End EWS virtual directory (/DoNotEnableEP_FEEWS).

Extended Protection CU installer configuration scenarios

In this section, we provide the most common scenarios for configuring Extended Protection on Exchange Server by the help of the Exchange Server 2019 CU14 (or later) Cumulative Update (CU) installer.

Make sure that the Exchange server is properly configured and fulfills the requirements as outlined in the Prerequisites for enabling Extended Protection on Exchange Server section.

Scenario 1: Enable Extended Protection on an Exchange Server 2019

Run the Exchange Server 2019 CU14 (or later) setup in attended or unattended mode. The installer will configure Extended Protection as part of the installation of the server on which it was run.

Scenario 2: Enable Extended Protection on an Exchange Server 2019 which is published via Hybrid Agent

Follow the steps as outlined in the Identifying Exchange servers that are published using Hybrid Agent section to identify the Exchange Servers which are published via Hybrid Agent.

Run the Exchange Server 2019 CU14 (or later) setup in unattended mode by using the /DoNotEnableEP_FEEWS parameter. It skips enabling Extended Protection on the Front-End EWS virtual directory:

<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP_FEEWS

Scenario 3: Skip enabling of Extended Protection by Exchange Server 2019 CU14 (or later) setup

Run the Exchange Server 2019 CU14 (or later) setup in unattended mode by using the /DoNotEnableEP parameter. It skips enabling Extended Protection:

<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP

Enabling Extended Protection by using the PowerShell script

You can use the ExchangeExtendedProtectionManagement.ps1 script, to enable Extended Protection on some or all your Exchange servers at once.

You can run the script on any specific Exchange Server in your environment, which has the Exchange Management Shell (EMS) installed.

Permissions to configure Extended Protection by using the PowerShell script

The user who runs the script, must be a member of the Organization Management role group. The script must be executed from an elevated Exchange Management Shell (EMS).

Extended Protection script configuration scenarios

In this section, we provide the most common scenarios for configuring Extended Protection on Exchange Server by the help of the ExchangeExtendedProtectionManagement.ps1 PowerShell script.

Read the script documentation for more examples and a description of the script parameters.

Scenario 1: Enable Extended Protection on all Exchange Server

Run the script as follows to enable Extended Protection on all Exchange servers within your organization:

.\ExchangeExtendedProtectionManagement.ps1

The script performs several checks to ensure that all Exchange servers are on the minimum required CU and SU version to enable Extended Protection. It also checks if all Exchange servers are using the same TLS configuration.

After the prerequisites checks have been passed, the script will enable Extended Protection and add the required SSL flags on all virtual directories of all Exchange servers in scope. It stops in case that an Exchange server doesn't fullfil the requirements (for example, if an inconsistent TLS configuration was detected).

Scenario 2: Configure Extended Protection when running a Modern Hybrid configuration

In case you have Modern Hybrid configuration, you must skip enabling Extended Protection on the Front-End EWS virtual directory on Exchange Servers, which were published using the Modern Hybrid Agent.

This configuration can be done by using the ExcludeVirtualDirectories parameter:

.\ExchangeExtendedProtectionManagement.ps1 -ExchangeServerNames MHServer1, MHServer2 -ExcludeVirtualDirectories "EWSFrontEnd"

Enable Extended Protection by using IIS Manager

If you want to enable Extended Protection in your environment manually without using the script, you can use the following steps.

Set Extended Protection to required or accept for on a virtual directory

1. Launch the IIS Manager (INetMgr.exe) on the Exchange server on which you want to configure Extended Protection
2. Go to Sites and select either the Default Web Site or Exchange Back End
3. Select the virtual directory, which you want to configure
4. Select Authentication
5. If Windows Authentication is enabled, select Windows Authentication

   

6. Select Advanced Settings (on the right side) and in the opening window, select the suitable value from the Extended Protection dropdown

   

Set the Required SSL setting for a virtual directory

1. Click on the virtual directory to open the home page

   

2. Select SSL Settings
3. Check the Require SSL settings to make sure that Require SSL is enabled for the virtual directory

   

4. Click Apply to confirm the new setting

Disabling Extended Protection

You can use the ExchangeExtendedProtectionManagement.ps1 PowerShell script to disable Extended Protection.

The following command will disable Extended Protection configuration for all the Exchange Servers that are online by setting the value at all current configuring locations to None:

.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection

You can also specify a subset of servers on which Extended Protection should be disabled:

.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection -ExchangeServerNames ExchServer1, ExchServer2

Troubleshooting

This section contains known issues that exist with Extended Protection and lists some troubleshooting tips for known failure scenarios.

Known issues with Extended Protection

All previously reported issues with Extended Protection on Exchange Server have been fixed. We strongly recommend to install the latest Exchange Server update for the version of Exchange that you run in your organization to benefit from the latest fixes and improvements.

Issue: When you execute /PrepareSchema, /PrepareDomain or /PrepareAllDomains in Exchange Server 2019 CU14 unattended mode setup shows that Extended Protection has been activated

This is a known issue with Exchange Server 2019 CU14 which can be safely ignored. Extended Protection isn't enabled when running /PrepareSchema, /PrepareDomain or /PrepareAllDomains to prepare the environment as described in the Prepare Active Directory and domains for Exchange Server documentation.

Issue: Changing permissions for Public Folders by using an Outlook client fails with the following error: 'The modified Permissions can't be changed'

This issue happens if the Public Folder for which you try to change the permissions, is hosted on a secondary Public Folder mailbox while the primary Public Folder mailbox is on a different server.

The issue has been fixed with the latest Exchange Server update. Follow the instructions as outlined in this KB to enable the fix.

Issue: Creating Public Folders by using an Outlook client fails with the following error: 'Cannot create the public folder. You do not have sufficient permissions to perform this operation on this object. See the folder contact or your system administrator.'

This issue happens if the Public Folder for which you try to change the permissions, is hosted on a secondary Public Folder mailbox while the primary Public Folder mailbox is on a different server.

The issue has been fixed with the latest Exchange Server update. Follow the instructions as outlined in this KB to enable the fix. Note that this fix does not work if a global override to set PublicFolderHierarchyHandlerEnabler to disabled has been implemented to address the issue outlined in this KB.

Warnings and errors during Extended Protection configuration script execution

1. The script shows a warning of known issues and asks for confirmation:

   To prevent administrators from running into scenarios where existing Exchange Server functions are disrupted due to enabling Extended Protection, the script provides a list of scenarios which have known issues. Read and evaluate this list carefully before enabling Extended Protection. You can proceed to turn on Extended Protection by pressing Y.

   

2. The script doesn't enable Extended Protection because a prerequisite check failed:

   • No Exchange server runs a build that supports Extended Protection:

     If no Exchange server in the organization is running a build that supports Extended Protection, the script doesn't enable Extended Protection on unsupported servers to make sure that server-to-server communication doesn't fail.

     To resolve this case, update all Exchange servers to the latest CU and SU and run the script again to enable Extended Protection.

   • TLS mismatch was detected:

     A valid and consistent TLS configuration is required on all Exchange servers in scope. If the TLS settings on all servers in scope aren't the same, enabling Extended Protection disrupts client connections to mailbox servers.

     

     Read the Exchange Server TLS configuration best practices for more information.

3. Some Exchange servers aren't available/reachable:

   The script performs multiple tests against all Exchange servers, which are in scope. If one or more of these servers aren't reachable, the script excludes them as it can't perform the required configuration action on these machines.

   

   If the server is offline, you should configure Extended Protection as soon as it's back online. If the server was unreachable for other reasons, you should run the script on the server itself to enable Extended Protection.

Users can't access their mailbox through one or more clients

There could be multiple reasons why some or all clients can start giving authentication errors to users after Extended Protection was enabled.

• Users can't access their mailbox permanently or sporadically by using Outlook for Windows, Outlook for Mac, Outlook Mobile or the native iOS email client:

  • If the TLS configuration across the Exchange organization isn't the same (for example, the TLS configuration has been changed on one of the Exchange servers after Extended Protection was enabled), this misconfiguration can cause client connections to fail. To resolve this issue, check the instructions to properly configure TLS on all Exchange servers, and then use the script to configure Extended Protection again.

  • Check if SSL Offloading is used. Any SSL termination causes the Extended Protection Channel Binding Token check to fail as SSL Offloading is considered as a man-in-the-middle, which is prevented by Extended Protection. To resolve this issue, disable SSL Offloading and use the script to enable Extended Protection again.

• Users can access their emails by using Outlook for Windows and OWA, but not through non-Windows clients like Outlook for Mac, Outlook Mobile or the iOS native email client. This can happen if the Extended Protection setting for EWS and/or Exchange ActiveSync is set to Required on one or all Front-End servers:

  • To resolve this issue, either run the ExchangeExtendedProtectionManagement.ps1 script with the ExchangeServerNames parameter and pass the name of the Exchange server, which has a misconfigured Extended Protection setting. You can also run the script without any parameter to check and configure Extended Protection for all servers again

  • Alternatively, you can also use IIS Manager (INetMgr.exe) and change the Extended Protection setting for those virtual Directories to the proper value as outlined in the table. We strongly recommend using the script as it checks for the correct values and performs the reconfiguration automatically if the values aren't set as expected.

• Users are unable to access OWA or ECP by using the Apple Safari browser on macOS or iOS when NTLM SSO is used and Extended Protection was enabled:

  • For users on the macOS platform, we suggest utilizing a web browser with Extended Protection support. Our recommendation is Microsoft Edge (Chromium).

  • For users on the iOS platform, there is no web browser with Extended Protection support.

  • A solution that works on both platforms is to configure Hybrid Modern Authentication for OWA and ECP or use AD FS claims-based authentication with Outlook on the web.

If after following the above steps, some clients are still not working as expected, you can roll back Extended Protection temporarily and report the issue to Microsoft by opening a support case with us. Follow the steps as outlined in the Disabling Extended Protection section.

Hybrid free/busy or mailbox migration isn't working

If you're using Modern Hybrid, enabling Extended Protection can cause Hybrid features like free/busy and mailbox migration to stop working if the configuration wasn't performed as described in this article. To resolve this issue, identify the hybrid servers that were published using Hybrid Agent and disable Extended Protection on the Front-End EWS virtual directory on these servers.

Public Folders are no longer visible/accessible

There are two issues that could affect Public Folders connectivity when Extended Protection is enabled. Make sure to follow the instructions as outlined in the Extended Protection and Public Folders section of this article.

FAQs

Question: Is it required to install the August 2022 Security Update (SU) if it was already installed on the previous Cumulative Update (CU)?
Answer: Yes, it's required to install the August 2022 SU again if you update to a newer CU build (for example, Exchange Server 2019 CU11 to Exchange Server 2019 CU12).

Remember: If you plan to do the update immediately (means CU + SU installation), Extended Protection doesn't need to be switched off. If you plan to stay on the CU without installing the SU immediately, you must disable Extended Protection as the CU build (without the SU being installed), doesn't support Extended Protection and therefore, you might experience client connectivity issues.

Question: Is it safe to enable Extended Protection in an environment that uses Active Directory Federation Services (AD FS) for Outlook on the web (OWA)?
Answer: Yes, Extended Protection doesn't have an impact on AD FS claims-based authentication with OWA.

Question: Is it safe to enable Windows Extended Protection in an environment that uses Hybrid Modern Auth (HMA)?
Answer: Yes, HMA won't be impacted from this change. While Extended Protection doesn't further enhance HMA, Windows authentication can still be used for applications that don't support Hybrid Modern Auth. Considering this, the enablement of Extended Protection would be recommended in any environment eligible that still has Exchange on-premises services.

Question: Does Extended Protection affect Hybrid Modern Auth or Microsoft Teams integration?
Answer: Extended Protection doesn't affect Microsoft Teams integration or Hybrid Modern Auth.

Question: I am unable to access OWA/ECP after enabling Extended Protection with an HTTP 400 status code, my OWA/ECP is published through the Entra Application Proxy, what can I do to resolve this?
Answer: Publishing Exchange OWA/ECP through the Entra Application Proxy isn't supported, you'll need to publish OWA/ECP through a supported network topology by Extended Protection Standards.

Question: While we understand that preventing MitM attacks is important, can we have our own devices in the middle with our own certificates?
Answer: If the device uses the same certificate as the Exchange server, they can be used.