As an example, a locality change might change a policy on a smartphone. International dialing might be disabled (or enabled). Perhaps a smartphone has been reported as missing, and the phone is remotely "killed" or wiped back to factory state with a new passcode. A new contact list is delivered. Updated software might be silently downloaded. Resident software might be tallied. The possibilities are as endless as smartphone features and the intelligence of the MDM application and its features. There are many common denominators of policy control item for mobile device features, like demanding that the phone has a PIN, or that only a specific group of phones having a certain revision level of OS and/or phone firmware gets a specific update, and so on.
Agents do their best to deliver information about the mobile device's state back to the MDM application. The mobile device state is a summary of conditions, settings, and where enabled, additional data such as the location of the phone, messages/calls sent received, software installed (and versions), security data, and policies in place.
Devil's in the details
MDM applications must control a range of features and be able to detect numerous smartphone or device states. This becomes complicated for MDM application vendors for many reasons as there are strong differences between platforms, carriers, operating systems, and user options.
One of the major detection problems surrounds differences in operating systems and their versions—and there are numerous operating system versions to track unless an organization has selected a single mobile OS—which has become increasingly rare. The most popular smartphone operating systems include Windows Mobile in three distinctly different versions; Apple's iOS in four versions; Android in three+ versions; Blackberry OS in two major current releases; HP/Palm's WebOS in two versions (more coming soon); and Symbian, which can be found on numerous phones, especially from Nokia and Sony-Ericcson. Each of these vendors plans upgrades in the near future.
Smartphone and mobile device hardware makers usually develop their phones to work at a "spec" designed to meet the requirement of a smartphone OS version. The vendor's operating system components may or may not allow user updates to core software. Smartphone hardware vendors can limit specific smartphone phone features, or the telco/carrier used by the phone. As data plans vary vastly for smartphones, some vendors limit browsers to specific sites to conserve data transfer costs. Some limit GPS functionality to save battery life. Others change defaults to various applications like POP email—to point mail to a carrier's favored host. Uniformity across an operating system for smartphones isn't guaranteed.