MBYOD – Tiering Your Ecosystem

by Brian Katz on May 31, 2013 · 2 comments

There’s a lot of hubbub about BYOD (Bring Your Own Device). It’s guaranteed to stir debate especially when you get IT in the same room as the Business. The arguments start simply enough. IT doesn’t like the loss of control while the Business wants to either save money or enable their workers. It quickly becomes an argument about security, which is ITs way of exerting control and winning any argument. Who knows what will happen to the data on a device someone brings in from home and what if they lose it. The problem here is that the same issue is still there when you go with a COPE (Corporate Owned Personally Enabled) device.

The real way to handle BYOD is to move away from the traditional definition of BYOD and move to MBYOD (Managed BYOD). Let’s be clear, when we are talking MBYOD, we don’t mean managing the device. You still need to invest in tools to manage your data as it will be going on devices and this means investing in a good EMM (Enterprise Mobile Management system). You need to start with securing your data and then securing it at rest and in transit from the device to your internal systems. Your goal is to use tools that allow you to manage the enterprise data without interfering with the personal data (regardless of BYOD or COPE).

Well, if MBYOD doesn’t mean having a good EMM in place, as that is a requirement of just having mobile devices, what is MBYOD? Quite simply, MBYOD is building a tiered system for access to your corporate ecosystem. You create your tiered system of access and then you associate different devices with each level of access. The final piece is to then publicize this system to everyone in the company.

The Holy Grail for any mobile user is complete access to the corporate ecosystem. This means that they can use their device to function like they were sitting on a computer working internally at their desk. They have complete access to where their files are stored; they can move around on the internal network, get their email and access the intranet. This is what you give to devices that have the best built in controls. You can use your EMM to fully protect whatever data is on the device. You know that if the phone is lost or stolen that you can wipe all the corporate data from the device. Let’s call this Tier 0.

You then have another tier where you might allow users to access on-premises resources but without any data actually residing on the device (or very little data). They may use solutions like server based computing, VDI or mobile enhanced solutions like Framehawk. You have some controls built into these devices but it is very difficult to fully protect your data. We’ll call this Tier 1.

Your next layer is where you really give minimal access to your users. The users are using devices that have few if any security controls. The only way to give users access to data at this level is to rely on a trusted app that can protect your data. This is where you see solutions like Good Technology or Touchdown where the app builds its own encrypted container for email and that is all that is allowed on the device. The app controls the connection to the mail service and encrypts the data on route to the device as well as on the device itself. We’ll call this Tier 2.

Your final tier is where you don’t give any access at all to your users. Their devices lack all conceivable controls and there are no apps that will work reliably to help you secure your data on the device. This is Tier 3.

Now that you have defined the tiered access to your corporate ecosystem, you have to look at all the devices that are in the market and divide them up by the tiers.  You would choose devices that have the best controls for Tier 0. To make your life easier, be more specific based upon the better access the device has. In the diagram below, you notice that we define Tier 0 very specifically but as we move to the lower access levels we get more generic.


Tier Tier 0 Tier 1 Tier 2 Tier 3


BB 10

iOS 6

Samsung Knox

HTC      (Android 4.2)

Motorola (Android 4.2)

LG, Sony, etc Android 4.X

Windows Phone 8



Android < 4.0



In reality, you can build as many tiers as you like, although the more you build, the harder it will become to define what devices go where. The goal is for this to become a very easy list to maintain.

Next comes the easy part. You have defined the different levels of ecosystem access and now you want to use it to turn your BYOD program into a managed one. The way to do this is quite simply to publish this list and make sure every user is aware of it. This has to be something that is accessible on the corporate intranet and hits every user’s inbox. This is when the magic happens. Users who participate in your BYOD program will look at the list and will determine what device they’re going to buy based upon what type of access they want. They know if they buy a windows phone 8 device they are only going to have access to email through a 3rd party client. The more access they want, the better their choice will be. IT and the business aren’t telling the user what sort of device to buy. They are just limiting what the user can do if they don’t buy the right device. This turns any BYOD program into a self-managed BYOD program. IT only needs to evaluate new devices as they come out and add them to the appropriate place on the list. Users have the guidance they need to make an informed choice and security is happy because they have the tools in place to protect the company’s data even on non-corporate devices.

{ 2 comments… read them below or add one }

Art May 31, 2013 at 11:06 am


So, I’ve been thinking about EAS (Def: Exchange ActiveSync) in this new world. The big policy gorilla has appeared to be the almost reckless exposure of EAS with no policies, etc. as you have so correctly pointed out numerous times along with “BYOD != Email and Calendar”.

Do you think EAS lives in a new mode:
* Connecting client must possess a company issued cert and the core only builds a TLS tunnel with company certificate enabled devices.
* EAS is divested for a container strategy that implements a pleasant non-native mail interface.
* EAS is divested of for a different interface because of the massive charges from MSFT in the EA for true-up such that another remote access method self-funds from ditching EAS. Like the BES peer-MAPI server does in BB.
* Or business as usual because to serve you customers best, single factor email and EAS are not enough of a risk to fight for a conversion.

Love to have this conversation around “open EAS e-mail” on a #mobilebiz chat.



Bob Egan May 31, 2013 at 3:24 pm

Art – I realized you asked Brian the question, so pardon my .02.

I don’t think they’ll be a divestiture but I do more policy capabilities on the horizon.


Cancel reply

Leave a Comment

Previous post:

Next post: