Understanding Email Compliance

When email management is enabled in the AirWatch Console, AirWatch will determine whether to allow or block access to the email server for each device based on the various compliance rules and overrides that have been configured. This article outlines the overall process for AirWatch determining whether a device is allowed or blocked, as well as the multiple options available when configuring email compliance.

This article applies to the AirWatch Admin Console 8.0 and higher.

Email Compliance Algorithm

The AirWatch compliance engine will process numerous steps to determine whether a device will be allowed or blocked from accessing the EAS server based on the configured policies.. Though each step can be broken down further, there are three main phases in the evaluation:

  1. Is compliance currently active (or has it been disabled/is the SEG currently in test mode)?
  2. Has the device been separately whitelisted or blacklisted, thus overriding the compliance rules?
  3. Is the device compliant or non-compliant based on the configured rules?

AirWatch will work through these three phases in that order and ultimately determine whether to allow or block a device. If AirWatch determines a course of action in one of the earlier steps, then it will not process through the later steps for that particular device. The flow chart below shows the individual steps used when determining the status of a device.


Configuring Compliance Policies

When determining whether a device is compliant to the configured rules, a device must meet all specified criteria. If a device does not meet even one of the configured rules, that device will be marked as non-compliant. For each category, it is important to understand the result being reported in the Current Compliance Policies column. This column will describe the outcome of the currently configured policy for each category. The available configurable rule set is outlined below.

General Email Policies

These policies generally apply to both managed and unmanaged devices using the SEG or Direct PowerShell deployment models.

  • Sync Settings - This policy is the exception to the rule and only applies to SEG deployments. It allows administrators to determine which items (such as mail, calendar, contacts, etc.) can be synced by the mail client on the device. Note that any change to this policy will require the EAS profile to be reprovisioned to the device for the changes to take effect.
  • Managed Device - Only allow devices that are currently assigned to a particular MEMConfig.
  • User - Configure access for specific users or user groups.
  • EAS Device Type - Configure access based on the ActiveSync field DeviceType. This field roughly overlaps with a specific mail client on the device. Typically this policy is used to allow access for only a certain mail client (such as the AirWatch Inbox) while blocking all others.
  • Mail Client - Configure access for specific mail client types and versions. This is typically used to block certain versions of a mail client if it is problematic for any reason (e.g. a company may find that the Apple-iPad/702.367 mail client is problematic in their environment).

Managed Device Policies

The below policies apply for only managed devices using all MEM deployment types.

  • Inactivity - This policy will deny a device access if it has not checked into the AirWatch Console in a certain number of days.
  • Device Compromised - This policy will block a device if it has reported into AirWatch as compromised.
  • Encryption - This policy will block devices that have reported to AirWatch as unencrypted.
  • Model - This policy can be used to restrict access to certain device platforms and models (e.g. Apple iPad).
  • Operating System - This policy can be user to restrict access to certain operating system versions. It is typically used when certain OS versions have known issues with a company's email infrastructure.



Have more questions? Submit a request


Article is closed for comments.