How do you handle computers purchased outside of and unmanaged by IT?

Background: Over on Slack, @nangra asked how people handled computers purchased outside of the IT Department, and over which the IT department doesn’t have explicit admin privileges.

I was going to respond there, but my response seemed better suited to a forum post, so over here I came.

In reading through the back-and-forth on this topic in Slack, there was a lot of good information regarding how to approach conversations that resulted in all machines being brought into the IT departments managed environment, regardless how they were environment.

I don’t think that advice was bad or wrong. But I don’t think it’s the only way of looking at this question.

Allow me to introduce a separate line of thinking.

… Why do you care if a department buys a computer that is outside of your scope, and not connected to your managed environment? I’m not suggesting there are not perfectly valid reasons to care. But I’d like you to enumerate yours. Some really common ones are:

  1. someone will, invariably, ask for help - and being outside the managed environment brings with it additional hurdles.
  2. it will, invariably, need to access at least some resource within our managed environment, and thus will introduce headaches for us when we then need to bring an unmanaged device into a managed environment.
  3. there are information security or PII concerns related to unmanaged devices.

While bringing everything into a managed environment is one linear way to (partially?) solve for these issues, it isn’t the only way.

In fact, I am begining to question if it is even still the best way.

If we modernize our productivity tools (M365/Workspace, ChMS, etc) such as they identify and classify PII and protected information and then putting protection around the data at the service level - we can solve those concerns even in the absence of a managed hardware environment. Arguably this needs to be done whether you have a managed or unmanaged hardware environment as the risks of leakage are only slightly - and I do mean slightly - less in a fully managed hardware environment /vs/ an unmanaged one.

Data security concerns resolved, the next question is access to data within our managed environment. The answer to this one is very situational, but the broad-brush consideration is to move services into an authentication realm where they trust the user, not the machine. This is often done by moving data and services into paradigms where access is granted not by domain membership, but by login via an MFA protected, SSO’d user session. If there are situations where we don’t want access to services but by machines within our managed environment, we can put constraints on the authorization pipeline to force a managed compliance check before authorization.

By combining the access constraints and authorization pipeline with self-service onboarding to an MDM or similar modern management platform - we can adeptly secure access to data by user credential, and if we need a machine in management to say, enforce device encryption - we can make access to the service dependent on (Self Service!) enrollment in our modern management system.

Finally, in the above world, we find that our net-service requests go down along with our time to resolution. Yes we still need to occasionally help people, but its typically much more constrained in scope. By creating many happy paths where the only way to get to a given destination is one that enforces whatever need be for the interaction type, and the onboarding processes are largely self service - you remove much of the support headache. A screen-connect instance or the like for on-demand help is often all the remote support/management tool you end up needing.

If you have all the above in place, I think it begins to matter much less who buys the computer, whether it is fully managed or not - etc. And if it doesn’t matter that much, maybe it isn’t worth the energy to fight over anymore? Just let people do what they want to do, which is go out, buy a machine, and replace it when they feel like it.

Depending on the state of your current environment, the above might seem very far - or very close! - to your reach. But regardless of your belief as to allowing some sort of sanctioned, org-funded, BYOD thing, it is work worth doing.

The environments working like the above today have lower-friction accessibility, (much) better security, and are quieter to own and manage.

It’s a good thing to have conversations about trust and manageability being precursor to bringing all your systems into a managed environment. But once you have that trust, maybe it’s time to let people do what they want - regarding hardware - anyways?


I’ve found that it can get a tad more complicated when you throw in the sensitivity of given types of data or certain roles with access to things that would be considered sensitive in the church/missions agency, but yeah, every client we work with has both managed and unmanaged devices accessing data through Conditional Access policies whether fully AAD joined or through MIM/MAM/WIP. In our case it is both verification of the device and user that is used to determine how data gets accessed, but any device can get some level of access even if just a browser to access via :sunglasses: