Getting Started with Office 365 Client Access Policies Skip to main content
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Getting Started with Office 365 Client Access Policies
Published: Jun 17, 2016   -   Updated: Jun 25, 2018

What are Office 365 Client Access Policies?

Note: Some options described in this topic may be Early Access features which may not be available in your org. To enable them, contact Okta Support.


Important Security NoteLegacy email protocols such as IMAP and POP are not capable of processing Client Access Policies or MFA. This can present a significant security risk, as potential attackers who acquire user credentials will not be challenged for MFA if they use a legacy protocol. To disable these legacy protocols in your Office 365 tenant, please refer to How to enable or disable POP3, IMAP, MAPI, Outlook Web App or Exchange ActiveSync for a mailbox in Office 365

In the past, Okta was able to restrict access to your applications based on network location, group membership, and Multi-Factor Authentication (MFA), just to name a few.

With Office 365 Client Access Policies, we extend the reach of these controls. Now, Okta allows you to set specific access requirements for different client types (desktop clients, mobile devices, and web browsers) that access Office 365 services.

In order to achieve this granular level of control, Okta leverages host headers sent from the client and from the Office 365 service to make access decisions based on the policies that you configure. These headers include details about:

  • Originating IP Address

  • Client Type (Desktop, Mobile, Web Browser)

Note: Okta determines the client type by reading the request header. The client writes the header, which is responsible for its accuracy. Okta provides flexibility to inspect these headers as part of our System Log functionality that is detailed later in this guide.

You can deploy Office 365 Client Access Policies in your environment incrementally (by applying rules to groups and users) or across all users that access the application. It is important to thoroughly review this guide to ensure that the policies apply to your enterprise as you intend.

Where are Office 365 Client Access Policies configured?

Before you begin, ensure that you have an Office 365 application created in your Okta tenant, and that the application uses Single Sign-On (SSO). If you’re just getting started with Office 365, refer to our Office 365 Deployment Guide for setup instructions and configuration options.

Once you configure the application and SSO, you’re ready to get started with Office 365 Client Access Policies.

  1. From the Okta Admin Console, go to Applications > Applications > Office 365.

  2. Click the Sign On tab.

  3. Scroll to Sign On Policy.

    The default Sign On rule allows access to all clients from any network without requiring MFA. It cannot be modified.

    Note: Okta evaluates rules by priority, starting from Priority 1 to the final rule. Okta then applies the rule that first matches. If a user does not fall within the scope of a preceding rule (or rules applied globally across the tenant), they will be subject to the ‘Default sign on rule’ allowing access to Office 365 services.

  4. Click Add Rule to get started configuring rules for Office 365 Client Access Policies.

Configuring Rules for Office 365 Client Access Policies

You can layer rules for Office 365 Client Access Policies to provide a tightly controlled user sign-on experience. User experience depends on the different components present in each of the rules. 

  1. Give a descriptive name for each of your rules.

  2. Configure the Conditions that will cause a user to fall into the scope of this rule:

    User-added image

Note: Depending on the configuration and features available in your Okta tenant, your user interface may vary. The ability to configure multiple Network Location Zones requires Okta’s Adaptive MFA SKU.

Looking at the App Sign On Rule above, consider the following configuration options when developing your own rules:


You can scope Office 365 Client Access Policies to all users accessing the Office 365 application, or you can break them down to a subset of users/groups. When configuring these rules it is important to consider:

  • Should the rule apply to all users accessing the Office 365 application?

  • Should the rule apply to a subset of users or groups only? Consider scoping the rule to groups or users if:

    • There is a requirement to enable exceptions for application access.

    • There is a need to slowly phase these sign-on rules into an existing Office 365 deployment.


You can also scope rules to specific locations or zones. The Office 365 Client Access Policies work seamlessly with Okta’s Geographic Network and IP Zones that can be configured in the Okta Admin console within Security > Network.

In order to apply these rules, Okta relies on the IP Address(es) that are passed in the authentication request headers. It is recommended to include Microsoft's Exchange Online IP addresses (listed here) as Proxy IPs in your Network configuration. Consult our Network guide for details.

It is important to consider the impact of network zones when thinking about restricting access and prompting for MFA. The available options include:

  • Anywhere: Apply this rule to all users regardless of where the access is originating.

  • In Zone: Apply this rule to users coming from a specific location or IP Range.

    As an example, you may have a branch office in a location with questionable security. As a result, you may require MFA to be conducted always from this location.

  • Not in Zone: Apply this rule to anyone not coming from a specific location or IP Range.

    As an example, you may have Corporate Offices configured as a network location in Okta. When a user is not coming from one of these known networks, you may require that MFA be enforced always in this location.


The key to Office 365 Client Access Policies is the ability to distinguish different access based on the client that is accessing the Office 365 resource.

Note: Clients using Modern Authentication are treated as web browsers. Microsoft documents this limitation as part of Office Clients and the Office 365 service. Further detail is available from:

User-added image

Client can refer to:



  • Mobile:
    • iOS
    • Android
    • Other mobile (e.g. Blackberry). Select this option for:
      • Non-iOS and non-Android clients (for example, Blackberry).
      • Client types for which Okta cannot determine the OS Type by inspecting the request header. For example, when using an Outlook mail app on an iOS or Android device, the request header contains both iOS and Android. Selecting Other allows the client access policy to evaluate requests from these clients.
  • Desktop:
    • Windows
    • macOS
    • Other desktop (e.g., Linux)

Device Trust

Note: This is an Early Access feature. To enable it, contact Okta Support.

If enabled for your org, device trust settings allow you to gate access to apps depending on whether users' devices are trusted. For details, see Device Trust documentation.


Finally, specify the actions that should be taken if the user falls into scope of the rule specified above:

User-added image

The key to selecting appropriate actions is deciding whether access should be Allowed or Denied.

  • If the user is coming from a risky or unknown network location, this may be cause to deny the request.

  • There may also be a requirement to prompt the user to re-authenticate after a certain amount of time prior to launching the application.

  • Finally, Okta can prompt the user to perform MFA when logging into the application.

Note: Okta enforces Sign On policies when a client is directed back to its Okta org. For browser-based clients, this generally occurs when the session is terminated by closing the browser or clearing cookies.

Note: For Desktop Clients (not using Modern Authentication) and Exchange ActiveSync clients, an authenticated session is cached for up to 24 hours within the Microsoft service. After configuring Client Access Policies to restrict these client types, it may take up to 24 hours in order for the restrictions to take effect.

For thick clients supporting MFA, the individual application or service determines the frequency at which they are directed back to Okta for authentication. For Microsoft Office applications, these refresh intervals are documented in