Problem solve Get help with specific problems with your technologies, process and projects.

Smartphone security implications of Microsoft Exchange Activesync

How can employees securely sync their smartphones to your company's Exchange email system? Greg Braunton details the features and products you need to keep data secure.

Midsized enterprises can't do business in today's connected world without supporting smartphone technologies. Employees...

commonly use their smartphones for email, calendaring and managing contacts. The Web is full of user forums discussing the security concerns of various smartphone platforms, and whether they can synchronize data with their Microsoft Exchange server using Microsoft Exchange ActiveSync. As this tip explores, the important question is not what phone platform an organization should adopt, but rather, what are the minimum security controls required prior to allowing users to synchronize corporate email to mobile devices?

Before we dive into the various Smartphone platforms, it's important to establish the minimum necessary Microsoft Exchange environment that supports the features discussed. The core service associated with synchronizing PDAs and smartphones is Microsoft Exchange ActiveSync (AES). Initially a free client-based application designed for wired (USB) synchronization through Outlook, AES now sits on the server side making over the air (OTA) synchronization possible over any network connection that can talk to the Outlook Web Access (OWA) server. Although OTA is possible, synchronizing email, calendar and contacts to a mobile phone is still a client-server relationship. In order to maximize the available security controls native to Exchange, you need to be running Microsoft Exchange 2003 SP2 or higher and an AES (or compatible) client. There are several enhanced and compelling security controls in the 2007 and 2010 Exchange revs, but 2003 SP2 is the bare minimum to achieve some rudimentary controls. Reference Figure 1 to quickly understand a few of the more important security controls available in the last three versions of Exchange.




Device Wipe

Password Enforcement to Access Device



External Media Card Encryption

Wipe on

Failed Login

Device Lock on Idle Timeout

2003 SP2






















Figure 1 – MS Exchange AES Policy Comparison

One of the biggest misunderstandings regarding smartphones and an Exchange mail system is that only Windows Mobile smartphones are compatible. In truth, only Microsoft AES-compatible phones are compatible. Even this statement must be qualified, because most implementations of AES "compatibility" are selective and/or dependent on the version of Exchange server in use. In other words, only a portion of the AES features are implemented in the client. Early in the evolution of smartphones and connecting to corporate Exchange environments, Microsoft seized the lead with Pocket PC or Windows Mobile, which were the only natively supported devices that could synchronize with Exchange without costly additional hardware or middleware (such as Research In Motion Ltd.'s BlackBerry Enterprise Server). Realizing the huge market associated with enterprise device users, smartphone OS vendors quickly rallied to support Microsoft Exchange Activesync; today, all the major smartphone platforms support some variant of an AES-compatible client; Android (Droid apps Moxier Mail, Nitro Touchdown), WebOS (AES built in), Apple iOS (AES built in), and RIM (BlackBerry ActivSync). Therefore, the decision for organizations today is not what smartphone platform they will adopt, but what are the minimum necessary AES security controls acceptable to mitigate the risk of a lost, stolen or compromised device?

Microsoft Exchange ActiveSync features
Organizations that are already using Microsoft Exchange and are serious about mobile device security can use native mobile security controls in Exchange to meet their business needs. While it's not reasonable to proclaim mobile security controls free in a Microsoft-centric enterprise (you still do have to pay for Exchange client access licenses) there are no further infrastructure or server services required. So if you're already running Exchange 2007 SP3 or 2010 SP1, you have a nimble, robust set of mobile device controls available at your fingertips. The mobile device security controls are implemented via Exchange ActiveSync mailbox policy settings. As a caveat, it's important to note that available mailbox security policies are tied to the type of Exchange client access license (CAL) in use; an enterprise CAL provides a richer set of controls than a standard CAL, so be aware of this key distinction.

One of the biggest misunderstandings regarding Exchange is that only Windows Mobile Smart phones are compatible. 
In truth, only MS AES compatible phones are compatible. 


Gregg Braunton,

The security policy settings for Exchange 2007 and 2010 offer granular controls, and many IT and security professionals may not be aware of them. Concerned about exploits or compromises via HTML tags? Counter this threat by forcing all email synchronized to the device to be plain text. Fearful that confidential or propriety data is being siphoned off to an external media card beyond your control? Easy, block the use of external media cards. Do you distrust connections to Wi-Fi hot spots? If so, turn off Wi-Fi access for the device. Ever had a report of a lost or stolen mobile device? Sleep well by using device and external storage card encryption and issuing a remote wipe of the device and storage card. More than 40 mailbox policy settings are available, but remember the policy settings supported by the AES client (on the mobile device) truly define what is enforceable. Again, buyer beware, because even Microsoft's newly touted Windows Mobile 7 only supports a subset of the available policies.

Droid, iPhone, Palm and BlackBerry support for AES
Given this lack of Microsoft's own product synergy, what about allowing other devices like the Droid, iPhone, Palm Pre or the BlackBerry to synchronize? Only your organization can answer that. First and foremost, a leadership discussion should occur that focuses on the analysis of risk to the organization due to the loss, theft or compromise of information on a corporate synchronized mobile device. Second, given the risk decision and agreed upon minimum controls, the Exchange and AES client pairing needs to be fully vetted to ensure approved devices (and their AES client) can reliably enforce the Activesync mailbox policies crucial to your chosen security posture. While each organization is unique, there are some regulatory undertones worth factoring into your mobile device security controls.

If you are in the financial or health care industry, a required control today should be encryption. Mobile data encryption is imperative for any mobile device and any ancillary storage (SD cards). For the financial sector, given the sensitivity and value of the data, it's just due diligence to enforce encryption, and anything less would be negligent. In health care, under the HITECH Breach Disclosure Act of 2009, encryption is a "safe harbor." If a device is lost or stolen, and if as an organization you can demonstrate the information was encrypted, this loss is excluded under the provisions of the act and no disclosure or notification is required. Further, if you can confirm remote destruction (wipe) of the data, you limit further unauthorized use and downstream liability (State AGs are aggressively pursuing breaches and negligent responses/notifications) Of course a compromise warrants a forensic investigation to confirm the nature and scope of the disclosure, but ask yourself: how many reports of a lost or stolen smartphone has your organization sustained versus a confirmed compromise/hack of protected/regulated data on a device? If your midsized business operates in an industry other than financial or health care, you're likely on safe ground if you don't mandate encryption as a minimum. But, given the changes in state laws and several bills in legislation today, most notably H.R. 2221, S.1490, S.3742, encryption will be a universal "safe harbor" within the next one to two years, so it should certainly be on your road map.

Other controls that merit the required list are standard "best practices" controls that limit the likelihood of data becoming compromised. These controls include password enforcement and complexity, failed login attempts, idle timeouts and Bluetooth connections to name just a few, all of which can be managed via Exchange ActiveSync policies. Rememberto verify that the AES client supports the AES security controls that your organization deems necessary. And one of the most effective, cost-free controls is publishing a policy detailing smartphone compatibility requirements that clearly calls out the required phone platforms and AES clients. Make it clear to everyone that if a device is not on the list, it's not allowed.

If you have an existing Exchange shop, reliable mobile security is within reach. Dive into the ActiveSync mailbox policies and you'll find that, by pairing the technical controls natively available in Microsoft Exchange with compatible AES clients and published policy requirements, you have the makings of a viable mobile security policy to begin allowing users to synchronize corporate email to mobile devices.

About the author:
Gregg Braunton, CISSP, GSEC, C|EH, MCP serves as an Information Security Officer. He possesses fifteen years experience working in the information technology field with expertise in user awareness education, security compliance, forensics and technical and policy based security controls across various technologies and platforms.


This was last published in November 2010

Dig Deeper on Wireless and mobile security