How to Enable Extended Protection for Authentication on Exchange

Extended Protection for AuthenticationExtended Protection for Authentication🛡️A Windows security feature that binds an authentication token to the TLS channel it was issued on, so a token replayed on a different channel is rejected. It is the primary defense against NTLM relayNTLM Relay🛡️An attack where a valid NTLM authentication is forwarded in real time to a different service than the one intended, granting the attacker the victim's access without ever cracking a credential.. is one of those security features that does nothing until you deliberately enable it, and then quietly defeats an entire class of attack. The Exchange CVE-2026-62911 authentication bypassAuthentication Bypass📖A security vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. that allows an attacker to circumvent the login verification process and gain unauthorized access to a system without providing valid credentials. is a direct consequence of that gap: the vulnerable endpoint did not enforce Extended Protection, so a relayed authentication sailed through. This guide explains what the control does and how to deploy it correctly.

What Extended Protection Actually Does

Extended Protection for Authentication, sometimes abbreviated EPA, adds a binding between an authentication token and the specific secure channel it travelled over. It does this with a mechanism called a Channel Binding TokenChannel Binding Token🛡️A fingerprint of a TLS session attached to an authentication token so the server can confirm the token arrived over the same channel it was issued on. It is the mechanism Extended Protection uses to stop relay., which ties the authentication to the TLS session between client and server.

The practical effect is simple. In a relay attack, an attacker captures an authentication from one connection and replays it on another. With channel binding in place, the token carries a fingerprint of its original TLS channel. When it arrives on a different channel, the server sees the mismatch and rejects it. The relayed authentication that would otherwise succeed now fails. This is the same defensive idea that underpins hardening against how NTLM relay attacks bypass authentication.

Before You Enable It

Extended Protection is powerful, but turning it on blindly can break legitimate traffic, so preparation matters.

• PatchPatch🛡️A software update that fixes security vulnerabilities, bugs, or adds improvements to an existing program. first. Make sure every Exchange server in the organization is on a build that supports Extended Protection and has the current security updates. Enabling the control on a server that is out of date, or in a mixed environment where some servers are unpatched, can cause authentication failures.
• Require TLS. Extended Protection depends on TLS being properly configured, because the channel binding is derived from the TLS session. Confirm that TLS 1.2 or higher is enforced and that older protocols are disabled.
• Inventory your virtual directories. Exchange exposes several authentication endpoints as IIS virtual directories, and the setting has to be applied consistently across them rather than to a single one.

Turning It On

Microsoft ships tooling to configure Extended Protection across Exchange rather than expecting administrators to edit each virtual directory by hand, and using the supported tooling is strongly preferred because it applies consistent settings and understands the dependencies between endpoints.

The control is exposed in IIS on each Exchange virtual directory under the Windows Authentication settings, where Extended Protection can be set to Off, Allow, or Required. Allow accepts both bound and unbound tokens, which is useful as a transitional state; Required enforces binding and is the hardened target state. You can verify the current value on a given virtual directory by querying its token-checking configuration, for example with Get-WebConfigurationProperty against the windowsAuthentication filter and the extendedProtection.tokenChecking property. Move from Allow to Required only after confirming clients authenticate cleanly in the Allow state.

Deploying Microsoft's Exchange Emergency Mitigation service alongside this work gives you a fast way to apply interim protections while you validate the full configuration.

Verify and Monitor

After enabling Extended Protection, confirm that mail flow, client connectivity, and hybrid features still work, because these are the areas most likely to reveal a misconfiguration. Watch authentication logs for failures that cluster around the change, which usually point to a virtual directory that was missed or a client stuck on outdated TLS.

On an ongoing basis, treat Extended Protection as part of your baseline configuration, not a one-time fix. New cumulative updates, reinstalled servers, and added virtual directories can all reset or omit the setting, which is how servers that were once protected drift back into exposure. This drift is a big part of why so many servers remained vulnerable to the Exchange flaw despite a patch being available, a pattern explored in the analysis of the CVE-2026-62911 exposure. Pair this control with a broader plan to reduce an internet-facing Exchange server's attack surfaceAttack Surface🛡️The sum of all points where an unauthorized user could attempt to enter or extract data from a system: exposed services, interfaces, accounts, and integrations. Reducing attack surface means removing reachability, not just patching. for defense in depthDefense in Depth🛡️A security strategy using multiple layers of protection so that if one layer fails, other layers continue to provide security..