Office 365 Client Access Policies

Important Security Note

Legacy email protocols such as IMAP and POP are not capable of processing clientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. 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, refer to this Microsoft (MS) Support documentation: How to enable or disable POP3, IMAP, MAPI, Outlook Web app or Exchange ActiveSync for a mailbox in Office 365.

Okta policies allow you to restrict access to your applications based on end-user network location, group membership, and/or their ability to satisfy multifactor authentication (MFA) challenges. Office 365 client access policies allow you to extend the reach of these controls by specifying access requirements for the following client types that access Office 365 services:

  • Originating IP Address
  • Web browser
  • Modern authentication client
  • Exchange ActiveSync client
  • Modern authentication supported mobile apps (iOS, Android, other mobile)

To achieve this granular level of control, Okta leverages host headers sent from the client and Office 365 service to make access decisions based on the policies that you configure. 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.

Important to know about the User-Agent

Okta’s Client Access Policies (CAPs) allow you to manage access to your enterprise apps based on the client type and device platform. Okta CAPs evaluate information included in the User-AgentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. request header sent from the users’ browser. Because the User-Agent can be spoofed by a malicious actor, you should consider using a whitelist approach when you create CAPs and require MFA or Device Trust as described in the following best practices:

  1. Implement a whitelist consisting of one or more rules that specify the client type(s) + device platform(s) + trust posture combinations that will be allowed to access the appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in..
  2. Require Device Trust or MFA for app access.
  3. Include a final catch-all rule that denies access to anything that does not match any of the CAPs preceding rules.

Best Practices

  • Okta recommends that you configure Office 365 client access policies to only allow MFA-supported protocols. Enforcing MFA ensures a robust security framework.
  • Ensure that your end-users are using the most up-to-date app versions, especially for thick clients such as Microsoft Outlook.

Rule Configuration

Important Security Note

Legacy 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, refer to this Microsoft (MS) Support documentation: How to enable or disable POP3, IMAP, MAPI, Outlook Web app or Exchange ActiveSync for a mailbox in Office 365.

You can deploy Office 365 client access policies in your environment incrementally (by applying rules to users and/or user groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups.) or across all users that access the app.

Before you begin, do the following:

Note the following when creating new rules:

You can layer rules for Office 365 client access policies to provide a more tightly controlled user sign-on experience. This user experience is dependent on the components configured within the rules.

To create your rules, do the following:

  1. From the AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. Dashboard, hover over Applications drop-down menu.
  2. On the Applications page, scroll down to the Office 365 app instance and click the app.
  3. Click the Sign On tab. Scroll down to Sign On Policy.
  4. Click Add Rule. The App Sign On Rule page appears.
  5. Give a descriptive name for your rule.
  6. Configure the desired conditions for the rule.


Note: Depending on the configuration and features available in your Okta tenant, your user interface may vary.


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 you should consider who they should apply to

  • All users accessing the Office 365 app OR
  • Only a subset of users or groups

Consider scoping the rule to groups or a subset of 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 scope rules to specific locations or zones. The Office 365 client access policies work seamlessly with Okta’s geographic network and IP Zones. These options can be configured in Okta under Security > Networks.

In order to apply these rules, Okta relies on the IP Address(es) that are passed in the authentication request headers. Okta recommends including Microsoft Exchange Online IP addresses as proxy IPs in your network configuration.

It is important to consider the impact of network zones when restricting access and prompting for MFA.

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. Consider a branch office in a location with unreliable security, for example. You may make MFA a consistent requirement 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. You may require that MFA is always enforced when users are not coming from one of these known networks.


One benefit to Office 365 client access policies is that they allow you to manage access based on the client that is requesting the Office 365 resource.

Note: Clients using Modern Authentication client are treated as Web browsers. Microsoft documents this limitation as part of MS Office Clients and the Office 365 service. For details, refer to this MS Support documentation: MS TechNet: Things to know before onboarding.

Client type

Web browser or Modern Authentication client: Includes browsers such as Chrome, Safari, or Internet Explorer, as well as thick client applications configured to leverage Modern Authentication. This includes Office 2013 and 2016 clients with required patches or configuration updates, as detailed in this MS Support documentation: Updated Office 365 modern authentication.

Note: Modern Authentication is a configurable setting on the Office 365 tenant for Exchange Online. For more information about configuring this setting, refer to these Microsoft articles:

Exchange ActiveSync or Legacy Auth client: Includes native mail clients on iOS or Android devices, as well as older desktop clients on macOS and MS Windows that do not support modern authentication.

Note: Exchange ActiveSync or Legacy Auth client do not support multifactor authentication.

Platform type

  • iOS
  • Android
  • Other mobile options. Select this option for:
    • Non-iOS and non-Android clients such as Blackberry.
    • Client types for which Okta cannot determine the operating system 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.
  • MS Windows
  • macOS
  • Other desktop OS platforms such as Linux

Device Trust

This is an Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. feature. To enable it, contact Okta Support.

If enabled for your orgThe Okta container that represents a real-world organization., Device Trust settings allow you to gate access to apps depending on whether devices are trusted. For details, see Device Trust documentation.


Finally, when all the conditions set above are met, specify the actions to be taken if a user triggers a rule.

Specify whether the conditions you've set allow access to be Allowed or Denied:

  • You can deny access if a user is coming from a risky or unknown network location.
  • You can set a requirement to prompt the user to re-authenticate after a set amount of time has elapsed after the app has launched.
  • You can prompt the user to perform MFA when signing into the app.

Please also note the following:

  • 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.
  • 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 for the restrictions to take effect.

For thick clients supporting MFA, the individual app or service determines how frequently they are directed back to Okta for authentication. For MS Office apps, refer to this MS Support documentation, Session timeouts for Office 365, for refresh intervals.