Over the past few years, the global business landscape has experienced both an increase in BYOD adoption and the expansion of existing BYOD programs. Organizations are moving beyond the basics of email and Internet browsing and into fully comprehensive and sustainable BYOD strategies involving a plethora of internal and external applications. Given this momentum, organizations are still torn on the best approach to empower their employees with mobile access to data and applications without sacrificing security and end-user privacy.
To overcome this complex roadblock, the most sought-after BYOD enablement functionality is the ability to compartmentalize work and personal data on employee-owned devices. This contained separation ensures that IT can access and manage only work-related apps and settings, safeguarding end-user privacy by making personal apps and data inaccessible. For this post, the notion of separating work and personal data will be referred to as containerization.
Mobile Application Management (MAM) technology is the most common BYOD solution in today’s market, because these solutions only manage applications—not devices. A few years ago, the only technology that enabled MAM controls and containerized data required proprietary containerization tools, such as application wrapping or software development kits (SDKs). However, recent advancements in iOS, Android and Windows operating systems offer an alternative to proprietary methods by building MAM and containerization capabilities into the native OS. This secondary approach is commonly referred to as native containerization and is gaining traction as a sustainable BYOD technology.
These two approaches can have a polarizing effect within enterprises, making IT leaders feel like they must choose one or the other. The truth is that native and proprietary containers are not mutually exclusive; each approach fulfills different needs based on unique BYOD program requirements.
To build a business mobility strategy that can scale across the entire organization—not just BYOD, but also corporate-owned and line-of-business mobile deployments—successful companies choose a mobility platform that supports both models.
What is Native Containerization?
Over the past couple of years, operating systems—including iOS, Android and Windows—have innovated by building containerization and MAM frameworks directly into the operating platforms, including:
- App Tunneling: Selectively enable approved apps to use an App Tunnel to securely connect to backend and corporate networks.
- Single Sign-on: Enable SSO across enterprise apps, leveraging existing identity management solutions.
- Conditional Access: Restrict apps to run only on approved and compliant devices.
- App Configuration: Auto-configure URL/port settings, group codes, email addresses and license keys to eliminate the need to educate users about first-time set-up.
- Security Policies: Enforce security policies, such as required encryption and data loss protection at the app level.
There are five types of apps that can be containerized in this model:
1. Built-in apps, such as native browsers, and native email;
2. Internal apps, such as those built by the enterprise;
3. Bulk purchased apps, such as those procured via a volume purchase program;
4. Free public apps from independent software vendors (ISVs), such as Salesforce or Concur; and
5. AirWatch or EMM vendor provided apps like AirWatch Content Locker, Inbox and Browser.
Benefits of Native Containerization
Native containerization is the best way to containerize public apps in a way that is stable and scalable—without violating any support agreements with ISVs or public App Stores. This methodology is the most native and user-friendly experience. It also protects privacy by honoring all the OS privacy notices and consent statements. Native containers also tend to support a broader set of applications; every application on the Apple App Store, for example, can be containerized using native controls.
How to Implement the Native Container
Most native container capabilities require no code changes, including SSO, app tunnel, conditional access and security for ISVs and developers. Some capabilities, however, require minor standards-based code changes that are also encouraged by OS vendors, such as Apple and Google. Implementation is typically a simple process, usually taking less than a day. Watch this quick demo to see native containerization implementation in action, using the Salesforce1 app as an example:
To streamline native container development and implementation, a community of app developers, enterprises and EMM providers founded ACE to establish native container capabilities and best practices—an EMM-neutral approach that continues to garner attention and new partners. The ultimate goal of ACE is to drive a more consistent, open and streamlined way to configure and secure mobile applications and adoption within the enterprise. AirWatch, as one of the founding members, supports all the capabilities defined in ACE.
To take advantage of ACE and any native container model, devices must be enrolled in the native MAM framework, including enrollment for iOS and Android for Work.
What is Proprietary Containerization?
Proprietary containers are provided by EMM vendors, including AirWatch, and third-party vendors. Customizations made to individual apps must follow an EMM vendor’s proprietary protocols and APIs for policies. This methodology uses app wrapping and SDKs, which typically enable EMM vendors to provide a more granular feature set that is not dependent on the native operating system.
Using the same breakdown of app categories in the native containerization section above, here is how proprietary containers manage those five app types:
1. Built-in apps: No.
2. Internal apps: Yes. A common misconception, however, is that no developer is required when using a proprietary container. App wrapping works on an explicit set of supported libraries and functions in an app, and a developer is likely needed to verify or modify the code in an application to make sure these supported libraries are used.
4. Free public apps: No, at least practically speaking. Although the technology supports it and many EMM vendors advertise this capability, the reality is that public app management in a proprietary container environment introduces complexities for the end user and often violates the support and maintenance model of the app itself. Some EMM vendors endorse support for proprietary containers for apps like Salesforce and Box—however these ISVs have since joined the ACE community in favor of the native containerization approach as the strategic direction forward.
5. AirWatch EMM-provided apps: Yes.
Benefits of Proprietary Containerization
For businesses who need to empower their workers with internally developed applications, proprietary containerization can deliver comprehensive app security, management and deployment. While native containers are typically the most appropriate solution for most use cases, proprietary is preferred option for extended enterprise scenarios for franchises, partners, and vendors where there may already be another EMM vendors’ technology on the device that may conflict with native containerization.
How to Implement the Proprietary Container
As mentioned above, app wrapping and/or SDKs are required for proprietary container implementation.
App Wrapping: App wrapping is compatible with an explicit list of methods and functions in an application and may require the involvement of a developer to verify or modify the application using supported libraries. Click here to access the “App Wrapping Guide.”
SDKs: SDK adds containerization to apps through a library of code a developer must include when developing the app. Click here to learn more about SDKs.
The Perception of Privacy
Regardless of the container approach deployed by enterprises, privacy will be a perceived issue for end users—but in different ways. With native containers, the user is trusting the operating system and sees familiar consumer brand names and native prompts to consent to disclose their personal information—just like they would in any other app. With proprietary containers, the user is trusting custom software that can operate a bit like a black box—not necessarily built on the OS’ trust framework and may be inadvertently collecting personal information. See The Guardian’s “Apple Pulls 250 Privacy-infringing Apps from Store.”
Which would you trust as an employee: the recognized brand or the black box?
In either case, there will be some users who are uncomfortable with either approach—native or proprietary—and appropriate marketing and internal communications should be deployed to build trust with end users and the IT systems they are using.
In terms of which is the better technology, the key lies in building a scalable mobile strategy that flexes with your organization’s shifting needs and the quickly evolving technology landscape.
At AirWatch, business mobility isn’t an either/or proposition; administrators should be able to configure the co-existence of both solutions within the same environment sharing a common configuration. We are proud to be one of the only EMM providers in the world that developed our solutions to help enterprises empower this co-existence and create a strategy that meets their unique mobility needs—not one that is hampered by the limitations of an either/or container.