In September 2022, we announced that we will start the retirement of Client Access Rules (CARs) in Exchange Online. Since then, CARs have already been retired for tenants without active rules. CARs will be deprecated for all tenants on September 1, 2025. Additionally, if tenants choose to turn off CARs before the deadline, we will disable it for their tenant. We recommend moving away from CARs as soon as possible to ensure a smooth transition and to take advantage of the enhanced security features offered by Conditional Access (CA) with Continuous Access Evaluation (CAE).
Background
CARs help you control access to your Exchange Online organization based on client properties or client access requests. However, CARs are now considered legacy technology. Further, CARs defined in the service would work only with Exchange Online.
We recommend using Conditional Access (CA) with Continuous Access Evaluation (CAE) instead of CARs. CAE ensures your location policies are applied when you configure IP location-based CA policies. Multiple Microsoft 365 services support CAE, including Exchange Online, SharePoint Online, and Teams.
Even when considering Exchange Online alone, many new protocols and services have been introduced in Exchange Online over the years, and only a small subset of protocols enforce CARs. In contrast, CA with CAE can truly allow or block access to those services. Additionally, CARs only provide basic enforcements, such as filtering by IP address, protocol, and user. They lack modern enforcement controls required for higher security standards, such as the physical location of the device, multi-factor authentication (MFA), and device compliance.
This makes CARs outdated and insufficient for meeting higher security requirements. This limited functionality that CARs offer overlaps with CA and CAE. Exchange Online implements CAE, which provides the functional equivalent of CARs, where the IP location CA policies are evaluated on every access to Exchange Online.
Conditional Access also provides rich monitoring and reporting insights, allowing IT admins to gain visibility into how their policies are enforced. Microsoft continues to enhance both CA and CAE as part of its Entra ID services, ensuring ongoing improvements and investments in this area.
Please note that Exchange Server on-premises CARs are completely separate from this deprecation and guidance and continue to be managed on-premises separately.
Migrating from CARs to CAE
If you are using CARs, you will not be able to do so after September 1, 2025. To migrate from CARs, consider the following:
- Configure the necessary IP location Conditional Access policies to enable IP location enforcement with Continuous Access Evaluation while accessing Exchange Online.
- Utilize the Set-CASMailbox and Set-CASMailboxPlan cmdlets to configure client access settings on a mailbox for specific protocols. For instance, you can configure settings for Exchange ActiveSync, Outlook, Outlook on the web, POP3, and IMAP4.
Please note that if today you use CARs, you must take action before September 2025. After this date, existing CARs will no longer function as the feature will be deprecated.
Migration Options
Migration of a single rule falls into 3 categories, using variations of IP addresses conditions and protocol conditions as shown in the below table. Use this table to analyze which category your rule falls under. We recommend testing your new CA rules before deleting any existing CAR. Additionally, after setting up CA, wait 24 hours before deleting your CARs to allow policies to sync with Exchange Online. This will ensure that there is no period during which your tenant is not protected by your rules.
|
|
|
is AnyOfClientIPAddressesOrRanges or ExceptAnyOfClientIPAddressesOrRanges set? |
|
|
|
|
No |
Yes |
|
is AnyOfProtocols or ExceptAnyOfProtocols set? |
No |
Supported. See “Migrating User-Only Based Rules” section below. |
Supported. See “Migrating IP Address-Only Rules” section below. |
|
Yes |
Partially supported. See “Migrating Protocol-Only Rules” section below. |
Not supported. See “About Rules with IP Address and Protocol Conditions” |
|
Category 1: Migrating User-Only Based Rules
These rules have no conditions based on IP addresses or protocols. They essentially allow or deny access to all of Exchange Online.
|
If your Client Access Rule looks like this |
Then do this |
AnyOfClientIPAddressesOrRanges : {}
|
Create a Conditional Access policy to allow or deny access to the Exchange Online application referencing the same user used in the CAR.
|
AnyOfClientIPAddressesOrRanges : {}
|
Create a security group with dynamic membership which uses the regex as criteria for the userPrincipalName property (domain\user format is not supported). More details here: Manage rules for dynamic membership groups in Microsoft Entra ID. Then create a Conditional Access policy to allow or deny access to the Exchange Online application, and the condition with reference to the security group above. |
AnyOfClientIPAddressesOrRanges : {}
|
Create a security group with dynamic membership which uses the same filter. More details here: Manage rules for dynamic membership groups in Microsoft Entra ID. Create a Conditional Access policy to allow or deny access to the Exchange Online application referencing the same security group used in the CAR. |
Category 2: Migrating IP Address-Only Rules
This applies to rules which specify IP address condition (either AnyOfClientIPAddressesOrRanges or ExceptAnyOfClientIPAddressesOrRanges), but no protocol condition (either AnyOfProtocols or ExceptAnyOfProtocols).
They may or may not contain user-based condition (any of these: UsernameMatchesAnyOfPatterns, ExceptUsernameMatchesAnyOfPatterns, UserIsMemberOf, ExceptUserIsMemberOf). The steps described in the section above also apply here for the variation on how to specify users.
|
If your Client Access Rule looks like this |
Then do this |
AnyOfClientIPAddressesOrRanges : 203.0.113.4 or AnyOfClientIPAddressesOrRanges : {}
|
Create a Conditional Access policy to allow or deny access for those IP addresses for the Exchange Online application. Network in Conditional Access policy
See Conditional Access - Block access by location for a step-by-step guide to set the policy.
|
AnyOfClientIPAddressesOrRanges : 203.0.113.4 or AnyOfClientIPAddressesOrRanges : {}
|
Create a Conditional Access Policy to allow or deny access for those IP ranges, applying only to those specific users. |
Sample steps to create a Conditional Access policy that matches one of the examples above:
$params = @{
"@odata.type" = "#microsoft.graph.ipNamedLocation"
DisplayName = "Corp network IPv4 address"
IsTrusted = $true
IpRanges = @(
@{
"@odata.type" = "#microsoft.graph.iPv4CidrRange"
CidrAddress = "203.0.113.4/32"
}
)
}
$namedLocation = New-MgIdentityConditionalAccessNamedLocation -BodyParameter $params
$params = @{
displayName = "Allow access only from corp network."
state = "enabled"
conditions = @{
clientAppTypes = @("all")
applications = @{ includeApplications = @("00000002-0000-0ff1-ce00-000000000000") }
locations = @{ includeLocations = @($namedLocation.Id) }
}
grantControls = @{
operator = "OR"
builtInControls = @("block")
}
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $paramsCategory 3: Migrating Protocol-Only Rules
This applies to rules which specify protocol condition (either AnyOfProtocols or ExceptAnyOfProtocols), but no IP address condition (either AnyOfClientIPAddressesOrRanges or ExceptAnyOfClientIPAddressesOrRanges).
Protocol is: Active Sync, Admin Center, EWS, IMAP, OutlookAnywhere, OWA, or POP
This applies to protocol-only rules when the protocol is one of the following: ExchangeActiveSync, ExchangeAdminCenter, ExchangeWebServices, IMAP4, OutlookAnywhere, OutlookWebApp, POP3.
|
If your Client Access Rule looks like this |
Then do this |
AnyOfClientIPAddressesOrRanges : {}
|
For any existing users (with a mailbox and a license) to whom this rule would apply, run the following (as an example, using OWA and EWS): Set-CASMailbox -EwsEnabled -OWAEnabled If you want these restrictions to apply to all future users created with a mailbox and a specific license, you can also create the following CAS Mailbox Plan (using the same example as in Set-CASMailbox above): Set-CASMailboxPlan -EwsEnabled -OWAEnabled If you only want this to apply to particular new users, however, Set-CASMailbox will need to be run for those users in the future. (Note: See table below for the equivalent Set-CASMailboxPlan) parameter names with respect to the CARs parameter name.) |
Protocol is: RemotePowerShell
This applies to protocol-only rules when the protocol is RemotePowerShell.
AnyOfClientIPAddressesOrRanges : {}
|
For any existing users to whom this rule would apply, run the following: Set-User –RemotePowerShellEnabled For new users to whom this rule would apply, Set-User will need to be run again the same way; Set-CASMailboxPlan would have a gap in coverage in this case, because it only applies to users with a mailbox and a particular license applied, but RPS can be used by users without a mailbox/license, unlike the other protocols. Therefore, Set-User should be applied for future users instead, to prevent that gap. |
Protocol is: OfflineAddressBook, PowerShellWebServices, or REST
This applies to protocol-only rules when the protocol is one of the following: OfflineAddressBook, PowerShellWebServices, REST.
Rule applies to specific protocol(s) and to specific usernames/username patterns/user groups, but not to IP ranges, IF the protocol(s) the rule applies to is one of the following: OfflineAddressBook, PowerShellWebServices, REST.
|
There is no equivalent to using other cmdlets for the protocols OfflineAddressBook, PowerShellWebServices, or REST. OfflineAddressBook is a service only used by Outlook Win32 and Outlook for Mac, and if customers block user access to Outlook Win32 using OutlookAnywhere, it is not necessary to block OfflineAddressBook, as it will never be accessed by the Outlook client. |
About Rules with IP Address and Protocol Conditions
This applies to rules which specify both protocol condition (either AnyOfProtocols or ExceptAnyOfProtocols) and IP address condition (either AnyOfClientIPAddressesOrRanges or ExceptAnyOfClientIPAddressesOrRanges.
If you have multiple rules and those rules use different IP addresses, or range of addresses, but have all the exact same list of protocols for all users, then you can configure IP location CA policies with those IP addresses, and the condition for protocols you can migrate to CASMailbox and CASMailboxPlan:
|
If your Client Access Rule looks like this |
Then do this |
|
Rule 1: AnyOfClientIPAddressesOrRanges : 203.0.113.4 Rule 2: AnyOfClientIPAddressesOrRanges : 203.0.201.10 |
Create a Conditional Access policy to allow or deny access for those different sets of IP addresses for the Exchange Online application.
Use Set-CASMailbox to disable access to all protocols except MapiEnabled, for all existing users. Use Set-CASMailboxPlan to set the same policy for all users that are created in the future. |
If you have multiple rules and those rules have different set of protocols, but the exact same set of IP addresses, or range of addresses, you can configure IP location CA policies and CASMailbox and CASMailboxPlan:
|
If your Client Access Rule looks like this |
Then do this |
|
Rule 1: AnyOfClientIPAddressesOrRanges : 203.0.113.4 Rule 2: AnyOfClientIPAddressesOrRanges : 203.0.113.4 |
Create a Conditional Access policy to allow or deny access for that IP address for the Exchange Online application.
Use Set-CASMailbox to disable access to all protocols except MapiEnabled and ActiveSync, for all existing users. Use Set-CASMailboxPlan to set the same policy for all users that are created in the future. |
However, if you have multiple rules which have different sets of protocol and different sets of IP addresses, or range of addresses, across those rules, there is no migration option for them. Our recommendation is that you reconcile your rules to have a single set of IP addresses, or range of addresses, that is a superset of all addresses, and use that in Conditional Access policy to apply to Exchange Online application.
Corresponding Set-CASMailboxPlan Parameters
The following is a table of CARs protocol names and the corresponding parameter for Set-CASMailboxPlan:
|
CARs Protocol |
SetCASMailboxPlan Parameter |
|
ExchangeActiveSync |
ActiveSyncEnabled |
|
ExchangeAdminCenter |
ECPEnabled |
|
ExchangeWebServices |
EwsEnabled |
|
IMAP4 |
ImapEnabled |
|
OutlookAnywhere |
MAPIEnabled |
|
OutlookWebApp |
OWAEnabled |
|
POP3 |
PopEnabled |
Frequently Asked Questions
1. I completed migration of IP based policies CARs to Conditional Access. Is my access policy to Exchange Online enforced the same way as it was enforced before?
After migration, your access policies continue to be effective, but the mechanism of such enforcements changes. With CARs, IP based access policies were evaluated when the user connected to Exchange Online resources, while with Conditional Access they are evaluated starting login time and then with CAE during resource access.
2. What is CAE with strict enforcement and is it required to protect my organization?
When a named IP location CA policy is correctly configured, CAE immediately denies access to Exchange Online from IP addresses that aren’t in the trusted locations configured in the CA policy. Strict location enforcement is not necessary for CAE’s IP policy to work.
In some complex network topologies, authentication requests can come from allowed IP addresses even when the access request originates from disallowed ones. In such cases, Microsoft Entra suspends IP address checks for Exchange Online for an hour and the location checks are done periodically every hour at token issuance. This exception maintains user productivity by ensuring access to critical resources. You shouldn’t enable strict location enforcement in these topologies as your users would lose access to Exchange Online immediately.
For stable networks, where both the login traffic and data connections both consistently match the IP location CA policy, you can opt for Strict Location Enforcement mode (in preview), but enable it cautiously by following the documentation as it may impact users negatively.
We hope that this post provides clarity about CAR deprecation. Please leave comments below if you have additional concerns.
The Exchange Online Team
Microsoft
