What a loaded question. Buckle up, folks… this could get spicy.
When looking to meet the Cybersecurity Maturity Model Certification (CMMC) requirements, many Department of Defense (DoD) contractors wonder how integrating a Bring Your Own Device (BYOD) policy — where employees are permitted to use their personal devices for performing work-related functions — impacts their pursuit of a CMMC certification. In other words, would a Defense Industrial Base (DIB) contractor fail a CMMC assessment just for using BYOD? Or, is achieving CMMC compliance even realistic with BYOD? In this post, we will address these questions and share important CMMC considerations for BYOD.
We must preface this post by making clear that we are not privacy lawyers. This post touches on concepts that are intertwined with personal privacy, and therefore we recommend consulting legal counsel before making any decisions in response to BYOD and CMMC.
Back to the basics
Before we tackle this question, it’s helpful to return to square one and work our way up. Recall that CMMC is a tiered model, where the CMMC level a given DIB member must target depends upon the type of DoD information they are handling. Specifically, contractors should expect to target:
- Level 1 if they only handle Federal Contract Information (FCI), whereby they must implement FAR 52.204-21
- Level 2 if they handle Controlled Unclassified Information (CUI), a more sensitive subset of FCI, whereby they must implement NIST SP 800-171
- Level 3 if they handle CUI and are working on contracts involving more sensitive systems, such as hypersonics, whereby they must implement NIST SP 800-171 and NIST SP 800-172 (very few contractors, likely large primes, will target L3, and 800-172 is still being finalized)
An absolutely critical takeaway from this model is that, under CMMC, the requirements (what we, the DIB, must “do”) follow the sensitive information. Assets (hardware, software, people, facilities) that handle (process, store, or transmit) CUI are subject to the requirements outlined in NIST 800-171 and will be considered “in-scope” and assessed at CMMC L2 accordingly. Likewise, assets that handle FCI are subject to the requirements outlined in FAR 52.204-21 and will be assessed at CMMC L1. An asset that neither handles FCI nor CUI (with some caveats, such as Security Protection Assets) is not subject to either set of requirements. This has huge implications when it comes to permitting BYOD, as we will elaborate upon in the coming sections.
Does CMMC forbid BYOD?
No, BYOD is not explicitly “forbidden” by CMMC, per se. You’re not going to fail a CMMC assessment just for having BYOD, nor are you going to find any control/assessment objective in NIST 800-171/A that even mentions BYOD. However, while the DoD has not outright banned contractors to permit BYOD, this does not necessarily mean that allowing it is a good idea. Why? It all boils down to what the personal devices are being used for. If personal devices have access to FCI/CUI, whether intentionally or unintentionally, they are considered “in-scope” for a CMMC assessment, and the requirements then must be applied to those personal devices. This is the single most important factor to consider when it comes to permitting BYOD, whereby personal devices have access to a contractor’s “covered system”; i.e., the environment where FCI/CUI is being handled. Whether an employee has access to the contractor’s covered system through their personal phone, laptop, tablet, or other device, it does not matter; the requirements would apply.
Some may read this and feel as though this isn’t necessarily a deal-breaker, and you would be right, it isn’t. It ultimately depends upon whether or not the organization believes it can satisfy the CMMC requirements for “in-scope” BYOD devices while also satisfying the personal privacy aspect of this equation. Needless to say, this could pose significant challenges, as some staff may not be comfortable subjecting their personal devices to the CMMC requirements. If BYOD is on the table, then this is a conversation that must be fleshed out by company leadership. The following sections elaborate on the BYOD implications of the CMMC requirements at both Level 1 and Level 2.
BYOD considerations at CMMC Level 1
At CMMC Level 1, a contractor’s covered system refers to the environment where it handles FCI. Any assets with access to the covered system are in scope for CMMC. For instance, if a contractor stores FCI in Microsoft Commercial SharePoint (which is permitted), and employees have access to the FCI from their personal devices, these devices would be in scope. For mobile devices, this is most commonly seen when employees have downloaded and are using applications such as Teams or Outlook on their smartphones. By design, these applications have access to SharePoint, and therefore the FCI therein. In other cases, these apps may be used for transmitting FCI internally (such as through Teams) or externally (such as through Outlook). Many employees depend upon applications such as these to perform their job responsibilities, and therefore outright removing them may prove difficult, given the potential impact on business productivity.
For in-scope BYOD assets, at CMMC Level 1, it is the contractor’s responsibility to ensure the 15 cybersecurity requirements outlined in FAR clause 52.204-21 are applied to those FCI assets. Most of these requirements are relatively straightforward and don’t pose much of a concern for BYOD, such as:
- Maintaining an asset inventory, including listing all hardware, software, services, third-parties, and users that are part of the covered system — (b)(1)(i)
- Ensuring FCI is not posted on public websites — (b)(1)(iv)
- Requiring credentials for access to the covered system — (b)(1)(v)
- Locking and alarming doors and windows at the physical facility — (b)(1)(ix)
- Escorting and monitoring visitors — (b)(1)(ix)
However, there are a few requirements that will be difficult to achieve in a BYOD environment. What is likely the single greatest CMMC challenge contractors encounter when permitting BYOD is found in the seventh requirement in the list:
Sanitize or destroy information system media containing Federal Contract Information before disposal or release for reuse.
See our sanitization blog for a detailed description on what exactly is entailed by “sanitize or destroy”. The bottom line is that if a personal device contains FCI, or at any point contained FCI, that device must be sanitized before it is reused, or it must be destroyed entirely at the end of its life. For instance, if an employee uses their personal laptop to access their organization’s Microsoft Commercial tenant, and they proceed to download and store FCI locally, that internal hard drive/SSD would eventually require sanitization/destruction. Another example could include a user accessing the organization’s Microsoft tenant using their smartphone, such as through Teams or Outlook. Unless the apps are “containerized” (see below), should FCI at any point touch the SSD of the smartphone, that drive eventually must be sanitized/destroyed.
This means that the organization would need to establish, within its media sanitization policy (or an equivalent document), a procedure for retrieving in-scope personal devices before their reuse/disposal and subsequently sanitizing/destroying them. Needless to say, users may not feel comfortable turning over their personal devices to the organization for sanitization/destruction. Entities that have employees working remotely may find it difficult to collect these devices. All-in-all, it can be a difficult situation to govern while also ensuring personal privacy.
Aside from sanitization, which, in our opinion, is the greatest deterrent to permitting BYOD, there are a few other requirements in FAR 52.204-21 that may pose challenges for those targeting CMMC Level 1, concerning vulnerability scanning and antivirus:
Identify, report, and correct information and information system flaws in a timely manner.
Provide protection from malicious code at appropriate locations within organizational information systems.
Update malicious code protection mechanisms when new releases are available.
Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened, or executed.
Identifying, reporting, and correcting flaws (i.e., vulnerability scanning and remediation), as well as enabling antivirus, are generally not seen as some of the more “difficult” requirements to implement. At least, this is the case when scanning corporate-owned machines. With BYOD, it may become difficult. Are your employees going to be comfortable with you enrolling their device in whichever vulnerability management/antivirus solution you opt to use? Does that solution work with scanning mobile devices? Does it support both Android and iOS? How are identified vulnerabilities fixed; and how invasive are these fixes? Does the antivirus provide real-time protection? Plenty of questions to consider. Once again, containerization can offer a benefit here; if you were able to isolate the company-managed applications (e.g., Outlook, Teams) to a specific container, you can implement controls like antivirus (such as Microsoft Defender) only within the isolated applications themselves, and not across the entire device. Contact us if you’re contemplating this and want some help thinking through it.
These are our top BYOD considerations for those pursuing CMMC Level 1. For those targeting Level 2, everything in this section would apply to you as well, since the FAR 52.204-21 requirements are all found in NIST 800-171. For more on Level 2, see the next section.
BYOD considerations at CMMC Level 2
Addressing BYOD for the protection of Controlled Unclassified Information (CUI) at CMMC Level 2 assumes you have already addressed protecting FCI at Level 1, including FCI sanitization. If you have not yet done so, we recommend you go back and read the previous section.
TL;DR, if you are permitting personal device usage for the handling of CUI, unless leveraging an entirely cloud-based CUI enclave where no CUI ever resides on the BYOD device, you need to stop right now. NIST 800-171 may feel very invasive to your users if you try to apply the requirements to their personal devices.
In addition to the 15 requirements in FAR 52.204-21, there are an additional 95 requirements in NIST 800-171 Revision 2, spanning 14 total control families. At CMMC Level 2, a contractor’s covered system refers to the environment where it handles CUI and FCI. If a BYOD device is used to handle only FCI, it would only be in-scope for CMMC Level 1, but if that device is used to handle CUI, it falls into scope for Level 2 and is subject to all 110 requirements. For instance, a BYOD device handling CUI would still require sanitization.
While the challenges of securing BYOD to meet CMMC Level 2 span across many different controls, this post will focus on a select few that are particularly burdensome: monitoring, secure configuration, and encryption. First up is monitoring, with two of the 10+ relevant controls listed below:
Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.
You will need to monitor (i.e., collect and analyze event logs) for all BYOD devices included in your CMMC Level 2 scope. Of all the controls in NIST 800-171, none make end users think about security quite like the monitoring controls do. They can be a real boon to the security posture of an organization, as users are aware that they need to tread carefully. The flip-side, however, is the unsettling feeling that “Big Brother is watching”, and, consequently, it’s unlikely that many of your users will take comfort knowing that their personal devices are being monitored by their employer. This does not even take into consideration the end users’ own right to privacy (Warren & Brandeis); to what extent can an employer expect that employees use their own devices for work? Additionally, to what extent can the employer monitor its users’ personal devices without a breach of personal privacy occurring? There’s no clear answer, but these are important questions to be asking if you are contemplating permitting BYOD. From what we’ve seen (and experienced ourselves), the monitoring controls tend to present the most concern among end users.
Contractors may find it especially challenging to fulfill the monitoring requirements on mobile devices. If the CUI is not isolated to a specific container (see below), the organization would need to “create and retain audit logs and records” across the entire mobile device, as it is now fully in-scope. Remember: the requirements follow the sensitive information. This will almost certainly result in concern from end users.
Next up is secure configuration:
Establish and enforce security configuration settings for information technology products employed in organizational systems.
Our security configuration settings blog goes into greater depth on this topic. For this post, the biggest takeaway from this control is that any BYOD device included in your CMMC Level 2 scope will need to be “hardened” according to a hardening standard, such as the Microsoft Security Baselines (for Windows devices). This will involve configuring device parameters, such as the operating system or the software installed on the device, such that the risk of a cyberattack is reduced. For instance, configuring the device to require passwords to be 15+ characters. This would be one “secure configuration” in a list of many — however many are outlined in the hardening standard of choice. Another important consideration for secure configuration is that even mobile devices handling CUI will need to be hardened, such as according to the Center for Internet Security (CIS) Benchmarks. The bottom line: hardening is a great security measure, but it is time-consuming and often limits what the end users can do. This might be concerning to end users.
And finally is FIPS-validated encryption:
Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
Once again, please refer to our FIPS-validated cryptography blog for an in-depth analysis of this particular control. In the context of BYOD, this control has great relevance. When the protection of the confidentiality of CUI cannot be guaranteed — particularly through physical security safeguards such as locks and alarms at a corporate facility — FIPS 140-2-validated encryption is required. Even if employees are only using their personal devices for work-related purposes while at the physical facility, the fact that the devices can — and are — removed from the “safety” of the physical facility means that FIPS-validated encryption is necessary. Depending on how the device handles CUI, this may entail encrypting the applicable drive and applying FIPS mode when doing so. If CUI is going to be transmitted from the BYOD device, FIPS-validated encryption must also be used to secure the CUI in-transit. Bottom line: not all vendors’ products have undergone the FIPS validation process, as it is lengthy and expensive. Therefore, we (the DIB) are limited in terms of which devices we can use that have FIPS-validated modules. Contractors may find it challenging ensuring FIPS validation for CUI stored, processed, or handled by BYOD devices.
What are my options?
As we see it, some of your options for navigating BYOD and CMMC are as follows:
- Prohibit BYOD, and issue corporate-owned devices to all employees with access to the covered system. This is probably the most straightforward solution. In this scenario, all devices used in support of the DoD contract belong to the company, and therefore the company can decide how best to implement the requirements on those devices without worrying about encroaching upon personal privacy. To state the obvious, it likely won’t be cheap, as new hardware will need to be procured. This may be enough of a deterrent for the organization to consider alternate options.
- Permit BYOD, and leverage an exclusively cloud-based enclave for the handling of all FCI/CUI. In this scenario, a solution such as Totem’s ZCaaS™ secure enclave is used whereby no FCI/CUI ever “contaminates” the BYOD device and is instead isolated only within the cloud. If the organization needs to handle FCI/CUI in physical form, leveraging a cloud-based enclave may not be the right fit. The organization inherits the protections afforded by the enclave, including monitoring, secure configuration, and encryption.
- Permit BYOD only for handling FCI, containerize necessary FCI-laiden applications on BYOD devices, and provide corporate-owned devices for those handling CUI. This one could be time-consuming, but it may just work. In this case, those handling CUI are given corporate-owned devices to do so, such as laptops. The organization manages and configures these according to NIST 800-171 (the org could still leverage a CUI enclave, if desired). For BYOD devices used to handle FCI, the organization can enroll the devices in Microsoft Intune, whereby it can then “containerize” (via app protection policies) the Microsoft apps used on the BYOD device, such as Teams and Outlook. We’ve also seen companies such as ManageEngine offer containerization technology for mobile apps. This would solve the sanitization component of FAR 52.204-21, as all FCI on the device is isolated to the container and can be cryptographically erased whenever needed. Furthermore, the organization can leverage Microsoft Defender within the container only to fulfill the antivirus component of FAR 52.204-21. The organization would still need to determine how to fulfill the vulnerability scanning requirement within the container. Some employees may still feel uncertain about enrolling their personal device in Microsoft Intune, although the organization would have no visibility into anything other than the apps inside the container.
- Permit BYOD, and implement the requirements on all in-scope assets. While technically viable, this option may result in the greatest hostility from end users, as it is the most privacy-invasive option. Allowing users to handle FCI/CUI on their personal devices, without the use of containers or an enclave, subjects the BYOD devices to the full force of FAR 52.204-21/NIST 800-171. We’ve elucidated in this post why this may create privacy concerns for end users, specifically when considering sanitization, monitoring, secure configuration, and encryption.
The solution you end up choosing may be different from these, or it may be a combination of multiple. Either way, as long as your organization can ensure that any in-scope BYOD devices have met the requirements at the appropriate CMMC level, you can move forward with confidence towards your eventual CMMC assessment. However, if your decision involves bringing BYOD into scope, you will need to understand the personal privacy implications of that decision, which may result in consulting legal counsel.
Wrapping up
If you are considering permitting BYOD, or are already doing so, your first priority should be to read through the FAR 52.204-21/NIST 800-171 requirements to understand what is expected for the protection of FCI/CUI. While BYOD is not outright prohibited by CMMC, it may become a significant undertaking to ensure the requirements are met while also preserving personal privacy.
If this post produced more questions than answers for you, that’s OK! Grab a seat in our next CMMC Workshop, where we discuss BYOD in detail. Or, drop us a line with any questions you have about this blog, CMMC, or anything else. Until next time!
Keep fighting the good fight!
–Nathan
