When workers bring their own equipment on the job, it opens the door to all kinds of trouble–just ask the NFL.
In 2006, the NFL instituted a rule change that allowed each team’s offense to use their own footballs during games, as long as those footballs met the league’s requirements. This change was made at the request of the league’s quarterbacks, who wanted more control over the equipment they use to throw touchdowns.
But in 2015, the NFL’s BYOD policy led to disaster. The New England Patriots and their quarterback Tom Brady were accused of deliberately underinflating footballs below NFL standards, in a scandal known as Deflategate.
Whatever you believe about the Patriots’ guilt or innocence, Deflategate illustrates the pitfalls that come with BYOD-how a well-meaning policy can end up creating a culture of mistrust and putting the most sensitive devices in your organization at risk.
In this piece, we’ll talk about whether or not BYOD policies can be compatible with good security (spoiler alert: the answer is “it depends”), and how to differentiate between BYOD solutions that look good on paper and those that work in the real world.
To understand the issues surrounding managed versus unmanaged devices, it’s helpful to have a working knowledge of mobile device management solutions (MDM). If you’d like a starter/refresher, check out our blog on the subject.
Bring your own device (BYOD) refers to organizations allowing their employees and contractors to use their own computers, phones, and other devices for work. BYOD has been popular since the 2010s, and many businesses believe in its cost effectiveness and positive impact on employee experience. But BYOD has also been consistently dogged by concerns about its effects on employee privacy, productivity, and, in particular, security.
There are valid cases to be made for and against BYOD. However, it’s difficult to make universal statements about BYOD as a concept, since the risks and benefits vary so much depending on what types of devices we’re talking about, as well as the specifics of an organization’s BYOD policy (or lack thereof).
Some employee-owned devices get much the same level of management as employer-owned devices, and some get no oversight from the company at all. Likewise, not all devices are equally risky, because not all devices or users have the same level of access to sensitive data. In other words, a marketer who checks Slack on their MDM-enrolled iPhone poses a very different set of risks from a developer who accesses the company’s source code on an unmanaged laptop.
For that reason, we need to spend some time differentiating between the different types of BYOD before we can assess how they can (or cannot) be compatible with good corporate security.
When a lot of people say “BYOD,” what they’re really talking about is mobile phones. Employees using their personal cell phones for work tasks is most likely the largest BYOD use case, especially among knowledge workers in Western countries. (Unfortunately we can only say this is “most likely,” since there are few reliable BYOD statistics more recent than 2020, and the pandemic undoubtedly changed the landscape after that).
There are a few reasons that phones represent the biggest tranche of BYO-devices, including:
Many workers want or need to be available for workplace communication when they’re away from their computer, and most don’t want to carry around two cell phones.
The kinds of work that most people do on their phones–messaging and email–are considered low-risk from a security perspective, so businesses are less concerned about the potential for data leakage, loss, or theft. (It’s worth pointing out that a lot of sensitive data gets passed around on messaging apps, so they’re far from harmless, but the perception remains.)
Money, of course! Smartphones and tablets are expensive, and companies would prefer not to pay for them, especially if workers don’t really need them to do their jobs. So unless a worker does the majority of their work on a mobile device–like a service technician who works off a phone or tablet–companies would rather avoid paying for service and upkeep on a mobile fleet.
Plenty of organizations purchase devices for their employees, but let outside contractors use their own computers. Even within this category of BYOD, there are subcategories that present different risk levels.
Specialized individuals/freelancers: Specialists like web designers or consultants may work independently or for small agencies and be brought on for a specific project. Depending on the nature of that project, their access to company resources may be very limited, or they could be deeply embedded in the organization, with access equal to high-level employees.
Larger contractor teams: Large corporations often subcontract work to other businesses that specialize in providing services, such as content moderation or customer service. The contractor’s employees may be working on their personal devices, or they may be working on devices provided to them by the contractor. And again, their access to sensitive data may be heavily restricted or relatively unsupervised, depending on the nature of their work and the contractor’s own security policies.
Vendors and service providers: This category encompasses anyone performing work that is not directly tied to your business operations but that must access its systems–anyone from your building’s security to your HVAC company.
As you can likely guess, BYOD presents more risk in some of these circumstances than others.
If you outsource your IT help desk to an MSP, those contractors can operate as highly-privileged superadministrators, and are often targeted by bad actors. But even seemingly inconsequential vendors can be an entryway for attackers if they have sufficient access to your network. In the infamous 2014 Target hack, credentials stolen from an HVAC company led to an attack that cost Target over $200 million.
Some companies allow or require their employees to work on their own devices. The most obvious reason for this is budgetary (although experts debate whether BYOD actually saves money once you factor in all its associated costs).
In other cases, BYOD may be a matter of employee preference or need. For instance, some developers come equipped with their own Linux laptops, and reject working on a standard-issue employee PC.
In still other cases, employees may be allowed to work on a combination of their work-issued and personal devices. For example, an employee may typically work on their company-issued laptop, but use their personal machine if they’re on vacation.
Often, BYOD operates in a gray area between an actual policy and benign neglect. In one common situation, an employee has to use their work-issued device to log into their company’s VPN and access certain resources. But other apps don’t go through the VPN at all, so the employee can log in using their credentials on their personal computer.
In Kolide’s Shadow IT report, we found that 47% of companies allow employees to access their company resources on unmanaged devices, and 43% of workers reported using their personal device because they preferred it to their company-issued one.
Regardless of the situation, the main question we should ask about this type of BYOD is: is it governed by an actual, enforceable policy, or is it merely tolerated?
The answers here run the gamut. On one end of the spectrum, you’ll find personal devices that are nonetheless enrolled in the company’s MDM and subjected to much the same policies as a company-owned device. On the other end of the spectrum, you’ll find employees working on devices that IT has no visibility or control over. In that case, BYOD is effectively Shadow IT, and it presents some of the most serious risks to a company’s security.
Generally speaking, employee-owned devices are at far greater risk than company-owned devices of letting sensitive data out and bad actors in. That’s because in most cases, IT does not have the ability to enforce security policies on these devices.
This can lead to:
Malware, since security tools are less likely to be installed and properly configured, and personal devices may be running vulnerable, unpatched software
Data leakage, since IT cannot monitor downloads or transfers of data onto these devices’ hard drives and applications
Lost/stolen devices, since IT may lack the ability to remotely wipe an employee-owned device
Credential-based attacks, since bad actors can steal or phish employee credentials and impersonate them
There are ways to maintain a BYOD policy while minimizing security risk, but any solution you consider needs to pass a very simple smell test: would this work in the real world?
Much of the advice you’ll find on BYOD security boils down to: “treat employee-owned devices exactly like company-owned devices.” That means installing whatever MDM, VPN, and EDR tools you’d use on your company-owned fleet, so IT can monitor and manage them. But it’s not reasonable to expect employees to relinquish all control and privacy on the same device where they keep their family photos and half-finished novel.
There are also a slew of solutions that claim to enable BYOD by partitioning work tasks on a device, so there is minimal contact between those activities as the rest of the device, and users are prohibited from downloading or even screenshotting their work tasks. Those solutions include things like virtual desktop infrastructure (VDI), web application isolation (WAI), or enterprise browsers. There are genuine use cases where those tools can be helpful, but their drawbacks–technical complexity, high costs, and negative employee experiences–often outweigh their benefits.
We can’t get into every permutation of security tool and BYOD use-case, but we can go in-depth on MDM, since it’s the most commonly-suggested solution and illustrates the complexities at play.
MDMs are to endpoint security what over-the-top guitar solos were to 80s rock bands: so ubiquitous, they’re almost synonymous. MDM solutions let IT do a lot of important things: force updates onto a device, set its default security settings, and remotely wipe it if it’s lost or an employee leaves the company.
However, MDM is not well-suited, or even possible, for many types of BYOD.
Until a few years ago, asking employees to install MDM on their personal phones was a dicey proposition, partly due to stories of employers wiping all the data from an employee’s device in a careless or retaliatory manner.
But these days, both iOS and Android offer less invasive ways to segregate work and personal applications, so MDM cannot view or erase personal data.
For iOS, this type of management comes in the form of Apple User Enrollment and managed Apple IDs, while Android offers work profiles that clearly delineate work from personal apps and data. (For a detailed guide to each, check out TechTarget’s excellent comparison piece.)
With these safeguards in place, it is reasonable to expect that if employees want to access company data on their phones, they need to enroll in MDM. That being said, employees may still perceive MDM as invasive, and the legal consensus seems to be that companies cannot force management tools on personal devices.
In the event that an employee rejects this measure, you will need to either purchase them a separate, managed mobile device, or prohibit them from doing work on their personal phone. (And that might be a blessing in disguise, since the world would keep turning if we all checked Slack a little less.)
We can cover this one quickly: there are very few situations in which you have the right to install MDMs and similar management tools on the computers of people who are not your employees.
For one thing, a contractor may already be enrolled in MDM via their actual employer, and it’s not possible to be enrolled in multiple MDMs simultaneously. But even if it were possible, contractors have much less incentive than employees to accept the loss of agency and privacy that comes with MDMs.
However, given that contractor devices can introduce significant risk, it’s clear that companies need some way of enforcing baseline security policies on them. It’s just that a successful approach must take a lighter touch than MDMs, which rely on forced restarts and grayed-out System Settings options. (Don’t worry, we’ll get into what lighter device management entails in a moment.)
Rolling out MDM on your employees’ personal computers can go a number of different ways, ranging from painless, to disruptive, to simply impossible.
In the best case scenario, end users have a strong, trusting relationship with leadership and IT, no reason to suspect that an MDM will be used against them, and they use the device in question primarily for work. Think of a video editor who joins the company with a specialized workhorse of a PC; this person doesn’t expect the company to buy them a new desktop, and is basically comfortable with their existing computer being treated like any other member of the fleet.
On the other hand, if you suddenly require MDM for workers who were used to an unmanaged BYOD policy, you may incite a backlash. This is especially likely if you fail to adequately communicate to end users about how MDM will impact their privacy, or if you implement it in a heavy-handed way. In a 2014 article for CIO.com, Tom Kaneshige bemoaned “companies taking advantage of advanced MDM capabilities, thus threatening to ruin the user experience.” He warned that “poor usability and privacy violations can derail the BYOD movement.”
Though MDMs have evolved in the subsequent decade to (at least theoretically) allow for a more surgical and less invasive user experience, in practice, end users rarely respond well to their freedoms being taken away. Imagine a developer, for instance, who needs to occasionally turn off their firewall in order to run tests, but now finds that option grayed out by the MDM’s settings.
Finally, making MDM a part of your BYOD policy may not be possible, for two reasons. In the first case, as we’ve written before, there is no such thing as MDM for Linux. So those machines–which typically make up a tiny but highly-privileged fraction of your fleet–are automatically out of consideration.
But moreover, requiring MDM on personal devices is impossible if you have no way to enforce that requirement, and many companies don’t. (As we discussed earlier, 47% let users authenticate on any device as long as they have the right credentials.)
To make MDM a true requirement, you must be able to block devices from accessing company resources unless the MDM is present.
Whether you love or hate BYOD, at this point it’s so firmly entrenched in our work lives that it feels inevitable. Some form of it–whether through mobile phones, contractor devices, or employee work stations–tends to creep in in all but the most security-obsessed organizations.
In designing BYOD policies, organizations have both the right and obligation to secure their data by ensuring that every device meets minimal security standards. However, end users also have the right to reject unreasonable intrusions on the devices they bought and paid for.
So how to reconcile these two truths? In some cases, as we’ve shown, MDM solutions work well at striking this balance. But in situations where MDM is either unfeasible or impossible, companies need a lighter form of management. And in either case, BYOD policies must have an enforcement mechanism that ensures unsecured and unknown devices are kept out.
While there are multiple ways to achieve these goals, let’s focus on the one we know best at Kolide: device trust.
Device trust is a subset of Zero Trust security, and it requires that any device trying to access company resources meet the following criteria:
A device must be known (its identity must be recognized based on more than user credentials)
A device must be in a secure state, and prevented from accessing company resources unless it meets security requirements
Device trust solutions like Kolide’s (forgive us for using ourselves as an example) allow organizations to enforce BYOD policies with minimal impact on user experience and privacy.
This approach works well in situations where MDM would be unpopular or impossible. That’s because, unlike MDM, Kolide has no ability to remotely wipe a user’s device or forcibly install updates, so users maintain their agency over their devices. However, Kolide still prevents a device from authenticating to the organization’s apps unless it’s secure.
The difference between Kolide and MDM is that Kolide shows users how to fix these problems themselves, instead of trying to do it for them. That way, the developer who needs to turn off their firewall for an hour can do so, then simply turn it back on when it’s time to authenticate.
Kolide also works well in situations where MDM is required, since admins can design a policy that only allows devices enrolled in MDM to authenticate. You could write a similar policy that checks for EDR tools like Crowdstrike, or any other requirement–Kolide’s osquery-based agent can run checks based on hundreds of device properties. Plus, Kolide is platform-agnostic, so you can use a single solution to manage all your devices: macOS, Windows, iOS, Android, and even Linux.
In the aftermath of Deflategate, the NFL implemented its own device trust solution. The current rules for ball preparation require both teams “to bring 24 footballs (12 primary and 12 back-up) to the Officials’ Locker Room for inspection.”
In the end, it might have been simpler for football to avoid BYOD altogether, but it’s difficult to claw back a policy that end users enjoy. So whether you’re trying to open up your organization to BYOD, or lock it down, start with end users in mind. Anticipate how your BYOD approach will impact users–if it’s too onerous or too laissez-faire they will find ways to go around it. And that can really take the air out of your company’s security.
To learn more about how Kolide’s approach to device trust protects both managed and unmanaged devices, watch our on-demand demo.