1 Draft NIST Special Publication 800-124

2 Revision 2

3 Guidelines for Managing the Security of

4 Mobile Devices in the Enterprise
5
6
7
8 Joshua M Franklin
9 Gema Howell
10 Vincent Sritapan
11 Murugiah Souppaya
12 Karen Scarfone
13
14
15
16 This publication is available free of charge from:
17 https://doi.org/10.6028/NIST.SP.800-124r2-draft
18
19
20
21
C O M P U T E R S E C U R I T Y
22
23
24
25
26
27
28
29
30 Draft NIST Special Publication 800-124
31 Revision 2
32

33 Guidelines for Managing the Security

34 of Mobile Devices in the Enterprise
35
36
37 *Joshua M Franklin Murugiah Souppaya
38 Gema Howell Computer Security Division
39 Applied Cybersecurity Division Information Technology Laboratory
40 Information Technology Laboratory
41
42 Vincent Sritapan Karen Scarfone
43 Science and Technology Directorate Scarfone Cybersecurity
44 Department of Homeland Security Clifton, VA
45
46 *Former employee; all work for this publication was done while at NIST
47
48
49 This publication is available free of charge from:
50 https://doi.org/10.6028/NIST.SP.800-124r2-draft
51
52
53
54 March 2020
55
56

57
58
59 U.S. Department of Commerce
60 Wilbur L. Ross, Jr., Secretary
61 National Institute of Standards and Technology
62 Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology
 63
64 Authority

65 This publication has been developed by NIST in accordance with its statutory responsibilities under the
66 Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law
67 (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including
68 minimum requirements for federal information systems, but such standards and guidelines shall not apply
69 to national security systems without the express approval of appropriate federal officials exercising policy
70 authority over such systems. This guideline is consistent with the requirements of the Office of Management
71 and Budget (OMB) Circular A-130.

72 Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and
73 binding on Federal agencies by the Secretary of Commerce under statutory authority. Nor should these
74 guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce,
75 Director of the OMB, or any other Federal official. This publication may be used by non-governmental
76 organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would,
77 however, be appreciated by NIST.

78 National Institute of Standards and Technology Special Publication 800-124 Revision 2

79 Natl. Inst. Stand. Technol. Spec. Publ. 800-124 Rev. 2, 59 pages (March 2020)
80 CODEN: NSPUE2

81 This publication is available free of charge from:

82 https://doi.org/10.6028/NIST.SP.800-124r2-draft
83

84 Certain commercial entities, equipment, or materials may be identified in this document in order to describe an
85 experimental procedure or concept adequately. Such identification is not intended to imply recommendation or
86 endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best
87 available for the purpose.
88 There may be references in this publication to other publications currently under development by NIST in accordance
89 with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies,
90 may be used by federal agencies even before the completion of such companion publications. Thus, until each
91 publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For
92 planning and transition purposes, federal agencies may wish to closely follow the development of these new
93 publications by NIST.
94 Organizations are encouraged to review all draft publications during public comment periods and provide feedback to
95 NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at
96 https://csrc.nist.gov/publications.

97
98 Public comment period: March 24, 2020 through June 26, 2020
99 National Institute of Standards and Technology
100 Attn: Applied Cybersecurity Division, Information Technology Laboratory
101 100 Bureau Drive (Mail Stop 2000), Gaithersburg, MD 20899-2000
102 Email: 800-124comments@nist.gov
103
104 All comments are subject to release under the Freedom of Information Act (FOIA).
105
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

106 Reports on Computer Systems Technology

107
108 The Information Technology Laboratory (ITL) at the National Institute of Standards and
109 Technology (NIST) promotes the U.S. economy and public welfare by providing technical
110 leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test
111 methods, reference data, proof of concept implementations, and technical analyses to advance
112 the development and productive use of information technology. ITL’s responsibilities include the
113 development of management, administrative, technical, and physical standards and guidelines for
114 the cost-effective security and privacy of other than national security-related information in
115 Federal information systems. The Special Publication 800-series reports on ITL’s research,
116 guidelines, and outreach efforts in information system security, and its collaborative activities
117 with industry, government, and academic organizations.
118
119 Abstract
120
121 Mobile devices were initially personal consumer communication devices but they are now
122 permanent fixtures in enterprises and are used to access modern networks and systems to process
123 sensitive data. This publication assists organizations in managing and securing these devices by
124 describing available technologies and strategies. Security concerns inherent to the usage of
125 mobile devices are explored alongside mitigations and countermeasures. Recommendations are
126 provided for deployment, use and disposal of devices throughout the mobile-device lifecycle.
127 The scope of this publication includes mobile devices, centralized device management and
128 endpoint protection technologies, while including both organization-provided and personally
129 owned deployment scenarios.

130 Keywords
131
132 enterprise mobility management (EMM); mobile; mobile device management (MDM); mobile
133 security; smartphones; tablets.

134

135

ii
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

136 Acknowledgments

137 The authors wish to thank the Federal CIO Council’s Mobile Technology Tiger Team and the
138 Advanced Technology Academic Research Center (ATARC) Mobile Working Groups. The
139 authors especially appreciate the contributions of Wayne Jansen, who coauthored the original
140 version of this publication. The authors also thank all the individuals and organizations that
141 provided comments on the publication, including Andrew Regenscheid and Nelson Hastings of
142 NIST; Jeffrey A. Myers of the Department of Homeland Security (DHS); Deborah Shands and
143 Kareem Eldefrawy of SRI International; and Michael Peck and Terri Phillips of MITRE.

144 Trademarks

145 All registered trademarks or other trademarks belong to their respective organizations.
146

iii
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

147 Call for Patent Claims

148 This public review includes a call for information on essential patent claims (claims whose use
149 would be required for compliance with the guidance or requirements in this Information
150 Technology Laboratory (ITL) draft publication). Such guidance and/or requirements may be
151 directly stated in this ITL Publication or by reference to another publication. This call also
152 includes disclosure, where known, of the existence of pending U.S. or foreign patent applications
153 relating to this ITL draft publication and of any relevant unexpired U.S. or foreign patents.

154 ITL may require from the patent holder, or a party authorized to make assurances on its behalf,
155 in written or electronic form, either:

156 a) assurance in the form of a general disclaimer to the effect that such party does not hold
157 and does not currently intend holding any essential patent claim(s); or

158 b) assurance that a license to such essential patent claim(s) will be made available to
159 applicants desiring to utilize the license for the purpose of complying with the guidance
160 or requirements in this ITL draft publication either:

161 i. under reasonable terms and conditions that are demonstrably free of any unfair
162 discrimination; or
163 ii. without compensation and under reasonable terms and conditions that are
164 demonstrably free of any unfair discrimination.

165 Such assurance shall indicate that the patent holder (or third party authorized to make assurances
166 on its behalf) will include in any documents transferring ownership of patents subject to the
167 assurance, provisions sufficient to ensure that the commitments in the assurance are binding on
168 the transferee, and that the transferee will similarly include appropriate provisions in the event of
169 future transfers with the goal of binding each successor-in-interest.

170 The assurance shall also indicate that it is intended to be binding on successors-in-interest
171 regardless of whether such provisions are included in the relevant transfer documents.

172 Such statements should be addressed to: 800-124comments@nist.gov

iv
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

173 Executive Summary

174 Modern mobile devices, which are essentially general-purpose computing platforms capable of
175 performing tasks far beyond the voice and text capabilities of legacy mobile devices, are
176 widespread within modern enterprise networks. Mobility has transformed how enterprises
177 deliver information technology (IT) services and ensure mission impact. Targeted toward
178 consumers for on-demand personal access to communications, information, and services, these
179 devices are not configured by default for business use. As mobile devices perform everyday
180 enterprise tasks, they regularly process, modify, and store sensitive data. While organizations
181 understand that using mobile devices and mobile applications for anytime, anywhere access can
182 increase employee productivity, enhance decision making and situational awareness, they may
183 also consider that these devices bring unique threats to the enterprise.
184
185 While consumers and enterprise organizations have increased their adoption and use of mobile
186 technologies, the mobile threat landscape has also shifted. This includes an increase in mobile
187 malware and vulnerabilities that span the device (e.g., operating system, firmware, the baseband
188 processor used to access cellular networks), mobile apps, networks, and management
189 infrastructure. The diversity and complexity of the mobile ecosystem and the rapid pace of
190 change offers challenges to selection, integration, and management of mobile technologies into
191 an enterprise IT environment. To reduce risk to sensitive data and systems, federal enterprises
192 need to institute the appropriate policies and infrastructure to manage and secure mobile devices,
193 applications, content, and access.
194
195 Mobile devices often need additional protections as a result of their portability, small size, and
196 common use outside of an organization’s network, which generally places them at higher
197 exposure to threats than other endpoint devices. Laptops are excluded from the scope of this
198 publication. Although some laptop/desktop management technologies are converging with
199 mobile device management technologies, the security capabilities currently available for laptops
200 are different than those available for smartphones, tablets, and other mobile device types.
201 Further, mobile devices contain features not generally available in laptops (e.g., multiple wireless
202 network interfaces, Global Positioning System, numerous sensors, and built-in mobile apps).
203 Devices with minimal computing capability, such as the most basic cell phones and general
204 Internet of Things (IoT) devices are also out of scope because they typically do not have a full-
205 fledged operating system (OS), and limited functionality and limited security options are
206 available.
207
208 Organizations should implement the following guidelines to improve the security of their mobile
209 devices.

210 Organizations should conduct a threat analysis for mobile devices and any information
211 systems accessed from mobile devices.
212 Before designing and deploying mobile device solutions, organizations should conduct a threat
213 assessment for managing and using mobile devices and mobile apps to access and process
214 sensitive data. Threat modeling involves identifying resources of interest and the feasible threats,
215 vulnerabilities, and security controls related to these resources, quantifying the likelihood of
216 successful attacks and their impacts, and then synthesizing this information to determine where

v
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

217 security controls need to be improved or added to mitigate the threats. General security
218 recommendations for any IT technology are provided in NIST Special Publication (SP) 800-53,
219 Security and Privacy Controls for Federal Information Systems and Organizations [1]. Specific
220 controls for securing mobile devices are presented in an appendix of this publication.
221
222 Threat models such as NIST’s Mobile Threat Catalogue [5] and its associated NIST Interagency
223 Report (NISTIR) 8144, Assessing Threats to Mobile Devices & Infrastructure [6] used in
224 conjunction with a threat modeling process such as draft NIST SP 800-154, Guide to Data-
225 Centric System Threat Modeling [48] can help organizations identify security requirements and
226 design mobile device solutions to incorporate the necessary controls to meet the security
227 requirements. See also the Department of Homeland Security’s Congressional report, Study on
228 Mobile Device Security [23], for additional threat information on mobile device security for
229 federal agencies.

230 Organizations should employ Enterprise Mobility Management, Mobile Threat Defense,
231 and other applicable enterprise mobile security technologies.
232 The reliance on mobile devices to access and process enterprise information requires a
233 comprehensive solution for mitigating threats to the organization’s information and systems from
234 use of mobile devices. Enterprise Mobility Management (EMM) systems are a suite of products
235 used to deploy, configure and actively manage mobile devices in an enterprise environment.
236 They are central to an enterprise mobile security solution and can be used to control the use of
237 both organization-issued and personally-owned mobile devices by enterprise users. In addition to
238 managing the configuration of mobile devices, these technologies offer other features, such as
239 controlling access to enterprise computing resources.
240
241 By integrating EMM with enterprise backend services such as authentication, an organization
242 can enable more granular management of mobile device access to mission-critical enterprise
243 resources. System administrators can set policy-based configurations for mobile devices to
244 constrain access to sensitive resources, depending on mobile device conditions (e.g., device
245 connecting from a public WiFi network, jailbroken or rooted device, user-managed device
246 running a corporate application). EMM systems should be integrated with Mobile Threat
247 Defense (MTD) systems to protect the mobile endpoint. MTD systems can detect the presence of
248 malicious apps or operating system (OS) software, known vulnerabilities in software or
249 configurations, and connections to blacklisted websites/servers or networks. The integration of
250 MTD with EMM enables administrators or defense systems to remediate detected vulnerabilities
251 or quarantine applications or devices.
252
253 EMM systems can also be extended to provide Mobile Application Vetting (MAV) capabilities
254 using tools that perform enterprise-level security analysis of managed apps and their libraries
255 prior to deployment and throughout the lifecycle of the apps. Vulnerabilities or malicious code
256 discovered prior to deployment can be referred to the developer, or the app may be disallowed
257 for use on the organization’s devices or within the enterprise mobile appstore. If vulnerabilities
258 or malicious code are discovered after an app has been deployed or updated, the administrator is
259 informed and offered the option to deploy various EMM remediation actions.

vi
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

260 Organizations should leverage the Enterprise Mobile Device Deployment Lifecycle where
261 applicable.
262 Organizations may wish to consider a number of key steps in the deployment process of the
263 Enterprise Mobile Device Deployment Lifecyle before putting mobile devices in the hands of
264 users or allowing users to access enterprise resources via a mobile device. The lifecycle contains
265 guidance on selecting a deployment model (e.g., enterprise use only, organization-managed with
266 personal use allowed, or bring your own device), device and EMM selection, conducting a risk
267 assessment, and device and EMM configurations. Each step of the lifecycle discusses numerous
268 security considerationssuch as ensuring an accurate inventory of devices, selecting devices
269 supported by the vendor for OS and app updates and patches, securely configuring devices,
270 selecting an EMM and applying security policies to the device, verifying configuration each time
271 the user attempts to access the network, and integrating EMM into existing identification,
272 authentication and remote access infrastructure.

273 Organizations should implement and test a pilot of their mobile device solution before
274 putting the solution into production.
275 Any new mobile device solution should be tested before use. This includes in a laboratory or test
276 environment and subsequently with a small group of users. Aspects of the solution that should be
277 evaluated for each type of mobile device include connectivity, protection, authentication,
278 application functionality, solution management, logging and performance. The enterprise should
279 carefully consider whether the proposed solution meets the predetermined functional and
280 technical requirements, alongside helping to meet stated policy and security objectives.

281 Organizations should fully secure each organization-issued mobile device before allowing a
282 user to access the organization’s systems or information.
283 For newly deployed mobile devices, organizations should enroll and configure the device in an
284 EMM solution. Baseline profiles are available in industry, but the precise profile to be deployed
285 should be tailored based on an organization’s needs and risk assessment. Commercial programs
286 are available to simplify device enrollment and enforce security and configuration policies prior
287 to provisioning; in-house programs can be leveraged to accomplish this task as well. This
288 ensures a basic level of trust in the device before first use. For already-deployed, organization-
289 issued mobile devices with an unknown security profile (e.g., unmanaged device), organizations
290 should fully secure them to a known good state (for example, through deployment and use of
291 EMM technologies using the latest mobile OS). Supplemental security controls, such as MTD,
292 MAV, and Data Loss Prevention (DLP) technologies, should be deployed per results of mobile
293 device risk assessment.

294 Organizations should keep mobile operating systems and apps updated.
295 As with any technology, vulnerabilities in mobile devices or OSs are discovered quite
296 oftenparticularly with broadly deployed devices or OSs. Attackers seeking to gain access to
297 sensitive personal or business information will exploit vulnerabilities in the mobile OS, device
298 firmware, or app. OS and firmware vendors produce security updates to fix the vulnerabilities,
299 and app developers often produce mobile app patches and updates to fix known vulnerabilities.
300 Organizations can use EMM and mobile app management solutions to maintain an inventory of
301 their mobile devices, OSs, and deployed apps, enabling them to identify vulnerable mobile

vii
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

302 devices. Organizations may have a vulnerability management system in place that allows them to
303 continuously check for these patches and updates and immediately apply them to the mobile
304 devices within their enterprise.
305
306 Organizations should regularly maintain mobile device security.
307
308 Organizations should perform periodic assessments to confirm that their mobile device policies,
309 processes and procedures are being followed. Assessment activities may be passive, such as
310 reviewing device and management infrastructure (e.g., EMM) logs, or active, such as performing
311 vulnerability scans or penetration testing of the mobile management infrastructure. Operational
312 processes to maintain device security include checking for upgrades and patches and acquiring,
313 testing and deploying them; ensuring each mobile device infrastructure component has its clock
314 synced to a common time source; verifying that device and infrastructure audit logs are collected
315 and sent to the enterprise’s security logging system; reconfiguring access control features as
316 needed; and detecting and documenting anomalies within the mobile device infrastructure,
317 including unauthorized configuration or policy changes to mobile devices. Additional
318 maintenance processes include keeping an active inventory of each mobile device, its user and its
319 apps; revoking access to or deleting installed apps that have subsequently been assessed as too
320 risky to use; and scrubbing sensitive data from mobile devices before reissuing them to new
321 users.
322

viii
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

323 Table of Contents

324 Executive Summary .................................................................................................................... v
325 1. Introduction ......................................................................................................................... 1
326 1.1 Purpose ....................................................................................................................... 1
327 1.2 Scope .......................................................................................................................... 1
328 1.3 Audience ..................................................................................................................... 1
329 1.4 Document Structure .................................................................................................... 1
330 1.5 Document Conventions ............................................................................................... 2
331 2. Overview of Mobile Devices ............................................................................................... 3
332 2.1 Mobile Device Definition ............................................................................................. 3
333 2.2 Mobile Device Characteristics ..................................................................................... 3
334 2.3 Mobile Device Components ........................................................................................ 4
335 2.4 Mobile Communication Mechanisms .......................................................................... 5
336 3. Threats to the Mobile Enterprise ....................................................................................... 7
337 3.1 Threats to Enterprise Use of Mobile Devices .............................................................. 7
338 3.1.1 Exploitation of Underlying Vulnerabilities in Devices ....................................... 7
339 3.1.2 Device Loss and Theft ..................................................................................... 7
340 3.1.3 Accessing Enterprise Resources via a Misconfigured Device ......................... 8
341 3.1.4 Credential Theft via Phishing........................................................................... 8
342 3.1.5 Installation of Unauthorized Certificates .......................................................... 8
343 3.1.6 Use of Untrusted Mobile Devices .................................................................... 8
344 3.1.7 Wireless Eavesdropping .................................................................................. 9
345 3.1.8 Mobile Malware ............................................................................................... 9
346 3.1.9 Information Loss Due to Insecure Lockscreen Configuration .......................... 9
347 3.1.10 User Privacy Violations .................................................................................... 9
348 3.1.11 Data Loss via Synchronization ...................................................................... 10
349 3.1.12 Shadow IT Usage .......................................................................................... 10
350 3.2 Threats to Device Management Systems ................................................................. 11
351 3.2.1 Exploitation of Vulnerabilities within the Underlying EMM Platform .............. 11
352 3.2.2 EMM Administrator Credential Theft ............................................................. 11
353 3.2.3 Insider Threat ................................................................................................ 11
354 3.2.4 Installation of Malicious Developer & EMM Profiles ...................................... 12
355 4. Overview of Mobile Security Technologies .................................................................... 13
356 4.1 Device-Side Management & Security Technologies ................................................. 13
357 4.1.1 Hardware-Backed Processing & Storage ...................................................... 13
358 4.1.2 Data Isolation Mechanisms ........................................................................... 13
359 4.1.3 Platform Management APIs ........................................................................... 14
360 4.1.4 VPN Support.................................................................................................. 14
361 4.1.5 Authentication Mechanisms ........................................................................... 14
362 4.2 Enterprise Mobile Security Technologies .................................................................. 15
363 4.2.1 Enterprise Mobility Management ................................................................... 15
364 4.2.2 Mobile Application Management ................................................................... 16
365 4.2.3 Mobile Threat Defense .................................................................................. 17
366 4.2.4 Mobile App Vetting ........................................................................................ 18
367 4.2.5 Virtual Mobile Infrastructure ........................................................................... 18
368 4.2.6 Application Wrapping..................................................................................... 18

ix
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

369 4.2.7 Secure Containers ......................................................................................... 19

370 4.3 Recommended Mitigations and Countermeasures ................................................... 19
371 4.3.1 EMM Technologies ........................................................................................ 20
372 4.3.2 Cybersecurity Recommended Practices ....................................................... 20
373 4.3.3 Remote/Secure Wipe .................................................................................... 21
374 4.3.4 Security-Focused Device Selection ............................................................... 21
375 4.3.5 Use of a VPN ................................................................................................. 22
376 4.3.6 Rapid Adoption of Software Updates ............................................................ 23
377 4.3.7 OS & Application Isolation ............................................................................. 23
378 4.3.8 Application Vetting ......................................................................................... 24
379 4.3.9 Mobile Threat Defense .................................................................................. 24
380 4.3.10 User Education .............................................................................................. 25
381 4.3.11 Mobile Device Security Policies..................................................................... 25
382 4.3.12 Notification and Revocation of Enterprise Access ......................................... 26
383 4.3.13 Additional Authentication for System Administrators ..................................... 26
384 5. Enterprise Mobile Device Deployment Lifecycle ........................................................... 27
385 5.1 Identify Mobile Requirements ................................................................................... 27
386 5.1.1 Explore Mobile Use Cases ............................................................................ 28
387 5.1.2 Survey Current Inventory ............................................................................... 28
388 5.1.3 Choose Deployment Model ........................................................................... 28
389 5.1.4 Select Devices ............................................................................................... 30
390 5.1.5 Determine EMM Capabilities ......................................................................... 31
391 5.2 Perform Risk Assessment ......................................................................................... 31
392 5.3 Implement Enterprise Mobility Strategy .................................................................... 32
393 5.3.1 Select & Install Mobile Technology ................................................................ 32
394 5.3.2 Integration of EMM into the Enterprise Service Infrastructure ....................... 34
395 5.3.3 Set Policy, Device Configuration and Provision ............................................ 35
396 5.3.4 Verification Testing ........................................................................................ 37
397 5.3.5 Deployment Testing....................................................................................... 37
398 5.4 Operate & Maintain ................................................................................................... 38
399 5.4.1 Auditing.......................................................................................................... 38
400 5.4.2 Device Usage ................................................................................................ 38
401 5.5 Dispose of and/or Reuse Device .............................................................................. 39
402 References ................................................................................................................................. 40
403 Appendix A. Acronyms and Abbreviations ..................................................................... 44
404 Appendix B. Supporting NIST SP 800-53 Security Controls .......................................... 46

405 List of Figures and Tables

406 Figure 1 - Mobile Device Components .......................................................................................... 5

407 Figure 2 - Mobile Communications Technology ............................................................................ 6
408 Figure 3 - Enterprise Mobile Device Deployment Lifecycle ........................................................ 27
409 Figure 4 - On-Premise Mobile Architecture ................................................................................. 33
410 Figure 5 - Cloud-Based Mobile Architecture ............................................................................... 34
411
412 Table 1 - Threat Mitigations and Countermeasures .................................................................... 19

413
x
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

414 1. Introduction

415 Mobile devices are no longer new to the workplace. Modern mobile devices are essentially general-
416 purpose computing platforms capable of performing tasks far beyond the voice and text capabilities of
417 legacy mobile devices. Smartphones and tablets process enterprise information and are regularly included
418 in the design phase of modern network architectures. Multiple mature mobile operating systems are
419 available in the marketplace and have a variety of functionality to secure these devices in the workplace.
420 New mobile technologies for the enterprise are still being introduced. Full parity does not yet exist when
421 comparing the management technology available for traditional desktop environments and those afforded
422 to security professionals to secure their mobile devices – although they are constantly evolving and
423 maturing.
424
425 1.1 Purpose

426 The purpose of this publication is to assist organizations with managing and securing mobile devices.
427 This publication provides recommendations for selecting, implementing, and managing devices
428 throughout their lifecycle via centralized management technologies. Additionally, security concerns
429 inherent to mobile devices are explored alongside mitigation strategies. This approach includes protecting
430 enterprise information such as email, contacts and calendar, which are some of the most commonly used
431 applications in the workplace. This can be expanded to include protection of enterprise-developed and
432 third-party applications, and the sensitive enterprise data they store and process. Recommendations also
433 are provided for deployment, use, and disposal of devices throughout the mobile device lifecycle. This
434 publication can be used to inform risk assessments, build threat models, enumerate the attack surface of
435 the mobile infrastructure, and identify mitigations for mobile deployments.

436 1.2 Scope

437 This publication is scoped to managing modern mobile devices in the enterprise. Mobile devices
438 primarily include smartphones and tablets, but also include other devices running a modern mobile
439 operating system (OS). Laptops are specifically excluded from the scope of this publication as the
440 security controls available today for laptops are quite different than those available for smartphones,
441 tablets and other mobile-device types. Mobile devices with minimal computing capability are excluded,
442 including feature phones, wearables and other devices included under the Internet of Things (IoT)
443 umbrella. This document does not discuss the mechanisms needed to evaluate the security of mobile
444 applications [2] or those needed to securely deploy and maintain a cellular network [3]. Unique feature
445 sets available in specialized areas (e.g., construction, public safety, medical) are not analyzed or
446 discussed.

447 1.3 Audience

448 This document is intended for information security officers, information security engineers, security
449 analysts, system administrators, chief information officers (CIOs), and chief information security officers
450 (CISOs). Other organization personnel may find this document helpful, such as security managers,
451 engineers, analysts, administrators and others who are responsible for planning, implementing and
452 maintaining the security of mobile devices. It assumes that readers have a basic understanding of mobile
453 device technologies, networking, and enterprise security principles.

454 1.4 Document Structure

455 The remainder of this document is organized into the following sections and appendices:

1
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

456 • Section 2 provides an overview of mobile devices, focused on what makes them different from
457 other computing devices, particularly in terms of security.
458 • Section 3 discusses threats to enterprise use of mobile devices.
459 • Section 4 presents an overview of mobile security technologies and discusses mitigations and
460 countermeasures to the threats listed in Section 3.
461 • Section 5 discusses security throughout the mobile device lifecycle. Examples of topics addressed
462 in this section include mobile device security policy creation, design and implementation
463 considerations, and operational processes that are particularly helpful for security.
464 • The References section contains a list of references cited in this document.
465
466 The document also contains the following appendices with supporting material:
467
468 • Appendix A defines selected acronyms and abbreviations used in this publication.
469 • Appendix B lists the major controls from NIST Special Publication 800-53, Security and Privacy
470 Controls for Federal Information Systems and Organizations and the subcategories from the
471 NIST Cybersecurity Framework that affect enterprise mobile device security.
472 1.5 Document Conventions

473 The following conventions are used throughout this document:

474 • Smartphone and appstore are both written as a single word,

475 • The term app is used in place of mobile application, and
476 • WiFi is written without the hyphen.

477

2
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

478
479 2. Overview of Mobile Devices

480 This section defines what a modern mobile device is, outlines characteristics of mobile devices, and
481 discusses their underlying architecture. Understanding the full composition of a mobile device is useful in
482 defining the threats facing these information systems. This section also provides an overview of the built-
483 in security capabilities such as isolation, communication and authentication mechanisms.

484 2.1 Mobile Device Definition

485 Mobile devices are essentially general-purpose computing platforms. They are not restricted to
486 performing one operation and can instead be used in many different domains—including medical,
487 industrial and entertainment. NIST Special Publication (SP) 800-53 Revision 4 [1] defines a mobile
488 device as:
489
490 A portable computing device that: (i) has a small form factor such that it can easily be carried by a single
491 individual; (ii) is designed to operate without a physical connection (e.g., wirelessly transmit or receive
492 information); (iii) possesses local, non-removable or removable data storage; and (iv) includes a self-
493 contained power source. Mobile devices may also include voice communication capabilities, on-board
494 sensors that allow the devices to capture information, and/or built-in features for synchronizing local
495 data with remote locations.
496
497 This definition emphasizes portability, wireless communication, local storage and long battery life—all of
498 which exist in modern smartphones and tablets. It’s common for these systems to have an always-on
499 cellular connection, but this feature is not shared by all mobile devices. In fact, many tablets lack a
500 cellular modem, yet still run a mobile OS. It also is not a requirement that mobile devices run applications
501 or apps, although this capability is commonplace. Applications are used to expand a mobile device’s
502 basic functionality.
503
504 2.2 Mobile Device Characteristics

505 Commercially available mobile devices lack a unified set of features. Each feature and characteristic has
506 the potential to introduce new threats to security and privacy, so it is important to establish a baseline
507 understanding of the set of characteristics that are common to mobile devices. The following list explores
508 the baseline characteristics of a mobile device for the purposes of this publication:

509 • Operating system: A mobile device comes with a rich OS that can be used in a variety of ways.
510 This is the primary distinction between mobile devices and IoT devices, which typically do not
511 have a full-fledged OS and have limited functionality.
512 • Small form factor: The size of a mobile device allows for easy portability.
513 • Self-contained power source: Mobile devices traditionally house a self-contained power source.
514 Some mobile devices are capable of swapping out their battery power source for another.
515 • Physical port: A physical connection can be used to sync/transfer data or to charge the device.
516 Some phones have wireless charging capabilities.
517 • Wireless network interface: Mobile devices have at least one wireless network interface for data
518 communications, often offering connectivity to the internet or other data networks.
519 • Data storage: Mobile devices contain local, built-in and non-removable data storage.
520 • Apps: A mobile device ships with native apps to handle common operations. Beyond native apps,
521 most mobile devices also support third-party apps, which usually add functionality and
522 significantly expand a device’s utility.

3
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

523 • Management capability: Mobile devices include a consistent way to manage the device via MDM
524 Application Programming Interfaces (APIs) or proprietary mechanisms.
525 The following details other common characteristics of mobile devices. These features do not define the
526 scope of devices included in the publication, but rather indicate features that are particularly important in
527 terms of security. This is not intended to be an exhaustive list:

528 • Network services: A mobile device may come with additional networking capabilities such as
529 Bluetooth, near-field communications (NFC), and cellular data and voice (e.g., 4G LTE or 5G).
530 • Camera: Mobile devices may use one or more digital cameras that are capable of capturing photos
531 and video recordings. Cameras also accept biometric input to unlock a device or can interpret non-
532 human readable data formats (e.g., Quick Response [QR] code).
533 • Sensors: Sensors within a mobile device capture data to perform an operation such as
534 authentication or measurement. Examples are: gyroscope, accelerometer, magnetometer,
535 fingerprint reader, pedometer, infrared, barometer, photometer, and thermometer.
536 • Speaker and/or microphone: A mobile device usually has a speaker that provides an audio output
537 ability and/or a microphone that provides audio input ability.
538 • Removable media: Removable media allows for additional data and memory storage on a mobile
539 device, normally provided through a secure digital (SD) card. Removable media also serves as a
540 way to transport data from one mobile device to another device.
541 • Data synchronization: Mobile devices have built-in features for synchronizing local data with a
542 different storage location (desktop or laptop computer, organization servers, telecommunications
543 provider servers, other third-party servers, etc.)
544 • Hardware-backed security module: A mobile device uses a hardware module or some portion of a
545 hardware chip to perform cryptographic functions and store sensitive cryptographic keys and
546 secrets.
547
548 2.3 Mobile Device Components

549 Multiple organizations work in concert to provide the hardware, firmware, software, and other technology
550 that make up a mobile device. For smartphones and tablets with cellular capabilities, a separation exists
551 between the hardware and firmware used to access cellular networks, and the hardware and firmware used
552 to operate the general-purpose mobile OS. Users and administrators generally interact with the general-
553 purpose mobile OS that utilizes the application processor. The hardware and firmware used to access the
554 cellular network, often referred to as the telephony subsystem, typically runs a completely separate real-
555 time operating system (RTOS). This telephony subsystem utilizes a completely separate System on a
556 Chip (SoC) called the baseband processor. This often means that a cellular-enabled smartphone is
557 concurrently running multiple OSs.

558 Other features of the telephony subsystem include the universal integrated circuit card (UICC),
559 international mobile equipment identifier (IMEI), and the international mobile subscriber identity (IMSI).
560 The UICC, also known as the subscriber identity module (SIM) card, stores cryptographic information
561 and personal data and is used to enable access to the cellular network. The IMEI is an identifier specific to
562 a mobile device and is used to uniquely identify a device to the cellular network. The IMSI is used to
563 uniquely identify a subscriber or user on the network. More information on these features can be found in
564 NIST SP 800-187, Guide to LTE Security [3].

565 A set of lower-level systems exist in the form of firmware to initialize the device and load the mobile OS
566 into memory, which includes the bootloader. This initialization firmware may also verify other device
567 initialization code, including device drivers. All of this activity occurs before a user can interact with the

4
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

568 device. If the initialization code is modified or tampered with, the device may not properly boot or may
569 function in a simplified mode. Many modern mobile devices contain an isolated execution environment,
570 which is used specifically for security-critical functions [6]. For example, these environments may be
571 used for sensitive cryptographic operations—e.g., to verify integrity—or to support Digital Rights
572 Management (DRM). These environments typically have access to some amount of secure storage that is
573 only accessible within that environment.

574 The mobile OS enables a rich set of functionality by supporting the use of mobile apps written by third-
575 party developers. Accordingly, it is common for mobile apps to be sandboxed (or securely separated) in
576 some manner to prevent unexpected unwanted interaction between the system, its apps and those apps’
577 respective data. This includes separating user data stored by different apps from interacting with each
578 other. Mobile apps may be written in a native language running close to the hardware, in interpreted
579 languages or in high-level web languages. The degree of functionality of mobile applications is highly
580 dependent upon the application programming interfaces (APIs) exposed by the mobile OS and the
581 frameworks used by the developer. Functionality is also dependent on the level of permissions granted to
582 allow the mobile app to leverage mobile device features, such as the camera or microphone.

583 This section has described the various technologies which work together to make a mobile device
584 function. Figure 1 illustrates a mental model of the previously discussed layers of a mobile device:

585
586 Figure 1 - Mobile Device Components

587 2.4 Mobile Communication Mechanisms

588 Mobile devices support a variety of wireless communication protocols such as cellular, WiFi, Bluetooth,
589 global positioning system (GPS) and NFC. Wired physical connections also are commonplace via a
590 power and synchronization cable using micro USB, USB-C and others. Figure 2 depicts some of the
591 communication mechanisms offered by mobile devices.
592

5
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

593
594
595 Figure 2 - Mobile Communications Technology

596 WiFi is a wireless local area network (WLAN) technology and is generally available on most mobile
597 devices. WiFi devices often connect via centralized wireless access point (AP) but can also work in a
598 device-to-device, ad-hoc mode. Bluetooth is a short-range wireless communication technology primarily
599 used to establish wireless personal area networks (WPANs). Bluetooth technology is common in
600 consumer mobile devices and can be used to communicate with headsets, wearables, keyboards, mice and
601 other IoT devices. Another form of short-range wireless communication is NFC, which typically is
602 optimized for distances of less than four inches but may be vulnerable at greater distances. NFC is based
603 on the radio frequency identification (RFID) set of standards. Mobile payment technology commonly
604 relies on NFC, which has led to a large increase of use in recent years.
605
606 A global navigational satellite system (GNSS) provides worldwide, geo-spatial positioning via GPS. GPS
607 uses line of sight communication with a satellite constellation in orbit to help a handset determine its
608 location. These systems run independently of cellular networks. The U.S. Federal Government operates a
609 GPS constellation, although mobile devices may use other constellations (e.g., Global Navigation
610 Satellite System [GLONASS], Galileo). The U.S. Federal Communications Commission (FCC) mandates
611 that cellular devices must have GPS built-in for public safety and emergency medical reasons. It should
612 be noted the GPS system is not the only way to identify a mobile device’s location. Other techniques
613 include cellular positioning, WiFi-assisted positioning, and geolocation of IP addresses.
614

6
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

615 3. Threats to the Mobile Enterprise

616 Mobile devices support a series of security objectives, but these can differ based on the organization.
617 These mobile security objectives can be accomplished via a combination of security features built into,
618 installed onto, or managed externally to mobile devices. Achieving an organization’s security objectives
619 often requires devices to be secured against a variety of threats. General security recommendations for
620 any IT technology are provided in NIST SP 800-53, Recommended Security Controls for Federal
621 Information Systems and Organizations [1]. Specific recommendations for securing mobile devices are
622 presented in Section 4.3 of this publication and are intended to complement the controls specified in SP
623 800-53. See Appendix C of this document for a summary of SP 800-53 controls tailored to mobile
624 enterprise security.

625 Before designing and deploying mobile device solutions, organizations should develop threat models for
626 all facets of mobile device usage. Threat modeling involves identifying resources of interest and the
627 feasible threats, vulnerabilities and security controls related to these resources; quantifying the likelihood
628 and impacts of successful attacks; and analyzing this information to determine where security controls
629 should be improved or added. Threat modeling helps organizations identify security requirements and
630 design the mobile device solution that incorporates the controls needed to meet the security requirements.
631 The NIST Mobile Threat Catalogue [5], a threat modeling process such as draft NIST SP 800-154, Guide
632 to Data-Centric System Threat Modeling [48], and the DHS Study on Mobile Device Security [23] can be
633 used as a foundation for beginning threat modeling activities. The threats listed in the following sections
634 are mapped to the corresponding threats from the NIST Mobile Threat Catalogue document.

635 3.1 Threats to Enterprise Use of Mobile Devices

636 The following threats are related to the general use of mobile devices.
637
638 3.1.1 Exploitation of Underlying Vulnerabilities in Devices

639 Software development is a complex discipline that creates the instruction set that powers mobile devices
640 and apps. In the case of typical software, errors and vulnerabilities exist at an estimated frequency of ~25
641 errors per 1000 lines of code [33]. There are many definitions for vulnerabilities, but this report leverages
642 the following definition [1]: “Weakness in an information system, system security procedures, internal
643 controls, or implementation that could be exploited or triggered by a threat source.” Software
644 vulnerabilities will exist at all levels of the mobile device stack. Due to the nature of how mobile devices
645 are developed and manufactured, multiple distinct organizations will contribute software and firmware to
646 the same device. The contributing organizations may or may not have robust software development
647 practices and processes in place. A vulnerability in the code from any of these vendors could potentially
648 compromise the device [25]. An example exploitation is using vulnerabilities in the voice assistance or
649 quick access features to bypass the lockscreen and gain unauthorized access to a mobile device.

650 NIST Mobile Threat Catalogue Reference: STA-0 – STA-11

651 3.1.2 Device Loss and Theft

652 Mobile devices are used in a variety of locations outside an organization’s control (e.g., building, office)
653 such as employee dwellings, coffee shops, hotels and taxis. Some organizations have strict rules around
654 mobile devices that state that they are only allowed to be used within an organization’s perimeters. Yet
655 many organizations have multiple sites, so mobile devices are transported from building to building. The
656 portability of mobile devices makes them more likely to be lost or stolen than traditional desktop systems,
657 and the sensitive data on these devices adds an increased risk of compromise to the organization.

7
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

658 NIST Mobile Threat Catalogue Reference: PHY-0

659 3.1.3 Accessing Enterprise Resources via a Misconfigured Device

660 Similar to most other information systems, mobile devices can be misconfigured. The mobile OS contains
661 many security and privacy-relevant configuration options such as the use of a passcode, device
662 encryption, user tracking, and VPN. Unfortunately, not all security- and privacy-relevant settings are
663 located within the security options area of the mobile OS interface. Apps installed on the device also can
664 be configured, sometimes within the administrative area of the device, but also within the app itself.
665 Relevant configurations include authentication to the app, tracking users and the proper use of encryption.
666 Connecting an improperly configured device to an enterprise resource such as a networked drive could
667 lead to information exposure to entities monitoring the network or those improperly accessing the device
668 directly.

669 NIST Mobile Threat Catalogue Reference: STA-8

670 3.1.4 Credential Theft via Phishing

671 Enterprise employees receive emails and text messages to their mobile devices on a daily basis.
672 Sometimes the authenticity of emails and texts can be difficult to determine. Often attackers attempt to
673 steal or request an employee’s user credentials through an email or text message. An employee may be
674 tricked into believing the message is from a trusted source and provide their credentials or allow an
675 attacker unauthorized access to their mobile device by clicking a hyperlink within the email or text
676 message. These are examples of phishing on mobile devices.

677 NIST Mobile Threat Catalogue Reference: AUT-9

678 3.1.5 Installation of Unauthorized Certificates

679 Digital certificates are software cryptographic tokens used for authentication and signing software, among
680 other things. These certificates can be distributed to devices through a variety of channels, including web
681 browsers, physical connections (e.g., USB cable) and profiles similar to EMM profiles. Once a certificate
682 is provided to a mobile device’s certificate store, it can be used for authentication, and it also can be used
683 for making trust-based decisions about apps by showing warnings to users. The presence of a malicious
684 certificate could trick a user’s device into trusting a phishing site or installing a fake phishing or Trojan
685 application such as a banking app.

686 NIST Mobile Threat Catalogue Reference: ECO-23

687 3.1.6 Use of Untrusted Mobile Devices

688 Many mobile devices—particularly those that are personally owned —are not inherently trustworthy.
689 There also is the frequent jailbreaking and rooting of devices, which bypasses built-in restrictions on
690 security, OS use, and other functions. Organizations should assume all mobile devices are untrusted
691 unless the organization has properly secured them and continuously monitors their security while the
692 devices are used to access enterprise apps or data. Untrusted devices are the riskiest mobile devices and
693 oftentimes have access to sensitive enterprise information, and are also the easiest to compromise.

694 NIST Mobile Threat Catalogue Reference: STA-1

8
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

695 3.1.7 Wireless Eavesdropping

696 Because mobile devices primarily use non-enterprise networks for internet access, organizations typically
697 will have no control over the security of the external communications networks the devices access.
698 Communications media may include wireless systems such as Bluetooth, WiFi and cellular networks.
699 Bluetooth devices often are used to transmit audio information (e.g., voice traffic, music) as well as
700 notifications and health information from wearable devices [31]. WiFi and cellular can be used to transmit
701 multiple types of traffic, including voice and data. All these network protocols and media are susceptible
702 to eavesdropping and man-in-the-middle (MitM) attacks that can intercept and modify communications
703 between a device and an enterprise system [26].

704 NIST Mobile Threat Catalogue Reference: CEL-0, CEL-6, CEL-18, LPN-2, LPN-16

705 3.1.8 Mobile Malware

706 Mobile devices are designed to make it easy for users to find, acquire, and install third-party apps offered
707 by appstores. This accessibility poses significant security risks, especially for mobile device platforms
708 and appstores that do not place security restrictions or other limitations on third-party app publishing.
709 Organizations should base their mobile device security policy on the assumption that all unknown third-
710 party apps downloaded by its employees to enterprise-accessible mobile devices are untrusted. Any
711 application installed onto a mobile device can act as a portal for the developer to compromise the device
712 and access sensitive enterprise information.

713 NIST Mobile Threat Catalogue Reference: APP-16, APP-26, APP-43, CEL-33, STA-15

714 3.1.9 Information Loss Due to Insecure Lockscreen Configuration

715 The lockscreen is the first barrier an unauthorized user must pass to gain access to information stored on a
716 mobile device. The lockscreen can be configured with a numeric password or pattern to restrict access to
717 the device. If poorly protected with a simple password, the lockscreen may be breached through a brute-
718 force attack. An unauthorized user with access to a mobile device can access all sensitive information,
719 modify the information and pretend to be the device’s owner to gain further access to enterprise data.

720 The lockscreen can also be configured to display quick access to notifications related to missed calls or
721 messages, app alerts, emails received, etc. Information shown on the lockscreen, such as emails, may
722 display sensitive enterprise information. These lockscreen notifications may provide an unauthorized user
723 with information without the need to unlock the mobile device.

724 NIST Mobile Threat Catalogue Reference: AUT-1

725 3.1.10 User Privacy Violations

726 The collection and monitoring of user or employee data can greatly undermine an individual’s personal
727 privacy. Many mobile devices and apps collect and monitor user data such as location, contacts, browsing
728 history, and general system information. A common use of this information is for marketing purposes to
729 direct specific advertisements to the user. Mobile applications are not the only systems that collect user
730 information, as most of the business systems (e.g., EMM, MTD) used for mobility may also have this
731 capability, meaning that an employer may collect sensitive information about an employee. Under the
732 Privacy Act of 1974, this type of data collection is allowed as long as the business publicly notifies users
733 of any data it has collected, including PII and other user information [38]. The collection of data without

9
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

734 the user’s consent hinders confidentiality and is a privacy violation because the collected data may be
735 used in an unwanted manner without the user’s knowledge.

736 One common privacy violation is user location tracking. Location services are commonly used by
737 applications such as social media, navigation and weather apps, as well as web browsers. In terms of
738 organization security and personal privacy, mobile devices with location services enabled are at increased
739 risk of targeted attacks because it is easier for potential attackers to determine where the user and the
740 mobile device are located and to correlate that information with other sources about who the user
741 associates with and the kinds of activities he or she performs in a particular location. Although access to
742 location services can have positive cybersecurity impacts by enabling location-based policies and device
743 configurations, this should require user consent accompanied by a thorough understanding of what type of
744 personal information an enterprise has access to.

745 NIST Mobile Threat Catalogue Reference: APP-24, APP-36, EMM-7

746 3.1.11 Data Loss via Synchronization

747 Mobile devices may interact with other systems to perform data exchange, synchronization, and storage.
748 This can include both local or remote device syncing. Local synchronization generally involves
749 connecting a mobile device to a desktop or laptop computer wirelessly or via a cable. It can also involve
750 tethering such as using one mobile device to provide network access for another mobile device. 1

751 Remote system synchronization often involves automatic backups of data to a cloud-based storage
752 system. When all of these components are under the organization’s control, risk is generally acceptable.
753 But often one or more of these components are external to the enterprise. Examples include connecting a
754 personally owned mobile device to an organization-issued laptop, connecting an organization-issued
755 mobile device to a personally owned laptop, connecting an organization-issued mobile device to a remote
756 photo backup service, and connecting a mobile device to an untrusted charging station. In all of these
757 scenarios, the organization’s data is at risk of being stored in an unsecured location outside the
758 organization’s control. In these scenarios, transmission of malware from one device to another also is a
759 possibility.

760 NIST Mobile Threat Catalogue Reference: EMM-9, STA-6

761 3.1.12 Shadow IT Usage

762 Organizations that implement a fully managed mobile device policy should be cognizant of the risks
763 associated with Shadow IT. The term “Shadow IT” typically denotes staff members’ work-related use of
764 IT-related hardware, software or cloud services without the knowledge of the IT organization. The
765 canonical example of Shadow IT is a department that performs mission-critical work using an
766 independently purchased server running software that is not approved, managed or even known by the
767 larger IT organization. IT staff may not learn of the existence of this system until it fails or is breached,
768 jeopardizing the critical mission.

769 Staff members often resort to use of Shadow IT systems when enterprise-provided systems and processes
770 are seen as cumbersome or impeding work, or when the enterprise fails to provide necessary systems. In
771 the mobile systems environment, staff members may be motivated to use personal devices to circumvent
772 restrictive mobile device policies implemented by full enterprise management of enterprise-provided

1 Organizations should have policies regarding the use of tethering. If an organization permits tethering, it should ensure the
network connections involving tethering are strongly protected (e.g., communications encryption). If an organization
prohibits tethering, it should configure mobile devices to prevent tethering.

10
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

773 mobile devices. Staff members may send work-related emails or documents to their personal email
774 accounts to better enable access during travel, or they may take pictures of whiteboard drawings with the
775 camera on their personal devices. Staff members may also be motivated to use Shadow IT when
776 enterprise administration practices appear to invade their privacy (e.g., warnings that enterprise system
777 administrators are permitted to monitor all communication from an enterprise-owned mobile phone).

778 Shadow IT systems do not comply with organizational requirements for enterprise control or
779 documentation and may or may not violate security or reliability policies. In a few cases, a benefit arising
780 from Shadow IT is that some of the technologies, software, or systems become part of the future
781 enterprise due to their benefit in boosting productivity. Organizations should be aware of the potential
782 threats from Shadow IT for which there is no single, complete solution (e.g., EMM technologies do not
783 completely address it), and should treat Shadow IT seriously.

784 NIST Mobile Threat Catalogue Reference: N/A

785 3.2 Threats to Device Management Systems

786 The following threats are related to the use of EMM and other systems used to manage and secure mobile
787 devices. More information describing EMMs can be found later in the document (Section 4.2.1).
788
789 3.2.1 Exploitation of Vulnerabilities within the Underlying EMM Platform

790 EMM infrastructure and subsequent components run on top of commodity hardware, firmware and
791 software—all of which are susceptible to publicly known software and hardware flaws. Although
792 extensive customization of systems occurs, commodity hardware and well-known OSs should be
793 identified and understood. This guidance implies these systems be properly configured leveraging the
794 security configuration guides found in the NIST Checklists repository and regularly patched to remediate
795 known vulnerabilities such as those listed in the National Vulnerability Database [39].
796
797 NIST Mobile Threat Catalogue Reference: EMM-1, EMM-2
798
799 3.2.2 EMM Administrator Credential Theft

800 Credential theft is a primary issue for employees, but the credentials of system administrators working the
801 EMM console can also be compromised. If attackers can log into the EMM as an administrator, there
802 could be a loss of sensitive information. For instance, EMMs store a variety of sensitive information
803 about employees at all levels of an organization. Examples include email addresses, phone numbers, user
804 names, assigned resources, levels of access, and potential metadata from voice and text communication.
805 Additionally, EMM administrator credentials allow an attacker to misconfigure and put mobile devices
806 into an insecure state by modifying the policies enforced on the devices. Finally, an attacker may also be
807 able to perform a denial of service (DoS) attack on an enterprise by removing enterprise access for all
808 mobile devices by erasing their records from the EMM.
809
810 NIST Mobile Threat Catalogue Reference: EMM-2
811
812 3.2.3 Insider Threat

813 An insider threat originates from an individual—for example, a current or former employee—who uses
814 authorized access to an organization’s system to violate the organization’s security policy. As an essential
815 tool for secure mobile system administration, an EMM system may be a “double-edged sword.” To wit, it
816 may be used both as a mechanism for protecting an enterprise from insider threats (e.g., to implement

11
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

817 practices focused on password and account management, access controls, system change controls and app
818 usage policies) as well as an attack vector for a malicious insider. A malicious insider with access to an
819 EMM system could weaken permissions to enable data leaks, enroll unauthorized devices or outsiders, or
820 whitelist malicious apps, among other inappropriate actions. The use of EMM systems and other mobile
821 device administration tools should be monitored carefully to detect possible malicious insider activities.
822
823 NIST Mobile Threat Catalogue Reference: EMM-2

824 3.2.4 Installation of Malicious Developer & EMM Profiles

825 Installation of EMM profiles enables an enterprise to control privileged operations provided by mobile
826 OSs. There are multiple ways mobile device users can be enrolled into the EMM and profiles distributed.
827 One of the most common is installing an EMM application—sometimes referred to as an MDM agent—
828 directly onto the mobile device. When this setup is completed, end-users can enter information unique to
829 their organization and authenticate to the EMM server. At this point, an EMM profile is presented to the
830 user. This profile contains specific permissions and other resources approved by administrators.
831
832 EMM profiles can be conveyed to a user from a variety of avenues such as email, text and drive-by
833 downloads. If a user accidentally accepts a malicious profile delivered via one of these methods,
834 privileged access could be provided to an attacker. Using this access, an attacker can leverage all
835 management APIs to access enterprise data on the device and possibly even information stored on
836 backend infrastructure run by the organization.

837 NIST Mobile Threat Catalogue Reference: EMM-3, STA-7

838

12
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

839 4. Overview of Mobile Security Technologies

840 Mobile security technologies have evolved over the past decade to become full-featured security
841 management suites. New capabilities and features are being added to increase the control administrators
842 have for their enterprise devices. Some of these capabilities are built into the device, whereas others are
843 services provided by external systems residing on more traditional webservers. Device-side security
844 capabilities are introduced in Section 4.1, and are followed by a description of enterprise management
845 technologies in Section 4.2. Recommendations on how to mitigate the threats described in Section 3
846 through policy, user education, use of security management technologies, and industry best practices are
847 presented in Section 4.3.
848
849 4.1 Device-Side Management & Security Technologies

850 The following sections detail common on-device technologies used to enable management and enhance
851 enterprise security. Note that not all mobile devices share the same functions and security capabilities.
852
853 4.1.1 Hardware-Backed Processing & Storage

854 Many mobile devices contain dedicated hardware components to protect cryptographic keys, passwords,
855 digital certificates, biometric templates and other sensitive information. These hardware components are
856 also frequently used to support the encryption of user data on the mobile devices. Some mobile devices
857 offer dedicated components to perform sensitive operations such as making security decisions (e.g.,
858 granting access to a privileged API) or performing cryptographic operations on data. On some platforms,
859 secure data storage and sensitive operations are combined into a single SoC. An example of this for Apple
860 devices is the secure enclave [21], while an Android example is the Trusted Execution Environment
861 (TEE) leveraging ARM TrustZone technology [22].
862
863 Although these components may exist on devices, they may not be used by default. Both the OS and/or
864 apps must properly leverage the right APIs to fully utilize the security functions that are provided by the
865 platform. On some platforms, APIs may not be exposed to all developers. Within other platforms, small
866 applications can be developed to run specifically within these restricted security environments.
867
868 Finally, devices may use other security modules or elements dedicated to specific tasks. These
869 modules/elements are often meant to provide a secure implementation of a specific task. One example is
870 Apple Pay, which uses a Secure Element. The Secure Element is a chip specifically designed to handle
871 certain transactions and encrypt payment information stored on the element.
872
873 4.1.2 Data Isolation Mechanisms

874 Some mobile devices provide data isolation mechanisms to prevent unauthorized access to user and
875 device data. Examples of data isolation mechanisms include encryption and application sandboxing.
876 Isolating data using encryption separates the data based on authorized access. This mechanism means
877 only users possessing the appropriate cryptographic key can access the encrypted data on the device.
878 Modern mobile devices generally encrypt user data, but data may be encrypted with a key that is managed
879 by the OS, and not the user, developer or enterprise.
880
881 Sandboxing on a mobile device can be implemented in multiple ways. An app sandbox is implemented by
882 the mobile OSs, which generally keeps apps from interacting with each other. Exceptions are made based
883 on well-defined methods explicitly accepted by the user, done by sometimes asking a user if they grant a
884 permission for an application to do a task. Additional sandboxes may exist at or below the user-level that

13
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

885 provide an additional layer of data segmentation. While these may be built into the OS, some Original
886 Equipment Manufacturers (OEMs) have decided to develop and ship their own (e.g., Samsung KNOX).
887
888 4.1.3 Platform Management APIs

889 The major mobile OS platforms offer a set of APIs and supporting protocols that can be used by third-
890 party management tools [27][28]. Management APIs offer access to capabilities that are not offered to
891 normal developers such as controlling app behavior, configuring device and security settings, and
892 querying sensitive device information. Access to these APIs may be restricted to a subset of particular
893 developers vetted by the platform owners. Additionally, access to these APIs must be agreed to by either
894 a device’s end-user or a member of an organization’s IT staff.
895
896 The management capabilities offered by the platform owners also are supplemented by external
897 infrastructure, which is discussed further in Section 4.2.1. In some management situations IT
898 administrators are able to directly manage the devices, while in other settings IT administrators send
899 commands to the platform owner’s infrastructure, which is subsequently relayed onward to the device.
900 Both of these scenarios can be accommodated within the same management panel and be made invisible
901 to the user.
902
903 4.1.4 VPN Support

904 Mobile platforms natively support virtual private networks (VPNs) that can be leveraged by developers
905 via APIs. VPNs primarily provide confidentiality protection by encrypting user data. There are three types
906 of VPNs: OS-level VPNs, app level-VPNs, and web-based VPNs. OS-level VPNs can be configured via
907 management platforms and sometimes can be put into an “always-on” state. OS-level VPNs may be more
908 power-efficient and can encrypt a large amount of user traffic. Protocols that may be used include Internet
909 Protocol Security (IPsec) and Layer 2 Tunneling Protocol (L2TP). Unlike OS-level VPNs, app-level
910 VPNs can be configured in multiple ways. They can leverage system VPN APIs to protect user data or
911 they may simply protect a single app’s data. More complicated setups can deploy VPNs per mobile app,
912 often known as a per-app VPN. Finally, web-based VPNs are easy for a user to take advantage of, often
913 by simply agreeing to a web page’s policy. Web-based VPNs use Transport Layer Security (TLS) and
914 may not leverage the same additional protections used by other types of VPNs.
915
916 4.1.5 Authentication Mechanisms

917 Mobile devices offer a variety of sensors that can enable standard and biometric-based authentication.
918 Use of biometric authentication on a mobile device may be used in combination with or in substitution of
919 passwords or PINs. Mobile hardware typically does not contain or store raw biometric data. Instead the
920 biometric data is transformed (e.g., tokenized) and may be stored securely, minimizing its susceptibility to
921 reverse engineering. Biometric data typically is encrypted, stored on the device and protected with a key
922 available only to a dedicated security environment. Sensors leveraged for biometric authentication include
923 the following:
924
925 • Fingerprint sensor for fingerprint-based authentication,

926 • Dedicated cameras and other sensors to assist in facial recognition,

927 • Gyroscope, accelerometer, or pedometer for gait-based authentication, and

928 • Microphone for voice recognition.

14
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

929 Individual sensors of the same type can be of varying quality and ultimately more or less secure than a
930 similar component. Some sensors are not directly exposed to developers and access decisions are made in
931 proprietary security environments. Although these sensors are most often used for local user
932 authentication, they also can be used for remote authentication. Another mechanism that can be used for
933 remote authentication is a derived personal identity verification (PIV) credential. This is where a mobile
934 device leverages certificate-based authentication through a token that is associated with a PIV credential.
935 Additional information can be found in NIST SP 800-63-3, Digital Identity Guidelines [4] and NIST SP
936 800-157, Guidelines for Derived Personal Identity Verification [41].
937
938 4.2 Enterprise Mobile Security Technologies

939 Technology to manage smartphones and tablets can be used to control organization-issued and personally
940 owned devices. This technology can take many forms such as a management tool for device
941 configuration, an application management tool, or a mobile threat defense (MTD) tool. MTD is a category
942 of technology that defends devices from a variety of threats posed to the devices themselves and any
943 connected networks. Other products such as mobile identity management, mobile content management
944 and mobile data management also exist, but are not covered in this publication. This section provides an
945 overview of the current state and use of these technologies, focusing on their components and security
946 capabilities. These technologies form the foundation for the recommended technical threat mitigations
947 and countermeasures in Section 4.3.

948 4.2.1 Enterprise Mobility Management

949 EMM is a solution used to deploy, configure and actively manage mobile devices in an enterprise
950 environment. An EMM suite may encompass mobile device management (MDM), mobile application
951 management (MAM) and other management technologies. These management systems are developed by
952 a variety of organizations, including mobile device manufacturers, mobile OS developers, and
953 independent third-party development organizations. EMMs rely on the MDM APIs and protocols
954 described in Section 4.1.3 and employ technologies to monitor mobile devices, track a device’s location,
955 deploy device policies, and configure device-side security technologies (e.g., secure containers).

956 The rest of this subsection contains a list of security capabilities that may be provided by EMMs or any of
957 their supporting systems. Most organizations will not need all of the security capabilities listed in this
958 subsection. Organizations deploying mobile devices should consider the merits of each security
959 capability, determine which services are needed for their environment, and then design and acquire one or
960 more solutions that collectively provide the necessary services for their needs. Additional guidance for
961 implementing these technologies can be found in Section 5.

962 4.2.1.1 General Policy Enforcement

963 EMM technology can enforce enterprise security policies on a mobile device, which can configure or
964 restrict the use of mobile functionality and security capabilities. EMM technology can automatically
965 monitor, detect and report when policy violations occur and automatically take action when possible and
966 appropriate. General policy restrictions or configuration options for mobile device security include the
967 following:

968 • Manage wireless network interfaces (e.g., WiFi, Bluetooth, NFC),

969 • Restrict user and app access to hardware (e.g., digital camera and removable storage) and device
970 features (e.g., copy and paste),
971 • Detect changes to the approved security configuration baseline, and

15
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

972 • Limit or prevent access to enterprise services based on the mobile device’s OS version (including
973 whether the device has been rooted/jailbroken), vendor/brand, model, or mobile device
974 management software client version (if applicable).
975 4.2.1.2 User and Device Authentication

976 User and device authentication can be defined and enforced using EMM technology. Some basic options
977 and considerations include the following:

978 • Require a password or other authenticator to unlock the device (e.g., passcode, fingerprint, face),
979 • Require a password/passcode and/or other authentication mechanism (e.g., token-based
980 authentication, network-based device authentication, domain authentication, digital certificate)
981 before accessing the organization’s resources. This includes basic parameters for password
982 strength and a limit on the number of retries permitted without negative consequences (e.g.,
983 locking out the account, wiping the device),
984 • Have the device automatically lock itself after it is idle for a period of time (e.g., 45 seconds, 5
985 minutes),
986 • Under the direction of an administrator, remotely lock the device if it is suspected the device is
987 lost or was left in an unlocked state in an unsecured location, and
988 • Wipe the device after a certain number of incorrect authentication attempts or after a
989 predetermined time interval without it checking into the EMM. Note that the ability to recover via
990 an EMM after it has been wiped is limited.
991 4.2.1.3 Data Communication and Storage

992 Protections for data communications and on-device data storage can be defined and enforced using EMM
993 technology. Considerations for these data protections include the following:

994 • Strongly encrypt data communications between the mobile device and the organization. This
995 encryption is most often accomplished in the form of a VPN (see Section 4.1.4), although it can
996 be established through other uses of secure protocols and encryption,
997 • Strongly encrypt stored data on both built-in storage and removable media storage. Removable
998 media also can be “bound” to particular devices so encrypted information only can be decrypted
999 when the removable media is attached to that specific device, thereby mitigating the risk of
1000 offline attacks on the media,
1001 • Wipe the device before reissuing it to another user, retiring the device, etc., and
1002 • Remotely wipe the device to scrub its stored data if it is suspected that the device has been lost,
1003 stolen or otherwise fallen into untrusted hands and is at risk of its data being recovered by an
1004 untrusted party.
1005 4.2.2 Mobile Application Management

1006 Some EMM systems include MAM functionality, enabling fine-grained control over different apps on a
1007 single managed device, although MAM also may be offered as a distinct third-party solution. MAM
1008 systems are designed to enable enterprise control over mobile apps that access enterprise services and/or
1009 data. These apps include privately developed apps and publicly available apps. Unlike MDMs, MAM
1010 systems do not require the device owner to enroll the entire device under enterprise management, nor
1011 must the owner accept installation of an enterprise profile on the device. This distinction is critical for
1012 apps designed, for example, to support business-to-business (B2B) transactions (e.g., an app provided to
1013 suppliers to enable access to an enterprise orders database). In such cases, the mobile user is not an
1014 employee of the enterprise that offers the app.

16
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1015 Apps used on mobile devices may be managed using EMM technology. Depending on how the device is
1016 managed and enrolled into an EMM solution, the following restrictions may be applied:

1017 • Restrict which appstores may be used (e.g., limit access to official appstores),
1018 • Restrict which apps may be installed through whitelisting allowed apps (preferable) or
1019 blacklisting prohibited apps. Whitelisting and blacklisting capabilities are highly platform-
1020 dependent and may not be available on all MAM systems,
1021 • Restrict the permissions (e.g., camera access, location access) assigned to each app.
1022 App-wrapping technology (described further in Section 4.2.6) may be used and is highly platform
1023 dependent and may also limit app functionality,
1024 • Safeguard mechanisms to install, update and remove apps on a mobile device. Keep a current
1025 inventory of all apps installed on each device. This capability is highly platform dependent and
1026 may not be available on all systems,
1027 • Restrict the use of OS and app-synchronization and sharing services (e.g., local device
1028 synchronization, remote synchronization services and websites),
1029 • Distribute apps from a dedicated enterprise mobile appstore provided through the EMM
1030 technology, and
1031 • Distribute the organization’s apps from a dedicated mobile appstore.
1032 MAM solutions often enable an enterprise to integrate an in-house enterprise app catalog with a mobile
1033 device vendor’s appstore (e.g., Apple’s AppStore, Google Play) to allow mobile users to easily install an
1034 enterprise app. Enterprise system administrators may be able to deploy apps or push out over-the-air
1035 updates to mobile users; they may also be able to restrict app functionalities without affecting the entire
1036 device, an approach that is preferred by BYOD users. Capabilities for specification and enforcement of
1037 security and privacy policies is a key function of MAM systems, often including user- or role-based
1038 policies for access to specific apps and integration with remote wipe for employees departing the
1039 organization or changing roles. Encryption or containerization may be used to separate execution
1040 environments of apps or their communication with enterprise services. Finally, MAM systems may enable
1041 enterprise system administrators to monitor app behavior, configuration compliance or presence of
1042 unauthorized apps on a user device.

1043 4.2.3 Mobile Threat Defense

1044 MTD systems are designed to detect the presence of malicious apps, network-based attacks, improper
1045 configurations and known vulnerabilities in mobile apps or the mobile OS itself. Although MTD is
1046 becoming the preferred term, the terms mobile threat protection (MTP) and endpoint protection also are
1047 colloquially used. These systems often run an agent on the device—typically a mobile app—and may also
1048 initiate analysis and learning on external cloud-based platforms. MTD systems provide real-time,
1049 continuous monitoring, assessing apps after deployment to a mobile device as well as during runtime. In
1050 an enterprise context, an MTD system may be integrated with an EMM to enable user or administrator
1051 notification or automated response to remediate detected vulnerabilities or quarantine apps or devices.

1052 An MTD can detect and protect the mobile device, apps and end-user against attacks via the wireless
1053 network. This defense covers MitM attacks that could intercept or eavesdrop on communications. MTD
1054 systems also may detect attacks against an app or OS software. For example, MTD systems may observe
1055 side-loaded apps—apps loaded from sources other than the standard mobile device vendor’s appstore
1056 (e.g., Apple’s Appstore, Google Play). Side-loaded apps may be special-purpose, enterprise-loaded, or
1057 whitelisted apps specified by the enterprise. MTD systems monitor the on-the-fly behavior of mobile apps
1058 within the current mobile environment, such as when the app navigates to known malicious URLs or
1059 phishing sites. For example, MTD systems may detect communication with a blacklisted service or an
1060 app’s failure to encrypt communication with an enterprise’s backend service. Unexpected interactions

17
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1061 among apps or use of data on the user device (e.g., the app accesses a device owner’s “contacts” or
1062 “location”) also may alert an MTD system to potentially malicious or risky behavior.

1063 4.2.4 Mobile App Vetting

1064 The goal of app vetting is to detect software or configuration flaws that may create vulnerabilities or
1065 violate enterprise security or privacy policies. An app vetting system is used by enterprise system
1066 administrators before an app is deployed to a user’s mobile device, unlike an MTD system. Mobile apps
1067 may be developed by mobile device manufacturers (e.g., Apple’s apps for iOS), the mobile OS vendor
1068 (e.g., Google Maps for Android), third-party providers or in-house enterprise developers. App developers
1069 and OS developers, as well as enterprise administrators may make mistakes when designing or building
1070 an app. They may also intentionally insert malicious functionality that may impact the security or privacy
1071 of the mobile user or the enterprise.

1072 App vetting involves a sequence of activities that typically are accomplished via automated test and
1073 analysis tools, which may interact with external vetting services. App vetting systems may analyze app
1074 source code, app binaries, or general app behavior. App vetting systems can expose several security-
1075 critical issues, such as problems with the use of cryptography, collection and handling of sensitive
1076 corporate or user data, or software dependencies on untrustworthy cloud services. Common problems
1077 with app use of cryptography include the use of weak or broken cryptographic algorithms, small key sizes
1078 or failure to cryptographically protect communications or stored data.

1079 Vetting systems may also detect that an app will collect sensitive enterprise data or PII of the mobile user.
1080 Apps may be designed to use the device’s camera or microphone or collect and share (or sell) sensitive
1081 information, including user location information, contact details, sensor data, photos and messages with
1082 backend services provided by untrustworthy third parties. Mobile app vetting systems may be able to
1083 expose such issues at several phases of the app lifecycle: during development by communicating issues
1084 and recommended mitigations to app developers; following development and prior to deployment by
1085 identifying vulnerabilities to app security analysts or enterprise system administrators; and post
1086 deployment through integration with an EMM by notifying enterprise system administrators of
1087 vulnerabilities in installed apps [2].

1088 4.2.5 Virtual Mobile Infrastructure

1089 Virtual mobile infrastructure (VMI) provides an alternative, or accompaniment, to EMM technology.
1090 Similar to Virtual Desktop Infrastructure (VDI), which hosts a virtual desktop image for applications and
1091 data, VMI uses backend infrastructure to host a virtual mobile device and mobile apps. A user then
1092 accesses their virtual device via an app (i.e., thin client) on their phone, and the thin client provides access
1093 to a virtual OS. This approach may be viewed as “sidestepping” data confidentiality concerns by storing
1094 sensitive information within external infrastructure versus on the mobile device itself. Since all enterprise
1095 information would only be available on the cloud-hosted infrastructure, enterprise data would likely be
1096 unavailable if there is no network connectivity. Depending upon how the VMI system is structured, VMI
1097 may or may not be deployed onto a device already provisioned into an EMM. VMI typically does not
1098 allow for device-wide controls and configurations. The deployment and use of this technology is not
1099 within the scope of this document.
1100
1101 4.2.6 Application Wrapping

1102 App wrapping is a security mechanism that modifies a ready-to-run mobile executable to prevent
1103 functionality defined by a mobile administrator. This approach is often seen as an alternative to the usage
1104 of a secure container. Wrapping allows for policies to be enforced onto third-party applications that the

18
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1105 enterprise does not own. App wrapping typically requires administrative access to the mobile device, and
1106 wrapped apps are installed onto the device without being uploaded to—or vetted by—a platform’s native
1107 appstore. This process of nonstandard installation also is known as sideloading and if done incorrectly
1108 could make a mobile device extremely vulnerable to attack. To mitigate against these potential attacks,
1109 the sideloading functionality should be disabled when not used for installing the wrapped apps. The use of
1110 app wrapping can be seen as beneficial from a usability standpoint, as users simply use apps like normal.
1111 From an IT administrator standpoint, deploying updates can be problematic and error prone.
1112
1113 4.2.7 Secure Containers

1114 Secure containers are mobile apps that provide software-based data isolation designed to segment
1115 enterprise applications and information from personal apps and data. Containers may present multiple
1116 user interfaces, one of the most common being a mobile application that acts as a portal to a suite of
1117 business productivity apps, such as email, contacts and calendar. IT administrators can manage policy sets
1118 on containers, but this process may require the use of a software development kit (SDK) integrated into an
1119 app. There are multiple secure container architectures, with the two major ones colloquially referred to as
1120 app-based and OS-based. App-based containers may not be wholly dissimilar from any other apps on a
1121 mobile device, with the exception of leveraging the management APIs provided by the OS developer. For
1122 instance, on most modern mobile platforms any information stored within an app’s directory on a device
1123 will be encrypted by default. A more extensible implementation of an app-level container allows an
1124 enterprise to manage the cryptographic key protecting the container. OS-based containers provide
1125 additional segmentation and data isolation when compared to app-based containers. They also provide a
1126 consistent FIPS 140-validated environment across different platforms independent of the local
1127 cryptographic functions, and these containers are often preferable from a security standpoint.
1128
1129 4.3 Recommended Mitigations and Countermeasures

1130 This section identifies mitigations to the threats identified in Section 3. Table 1 depicts the threats and
1131 associates them alongside potential mitigations and countermeasures. Not all threats have a corresponding
1132 mitigation listed. Unaddressed threats indicate open research areas and opportunities for new technologies
1133 and products. Each listed mitigation addresses at least one threat listed in Section 3. Applying the
1134 following mitigations to a personal device of an employee may not be easily accomplished if the user is
1135 required to configure their device without the assistance of an IT administrator. For example, it is
1136 commonplace for an EMM to create a profile that must be accepted by a user to put these mitigations in
1137 place, but an average user may be unable to acquire and properly configure the product.

1138 Table 1 - Threat Mitigations and Countermeasures

Threats Mitigations and Countermeasures

Exploitation of Underlying Vulnerabilities in Devices • Security-Focused Device Selection
• OS & Application Isolation
• Rapid Adoption of Software Updates
• Mobile Threat Defense
Device Loss and Theft • EMM Technologies
• Mobile Device Security Policies
• Remote/Secure Wipe
• Notification and Revocation of Enterprise Access for
Policy Violations
Credential Theft via Phishing • User Education
• Mobile Threat Defense
• Mobile Device Security Policies
• Remote/Secure Wipe

19
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

Threats Mitigations and Countermeasures

Installation of Malicious Developer & EMM Profiles • User Education
• Application Vetting
Accessing Enterprise Resources via a • EMM Technologies
Misconfigured Device • Mobile Device Security Policies
• Notification and Revocation of Enterprise Access for
Policy Violations
Installation of Unauthorized Certificates • Mobile Threat Defense
Use of Untrusted Mobile Devices • Security-Focused Device Selection
• Notification and Revocation of Enterprise Access for
Policy Violations
Wireless Eavesdropping • Use of a VPN
Mobile Malware • User Education
• Security-Focused Device Selection
• Rapid Adoption of Software Updates
• Application Vetting
• OS & Application Isolation
Information Loss Due to Insecure Lockscreen • EMM Technologies
• Mobile Device Security Policies
• User Education
User Privacy Violations • User Education
• Application Vetting
Data Loss via Synchronization • EMM Technologies
• Mobile Device Security Policies
• User Education
Shadow IT Usage • Mobile Device Security Policies
Exploitation of Vulnerabilities within the Underlying • Cybersecurity Recommended Practices
EMM Platform • User Education
EMM Administrator Credential Theft • Additional Authentication for System Administrators
Insider Threat • EMM Technologies
• Mobile Device Security Policies
• User Education
1139

1140 4.3.1 EMM Technologies

1141 EMM and its supporting technologies can mitigate several of the threats defined in Section 3 and
1142 prevalent in the mobile ecosystem. EMM can assist in preventing a misconfigured device from
1143 connecting to the enterprise by securely configuring device settings prior to granting access to enterprise
1144 resources. An EMM can also actively deny a device access to enterprise data if it is in an insecure state. If
1145 an employee loses his or her device or it is stolen, the EMM can wipe the enterprise data on the device.
1146 EMMs also can help manage what information is shared on a device lockscreen. Depending on the
1147 EMM’s capabilities, the list of issues that can be mitigated may be much larger because some EMMs can
1148 be used to manage and configure other technologies like MTD and VPN applications.

1149 Threats Addressed: Accessing Enterprise Resources via a Misconfigured Device, Device Loss and Theft,
1150 Information Loss Due to Insecure Lockscreen, Data Loss via Synchronization, Insider Threat

1151 4.3.2 Cybersecurity Recommended Practices

1152 EMM and other mobility management infrastructure rely on COTS systems to perform management
1153 functions. These core systems often run on top of general-purpose OSs and commodity hardware. It is
1154 important that computer security recommended practices, including network, physical and personnel

20
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1155 security, be applied to these components in the same way they are applied to general information
1156 technology systems throughout industry. Protection mechanisms such as patch management [42],
1157 configuration management [43][40] (e.g., disabling serial ports on field network equipment), identity and
1158 access management, malware detection, plus intrusion detection and prevention systems can be carefully
1159 planned and implemented throughout the enterprise.

1160 Threats Addressed: Exploitation of Vulnerabilities within the Underlying EMM Platform

1161 4.3.3 Remote/Secure Wipe

1162 Remote wipe enables enterprise system administrators to delete enterprise data and applications on
1163 enterprise-owned or employee-owned (BYOD) mobile devices. Remote wipe capability is widely
1164 available on mobile devices such as smartphones and tablets supporting Android or iOS. Variants of this
1165 feature also are natively available for OSs and third-party applications that can be installed on these
1166 devices.
1167
1168 To enable remote wipe, a system administrator installs and configures a profile/agent on a device before
1169 enterprise data or applications are available to be used. To later perform a remote wipe, an enterprise
1170 server issues an erase command that is sent over the network to instruct the EMM device agent to delete
1171 data and/or apps on the device. The EMM device agent responds to the server with an acknowledgement
1172 that the erasure has been performed or the wipe failed.
1173
1174 Remote wipe may be implemented at different levels of granularity, ranging from full-device wipe (e.g.,
1175 deleting everything within the system’s user partition; typically this level is used for an enterprise-owned
1176 device) to an enterprise wipe (e.g., deleting only those device settings, data and apps previously pushed
1177 out to the user for enterprise use [typically this level is used to delete work data residing on an employee’s
1178 personal device]). Native remote wipe capabilities for iOS and Android devices require the device be
1179 powered on (with a sufficient charge) and connected to the network. Some third-party EMM systems can
1180 execute a remote wipe even when the device is not connected to the network.
1181
1182 Organizations should not rely on remote wipe as the sole security control for protecting sensitive data, but
1183 instead consider it to be one layer of a multi-layered approach to protection. By itself, remote wipe is a
1184 fundamentally unreliable security control. For example, an attacker could access information on a device
1185 before it is wiped or an attacker could power off a device to prevent it from receiving a remote wipe
1186 signal.
1187
1188 Threats Addressed: Device Loss and Theft, Credential Theft via Phishing
1189
1190 4.3.4 Security-Focused Device Selection

1191 Out of the box, some devices may have embedded vulnerabilities or malicious software, firmware or
1192 hardware. Malicious actors who have access to the hardware, firmware or software supply chains may be
1193 able to modify device components, source code or executables during the design or manufacturing phases.
1194 For example, an attacker could manipulate software development or integration tools (e.g., compilers,
1195 software test systems, configuration management systems), software support tools (e.g., software update
1196 or upgrade systems), system administration tools (e.g., software installation and release management
1197 systems, patch management systems) or an MDM, MAM, or EMM system. NIST IR 8151, Dramatically
1198 Reducing Software Vulnerabilities [29] defines a framework and provides a broad catalog of supply chain
1199 attack patterns, which cover malicious insertion of hardware, software, firmware and system information.

21
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1200 While it is very difficult to avoid a targeted supply chain attack against a single organization or group of
1201 individuals, choosing validated devices and software and using a vetted system integrator can help to
1202 mitigate the risk of more broadly focused attacks. NIST’s Cryptographic Algorithm Validation Program
1203 (CAVP) “provides validation testing of [Federal Information Processing Standards] FIPS-approved and
1204 NIST-recommended cryptographic algorithms and their individual components” [13], while the NIST
1205 Cryptographic Module Validation Program (CMVP) validates cryptographic module implementations
1206 against the Security Requirements for Cryptographic Modules (FIPS 140-2) [17].

1207 The National Security Agency’s (NSA) National Information Assurance Partnership (NIAP) [7] is
1208 responsible for federal government implementation of the internationally recognized Common
1209 Criteria. Products certified through the Common Criteria program are evaluated for conformance with
1210 specific security protection profiles. NIAP’s product compliance list identifies evaluated products and
1211 may be searched by vendor, technology type, protection profiles and certifying country [8]. NSA’s
1212 Commercial Solutions for Classified Program (CSfC) [9][10] also “requires specific, selectable
1213 requirements to be included in the Common Criteria evaluation” and provides a list of software or
1214 hardware systems [34], including MDM and mobile platforms, that meet these more stringent
1215 requirements. In addition, CSfC provides a Trusted Integrator List [11], which identifies companies that
1216 have met its criteria for trustworthy systems integration capabilities. Organizations are encouraged to use
1217 lists of validated products and vetted system integrators to reduce the risk of acquiring devices or software
1218 with embedded vulnerabilities. In addition to these practices, devices and software manufacturers can also
1219 follow their respective industry recommended practices for secure software development to demonstrate
1220 they are meeting a set of requirements and have integrated them within their software development
1221 lifecycle. More information about secure software development can be found in the NIST Cybersecurity
1222 White Paper (DRAFT), Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software
1223 Development Framework (SSDF) [44].

1224 Threats Addressed: Exploitation of Underlying Vulnerabilities in Devices, Use of Untrusted Mobile
1225 Devices, Mobile Malware

1226 4.3.5 Use of a VPN

1227 VPN providers compete to provide different security functions in their products. System administrators
1228 understand what data is encrypted, what algorithms are used and how both ends are authenticating each
1229 other (if at all) by their selected VPN. VPNs may not encrypt all data, and organizations need to take time
1230 to fully understand what information is actually being protected. Additionally, the systems and
1231 geographic region that enterprise information is sent to are important to understand. Additional
1232 information for secure VPN implementation can be found in NIST SP 800-77 rev. 1 (Draft), Guide to
1233 IPsec VPNs [45] and NIST SP 800-113, Guide to SSL VPNs [46].

1234 An organization should base its mobile device security on the assumption that external networks between
1235 its mobile devices and its enterprise system, such as ISP and cellular networks, cannot be trusted. Risk
1236 from use of untrusted networks can be reduced by using strong encryption technologies such as a VPN to
1237 protect the confidentiality and integrity of communications as well as using mutual authentication
1238 mechanisms to verify the identities of both endpoints before transmitting data. Another possible
1239 mitigation is to prohibit use of unsecured WiFi networks, such as those running known vulnerable
1240 protocols.

1241 Threats Addressed: Wireless Eavesdropping

22
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1242 4.3.6 Rapid Adoption of Software Updates

1243 Developers are constantly improving their technology to provide better functionality, but also to fix
1244 software bugs and other errors. These technological improvements and security fixes are a key reason to
1245 upgrade a device’s software or firmware. It is important that a mobile device receives these updates,
1246 otherwise it will remain in a vulnerable state. Typically, these updates are not performed automatically,
1247 unless a device is configured to do so. Software updates are often developed and provided for the user to
1248 manually download and install on their device. Updates should be rapidly deployed, as the longer a
1249 mobile device is vulnerable to exploits, the longer enterprise information and all other information is
1250 vulnerable to compromise.

1251 EMMs can notify the user when OS and app updates are available. If the user does not make the
1252 appropriate updates, the administrator can enforce compliance actions. These actions include blocking or
1253 restricting access to enterprise information or the complete removal of enterprise information on the
1254 mobile device. If app management is enabled, EMMs can manually update apps and send them to mobile
1255 devices.

1256 When patching or updating the OS or an app, enterprise administrators should consider many of the same
1257 issues that arise in standard IT environments: the urgency of the update, the likelihood that an update will
1258 “break” mission-critical functionality for users, and the ability of the user, the mobile device, and affected
1259 systems to roll back failed patches. The urgency of an update is affected by the severity of the potential
1260 impact of a vulnerability’s exploitation (e.g., critical, important, moderate, low). For example, the
1261 Common Vulnerability Scoring System (CVSS) [19] [20] is a numerical scoring system used to
1262 communicate the severity of vulnerabilities. NIST uses the CVSS to score the vulnerabilities found in the
1263 NVD. Updates to mobile apps may interact poorly with existing enterprise infrastructure software or
1264 application software and cause a mobile app or even the entire device to become unusable.

1265 When choosing to take corrective actions and how “strong” such actions should be, the enterprise
1266 administrator should consider special factors that affect software deployment in the mobile computing
1267 environment. If users are traveling, “offline” for extended periods of time or connected only via low-
1268 bandwidth networks (e.g., cellular), updating software may be almost infeasible. To address these cases,
1269 administrators should develop mitigations in advance for unpatched mobile systems. For example,
1270 reducing permissions to sensitive enterprise assets can allow the mobile devices of traveling users to
1271 reconnect to the enterprise network and download the new software without undue risk to the enterprise.

1272 Best practices for mobile updates include pushing updates periodically (e.g., weekly) to acclimate users to
1273 regular patching and prevent apps from becoming excessively outdated. Administrators should identify a
1274 group of relatively tolerant users—for example, other system administrators—and push updates to these
1275 users before organization-wide patching of mobile devices. By using this approach, problems with
1276 updates may be discovered and addressed before they impact a larger number of users who are less
1277 tolerant of software problems.

1278 Threats Addressed: Exploitation of Underlying Vulnerabilities in Devices, Mobile Malware

1279
1280 4.3.7 OS & Application Isolation

1281 Using a secure container to isolate enterprise data is a commonplace strategy for preventing data
1282 compromise. As stated in Section 4.2.7, containers use a variety of underlying technology to separate
1283 enterprise and user data. Secure containers often act as an EMM’s device-side agent to obtain information
1284 about a device’s health, enforce enterprise policy and notify administrators of nonconformance. They also
1285 can be used to provide cryptographic confidentiality protection of data. Acting as the EMM agent, secure

23
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1286 containers may work in conjunction with the management APIs to perform their security and management
1287 functions.

1288 Administrators also can configure policy, receive notifications of policy violations, prevent data
1289 exfiltration and manage device health by embedding a security-focused SDK into an app residing on an
1290 employee device. Although this approach can be fruitful, it requires a certain level of expertise from the
1291 enterprise to develop the SDK. Another approach to isolation includes wrapping applications as
1292 mentioned in Section 4.2.6. All of these can work in concert to provide the desired degree of isolation.

1293 Enterprises may need to employ multiple isolation mechanisms within their mobile deployment. The
1294 exact combination necessary for a particular enterprise is a function of an enterprise’s unique security and
1295 operational requirements. Implementing all of the isolation mechanisms listed here may not be an
1296 appropriate response to the threats posed to an enterprise, and may also be too costly to implement. Yet
1297 enterprises should gain an understanding of what security benefits an isolation mechanism is actually
1298 providing, and what features are simply a byproduct of the underlying OS. In addition, organizations
1299 should ensure isolation mechanisms are activated and properly configured.

1300 Threats Addressed: Exploitation of Underlying Vulnerabilities in Devices, Mobile Malware

1301 4.3.8 Application Vetting

1302 MAV tools can be employed to identify vulnerabilities and malicious code in mobile applications. They
1303 can also integrate with many EMM and MTD systems. When an issue is discovered, an administrator can
1304 be properly informed and automatically deploy various EMM-provided remediation actions. These
1305 include notifying administrators, affected users and departments; automatically removing affected apps;
1306 disallowing access to enterprise resources; or performing other remediation actions available via the
1307 EMM. To achieve this automated operation, the EMM is integrated with MAV tools via APIs that
1308 coordinate the submission of mobile apps—one-off or in bulk—to the MAV service via the EMM
1309 dashboard. These APIs often are implemented using web services. For MAV services, EMM integration
1310 can enable a flexible conduit through which results from multiple MAV vendors can be received and
1311 aggregated at the EMM dashboard or portal without requiring all app vetting reports to conform to a
1312 single format.

1313 Threats Addressed: Installation of Malicious Developer MDM Profiles, Mobile Malware, User Privacy
1314 Violations

1315 4.3.9 Mobile Threat Defense

1316 MTD can operate as a standalone and isolated system that detects malicious applications and other
1317 threats. MTD systems can detect network-based attacks (e.g., MitM that could intercept and redirect or
1318 eavesdrop on communications), app-based attacks (e.g., information leakage or malicious, sideloaded
1319 apps), platform-based attacks (e.g., rootkits that undermine basic OS functions) and others. When coupled
1320 with an integrated EMM, these systems offer multiple remediation approaches following an attack
1321 attempt or data breach is detected or a device is compromised. Remediation for network-based attacks
1322 include disconnecting the device from the enterprise network, re-establishing a trustworthy connection or
1323 blocking attempts to connect to blacklisted networks.

1324 For app-based attacks, an integrated EMM and MTD system can remove malicious apps or modify app
1325 permissions to limit access to sensitive enterprise resources. In cases where an integrated EMM and MTD
1326 system detects a potential attack against the mobile platform, it might notify the user to apply an OS patch
1327 or—in the extreme—remotely wipe (i.e., factory reset) the device. Integrated EMM and MTD systems

24
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1328 typically are configured to alert the system administrator and potentially the mobile device user to the
1329 detected problem and the remediation approach initiated.

1330 Threats Addressed: Credential Theft via Phishing, Installation of Unauthorized Certificates

1331 4.3.10 User Education

1332 Security is everyone’s responsibility. The user cannot solely depend on the EMM and other third-party
1333 apps to secure their device and enterprise data. User awareness is important because the device user plays
1334 a vital role in securing the enterprise’s information. Understanding the importance of securing the device
1335 and how to contribute is important for both the user and the enterprise.

1336 Providing effective ways to teach users how to protect their mobile device is essential to understanding
1337 the importance of security mechanisms and how to apply them. Following are a few examples of mobile
1338 device security on which device users should be trained:

1339 • How to identify phishing attacks,

1340 • How to properly manage authentication credentials,
1341 • The organization’s privacy policy and the personal information collected,
1342 • How to identify malicious EMM profiles or other malicious applications, and
1343 • Why it is important to rapidly perform OS and application updates.
1344 If the device users are not educated on how to properly secure their mobile device, this oversight could
1345 endanger enterprise and user information. That’s why user education is essential for enabling users to do
1346 their part securing their mobile device—for themselves and the enterprise.

1347 Mobile device and EMM administrators also require the proper security training in addition to the users.
1348 The enterprise may want to identify the Workforce Categories and Specialty Areas from the
1349 National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework (SP 800-
1350 181) [47] that are of interest and applicable to the enterprise’s needs. Through identifying the Workforce
1351 needs, the enterprise will be able to understand the necessary knowledge, skills, and abilities for a mobile
1352 device/EMM administrator.

1353 Threats Addressed: Credential Theft via Phishing, Installation of Malicious Developer and EMM Profiles,
1354 Mobile Malware, Information Loss Due to Insecure Lockscreen, Data Loss via Synchronization,
1355 Exploitation of Vulnerabilities within the Underlying EMM Platform, Insider Threat

1356 4.3.11 Mobile Device Security Policies

1357 The development of security policies is vital to establishing a prominent security posture through well-
1358 defined procedures and governance. The purpose of security policies is to provide a clear course of action
1359 for organizations to follow when deploying new technologies and remediating issues or other
1360 occurrences. Mobile device security policies can be established by performing a threat modeling exercise
1361 or risk assessment to understand the attack landscape and plan according to an organization’s specific
1362 security needs.

1363 Mobile device security policies can define the device configurations required for each mobile device that
1364 accesses enterprise data. For example, a configuration policy may require user authentication before
1365 accessing the mobile device or the organization’s resources. Further, that policy may define the strength
1366 of the authentication mechanism or require multi-factor authentication. These types of policies inform the

25
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1367 system administrators of the policies to enforce on the mobile device and can in turn protect against an
1368 attacker gaining unauthorized access to enterprise resources.

1369 In the case of remediation, an organization should define policies to guide the necessary actions to
1370 perform in the case of an error or attack. An organization may develop a policy that requires a mobile
1371 device to be erased/wiped if it is lost or stolen. This policy will prevent anyone from retrieving
1372 unauthorized access to sensitive enterprise information. Additionally, if it is found that there is a breach
1373 due to implementation of a weak or outdated policy, an organization should have procedures for
1374 reviewing and updating policies as needed. Additional information about recommended mobile device
1375 security policies can be found in Appendix D.

1376 Threats Addressed: Device Loss and Theft, Credential Theft via Phishing, Accessing Enterprise
1377 Resources via a Misconfigured Device, Information Loss Due to Insecure Lockscreen, Shadow IT Usage,
1378 Insider Threat

1379 4.3.12 Notification and Revocation of Enterprise Access

1380 Every enterprise and organization should have security policies and rules that influence remediation
1381 actions when network attacks or breaches occur. These policies and rules also cover mobile devices.
1382 Remediation actions may span a spectrum of possibilities ranging from notifying affected individual users
1383 or groups of users, to revoking access to enterprise data and services, to wiping the data of the affected
1384 device(s) or restoring it/them to a default pristine state (e.g., factory reset).

1385 Notifying users of an issue is often the most basic and least aggressive remediation option. This is
1386 typically done via a push notification to the phone’s notification center or potentially an SMS to follow
1387 up. Temporary revocation of access to enterprise resources is often seen as the next step if the notification
1388 does not remediate the issue. This is most easily done via the EMM agent if one is installed on the
1389 employee device. The temporary revocation may last a predefined period of time—for example, 24
1390 hours—and access may be automatically restored or only restored manually by the enterprise’s systems
1391 administrators. Removing applications or wiping the mobile device are some of the more aggressive
1392 remediation options available to the enterprise. This more drastic action can be performed because an app
1393 on their mobile system was compromised or is malicious and is the source of attacks or leaks affecting the
1394 enterprise. But beware: wiping data not owned by the enterprise can cause legal issues.

1395 Threats Addressed: Device Loss and Theft, Accessing Enterprise Resources via a Misconfigured Device,
1396 Use of Untrusted Mobile Devices

1397 4.3.13 Additional Authentication for System Administrators

1398 System administrators who use the EMM console have access to sensitive information about the
1399 enterprise’s mobile devices. Individuals with EMM credentials can grant and revoke access to enterprise
1400 resources and collect private information about employees such as device location. Additionally, they
1401 may be able to wipe an entire device, not just the enterprise data. For this reason, EMM administrator
1402 credentials should conform to standard password strength and complexity rules listed in NIST SP 800-63-
1403 3 [4]. If supported by the EMM, multi-factor authentication also should be used. These additional layers
1404 of authentication for system administrators can help to thwart EMM credential theft.

1405 Threats Addressed: EMM Administrator Credential Theft

26
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1406 5. Enterprise Mobile Device Deployment Lifecycle

1407 There are many factors to consider when deploying mobile devices within an enterprise environment.
1408 These include selecting the correct management technologies and devices, alongside properly providing
1409 them to users. This section defines a process, as seen in Figure 3, for deploying devices and managing
1410 them throughout their operational lifecycle, known as the Enterprise Mobile Device Deployment
1411 Lifecycle. Each step of the process is described below along with necessary implementation details.
1412 Organizations may wish to document their decision-making process and implementation details into a
1413 mobile security policy.

1414 Alternative process models and frameworks exist, and enterprises should adopt or combine the ones that
1415 suit their needs while satisfying their requirements. One example is the Mobile Computing Decision
1416 Making Framework (MCDF), a four-stage framework that is used to determine if a mobile solution is
1417 necessary to support an enterprise’s overall mission. More information on the MCDF can be found in the
1418 CIO Council’s Mobile Computing Decision Making Framework [12].

1419

1420
1421 Figure 3 - Enterprise Mobile Device Deployment Lifecycle

1422
1423 5.1 Identify Mobile Requirements

1424 In this first stage of this Lifecycle, the organization decision-makers define the mission needs and
1425 requirements for mobile devices, inventory the mobile devices already in use, and identify the mobile
1426 deployment model that fits your organization. This is all in an effort to gather requirements for managing
1427 current and future mobile devices to meet mission needs for functionality, security and privacy.

27
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1428 Participation of both IT-focused and business-focused decision-makers is necessary in this stage to ensure
1429 that the needs of the mission will drive the technology choices in later stages.

1430 5.1.1 Explore Mobile Use Cases

1431 Many organizations find that mobile devices are essential to enable their staff to meet evolving mission
1432 requirements. Tasks that once might have been accomplished in the office (at a much slower pace) are
1433 now handled “in the field,” often while requiring access to enterprise data or apps and through interaction
1434 with colleagues from partner organizations. This need to meet challenging and fast-paced mission
1435 requirements should be weighed against the need to protect sensitive data, address privacy concerns,
1436 financial costs and other issues. Developing use cases specific to an organization’s needs for mobile
1437 devices can help to identify and clearly describe requirements. Common elements of use cases include
1438 understanding who your users are, why they need mobile devices, and what apps or device features will
1439 be necessary for them to meet their organizational objectives.

1440 For example, a disaster management organization may send staff members to sites affected by natural
1441 disasters, such as tornadoes, floods, and earthquakes, to provide assessments and assistance. Mobile
1442 devices are essential to reach back to enterprise data sources and to enable submission of information
1443 gathered on site. Staff also should share information with members of the public, local first responders,
1444 representatives of other local, state and federal organizations, as well as staff from various other non-
1445 governmental organizations (NGOs). In this use case example, the strong need for a mobile capability is
1446 clear, and backend systems may need to be restructured to enable appropriate security characteristics to
1447 support these interactions. The characteristics (e.g., durability will be important for rough worksites) and
1448 cost of the selected mobile devices should be considered carefully to ensure all staff have the necessary
1449 equipment and expensive devices are not too fragile for a rough worksite.

1450 5.1.2 Survey Current Inventory

1451 When modern mobile devices were first introduced to the enterprise, management platforms were less
1452 mature and likely had not been managed in a centralized manner. These sorts of practices may have
1453 continued over time. Therefore, an inventory of the mobile systems alongside other information systems
1454 within an organization’s network can be valuable when deploying a new mobile infrastructure. This can
1455 be performed by directly asking employees for the mobile devices they are using and performing network
1456 scans to understand the devices on a network. These two sources of information combined provide a
1457 picture of the devices that are actually being used and need to be protected and/or upgraded.

1458 Unidentified mobile devices may leave holes in the enterprise’s infrastructure. These devices may not
1459 acquire the necessary security configuration, which leaves the mobile user and the enterprise unprotected
1460 from vulnerabilities and exploits. Malware or unauthorized access to the enterprise’s network through the
1461 unidentified mobile device can leave the enterprise blind to attacks due to the lack of awareness of all
1462 mobile devices within their infrastructure. Identifying current inventory may be performed through an
1463 inventory management methodology. NIST and DHS produced NISTIR 8011, Automation Support for
1464 Security Control Assessments Volume 2: Hardware Asset Management [34], which provides operational
1465 guidance for automating and assessing the FISMA security controls with regards to hardware asset
1466 management.

1467 5.1.3 Choose Deployment Model

1468 Today, organizational leaders may choose from a variety of deployment models for the mobile devices to
1469 be used within the enterprise. A deployment model captures alternative options for device ownership, as
1470 well as policy and technological controls that manage device behavior. The spectrum of options ranges

28
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1471 from devices issued by (i.e., purchased or leased by) and fully managed by the enterprise to devices
1472 owned by individuals with little or no enterprise management of device interaction with enterprise
1473 systems. The following sections describe three of the most commonly used categories of options in the
1474 spectrum. NIST SP 800-114 Rev. 1, User's Guide to Telework and Bring Your Own Device (BYOD)
1475 Security identifies some similar categories in the context of devices used for teleworking [35].

1476 5.1.3.1 Strict Enterprise Usage

1477 Strictly enterprise-enabled mobile devices and the information on those devices are issued by the
1478 organization. Users should be made aware that all data on the device are owned by the organization.
1479 Within the federal government, this deployment model is sometimes known as Government Furnished
1480 Equipment (GFE). This section covers enterprise-enabled mobile devices that are provided to employees
1481 for (strictly) enterprise use only. GFE devices strictly limit personal use; employees typically own and
1482 carry a separate personal device.

1483 Enterprise-enabled mobile devices provide significant security benefits. Organizational leaders may
1484 consider the supply chain of candidate devices before selecting devices for purchase, and IT system
1485 administrators may develop device hardening plans before the products arrive. At deployment time, the IT
1486 staff may configure restrictive policy settings to significantly alter the functionality of the device such as
1487 removing text messaging functionality, restricting WiFi and Bluetooth access, and ensuring that
1488 communication takes place over a VPN. In the enterprise-enabled model of device deployment, tradeoffs
1489 between security and functional usability can be made entirely at the discretion of organizational leaders.

1490 An example for an only enterprise-enabled deployment includes a GFE that is provisioned to the end user
1491 as a fully managed or supervised device. Mobile security technologies include enrollment of the device
1492 into an MDM with the use of mobile threat defense for endpoint protection, and access to enterprise
1493 resources through web-based interfaces or mobile applications. A whitelisting approach is implemented
1494 for enterprise-enabled deployments; all mobile apps on the device will be examined through a mobile app
1495 vetting service before the apps are provisioned to the device or allowed to be downloaded from the
1496 managed enterprise appstore [2]. Access to the official public appstores or unofficial appstores is
1497 restricted in this deployment model.

1498 Device ownership status: Organization

1499 5.1.3.2 Corporate Owned Personally Enabled (COPE)

1500 COPE devices are issued by the enterprise to employees. The COPE model is less restrictive on employee
1501 personal use. While the enterprise owns (or leases) the device and enforces usage restrictions, these
1502 restrictions are more lenient, allowing employees some personal use of the device. For example, an
1503 employee may be permitted to download certain apps or receive personal text messages on the COPE
1504 device. Although a COPE device is personally enabled, the device and information on the device belongs
1505 to the enterprise. Employees should be informed about enterprise restrictions and have appropriate
1506 expectations of software and device configurations that affect functionality and privacy.
1507
1508 An example of the COPE deployment model includes a managed GFE device. This may include a fully
1509 supervised device or a separate enrollment to manage the device by downloading an EMM application
1510 from the official appstore. A blacklisting approach is implemented for many COPE deployments. All
1511 mobile apps on the device should go through a mobile app vetting service; apps downloaded to the device
1512 are vetted during or after installation by the app vetting service and checked and maintained against an
1513 application blacklist. For COPE, personal applications are allowed on the GFE device and the end user is
1514 able to access the official public appstores.

29
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1515 Device ownership status: Organization

1516 5.1.3.3 BYOD and Choose Your Own Device (CYOD)

1517 The BYOD deployment model allows employees to use their personally owned mobile devices to access
1518 enterprise data and services. The employee may, for example, access both personal email and sensitive
1519 enterprise email via the same application. The BYOD model raises concerns regarding leakage of
1520 sensitive enterprise information via the device to untrustworthy third-party backend systems that
1521 communicate with various apps on the device. To protect the confidentiality and integrity of enterprise
1522 data and systems as well as the privacy of the device user/owner, IT staff may use a tool such as an EMM
1523 to enforce DLP by applying restrictions such as disabling the copy/paste feature when in enterprise
1524 applications. Also, an enterprise may use MTD technology to ensure the device is protected from mobile
1525 threats and attempts to compromise the device.

1526 A Choose Your Own Device (CYOD) device is purchased by an employee for personal use. In the CYOD
1527 model, the enterprise provides employees a list of devices (e.g., the Commercial Solutions for Classified
1528 Component list) that are acceptable for interaction with enterprise networks and software. If the
1529 employee’s personal device is on the approved list, and the employee installs software required by the
1530 enterprise, then the employee may use that device to access the enterprise’s data and services. Employees
1531 with personal devices that are not on the approved list must often carry a second (enterprise-enabled)
1532 device for work-related activities, so choosing from the approved list allows a user to avoid carrying an
1533 additional device.

1534 Another concern with BYOD and CYOD devices is lack of supply-chain management. The enterprise has
1535 little-to-no knowledge of the device’s origination or if it has been modified. A BYOD/CYOD device may
1536 be rooted or jailbroken with installed untrusted apps. The device may be infected with malware without
1537 the user’s knowledge. The lack of a baseline leaves the enterprise at a disadvantage when it allows a user
1538 to access enterprise data via their device.

1539 For the organization, CYOD offers the opportunity to limit the hardware supply chain risk and to control
1540 access to enterprise data and backend systems through enterprise protection software (e.g., an EMM or
1541 MTD agent). The advantage of CYOD over BYOD is that employees are informed in advance of the
1542 devices which are capable of running the necessary enterprise protection software and, thus, will be
1543 permitted to access enterprise resources. When IT staff members decline to allow a BYOD device
1544 because it is unable to run an enterprise EMM agent, then BYOD equals CYOD, but with the appearance
1545 of IT management inconsistency and capricious application of unstated policies.

1546 Device ownership status: Employee

1547 5.1.4 Select Devices

1548 Organizational mission and constraints such as cost and deployment models are considered in the
1549 selection of mobile devices [18]. That is why an approach for assessing an organization’s mission needs
1550 for mobile solutions is needed. It recommends that “for each candidate mission, the organization must
1551 determine who needs mobile access, to what data, why and where.” For example, many organizations find
1552 that providing access to email through mobile devices allows a majority of employees to work more
1553 efficiently by enabling communication on time-critical issues. However, mobile access to specialized data
1554 and apps may be essential to only a few key employees. Understanding the impact of mobile devices on
1555 mission needs can help an organization to focus its selection process by narrowing it to a small set of
1556 candidate devices that satisfy the organization’s requirements.

30
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1557 Costs and security concerns related to mobile devices impact the purchasing decisions of many
1558 organizations. Costs can be minimized by limiting deployment of devices only to users who need them to
1559 support an organization’s mission and by selecting devices with only the necessary capabilities (e.g.,
1560 choosing a previous model rather than the “latest model”). For security, it is important to select device
1561 models that are current enough to be well supported by the manufacturer and can accommodate OS and
1562 application updates and patches.

1563 5.1.5 Determine EMM Capabilities

1564 Identifying the EMM capabilities required to work effectively within an enterprise is an important activity
1565 to perform before acquiring an EMM. This step requires organizational leaders to use the information
1566 gathered in the previous sections to define the capability requirements for their EMM solution. For
1567 example, the EMM must support the devices selected to meet the mission needs and, potentially, existing
1568 devices in the current inventory. Other commonly required EMM capabilities are options for integrating
1569 the EMM infrastructure into the enterprise’s infrastructure. These options include “on prem” operations
1570 (i.e., running on servers hosted on premises, within the enterprise datacenter), support for a Software as a
1571 Service (SaaS) model, or product certifications/accreditations and third-party service integrations. Section
1572 4.2 discusses many other important capabilities for EMMs and other enterprise technologies designed to
1573 support mobile computing for the enterprise. The list of required EMM capabilities will support the well-
1574 reasoned selection of an EMM for the enterprise, ensuring that it provides the necessary functional and
1575 security capabilities.
1576

1577 5.2 Perform Risk Assessment

1578 Risk assessments are a foundational component of cybersecurity. The risk-assessment process can be used
1579 to identify, estimate and prioritize risk to organizational operations and assets, staff and other
1580 organizations that result from the operation and use of information systems. Risk assessments should be
1581 performed periodically, as the threat landscape is constantly changing and the systems to be protected are
1582 evolving. Section 5.6 addresses the topic of periodic security audits, which assess the effectiveness of
1583 controls for protecting the enterprise. Periodic risk assessments should inform security audits.

1584 Risk assessments can be conducted at the organization level, mission level, and information-system level.
1585 This guidance recommends that mobile devices, mobile apps and any systems used to manage the mobile
1586 system be included as part of the risk-assessment process. The risk assessment may have mobile devices
1587 included under a larger risk assessment umbrella, or may be conducted against a specific mobile device
1588 deployment. A variety of risk assessment methodologies exist, such as mobile-agnostic guidance (NIST
1589 SP 800-30 Revision 1, Guide for Conducting Risk Assessments), and mobile-specific guidance (Mobile
1590 Computer Decision Framework) [14]. Another example of mobile-specific guidance also exists for
1591 performing risk assessments such as NISTIR 8144 (DRAFT), Assessing Threats to Mobile Devices &
1592 Infrastructure: The Mobile Threat Catalogue [5][6] used in conjunction with a threat modeling process
1593 such as draft NIST SP 800-154, Guide to Data-Centric System Threat Modeling [48], and the MITRE
1594 Mobile ATT&CK Framework [15]. Organizations that fail to conduct risk assessments may inadvertently
1595 select and apply incorrect security controls or spend precious resources addressing risks that are unlikely
1596 to occur. Enterprises are encouraged to revisit their identified requirements once a risk assessment has
1597 been performed in order to update the list of requirements based on information identified within the risk
1598 assessment.

31
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1599 5.3 Implement Enterprise Mobility Strategy

1600 Resource availability, mission needs, and various other organization constraints will guide decisions on
1601 mobile deployment options, devices, and EMM systems. Some organizations must have full control of all
1602 components in the enterprise environment, so all mobile equipment must be purchased by the
1603 organization and managed by enterprise system administrators through an EMM. Other organizations
1604 allow employees to bring their own devices (possibly from an approved list) and may manage a few
1605 enterprise applications through a MAM system. By focusing on the enterprise requirements, decision
1606 makers can narrow the range of appropriate deployment options.

1607 5.3.1 Select & Install Mobile Technology

1608 The list of mobile technology requirements previously identified should be compared against those of the
1609 EMMs under consideration. There may not be a perfect match with a complete overlap of requirements
1610 and capabilities, especially when EMM selection must be made from a predetermined list owned by an
1611 external organization. Once an EMM selection is made, the EMM should be appropriately implemented
1612 inside of the enterprise network boundary. This includes proper product configuration, which is another
1613 important step in securing enterprise mobile infrastructure. A misconfigured EMM can lead to data leaks
1614 of confidential and proprietary enterprise information which may include self-developed internal mobile
1615 apps, personnel employee data, and data that could include trade secrets.

1616 EMM technology can be set up in different ways within the enterprise, and different architectures are
1617 possible. The two primary methods focus on the location of the EMM and associated technology. These
1618 methods are on-premise and cloud-based, sometimes referred to as the Software-as-a-Service (SaaS)
1619 model. These are described below.
1620
1621 5.3.1.1 On-Premise Architecture

1622 On-premise (i.e., on-prem) instances of the EMM technology are less common. Organizations install and
1623 configure the EMM themselves, and also pay for any software licenses for any underlying platforms or
1624 components. Some EMM vendors offer images and containers that can help ease the burden of
1625 installation and configuration. Organizations are encouraged to double-check the images or containers for
1626 commonplace software vulnerabilities. The primary benefit of this model is that enterprise data resides
1627 within the organization, other than the allowed devices that can query and receive information they are
1628 authorized to obtain. Enterprises can monitor this traffic alongside all of the authentication from the EMM
1629 to other devices. Finally, physical security of the EMM can be ensured for this model.

1630 Below is a sample architecture demonstrating an on-prem implementation of the mobile security
1631 technologies. MTD applications are sometimes cloud-based, even if the organization’s management
1632 technology is on-prem. Figure 4 shows the MTD as part of the cloud, although real-world deployments
1633 may significantly differ. The EMM components are hosted via on-prem servers owned and managed by
1634 the enterprise. This architecture requires considerable installation and maintenance of the technologies by
1635 the enterprise, but also provides the enterprise with more control over how the enterprise data is
1636 transmitted and managed.

1637

32
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1638
1639
1640 Figure 4 - On-Premise Mobile Architecture

1641 5.3.1.2 Cloud Architecture

1642 The cloud solution is an alternative to the on-prem architecture that allows mobile security technologies
1643 to be hosted external from the local enterprise network. When using the cloud solution, the mobile
1644 security technology provider gives the enterprise the ability to use its applications, which are run on a
1645 cloud infrastructure. This is also known as SaaS, and mobile security and management services are
1646 delivered via the internet to the enterprise [24].

1647 Cloud-based EMM deployments are often easier to set up and begin using. They involve signing up for a
1648 web-based service, and users are quickly taken to the primary dashboard after payment is provided. The
1649 most difficult aspects of setup are joining the EMM to an Active Directory service and proving that the
1650 email domain being used actually belongs to the company. The EMM vendor often provides unique
1651 information that must be placed into DNS, and then can be externally checked. Another benefit of the
1652 SaaS model is that problems or issues can be more easily addressed by the vendor, since they have access
1653 to the EMM instance and underlying platform. Finally, with this model the enterprise data resides outside
1654 the traditional enterprise, much like the mobile devices the EMMs manage. This is oftentimes a key factor
1655 in organizations deciding not to use this model. Below is a sample architecture demonstrating a cloud-
1656 based mobile enterprise architecture (e.g., MDM server, app vetting server).

33
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1657
1658 Figure 5 - Cloud-Based Mobile Architecture

1659

1660 5.3.2 Integration of EMM into the Enterprise Service Infrastructure

1661 Both large and small enterprises may connect their EMM system to existing enterprise infrastructure
1662 services to improve security management of mobile devices. Such services support authentication,
1663 identification and access control to enterprise networks and resources. Remote Authentication Dial-In
1664 User Service (RADIUS) is a standard network authentication service protocol, providing authentication of
1665 access credentials followed by policy-based network resource assignments (e.g., Internet Protocol [IP]
1666 address, permitted network connection time). Directory services such as Microsoft’s Active Directory
1667 map network resources (e.g., volumes, printers, users, devices) to network addresses. Enterprise systems
1668 use the Lightweight Directory Access Protocol (LDAP) to communicate with directory services. Another
1669 set of services enables remote connectivity via a VPN to enterprise systems.

1670 By integrating an EMM with enterprise backend infrastructure services such as RADIUS or directory
1671 services, an organization can enable finer-grained management of mobile device access to mission-critical
1672 enterprise resources. System administrators can set policy-based configurations for mobile devices to
1673 constrain access to sensitive resources, depending on mobile device conditions (e.g., connection from a
1674 public WiFi network or user-managed device running a corporate application). When enterprises deploy
1675 an EMM without integrating it with their backend security infrastructure, mobile device connections to
1676 the enterprise network may be managed via global passphrases for connection to the enterprise WiFi
1677 network. Mobile devices with WiFi network access can then reach any of the services on the enterprise

34
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1678 network, meaning that when a device is connected to the WiFi network, it can access everything on the
1679 typical enterprise network.

1680 5.3.3 Set Policy, Device Configuration and Provision

1681 In certain deployment models, mobile devices should be properly set up before they can be provided to
1682 enterprise users. IT-focused and business-focused decision-makers should work together to define a
1683 mobile device usage policy acceptable for these devices. The usage policy should address the standard
1684 security protections to be applied to all enterprise mobile devices, as well as specifying the permissions
1685 and special configurations that apply to users with different organizational roles. Devices can then be
1686 properly configured and provisioned to enforce the chosen policy. For organizations with a less stringent
1687 stance on device usage, such as BYOD, users should be made aware of the mobile device usage policy
1688 and signal their acknowledgement of the policy.
1689
1690 5.3.3.1 Define EMM Policy

1691 An EMM policy is a set of rules that defines what a user is allowed (or not allowed) to do on their mobile
1692 device and the mobile device configuration requirements. EMM policies are put in place to assist in
1693 securing the enterprise data within the mobile device. To do so, the enterprise must understand the type of
1694 data the user handles (e.g., sensitive data), the risk factors and the proper way to protect that data from
1695 accidental or intentional threats. Upon understanding these key factors, the enterprise then documents the
1696 EMM policy and applies the policy configurations within the EMM.

1697 These policies may vary per user or device since a particular user group or role within the enterprise may
1698 have different permissions to adequately perform its duties. If the EMM policy is not well defined, the
1699 user permissions may not accurately reflect the policy requirements and a user may be given too much or
1700 too little access to enterprise data. This could negatively impact an employee’s ability to accomplish their
1701 work or allow the employee unauthorized access to enterprise information. Some examples of elements to
1702 include within an EMM policy include password requirements, device encryption, VPN requirements and
1703 geo-fencing.

1704 5.3.3.2 Consider Personal Account Usage

1705 One of the primary means of communication within an enterprise is email. While most businesses provide
1706 work email accounts to their employees, others might allow an employee to use a personal email account
1707 to handle business communication. Email may be used for general communication between employees,
1708 account establishment, password initiation/reset, the sharing of sensitive information, and enterprise
1709 alerts/notifications.
1710
1711 Using personal email accounts leaves the enterprise without security control over the personal email
1712 accounts. Similar issues also arise with other cloud-based services, e.g., cloud-based storage and sharing
1713 of documents. Without this control, sensitive enterprise information could be transferred to unauthorized
1714 recipients, the enterprise cannot control or have knowledge of what servers its emails are transmitted
1715 through, and it cannot apply enterprise-level security protection of its emails. Another concern is litigation
1716 against the enterprise; the inability to backup or archive personal email accounts could make it difficult
1717 for an enterprise to respond to a demand for discovery or a Freedom of Information Act (FOIA) request.
1718 If an employee resigns or is terminated, the enterprise is unable to remove that person’s access to
1719 enterprise emails that were sent to their personal email address. This security gap could allow a former
1720 employee to retain access to sensitive enterprise data.
1721

35
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1722 Enterprise email is the prime option for establishing account access for individuals because—as
1723 mentioned above—enterprise email addresses give an enterprise optimum control over its data. Access-
1724 control policies and privileges can be provisioned to a specified enterprise email account, which coincides
1725 with the employee who uses the email address. Personal email addresses can be used in a similar fashion,
1726 but enterprises are left with less control of information sent to them. Finally, shared emails—enterprise or
1727 personal—make it difficult to manage account access. Each employee on the shared account is given the
1728 same access privileges and has the ability to repudiate responsibility because there is no way of
1729 monitoring individual access. Multiple users having access to a single account eliminates the ability to
1730 apply least privilege and separation of duties.

1731 5.3.3.3 Device Configuration

1732 Device configuration is the system configuration of a mobile device before it is provisioned to the user.
1733 The system configuration may include updating the OS to the most recent release, establishing password
1734 length requirements and/or enabling device encryption. How devices are configured depends on the
1735 device deployment model used by the enterprise.

1736 The device configuration process for enterprise-issued and BYOD devices is different because of how
1737 devices are ultimately provided to users. Enterprise-issued devices can be preconfigured in-house, or the
1738 enterprise can have a mobile device vendor preconfigure the devices prior to shipping them to the users,
1739 such as Apple’s Device Enrollment Program (DEP). In the case of BYOD devices, it is required that the
1740 enterprise requests the device owner bring their device into the enterprise to be properly configured for
1741 enterprise access.

1742 The requirements for device configuration may vary per enterprise. An enterprise may reference
1743 suggested secure mobile-device configuration guidance from established entities. The Defense
1744 Information Systems Agency (DISA) provides Security Technical Implementation Guides (STIGs) that
1745 dictate detailed configuration standards for the Department of Defense (DOD). The Center for Internet
1746 Security (CIS) offers the CIS benchmarks, which are “best-practice security configuration guides both
1747 developed and accepted by government, business, industry and academia” [36][37]. NIST hosts the
1748 National Checklist Program (NCP) [40], which supplies checklists for securely configuring specific types
1749 of technology. Device manufacturers may also provide suggested configurations for their mobile
1750 products.

1751 5.3.3.4 Device Provisioning

1752 Device provisioning enrolls a device into the EMM by installing an EMM certificate onto each device
1753 that provides privileged device access to enterprises alongside in-depth security features. Provisioning a
1754 mobile device requires your device to have the necessary certificate to be enrolled in an EMM service.
1755 This certificate is installed on a device and allows the EMM to verify the device can be provisioned. Once
1756 the device is provisioned to the EMM, the appropriate EMM policies are applied to the mobile device
1757 and, if the device configuration is not automatically updated, the device will need to be configured to
1758 meet the policy requirements. After the provisioning process is complete, the device user has access to
1759 enterprise data (e.g., email, calendar, contacts) and the enterprise is able to monitor the device and ensure
1760 it is compliant to their enterprise policies.

1761 Devices may be provisioned in-person or remotely. In-person provisioning requires an administrator to
1762 physically have the device to install the EMM certificate and confirm the device is properly provisioned.
1763 Remote provisioning requires the device user to implement the provisioning process on their own. The
1764 user may not provision the device properly, which may render the device and enterprise data vulnerable
1765 because it may not be compliant to enterprise policies.

36
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1766 5.3.4 Verification Testing

1767 To protect the operational enterprise environment, as well as enterprise and user data, it is important to
1768 verify the device configurations and software installed on mobile devices that connect with the enterprise.
1769 Before deploying an app, a software update, or a patch throughout the enterprise, enterprise
1770 administrators may run pre-deployment tests to provide insight into how the change may impact the
1771 security or functionality of existing enterprise systems. For significant software deployments or major
1772 updates, administrators may want to first deploy to a limited group of users to enable assessment of the
1773 impact to the production environment.

1774 Allowing mobile devices to access enterprise resources can better enable staff members to execute the
1775 enterprise mission. However, mobile devices also carry security risks for enterprise systems, data and
1776 users. Verifying that mobile devices and their applications have acceptable configurations is essential to
1777 ensure that the benefits of mobile access outweigh the security risks that they present to the enterprise
1778 ecosystem.

1779 Mobile device or app-level configurations can significantly impact the security posture of the enterprise,
1780 thus permissions for the device or individual apps may be granted depending on specific configuration
1781 settings. Network configurations may include an obligation to authenticate and use a VPN before
1782 permitting connection to an enterprise wireless network. A geofencing policy may specify that a device
1783 operating within a particular geographic region be granted different permissions than the same device
1784 used within a different region. Different users, devices or apps may be granted different permissions for
1785 accessing enterprise backend services (e.g., a database holding sensitive information), depending on the
1786 app or device configurations. In many cases, mobile device security features are configured to better
1787 protect the enterprise in addition to the mobile device itself: device data encryption, screen lock timeout,
1788 password and application firewall requirements are configurable and contribute to the security posture of
1789 the enterprise. Finally, enterprise policy may restrict the apps that may be installed on the device, require
1790 updates to apps or the mobile OS, or limit access to some of the device features in order to protect
1791 enterprise systems or data.

1792 5.3.5 Deployment Testing

1793 Enterprise networks and applications require software updates to improve functionality, patch
1794 vulnerabilities, fix bugs, or enable new hardware deployment. To make sound enterprise deployment
1795 decisions, systems and network administrators may first perform deployment testing before pushing new
1796 software into the production environment.
1797
1798 Administrators consider a broad spectrum of test scenarios to evaluate a software update, deciding what
1799 tests will be sufficient to indicate that the update is ready for the production environment. A phased
1800 approach to component level, feature, network, and enterprise-wide testing is typically recommended for
1801 deployment testing.
1802
1803 For example, when introducing a new enterprise capability such as managed mobile devices or mobile
1804 application vetting, the administrator should consider rolling out a limited trial with only a small set of
1805 carefully chosen users. After the trial deployment has been operating satisfactorily for a predetermined
1806 period of time, and if the user experience and satisfaction has met its target level, the organization may
1807 then be ready for an enterprise-wide deployment. Following this approach not only ensures minimal
1808 disruption to the enterprise operation and a satisfactory user experience, but also facilitates the discovery
1809 of security issues as early as possible in the deployment process.

37
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1810 5.4 Operate & Maintain

1811 It is necessary to design and implement security controls to protect enterprise systems, as well as
1812 enterprise and user data. However, initial deployment of controls is not sufficient to protect an operational
1813 enterprise. In addition, IT audits should be used to periodically evaluate the effectiveness of security
1814 controls for protecting the evolving enterprise, identify security issues, and modify or add controls to
1815 better protect the system in the future. Auditors need data to perform those evaluations, and mobile device
1816 usage logs provide important data for assessing the effectiveness of controls on the mobile computing
1817 environment.

1818 5.4.1 Auditing

1819 In order to keep up with a rapidly changing attack surface and cybersecurity landscape, the enterprise
1820 security team may practice and conduct security assessments. An essential component of such
1821 assessments is the periodic audit of the enterprise IT and mobile networking infrastructure. A
1822 comprehensive audit should cover the following:

1823 • Enumerating the enterprise audit objectives,

1824 • Establishing a security baseline through periodic (e.g., annual) audits,

1825 • Relying on auditors with well-established (and verified) security assessment experience,

1826 • Developing an automated audit process to cover all of the enterprise IT infrastructure, including
1827 mobile devices,

1828 • Analyzing the data generated by the audit process, rather than relying on compliance checklists,
1829 and

1830 • Using a third-party auditor to report risks facing the enterprise.

1831 Periodic audits should include the enterprise mobile infrastructure and device management systems,
1832 including components such as EMM/MDM, services for mobile app vetting, integration with backend
1833 services, and the employees’ mobile devices and their applications. The audit should help the enterprise
1834 security team to assess whether the benefits of mobile access outweigh the security risks that they present
1835 to the enterprise ecosystem.

1836 5.4.2 Device Usage

1837 An organization should develop security and privacy policies for mobile device (and app) usage. A key
1838 element of that policy is enterprise monitoring of device/app usage. EMM, MAM and many mobile
1839 network monitoring systems enable enterprise administrators to track or monitor many mobile user
1840 activities, including identification of all device apps, app usage patterns (e.g., downloads, when/how often
1841 an app is launched), device features used by each app (e.g., microphone, camera), data used by an app
1842 (e.g., user location, contacts), device/user geographical location, and phone calls (e.g., phone number,
1843 name, time duration, date, location). An appropriate monitoring policy for devices/apps should consider
1844 many factors, including organization mission (and how the mobile device/app supports that mission),
1845 security/privacy characteristics of the enterprise data and systems accessed via the device, user
1846 relationship to the enterprise (e.g., employee, contractor, employee of a partner organization, members of
1847 the general public), deployment model (e.g., enterprise owned, BYOD), and user privacy. A monitoring
1848 policy that is appropriate for enterprise-owned devices carried by employees in a very high-sensitivity

38
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1849 environment might include location tracking the device/user and geo-fencing the use of certain
1850 applications. Such a policy would be unacceptable (and likely infeasible to implement) for individually
1851 owned devices of employees of a partner organization who are visiting the enterprise site.
1852
1853 User privacy is an important consideration because most devices will contain some personal user
1854 information, and certain types of monitoring (e.g., geolocation) may bring enterprise interests into conflict
1855 with privacy regulations. Organizations that do business within the European Union (EU) also should
1856 consider how the EU’s privacy and data protection regulation—the General Data Protection Regulation
1857 [30]—constrains mobile device/app usage monitoring.
1858
1859 5.5 Dispose of and/or Reuse Device

1860 Mobile devices may hold sensitive information such as passwords, account numbers, emails, voicemails,
1861 text message logs or mission-specific data such as law enforcement sensitive information. When a mobile
1862 device must be disposed of, it is important to take the proper steps to ensure that sensitive information
1863 does not fall into the wrong hands.

1864 While techniques such as degaussing, memory overwriting or even physical grinding can be used to
1865 sanitize magnetic media, these techniques are not effective for sanitizing the solid-state memory used in
1866 mobile devices. However, most mobile devices now store user data on Self-Encrypting Drives (SEDs),
1867 which provide “always-on” encryption. Mobile OSs leverage the encryption inherent in the SED to
1868 provide “hard reset” or “factory reset” functionality to clear nearly all information from the device’s
1869 memory using a “cryptographic erase” technique [16]. Cryptographic erase is accomplished by sanitizing
1870 the encryption key for the drive, rendering the encrypted user data unreadable. Some devices offer a
1871 choice to encrypt all user data when the device is initialized. It is essential to activate whole-device
1872 encryption before a device is deployed and to perform a “factory reset” operation to cryptographically
1873 erase all user data before disposing of a device.

1874 There are two additional considerations for secure device disposal: assured destruction of the drive
1875 encryption key and destruction of user data on removable memory cards (e.g., SIM or Secure Digital [SD]
1876 cards). If the device encryption key is backed up or escrowed outside the device, it is possible that the key
1877 could be used to recover user data on the device. The organization should address the existence and
1878 location of such backups when designing device sanitization procedures.

1879 In addition to storing information such as photos and downloaded documents on the device’s internal
1880 memory, many mobile devices store such information on an external SD card. Contacts, voicemails and
1881 text message logs may be stored on a SIM card as well as in the device’s internal memory. A factory reset
1882 will not clear the information contained on SIM or SD cards used with the device. To remove all
1883 information from these cards they should be physically removed and destroyed. A thorough device
1884 disposal process includes both a factory reset and removal of any associated cards.

1885

39
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1886 References

1887 The lists below provide examples of resources that may be helpful in better understanding mobile device
1888 security.

[1] Joint Task Force Transformation Initiative (2014) Assessing Security and Privacy Controls
in Federal Information Systems and Organizations: Building Effective Assessment Plans.
(National Institute of Standards and Technology, Gaithersburg, MD), NIST Special
Publication (SP) 800-53A, Rev. 4, Includes updates as of January 22, 2015.
https://doi.org/10.6028/NIST.SP.800-53r4

[2] Ogata MA, Franklin JM, Voas JM, Sritapan V, Quirolgico S (2019) Vetting the Security of
Mobile Applications. (National Institute of Standards and Technology, Gaithersburg, MD),
NIST Special Publication (SP) 800-163, Rev. 1. https://doi.org/10.6028/NIST.SP.800-
163r1
[3] Cichonski JA, Franklin JM, Bartock MJ (2016) Guide to LTE Security. (National Institute
of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-187.
https://doi.org/10.6028/NIST.SP.800-187

[4] Grassi PA, Garcia ME, Fenton JL (2017) Digital Identity Guidelines. (National Institute of
Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-63-3,
Includes updates as of March 02, 2020. https://doi.org/10.6028/NIST.SP.800-63-3

[5] National Institute of Standards and Technology (2019), Mobile Threat Catalogue,
Available at https://pages.nist.gov/mobile-threat-catalogue/
[6] Franklin JM, Brown CJ, Dog SE, McNab N, Voss-Northrop S, Peck M, Stidham B (2016)
Assessing Threats to Mobile Devices & Infrastructure: The Mobile Threat Catalogue.
(National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or
Internal Report (IR) 8144.
https://csrc.nist.gov/csrc/media/publications/nistir/8144/draft/documents/nistir8144_draft.p
df
[7] U.S. National Information Assurance Partnership (NIAP) (2019) Available at
https://www.niap-ccevs.org

[8] U.S. National Information Assurance Partnership’s (NIAP) (2019) Product Compliant List.
Available at https://www.niap-ccevs.org/Product/

[9] U.S. National Security Agency’s (NSA) (2019) Commercial Solutions for Classified
Program (CSfC). Available at https://www.nsa.gov/resources/everyone/csfc/
[10] U.S. National Security Agency’s (NSA) (2019) Commercial Solutions for Classified
Program (CSfC) Components List. Available at
https://www.nsa.gov/resources/everyone/csfc/components-list
[11] U.S. National Security Agency’s (NSA) (2019) Commercial Solutions for Classified
Program (CSfC) Trusted Integrator List. Available at
https://www.nsa.gov/resources/everyone/csfc/trusted-integrator-list.shtml
[12] Federal CIO Council, Mobile Computing Decision Framework, May 23, 2013.

40
NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

[13] U.S. National Institute of Standards and Technology (2019) Cryptographic Algorithm
Validation Program (CAVP). Available at
https://csrc.nist.gov/projects/cryptographic-module-validation-program

[14] Joint Task Force Transformation Initiative (2012) Guide for Conducting Risk Assessments.
(National Institute of Standards and Technology, Gaithersburg, MD), NIST Special
Publication (SP) 800-30, Rev. 1. https://doi.org/10.6028/NIST.SP.800-30r1

[15] The MITRE Corporation (2019) Adversarial Tactics, Techniques & Common Knowledge
Mobile Profile (ATT&CK). Available at
https://attack.mitre.org/mobile/index.php/Main_Page

[16] Kissel RL, Regenscheid AR, Scholl MA, Stine KM (2014) Guidelines for Media
Sanitization. (National Institute of Standards and Technology, Gaithersburg, MD), NIST
Special Publication (SP) 800-88, Rev. 1. https://doi.org/10.6028/NIST.SP.800-88r1

[17] U.S. National Institute of Standards and Technology (2019) Cryptographic Module
Validation Program (CMVP). Available at https://csrc.nist.gov/projects/cryptographic-
module-validation-program

[18] Miller JF, (2013) Supply Chain Attack Framework and Attack Patterns MITRE Technical
Report MTR140021. Available at
https://www.mitre.org/sites/default/files/publications/supply-chain-attack-framework-14-
0228.pdf

[19] First.Org, Inc. (2019) Common Vulnerability Scoring System SIG. Available at
https://www.first.org/cvss/

[20] National Institute of Standards and Technology (2019) National Vulnerability Database:
Vulnerability Metrics, (National Institute of Standards and Technology Gaithersburg, MD).
Available at https://nvd.nist.gov/vuln-metrics/cvss
[21] Apple (2018) iOS Security Guide. Available at
https://www.apple.com/business/docs/iOS_Security_Guide.pdf

[22] Android 2016 Android Security White Paper. Available at

https://source.android.com/security/reports/Google_Android_Security_2018_Report_Final.
pdf

[23] Department of Homeland Security (2017) Study on Mobile Device Security. (Washington,
DC). Available at
https://www.dhs.gov/sites/default/files/publications/DHS%20Study%20on%20Mobile%20
Device%20Security%20-%20April%202017-FINAL.pdf
[24] Franklin JM, Bowler K, Brown CJ, Dog SE, Edwards S, McNab N, Steele M (2019)
Mobile Device Security: Cloud and Hybrid Builds. (National Institute of Standards and
Technology, Gaithersburg, MD), NIST Special Publication (SP) 1800-4.
https://doi.org/10.6028/NIST.SP.1800-4

[25] Lookout (2015) Stagefright Detector: Lookout’s app tells you if your Android device is
vulnerable. Available at https://blog.lookout.com/stagefright-detector

41
NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

[26] Armis (2017) The Attack Vector “BlueBorne” Exposes Almost Every Connected Device.
Available at https://www.armis.com/blueborne/

[27] Google (2019) The Android Management API. Available at

https://developers.google.com/android/management/introduction

[28] Apple (2019) Mobile Device Management Protocol Reference. Available at

https://developer.apple.com/library/content/documentation/Miscellaneous/Reference/Mobil
eDeviceManagementProtocolRef/1-Introduction/Introduction.html

[29] Black PE, Badger ML, Guttman B, Fong EN (2016) Dramatically Reducing Software
Vulnerabilities: Report to the White House Office of Science and Technology Policy.
(National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or
Internal Report (IR) 8151. https://doi.org/10.6028/NIST.IR.8151
[30] Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016
on the protection of natural persons with regard to the processing of personal data and on
the free movement of such data, and repealing Directive 95/46/EC (General Data
Protection Regulation)
https://publications.europa.eu/en/publication-detail/-/publication/3e485e15-11bd-11e6-
ba9a-01aa75ed71a1/language-en

[31] Health Insurance Portability and Accountability Act of 1996, H. Rept. 104-736, H.R. 3103.
https://www.gpo.gov/fdsys/search/pagedetails.action?granuleId=CRPT-
104hrpt736&packageId=CRPT-104hrpt736
[32] Lookout (2016) Technical Analysis of Pegasus Spyware. Available at
https://info.lookout.com/rs/051-ESQ-475/images/lookout-pegasus-technical-analysis.pdf

[33] McConnell, Steve, Code Complete: A Practical Handbook of Software Construction,

Microsoft Press, 2nd edition, June, 2004.

[34] Dempsey KL, Eavy P, Moore G (2017) Automation Support for Security Control
Assessments: Volume 2: Hardware Asset Management. (National Institute of Standards
and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8011, Vol.
2. https://doi.org/10.6028/NIST.IR.8011-2
[35] Souppaya MP, Scarfone KA (2016) User's Guide to Telework and Bring Your Own Device
(BYOD) Security. (National Institute of Standards and Technology, Gaithersburg, MD),
NIST Special Publication (SP) 800-114, Rev. 1. https://doi.org/10.6028/NIST.SP.800-
114r1
[36] Center for Internet Security (2019) Apple iOS Benchmark. Available at
https://www.cisecurity.org/benchmark/apple_ios/

[37] Center for Internet Security (2019) Google Android Benchmark. Available at
https://www.cisecurity.org/benchmark/google_android/

[38] The United States Department of Justice (2015) The Privacy Act of 1974. Available
at https://www.justice.gov/opcl/privacy-act-1974

42
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

[39] National Institute of Standards and Technology (2019) National Vulnerability

Database. Available at https://nvd.nist.gov/

[40] National Institute of Standards and Technology (2019) National Checklist Program
Repository. Available at https://nvd.nist.gov/ncp/repository

[41] Ferraiolo H, Cooper DA, Francomacaro S, Regenscheid AR, Burr WE, Mohler J,
Gupta S (2014) Guidelines for Derived Personal Identity Verification (PIV)
Credentials. (National Institute of Standards and Technology, Gaithersburg, MD),
NIST Special Publication (SP) 800-157. https://doi.org/10.6028/NIST.SP.800-157

[42] Souppaya MP, Scarfone KA (2013) Guide to Enterprise Patch Management

Technologies. (National Institute of Standards and Technology, Gaithersburg,
MD), NIST Special Publication (SP) 800-40, Rev. 3.
https://doi.org/10.6028/NIST.SP.800-40r3
[43] Scarfone KA, Jansen W, Tracy MC (2008) Guide to General Server Security.
(National Institute of Standards and Technology, Gaithersburg, MD), NIST Special
Publication (SP) 800-123. https://doi.org/10.6028/NIST.SP.800-123
[44] Dodson D, Souppaya, MP, Scarfone K (2019) Mitigating the Risk of Software
Vulnerabilities by Adopting a Secure Software Development Framework (SSDF).
(National Institute of Standards and Technology Gaithersburg, MD), Draft NIST
Cybersecurity White Paper. Available at
https://csrc.nist.gov/CSRC/media/Publications/white-paper/2019/06/07/mitigating-
risk-of-software-vulnerabilities-with-ssdf/draft/documents/ssdf-for-mitigating-risk-
of-software-vulns-draft.pdf
[45] Frankel SE, Kent K, Lewkowski R, Orebaugh AD, Ritchey RW, Sharma SR (2005)
Guide to IPsec VPNs. (National Institute of Standards and Technology,
Gaithersburg, MD), NIST Special Publication (SP) 800-77.
https://doi.org/10.6028/NIST.SP.800-77
[46] Frankel SE, Hoffman P, Orebaugh AD, Park R (2008) Guide to SSL VPNs.
(National Institute of Standards and Technology, Gaithersburg, MD), NIST Special
Publication (SP) 800-113. https://doi.org/10.6028/NIST.SP.800-113
[47] Newhouse WD, Witte GA, Scribner B, Keith S (2017) National Initiative for
Cybersecurity Education (NICE) Cybersecurity Workforce Framework. (National
Institute of Standards and Technology, Gaithersburg, MD), NIST Special
Publication (SP) 800-181. https://doi.org/10.6028/NIST.SP.800-181
[48] Souppaya MP, Scarfone KA (2016) Draft NIST SP 800-154, Guide to Data-Centric
System Threat Modeling. (National Institute of Standards and Technology,
Gaithersburg, MD), NIST Special Publication (SP) 800-154. Available at
http://csrc.nist.gov/publications/drafts/800-154/sp800_154_draft.pdf
1889

43
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1890 Appendix A. Acronyms and Abbreviations

1891 Selected acronyms and abbreviations used in this publication are defined below.

1892 AP Access Point

1893 API Application Programming Interface
1894 ATARC Advanced Technology Academic Research Center
1895 B2B Business-to-Business
1896 BYOD Bring Your Own Device
1897 CAVP Cryptographic Algorithm Validation Program
1898 CIO Chief Information Officer
1899 CISO Chief Information Security Officer
1900 CMVP Cryptographic Module Validation Program
1901 COPE Corporately Owned, Personally Enabled
1902 CYOD Choose Your Own Device
1903 DEP Device Enrollment Program
1904 DHS Department of Homeland Security
1905 DLP Data Loss Prevention
1906 DRM Digital Rights Management
1907 EMM Enterprise Mobility Management
1908 FCC Federal Communications Commission
1909 FIPS Federal Information Processing Standard
1910 FISMA Federal Information Security Modernization Act
1911 FOIA Freedom of Information Act
1912 GFE Government Furnished Equipment
1913 GLONASS Global Navigation Satellite System
1914 GNSS Global Navigation Satellite System
1915 GPS Global Positioning System
1916 HTTP Hypertext Transfer Protocol
1917 HTTPS HTTP Secure
1918 IMEI International Mobile Equipment Identity
1919 IMSI International Mobile Subscriber Identity
1920 IoT Internet of Things
1921 IPsec Internet Protocol Security
1922 IR Interagency/Internal Report
1923 IT Information Technology
1924 ITL Information Technology Laboratory
1925 L2TP Layer 2 Tunneling Protocol
1926 LAN Local Area Network
1927 LDAP Lightweight Directory Access Protocol
1928 MAM Mobile Application Management
1929 MAV Mobile Application Vetting
1930 MCDF Mobile Computing Decision Framework
1931 MDM Mobile Device Management
1932 MitM Man in the Middle
1933 MTD Mobile Threat Defense
1934 MTP Mobile Threat Protection
1935 NFC Near Field Communication
1936 NGO Non-Governmental Organization
1937 NIAP National Information Assurance Partnership
1938 NIST National Institute of Standards and Technology

44
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1939 NSA National Security Agency

1940 OEM Original Equipment Manufacturer
1941 OMB Office of Management and Budget
1942 OS Operating System
1943 PAN Personal Area Network
1944 PID Process Identifier
1945 PII Personally Identifiable Information
1946 PIN Personal Identification Number
1947 P.L. Public Law
1948 QR Quick Response
1949 RADIUS Remote Authentication Dial-In User Service
1950 RFID Radio Frequency Identification
1951 RTOS Real Time Operating System
1952 SaaS Software as a Service
1953 SD Secure Digital
1954 SDK Software Development Kit
1955 SED Self-Encrypting Drive
1956 SIM Subscriber Identity Module
1957 SoC System on a Chip
1958 SP Special Publication
1959 SSID Service Set Identifier
1960 TEE Trusted Execution Environment
1961 TLS Transport Layer Security
1962 UICC Universal Integrated Circuit Card
1963 UID User Identifier
1964 URL Uniform Resource Locator
1965 VDI Virtual Desktop Infrastructure
1966 VMI Virtual Mobile Infrastructure
1967 VPN Virtual Private Networking
1968 WiFi Wireless Fidelity
1969 WLAN Wireless LAN
1970 XML Extensible Markup Language
1971

45
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

1972 Appendix B. Supporting NIST SP 800-53 Security Controls

1973 The list below maps mobile security technologies to the appropriate NIST SP 800-53 security controls and to the Cybersecurity Framework
1974 version 1.1 functions, categories, and subcategories.

Mobile Capabilities NIST SP 800-53 rev. 4 NIST SP 800-53 NIST Cybersecurity Framework (CSF) Functions,
Technology - Control Families rev. 4-Security Categories, Subcategories
Controls Function CSF Category CSF Subcategory
Enterprise Access Access Control AC-3, AC-4, AC-6, Protect Identity Management, PR.AC-3, PR.AC-4,
Mobile Control AC-7, AC-8, AC-11, Authentication and PR.AC-5, PR.AC-6,
Management AC-14, AC-16, AC- Access Control PR.AC-7
(EMM) or Mobile 17, AC-18, AC-19, Data Security PR.DS-5
Device AC-20
Management Protective Technology PR.PT-4
(MDM)
Identify Asset Management ID.AM-3
Identification & IA-2, IA-3, IA-5, IA-6, Protect Identity Management, PR.AC-1
Authentication IA-7, IA-10 Authentication and
Access Control
Security Assessment and CA-1, CA-9 Identify Asset Management ID.AM-3
Authorization
Governance ID.GV-1, ID.GV-3

Data Media Protection MP-5, MP-6, MP-7 Protect Protective Technology PR.PT-2
Protection
System and SC-3, SC-4, SC-7, Protect Protective Technology PR.PT-4, PR.PT-4
Communications SC-12, SC-13, SC- Identity Management, PR.AC-5
Protection 23, SC-24, SC-28, Authentication and
SC-39, SC-43 Access Control
Data Security PR.DS-1, PR.DS-2,
PR.DS-5
System System and Information SI-2, SI-3, SI-4, SI-7 Identify Risk Assessment ID.RA-1
Integrity Integrity
Protect Data Security PR.DS-5, PR.DS-6
Detect Anomalies and Events DE.AE-3
Security Continuous DE.CM-1, DE.CM-4,
Monitoring DE.CM-7
Respond Analysis RS.AN-1

46
 NIST SP 800-124 REV. 2 (DRAFT) GUIDELINES FOR MANAGING THE SECURITY OF
MOBILE DEVICES IN THE ENTERPRISE

Mobile Capabilities NIST SP 800-53 rev. 4 NIST SP 800-53 NIST Cybersecurity Framework (CSF) Functions,
Technology - Control Families rev. 4-Security Categories, Subcategories
Controls Function CSF Category CSF Subcategory
Configuration CM-2, CM-3, CM-5, Protect Information Protection PR.IP-1
Management CM-6, CM-7, CM-8, Processes and
CM-11 Procedures
Detect Security Continuous DE.CM-7, DE.CM-3
Monitoring
Detection and Audit and Accountability AU-2, AU-3, AU-5, Identify Supply Chain Risk ID.SC-4
Monitoring AU-7, AU-8, AU-9, Management
AU-10, AU-12, AU-14 Protect Protective Technology PR.PT-1
Respond Analysis RS.AN-3
Incident Response IR-5 Detect Anomalies and Events DE.AE-3, DE.AE-5
Respond Analysis RS.AN-1, RS.AN-4
Security Assessment and CA-9 Identify Asset Management ID.AM-3
Authorization
Virtual Private Access Access Control AC-4, AC-17 Identify Asset Management ID.AM-3
Network (VPN) Control
Protect Identity Management, PR.AC-3, PR.AC-5
Endpoint Authentication and
Access Control
Data Security PR.DS-5
Protective Technology PR.PT-4

Identification and IA-3 Protect Identity Management, PR.AC-1, PR.AC-7

Authentication Authentication and
Access Control
Data System and SC-8, SC-11 Protect Data Security PR.DS-2, PR.DS-5
Protection Communications
Protection
System System and Information SI-4 Detect Anomalies and Events DE.AE-1, DE.AE-2
Integrity Integrity
Security Continuous DE.CM-7
Monitoring
1975
1976

47