One of the challenges with deploying Apple devices in an enterprise or education environment is deciding how to manage Apple IDs used with those devices.
This was a particularly difficult challenge on iOS devices before iOS 7 because purchasing and provisioning apps to iOS users permanently associated the ownership of those apps with a user's Apple ID, which largely meant they took ownership of the app with them when they left a business or school.
Apple's new volume licensing program, introduced with iOS 7, resolves that problem by allowing administrators to revoke access to a company-purchased app, but it seems to go further in the other direction than needed. The new process allows an organization to purchase, distribute, and revoke access to apps without IT even knowing the Apple ID of each user and seems designed to prevent IT from ever learning the Apple IDs of individual employees. Although that may seem a sudden and dramatic about face on Apple's part, it's actually a very shrewd move to ensure its customers' privacy and security around their personal information and identity.
The simple reality is that Apple developed the Apple ID over time into something that is tightly integrated into the Apple user experience and into virtually every customer facing aspect of the company. While most of us tend to think of an Apple ID as simply an iTunes Store and/or iCloud account, it has evolved into an all-in-one identity for each Apple user or customer -- an Apple social security number, if you will.
The list of Apple services that are associated with an Apple ID is staggering. They include iTunes, iBooks, and App Store purchases, device activations (and Activation Lock in iOS 7), personal communication tools (iMessage, FaceTime, Find My Friends, Game Center), sync and backup through iCloud, access to Apple's support services and forums, Apple retail services, membership in Apple's developer programs that include access to pre-release content under NDA, and even extend to applying for jobs with the company -- and that's less than half the complete list.
Some of those features and services link to important confidential details for each user. With regards to the iTunes Store, that includes payment mechanisms like credit or debit card numbers or PayPal account details. Through the new iCloud Keychain feature, it can mean access to username and passwords for any online accounts or services as well as additional credit/debit card data. iOS 7's Activation Lock relies on a user's Apple ID to brick and unbrick a lost or stolen iPhone. Macs can be set up to allow a user's Apple ID to reset the password of a local administer user account. And that's before considering access to data or device backups stored in iCloud.
That deep integration of a user's Apple ID into the Apple ecosystem creates challenges for IT departments when it comes to activating corporate devices, supporting BYOD users, and managing software and hardware inventory for users of any Apple solution.
Exactly what is an Apple ID?
At the most basic level, an Apple ID is simply a user identification tool onto which Apple has layered several key services. Apple defines it pretty simply:
An Apple ID is a user name you use for everything you do with Apple. Creating an account for an Apple service, such as the iTunes Store or the App Store, creates an Apple ID.
The primary requirements for an Apple ID are a valid and verifiable email address and password along with some basic user information like a first and last name. Additional information like a rescue email address (should you be unable to access the primary address), security questions, two-factor authentication options, payment information and association with specific Macs, PCs, iOS devices, apps, or services extend the Apple ID. Unlike accounts with some other companies and services, an Apple ID isn't static. A user is free to change the primary email for his or her Apple ID as well as any other supporting attributes at any time and Apple suggests that users update the primary email address if they leave the company, school, or service provider that hosts or manages it.
Apple IDs are designed for individuals, not institutions
There is no restriction against a user having multiple Apple IDs, though Apple encourages users to use a single Apple ID for all their interaction with the company's products and services. Apple makes this recommendation even though many -- but not all -- devices, apps, and services that rely on Apple IDs can be associated with multiple IDs.
One of the main reasons is that Apple doesn't support combining or splitting Apple IDs and Apple has designed the Apple ID as a primary identity for individuals, not for an entire household, classroom or company. This can sometimes be confounding on a consumer level -- a couple will typically end up with two individual iTunes libraries, for example, rather than a single joint library. On the other hand, if that couple breaks up, each user will still own their own content.
It also raises challenges for institutionally owned devices. Associating a corporate device (or a school-owned device) with a user's personal Apple ID can be seen as giving them ownership of the device, as it will generally allow them to load their own personal apps and content onto it, although this can be mitigated with enterprise mobile management tools. This is particularly true when it comes to iOS 7's distinction between managed apps deployed through a mobile management tool or distributed through an enterprise app store, versus unmanaged apps installed by the user from the public App Store.
Although employees and students may resist associating their personal Apple ID with an institutionally owned device, there are benefits to doing so.
First, it can give the user a sense of ownership, which often encourages better and more frequent use of the device. This can be particularly helpful as IT departments move toward a self-service model in which users are expected to take on traditional IT tasks like activating and setting up devices, selecting and installing apps, and troubleshooting. This model tends to deliver better user satisfaction and lessen demands on IT departments.
It also allows users to work within a policy framework on a managed device rather than simply resorting to their own personal device instead. This has tremendous implication for device and data security. Allowing the user to personalize the device offers a common ground to educate them about risks and to explain the need for some boundaries. The more flexible and open IT can be here, the better the chance users will accept those policies. More importantly, it allows users to select the apps and build the workflows that work best for their specific needs and work methods.
One of the sectors where this approach is being used most effectively is in education. During the JAMF Nation User Conference earlier this month, I was surprised to hear how many K-12 schools are encouraging students, some as young as elementary school, to setup and use their own Apple IDs on devices in a 1-to-1 deployment. (Apple recently began allowing schools to create Apple IDs for students under proper supervision at school and at home.) In almost every case, students took better care of the devices and were less likely to break restrictions on them; there were only very limited reports of students using devices inappropriately.
The essential theme is that Apple designed the Apple ID to function across the various spheres that users operate in -- school, extra-curricular activities, community service, work, and home -- and made the effort to separate it from device, app, and content management systems required by businesses and schools. The intent was almost certainly to build a flexible system that delivers a seamless experience from one device or one app to the next -- and that seamless experience is what attracts users to these devices and empowers them professionally or academically as well as personally.
To paraphrase several IT managers I spoke with at JAMF Nation User Conference and at AirWatch Connect in September -- you can lock down an iPhone as much as a BlackBerry, but that somewhat defeats to the point of offering it.
(Many of these issues become moot when it comes to BYOD devices because the device is owned by the user and it's expected that it would have been activated using their own Apple ID.)
When to use institutional Apple IDs
There are situations where a user's personal Apple ID isn't appropriate in a business or school. They break down into two categories: Shared devices and special types of Apple IDs for institutions.
Shared devices. In the case of devices that are shared -- such as in a classroom not doing a 1-to-1 deployment where each student gets their own iPad, devices shared among nursing staff on a hospital ward, retail and hospitality where devices function as cash registers, or kiosk devices that customers interact with directly -- personal Apple IDs aren't really an option. These devices are not intended to have personal data or apps installed on them. They are deployed in a controlled environment where IT is in charge of provisioning and potentially managing them on a daily basis. In this case an institutional Apple ID or a series of them, perhaps one for each device if there are more than a few, is essentially required.
Note that Apple is very clear in the iCloud terms of service that Find My iPhone and iOS 7's Activation Lock is intended to be used by individuals for personal use rather than institutions. The fact that the feature cannot be enabled on devices operating in Supervised mode, which enables a tighter set of management restrictions on institutional devices deployed using Apple Configurator, is evidence of Apple's position on this point.
Special cases. The second instance relates to a handful of situations where Apple will require institutional Apple IDs for specific tasks. These are generally tasks where an institution is working with an Apple service and the Apple ID identifies that institution rather than individuals with in it.
Examples include the staff that manage app procurement and distribution through Apple's Volume Purchase Program and facilitators for Apple's enterprise developer program for a company. These Apple IDs are usually created in partnership with Apple when joining or administering such programs.
Developing policies for Apple IDs and Apple services
In the end, deciding how to best work with Apple IDs in an organization is more of a policy challenge than a technical challenge.
If you are going to support personal Apple IDs, do you want devices that have almost no restrictions? Or do you want to prevent some Apple services that interact via Apple ID, like iCloud device backup, iTunes and/or App Store purchases, Find My Friends or other location-aware apps, or FaceTime calls? What are the responsibilities of users if you offer largely unfettered access to a device? How do you want to handle Activation Lock if users can associate an iPhone with their personal Apple ID, which would allow them to brick the device when they leave? (The consensus I've heard from several IT managers has been to deduct the cost of the device from a final paycheck unless it is unbricked.)
These are ultimately questions that go beyond IT and ideally involve the input of other stakeholders like HR, legal, and senior management to develop and implement policies that work for the user, IT, and the organization as a whole.