Patent Publication Number: US-2023153150-A1

Title: Systems and methods for migrating users and modifying workspace definitions of persona groups

Description:
FIELD 
     This disclosure relates generally to Information Handling Systems (IHSs), and, more specifically, to systems and methods for migrating users and modifying workspace definitions of persona groups. 
     BACKGROUND 
     As the value and use of information continue to increase, individuals and businesses seek additional ways to process and store information. One option is an Information Handling System (IHS). An IHS generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes. Because technology and information handling needs and requirements may vary between different applications, IHSs may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in IHSs allow for IHSs to be general or configured for a specific user or a for specific use such as financial transaction processing, airline reservations, enterprise data storage, global communications, etc. In addition, IHSs may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems. 
     IHSs provide users with capabilities for accessing, creating, and manipulating data, and often implement a variety of security protocols in order to protect this data. Historically, IHSs have been designed to implement security paradigms that isolate them from possible security threats, much like a castle is designed and constructed to safeguard persons within its walls. In the case of a network of IHSs, for example, security systems implement strategies that isolate the entire network from threats. In effect, a set of castle walls is constructed around the entire network. While working from within the walls of such systems, users may be provided with secure and productive use of data. 
     However, security paradigms that isolate protected data within the walls of a castle are increasingly frustrated by the realities of modern computing. Nowadays, users expect to access protected data using a plethora of different IHSs while located at a variety of physical locations. In an effort to leverage the security of the system providing access to the data, current protocols for supporting remote access have sought to extend the defenses of the system to remote IHSs, essentially extending the castle walls to temporarily include all or part of the remote IHSs. 
     Another complication of modern computing is the user&#39;s expectation that they will be able utilize their own personal IHSs to access some or all of their protected data, even if those users are provided with enterprise-issued IHSs for accessing it. For administrators of such systems, this increases the difficulty in securing all manners in which protected data may be accessed. This difficulty is greatly expanded by the need to support access to protected data using an ever-growing list of software applications, whether on a personal IHS or an enterprise-issued IHS. Moreover, the administration of such systems is further complicated by the need to support access to protected data from a variety of physical locations and via a variety of networks, including untrusted networks. Faced with such problems, systems for providing access to protected data are often burdensome to administer and ultimately the data is insufficiently protected so as to facilitate its productive use. 
     A known technique for securing access to protected data accessed via an IHS is to isolate the data within a segregated or virtualization environment that runs on the IHS using a virtual machine or container. Conventional types of virtualization environments provide varying degrees of isolation from the hardware and operating system of the IHS. However, similarly to the castle wall defenses of security paradigms that seek to isolate protected data within a secure perimeter, conventional virtualization environments are also ill-suited to modern computing. Particularly, these virtualization techniques establish an isolated computing environment on an IHS that allows a user to access only data and applications approved for that user. 
     In some instances, conventional virtualization techniques may determine the data, applications, and protections to be provided by on an IHS based solely on the identity of the user, and therefore tend to implement all security protocols that would be necessary to secure access to all approved data and applications. As the inventors hereof have recognized, however, not only does this result in complex virtualization efforts that consume large portions of the memory and processing capabilities of the IHS, but conventional techniques also do not account for what the user actually intends to do while operating the IHS. 
     As the inventors hereof have further recognized, modern computing ought to provide users with access to protected data via a variety of IHSs and at practically any location. Yet conventional virtualization fails to account for the specific context in which an IHS is being used during a particular session, much less to account for changes to the context in which an IHS is used during a session. Furthermore, conventional virtualization techniques tend to provide support for many capabilities that are not actually used. The overhead required to provide such unnecessary capabilities unduly burdens the operation of an IHS and degrades productivity and user experience. 
     SUMMARY 
     Systems and methods for migrating users and modifying workspace definitions of persona groups are described. In an illustrative, non-limiting embodiment, an Information Handling System (IHS) may include a processor and a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution by the processor, cause the IHS to: distribute a first workspace definition based upon a first persona group associated with a user to a client device operated by the user; and in response to a change in user behavior, determine whether to: (a) migrate the user to an existing second persona group, or (b) create a third persona group and migrate the user to the third persona group. 
     The client device may be configured to instantiate a first workspace based upon the first workspace definition. The change in user behavior may include an installation of an application in the first workspace not prescribed or forbidden by the first workspace definition. 
     Additionally, or alternatively, the change in user behavior may be reflected in a change in a security metric associated with the first workspace. The security metric may include at least one of: a risk metric associated with a locale of the client device, a risk metric associated with the user, a risk metric associated with a network of the client device, a risk metric associated with hardware of the client device, a risk metric associated with a requested datafile, or a regulatory risk metric associated with the user, the locale, and the requested datafile. Additionally, or alternatively, the change in user behavior may be reflected in a change in a productivity metric associated with the first workspace. The productivity metric may include at least one of: a number of application installations, a number or volume of downloads, or a number of application executions. 
     Additionally, or alternatively, the change in user behavior may include a change in a geographical location of the client device. Additionally, or alternatively, change in user behavior may include operation of a different client device. 
     To determine whether to migrate the user to the second persona group, the program instructions, upon execution, may cause the IHS to determine that a changed user behavior matches a behavior of a second user of the second persona group. To determine whether to create the third persona group, the program instructions, upon execution, may cause the IHS to determine that a changed user behavior: (i) matches a changed behavior of a selected number of other users in the first persona group, and (ii) does not match a behavior of other users in the second persona group. In some cases, the number of other users may be selected based upon a relationship between a number of persona groups and a total number of users. 
     In response to the change in user behavior, the program instructions, upon execution, may cause the IHS to determine whether modify the first persona group and distribute a modified first workspace definition to the client device. Additionally, or alternatively, in response to the change in user behavior, the program instructions, upon execution, may cause the IHS to identify a potential security threat. 
     In another illustrative, non-limiting embodiment, a memory storage device having program instructions stored thereon that, upon execution by one or more processors of an Information Handling System (IHS) of a workspace orchestration service, cause the IHS to: distribute a first workspace definition based upon a first persona group associated with a user to a client device operated by the user, where the user IHS is configured to instantiate a first workspace based upon the first workspace definition; and in response to a change in a productivity or security metric of the first workspace, determine whether to: (a) migrate the user to an existing second persona group, (b) create a third persona group and migrate the user to the third persona group, (c) modify the first persona group and migrate the user to the modified first persona group, or (d) identify a potential security threat. 
     In yet another illustrative, non-limiting embodiment, a method may include: receiving a workspace definition from a workspace orchestration service based upon a first persona group associated with a user at a client device operated by the user, where the client device is configured to instantiate a workspace based upon the workspace definition; transmitting, from the client device to the workspace orchestration service, data indicative of a change in a productivity or security metric of the workspace; and receiving, from the workspace orchestration service at the client device, another workspace definition configured to: (a) migrate the user to another, existing persona group, (b) migrate the user to a new persona group, or (c) migrate the user to a modified first persona group. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention(s) is/are illustrated by way of example and is/are not limited by the accompanying figures, in which like references indicate similar elements. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. 
         FIG.  1    is a diagram depicting examples of components of an IHS configured to modernize workspace and hardware lifecycle management in an enterprise productivity ecosystem according to various embodiments. 
         FIG.  2    is a diagram depicting an example of a method for modernizing workspace and hardware lifecycle management in an enterprise productivity ecosystem, according to various embodiments. 
         FIGS.  3 A and  3 B  are a diagram depicting an example of a system configured to modernize workspace and hardware lifecycle management in an enterprise productivity ecosystem, according to various embodiments. 
         FIG.  4    is a flowchart describing certain steps of a process for securing a dynamic workspace in an enterprise productivity ecosystem, according to various embodiments. 
         FIG.  5    is a flowchart describing certain steps of a process for securing a dynamic workspace on an ongoing basis within an enterprise productivity ecosystem, according to various embodiments. 
         FIG.  6    is a diagram depicting an example of a method for workspace continuity and remediation, according to various embodiments. 
         FIG.  7    is a diagram of examples of dynamic workspace targeting with crowdsourced user context, according to various embodiments. 
         FIG.  8    is a flowchart of an example of a method for migrating users and modifying workspace definitions of persona groups, according to various embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     For purposes of this disclosure, an IHS may include any instrumentality or aggregate of instrumentalities operable to compute, calculate, determine, classify, process, transmit, receive, retrieve, originate, switch, store, display, communicate, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an IHS may be a personal computer (e.g., desktop or laptop), tablet computer, mobile device (e.g., Personal Digital Assistant (PDA) or smart phone), server (e.g., blade server or rack server), a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. An example of an IHS is described in more detail below.  FIG.  1    shows various internal components of an IHS configured to implement certain of the described embodiments. It should be appreciated that although certain embodiments described herein may be discussed in the context of a personal computing device, other embodiments may utilize various other types of IHSs. 
       FIG.  1    is a diagram depicting components of an example IHS  100  configured for securing a dynamic workspace in an enterprise productivity ecosystem. In some embodiments, IHS  100  may be employed to instantiate, manage, and/or terminate a workspace, such as a secure environment that may provide the user of IHS  100  with access to enterprise data while isolating the enterprise data from the operating system (OS) and other applications executed by IHS  100 . In some embodiments, the construction of a workspace for a particular purpose and for use in a particular context may be orchestrated remotely from the IHS  100  by a workspace orchestration services, such as described with regard to  FIG.  1   . In some embodiments, portions of the workspace orchestration may be performed locally on IHS  100 . IHS  100  may be configured with program instructions that, upon execution, cause IHS  100  to perform one or more of the various operations disclosed herein. In some embodiments, IHS  100  may be an element of a larger enterprise system that may include any number of similarly configured IHSs in network communications with each other. 
     As shown in  FIG.  1   , IHS  100  includes one or more processor(s)  101 , such as a Central Processing Unit (CPU), operable to execute code retrieved from system memory  105 . Although IHS  100  is illustrated with a single processor, other embodiments may include two or more processors, that may each be configured identically, or to provide specialized processing functions. Processor(s)  101  may include any processor capable of executing program instructions, such as an INTEL PENTIUM series processor or any general-purpose or embedded processors implementing any of a variety of Instruction Set Architectures (ISAs), such as the x86, POWERPC®, ARM®, SPARC®, or MIPS® ISAs, or any other suitable ISA. In the embodiment of  FIG.  1   , processor(s)  101  includes an integrated memory controller  118  that may be implemented directly within the circuitry of the processor(s)  101 , or memory controller  118  may be a separate integrated circuit that is located on the same die as processor(s)  101 . Memory controller  118  may be configured to manage the transfer of data to and from system memory  105  of IHS  100  via high-speed memory interface  104 . 
     System memory  105  that is coupled to processor(s)  101  via memory bus  104  provides processor(s)  101  with a high-speed memory that may be used in the execution of computer program instructions by processor(s)  101 . Accordingly, system memory  105  may include memory components, such as such as static RAM (SRAM), dynamic RAM (DRAM), NAND Flash memory, suitable for supporting high-speed memory operations by processor(s)  101 . In some embodiments, system memory  105  may combine both persistent, non-volatile memory and volatile memory. 
     In certain embodiments, system memory  105  includes secure storage  120  that may be a portion of the system memory designated for storage of information, such as access policies, component signatures, encryption keys, and other cryptographic information, for use in hosting a secure workspace on IHS  100 . In such embodiments, a signature may be calculated based on the contents of secure storage  120  and stored as a reference signature. The integrity of the data stored in secure storage  120  may then be validated at a later time by recalculating this signature of the contents of the secure storage and comparing the recalculated signature against the reference signature. 
     IHS  100  utilizes chipset  103  that may include one or more integrated circuits that are coupled to processor(s)  101 . In the embodiment of  FIG.  1   , processor(s)  101  is depicted as a component of chipset  103 . In other embodiments, all of chipset  103 , or portions of chipset  108  may be implemented directly within the integrated circuitry of processor(s)  101 . Chipset  103  provides processor(s)  101  with access to a variety of resources accessible via bus  102 . In IHS  100 , bus  102  is illustrated as a single element. However, other implementations may utilize any number of buses to provide the illustrated pathways served by bus  102 . 
     As illustrated, a variety of resources may be coupled to processor(s)  101  of IHS  100  through chipset  103 . For instance, chipset  103  may be coupled to network interface  109 , such as provided by a Network Interface Controller (NIC) that is coupled to the IHS  100  and allows the IHS  100  to communicate via a network, such as the Internet or a LAN. Network interface device  109  may provide IHS  100  with wired and/or wireless network connections via a variety of network technologies, such as wireless cellular or mobile networks (CDMA, TDMA, LTE etc.), WIFI and BLUETOOTH. In certain embodiments, network interface  109  may support connections between a trusted IHS component, such as trusted controller  115 , and a remote orchestration service. In such embodiments, a connection supported by network interface  109  between the remote orchestration service and the trusted component may be considered an out-of-band ( 00 B) connection that is isolated from the OS of the IHS. 
     Chipset  102  may also provide access to one or more display device(s)  108  via graphics processor  107 . In certain embodiments, graphics processor  107  may be comprised within one or more video or graphics cards or an embedded controller installed as components of the IHS  100 . Graphics processor  107  may generate display information and provide the generated information to one or more display device(s)  108  coupled to IHS  100 , where display device(s)  108  may include integrated display devices and/or external display devices coupled to IHS, such as via an I/O port  116 , where display device(s)  108  may include integrated display devices and/or external display devices coupled to IHS. In certain embodiments, graphics processor  107  may be integrated within processor  101 . The one or more display devices  108  coupled to IHS  100  may utilize LCD, LED, OLED, or other thin film display technologies. Each display device  108  may be capable of touch input such as via a touch controller that may be an embedded component of display device  108 , graphics processor  107 , or a separate component of IHS  100  accessed via bus  102 . 
     In certain embodiments, chipset  103  may utilize one or more I/O controllers to access hardware components such as user input devices  111  and sensors  112 . For instance, I/O controller  110  may provide access to user-input devices  110  such as a keyboard, mouse, touchpad, touchscreen and/or other peripheral input devices. User input devices  111  may interface with I/O controller  110  through wired or wireless connections. Sensors  112  accessed via I/O controllers  110  may provide access to data describing environmental and operating conditions of IHS  100  (e.g., accelerometers, gyroscopes, hinge sensors, rotation sensors, hall effect sensors, temperature sensors, voltage sensors, current sensors, IR sensors, photosensors, proximity sensors, distance sensors, magnetic sensors, microphones, ultrasonic sensors, etc.). 
     In some cases, chipset  103  may include a sensor hub capable of utilizing information collected by sensors  112  in determining the relative orientation and movement of IHS  100 . For instance, the sensor hub may utilize inertial movement sensors, that may include accelerometer, gyroscope, and magnetometer sensors, and are capable of determining the current orientation and movement of IHS  100  (e.g., IHS  100  is motionless on a relatively flat surface, IHS  100  is being moved irregularly and is likely in transport, the hinge of IHS  100  is oriented in a vertical direction). In certain embodiments, the sensor hub may also include capabilities for determining a location and movement of IHS  100  based on triangulation of network signal and based on network information provided by the OS or network interface  109 . In some embodiments, the sensor hub may support additional sensors, such as optical, infrared and sonar sensors, that may provide support for xR (virtual, augmented, and/or mixed reality) sessions hosted by the IHS  100  and may be used by the sensor hub provide an indication of a user&#39;s presence near IHS  100 , such as whether a user is present, absent, and/or facing the integrated display  108 . 
     In cases where the end-user is present before IHS  100 , the sensor hub may further determine a distance of the end-user from the IHS, where this determination may be made continuously, at periodic intervals, or upon request. The detected or calculated distances may be used by processor  101  to classify the user as being in the IHS&#39;s near-field (user&#39;s position&lt;threshold distance A), mid-field (threshold distance A&lt;user&#39;s position&lt;threshold distance B, where B&gt;A), or far-field (user&#39;s position&gt;threshold distance C, where C&gt;B). As described in additional detail below, the failure to detect an authenticated user of the IHS  100  within a proximity of the IHS  100  may result in a change in the security profile of IHS  100 , thus triggering a re-evaluation of the security risk of workspaces operating on IHS  100 . Similar re-evaluation may be triggered based on the detection of additional individuals in proximity to IHS  100 . 
     In embodiments where IHS  100  may support multiple physical configurations, such as a convertible laptop, N-in-1 device, or the like, the sensor hub may utilize one or more mode sensors  112  that collect readings that may be used in determining the current posture in which the IHS  100  is physically configured. In certain embodiments, such posture determinations may be additionally made using the movement and orientation information provided by sensors  112 . In laptop and convertible laptop embodiments, for example, processor  101  or trusted controller  115  may utilize a lid position sensor  112  to determine the relative angle between the two panels of the laptop in order to determine the mode in which IHS  100  is physically configured. In such embodiments, the lid position sensor may measure the angle of rotation of the hinge that connects the base panel and lid panel of IHS  100 . In some embodiments, processor  101  or trusted controller  115  may provide collected lid position information, such as the hinge angle, to the sensor hub for use in determining the posture in which IHS  100  is configured. In some embodiments, the sensor hub may interface directly with the lid position sensor in determining hinge angle information. 
     The sensor hub may determine the posture of IHS  100  based, at least in part, on the angle of rotation of the hinge of IHS  100  from a closed position. A first range of hinge angles from a closed position may indicate a laptop posture, a second range of hinge angles may indicate a landscape posture and a third range of angles may indicate a tablet posture. The sensor hub may additionally utilize orientation and movement information collected from inertial movement sensors  112  to further determine the posture in which the IHS  100  is physically configured. For instance, if the sensor hub determines that IHS  100  is configured with a hinge angle of a laptop configuration, but IHS  100  is oriented on its side, the IHS may be determined to be in a book mode. If IHS  100  is determined to be tilted such that the hinge is oriented between horizontal and vertical, the user&#39;s face is detected to be facing the integrated display, and IHS  100  is experiencing slight movement, the sensor hub may determine that the IHS  100  is being used in a book posture. The sensor hub may determine that IHS  100  is opened to a 180-degree hinge angle and lies on a flat surface, thus indicating that IHS  100  it is being used in a landscape posture. The sensor hub may similarly determine that IHS  100  is in a tent configuration, in response to detecting a hinge angle within a defined range, such as between 300 and 345 degrees, and also detecting an orientation of IHS  100  where the hinge is aligned horizontally and is higher than both of the display panels of IHS  100 . 
     Other components of IHS  100  may include one or more I/O ports  116  for communicating with peripheral external devices as well as various input and output devices. For instance, I/O  116  ports may include HDMI (High-Definition Multimedia Interface) ports for use in connecting external display devices to IHS  100  and USB (Universal Serial Bus) ports, by which a variety of external devices may be coupled to IHS  100 . In some embodiments, external devices coupled to IHS  100  via an I/O port  116  may include storage devices that support transfer of data to and from system memory  105  and/or storage devices  119  of IHS  100 . As described in additional detail below, the coupling of storage devices via an I/O port  116  may result in a change in the security profile of IHS  100 , thus triggering a re-evaluation of the security risk of workspaces operating on IHS  100 . 
     Chipset  103  also provides processor(s)  101  with access to one or more storage devices  119 . In various embodiments, storage device  119  may be integral to the IHS  100 , or may be external to the IHS  100 . In certain embodiments, storage device  119  may be accessed via a storage controller that may be an integrated component of the storage device. Storage device  119  may be implemented using any memory technology allowing IHS  100  to store and retrieve data. For instance, storage device  119  may be a magnetic hard disk storage drive or a solid-state storage drive. In some embodiments, storage device  119  may be a system of storage devices, such as a cloud drive accessible via network interface  109 . 
     As illustrated, IHS  100  also includes BIOS (Basic Input/Output System)  117  that may be stored in a non-volatile memory accessible by chipset  103  via bus  102 . Upon powering or restarting IHS  100 , processor(s)  101  may utilize BIOS  117  instructions to initialize and test hardware components coupled to IHS  100 . BIOS  117  instructions may also load an operating system for use by IHS  100 . BIOS  117  provides an abstraction layer that allows the operating system to interface with the hardware components of the IHS  100 . The Unified Extensible Firmware Interface (UEFI) was designed as a successor to BIOS. As a result, many modern IHSs utilize UEFI in addition to or instead of a BIOS. As used herein, BIOS is intended to also encompass UEFI. 
     In the illustrated embodiment, BIOS  117  includes a predefined memory or memory region that may be referred to as NVM (Non-Volatile Memory) mailbox  106 . In such an implementation, mailbox  106  may provide a secured storage location for use in storing workspace access policies, signatures, cryptographic keys or other data utilized to host and validate a workspace on IHS  100 . In certain embodiments, the BIOS mailbox  106  may be utilized as a secure storage utilized by a remote orchestration service in order to store access policies and cryptographic keys for use in delivering and deploying a secured container on IHS  100 . BIOS mailbox  106  and secured storage  120  in system memory  105  may be utilized in this manner instead of, or in conjunction with, out-of-band functions implemented by trusted controller  115 . 
     In certain embodiments, trusted controller  115  is coupled to IHS  100 . For example, trusted controller  115  may be an embedded controller (EC) that is installed as a component of the motherboard of IHS  100 . In various embodiments, trusted controller  115  may perform various operations in support of the delivery and deployment of a workspace to IHS  100 . In certain embodiments, trusted controller  115  may interoperate with a remote orchestration service via an out-of-band communications pathway that is isolated from the operating system that runs on IHS  100 . Network interface  109  may support such out-of-band communications between trusted controller  115  and a remote orchestration service. 
     Trusted controller  115  may receive cryptographic information required for secure delivery and deployment of a workspace to IHS  100 . In such embodiments, the cryptographic information may be stored to secured storage  121  maintained by trusted controller  115 . Additionally, or alternatively, trusted controller  115  may support execution of a trusted operating environment that may support cryptographic operations used to deploy a workspace on IHS  100 . Additionally, or alternatively, trusted controller  115  may support deployment of a workspace within the OS of IHS  100  via an out-of-band communications channel that is isolated from the OS and allows the workspace to communicate with a trusted agent process of the OS. 
     Trusted controller  115  may also provide support for certain cryptographic processing used to support secure deployment and operation of workspaces on IHS  100 . In some embodiments, such cryptographic processing may be provided via operations of a secure operating environment hosted by trusted controller  115  in isolation from the software and other hardware components of the IHS  100 . In some embodiments, trusted controller  115  may rely on cryptographic processing provided by dedicated cryptographic hardware supported by the IHS, such as a TPM (Trusted Platform Module) microcontroller. In some embodiments, the secured storage  121  of trusted controller  115  may be utilized to store cryptographic information for use in authorization of workspaces. 
     In certain embodiments, trusted controller  115  may be additionally configured to calculate signatures that uniquely identify individual components of IHS  100 . In such scenarios, trusted controller  115  may calculate a hash value based on the configuration of a hardware and/or software component coupled to IHS  100 . For instance, trusted controller  115  may calculate a hash value based on all firmware and other code or settings stored in an onboard memory of a hardware component, such as a network interface  109 . Such hash values may be calculated as part of a trusted process of manufacturing IHS  100  and may be maintained in the secure storage  121  as a reference signature. 
     Trusted controller  115  may be further configured to recalculate a hash value at a later time for such a component. The hash value recalculated for the component may then be compared against the reference hash value signature in order to determine if any modifications have been made to a component, thus indicating the component has been compromised. In this manner, trusted controller  115  may be used to validate the integrity of hardware and software components installed on IHS  100 . In certain embodiments, remote orchestration service  206  may verify the integrity of the trusted controller  115  in the same manner, by calculating a signature of trusted controller  115  and comparing it to a reference signature calculated during a trusted process for manufacture of IHS  100 . In various embodiments, one or more of these operations supported by trusted controller  115  may be implemented using BIOS  117 . 
     Trusted controller  115  may also implement operations for interfacing with a power adapter in managing power for IHS  100 . Such operations may be utilized to determine the power status of IHS  100 , such as whether IHS  100  is operating from battery power or is plugged into an AC power source. Firmware instructions utilized by trusted controller  115  may be used to operate a secure execution environment that may include operations for providing various core functions of IHS  100 , such as power management and management of certain operating modes of IHS  100  (e.g., turbo modes, maximum operating clock frequencies of certain components, etc.). 
     In managing operating modes of IHS  100 , trusted controller  115  may implement operations for detecting certain changes to the physical configuration of IHS  100  and managing the modes corresponding to different physical configurations of IHS  100 . For instance, where IHS  100  is a laptop computer or a convertible laptop computer, trusted controller  115  may receive inputs from a lid position sensor  112  that may detect whether the two sides of the laptop have been latched together to a closed position. In response to lid position sensor  112  detecting latching of the lid of IHS  100 , trusted controller  115  may initiate operations for shutting down IHS  100  or placing IHS  100  in a low-power mode. 
     IHS  100  may support the use of various power modes. In some embodiments, the power modes of IHS  100  may be implemented through operations of trusted controller  115  and/or the OS of IHS  100 . In various embodiments, IHS  100  may support various reduced power modes in order to reduce power consumption and/or conserve battery power when IHS  100  is not actively in use, and/or to control a level of performance available to the user by increasing or decreasing a maximum operating clock frequency of a component of IHS  100  (e.g., processor(s)  101 ). 
     In some embodiments, an IHS  100  may not include all of the components shown in  FIG.  1   . In other embodiments, an IHS  100  may include other components in addition to those that are shown in  FIG.  1   . Furthermore, some components that are represented as separate components in  FIG.  1    may instead be integrated with other components. For example, in certain embodiments, all or a portion of the operations executed by the illustrated components may instead be provided by components integrated into processor(s)  101  as systems-on-a-chip. 
       FIG.  2    is a diagram depicting an example of method  200  for securing a dynamic workspace in an enterprise productivity ecosystem. For sake of illustration, method  200  has been split into three phases: workspace initialization phase  200 A, workspace orchestration phase  200 B, and workspace termination phase  200 C. During initialization  200 A, user  201  (e.g., an enterprise user) operates an IHS  100  (e.g., a desktop, a laptop, a tablet, a smart phone, etc.) such as described with regard to  FIG.  1    within physical environment  202  (e.g., any type of environment and its associated context, including physical location, geographic location, location within a particular facility or building, detected networks, time of day, proximity of the user, individuals in the vicinity of IHS  100 , etc.). 
     Method  200  starts with an action by user  201  at a launch point  203  that may be, for example, a corporate launch point provided by an employer of user  201 , a launch point  203  provided by the manufacturer of IHS  100 , or a launch point provided as a service to user  201  by a third-party. Particularly, user  201  operates IHS  100  to access launch point  203  that is provided, for example, in the form of a web portal, a portal application running in the operating system of IHS  100 , a special-purpose portal workspace operating on IHS  100 , or the like. In various implementations, launch point  203  may include Graphical User Interface (GUI) elements representing different software applications, data sources and/or other resources that the user may desire to execute and/or manipulate. In various embodiments, launch point may provide a graphical, textual and/or audio interface by which data or other resource may be requested by a user  201 . As such, an authenticated user  201  may be provided a launch point that provides visibility as to one or more software applications and an aggregation of user&#39;s data sources available across all of their datastores (e.g., local storage, cloud storage, etc.). 
     As described in additional detail below, workspaces for providing user  201  with access to requested data or other resources may operate using a local management agent  332  that operates on IHS  100  and is configured to interoperate with workspace orchestration service  206 . In various embodiments, launch point  203  may be provided in the form of a portal (e.g., a webpage, OS application or special purpose workspace) that allows user  201  to request access to managed resources. In various embodiments, launch point  203  may be hosted by remote workspace orchestration service  206 , local management agent  332  on IHS  100 , or any suitable combination thereof. Examples of launch point  203  technologies may include WORKSPACE ONE INTELLIGENT HUB from WMWARE, INC., and DELL HYBRID CLIENT from DELL TECHNOLOGIES INC., among others. 
     Initialization phase  200 A begins when user  201  chooses to launch an application or access a data source managed by the workspace orchestration service  206 . In response to an access request issued by user  201  (e.g., the user “clicks” on an icon of launch point  203 ), local management agent  332  of IHS  100  collects initial security and productivity context information at  204 . As described in additional detail with regard to  FIG.  4   , the security context information may include attributes indicating a security risk associated with: the data and/or application being requested, a level of risk presented by the user  201 , the hardware utilized by the IHS  100 , the logical environment of IHS  100  in which a workspace will be deployed to provide access to the requested data and/or application, and the physical environment  202  in which IHS  100  is currently located. 
     Accordingly, in this disclosure, the term “security context” generally refers to data or other information related to a security posture in which a workspace will be deployed and utilized, where the security posture may be based on the, user, IHS  100 , data to be accessed via the workspace, and/or environment  202 . As described in additional detail with regard to  FIGS.  4  and  5   , a security context may be quantified as a security risk score in support of evaluations of the level or risk associated with providing user  201  access to requested data and/or application while using IHS  100  in the particular context. A “security risk score” generally refers to a numerical value usable to score, quantify, or measure various security characteristics of the security context associated with a request. A risk score may be an aggregate score associated with the overall security risk context, whereas a “risk metric” may be a measurement of risk for a sub-category of some part of the security context. 
     As described in additional detail with regard to  FIGS.  4  and  5   , security metrics that may be used in the calculation of a security risk score for a particular security context may include, but are not limited to: a classification of the requested data source and/or application, authentication factors used to identify user  201 , the location of IHS  100 , a persona group classification associated with user  201 , validation of networks in use by IHS  100 , type of network in use by IHS  100 , network firewall configurations in use by IHS  100 , indicators of attack (IoA), indicators of compromise (IoC) regarding IHS  100  or a resource being requested by user  201 , patch levels associated with the operating system and other applications in use on IHS  100 , availability of encryption, type of available encryption, access to secured storage, use of attestable hardware by IHS  100 , supported degree of workspace isolation by IHS  100 , etc. 
     The term “productivity context” generally refers to user productivity associated with a workspace, user, IHS, or environment. A “productivity score” generally refers to an index usable to score, quantify, or measure various productivity characteristics of a productivity context. Examples of productivity context information include, but are not limited to: the hardware of the IHS, the software of the IHS, including the operating system, power states and maximum clock frequencies of selected components of the IHS, peripheral devices coupled to the IHS, either permanently or temporarily, networks available to the IHS and the performance characteristics of those networks, software installers available on the IHS, etc. 
     Initial productivity and security targets for a workspace may be calculated based on the context of user&#39;s  201  actions combined with the productivity and security context in which the workspace will operate. The productivity and security targets may also be based on user&#39;s  201  behavioral analytics, IHS  100  telemetry and/or environmental information (e.g., collected via sensors  112 ). In some cases, at  205 , a local management agent operating on IHS  100  may calculate initial security and productivity targets based upon the collected security and productivity context. In other cases, remote workspace orchestration service  206  may calculate security and productivity targets. 
     As used herein, the term “security target” generally refers to the attack surface presented by a workspace that is created and operated based on a workspace definition, while the term “productivity target” generally refers to the productivity characteristics of a particular workspace definition. Examples of a productivity target include, but are not limited to: type of data or data source available to user  201 , minimum latency of a workspace, etc. Conversely, attributes that may be used to characterize a security target may include, but are not limited to: a minimum security score for a workspace, a minimum trust score of IHS  100 , authentication requirements for user  201  (e.g., how many authentication factors are required, frequency of re-authentication), minimum level of trust in the network utilized by a workspace, required isolation of a workspace from IHS  100 , the ability to access browser within a workspace, the ability to transfer data between workspaces, the ability to extend a workspace, etc. 
     Moreover, the term “workspace definition” generally refers to a collection of attributes that describe aspects a workspace that may be assembled, created, and deployed in a manner that satisfies a security target (i.e., the definition presents an attack surface that presents an acceptable level of risk) and a productivity target (e.g., data access, access requirements, upper limits on latency, etc.) in light of the security context (e.g., location, patch level, threat information, network connectivity, etc.) and the productivity context (e.g., available device type and performance, network speed, etc.) in which the workspace is to be deployed. A workspace definition may enable fluidity of migration of an instantiated workspace, since the definition supports the ability for a workspace to be assembled on any target OS or IHS that is configured for operation with the workspace orchestration service  206 . 
     In describing capabilities and constraints of a workspace, a workspace definition  208  may prescribe one or more of: authentication requirements for user  201 , containment and/or isolation of the workspace (e.g., local application, sandbox, docker container, progressive web application or “PWA,” Virtual Desktop Infrastructure “VDI,” etc.), primary applications that can be executed in the defined containment of the workspace to enable user  201  to be productive with one or more data sources, additional applications that enhance productivity, security components that reduce the scope of the security target presented by the productivity environment (DELL DATA GUARDIAN from DELL TECHNOLOGIES INC., an anti-virus, etc.), the data sources to be accessed and requirements for routing that data to and from the workspace containment (e.g., use of VPN, minimum encryption strength), workspace capabilities to independently attach other resources; etc. 
     In some implementations, workspace definitions may be based at least in part on static policies or rules defined, for example, by an enterprise&#39;s Information Technology (IT) personnel. In some implementations, static rules may be combined and improved upon by machine learning (ML) and/or artificial intelligence (AI) algorithms that evaluate historical productivity and security data collected as workspaces are life cycled. In this manner, rules may be dynamically modified over time to generate improved workspace definitions. If it is determined, for instance, that a user dynamically adds a text editor every time he uses MICROSOFT VISUAL STUDIO from MICROSOFT CORPORATION, then workspace orchestration service  206  may autonomously add that application to the default workspace definition for that user. 
     Still with respect to  FIG.  2   , during orchestration  200 B, the initial security and productivity targets are processed and/or reconciled against resources, device capabilities, and cloud services available, etc., to produce a workspace definition at  208 . As described, a workspace definition may specify capabilities and constraints of a workspace, such as: runtime security requirements of the workspace containment (e.g., such as isolation from the OS of IHS  100  or from certain hardware of IHS  100 ), the use of reference measurements to attest to the integrity of the workspace once running, applications to be provided for operation within the workspace, aggregation of resources available via the workspace, access configurations (e.g., virtual private network or “VPN”), etc. 
     The initial workspace definition may then then utilized by automation engine  302  of workspace orchestration service  206  to coordinate the assembly  209  and instantiation  210  of a workspace on an appropriate platform—e.g., on the cloud or on IHS  201 —based on the security and productivity contexts in which the workspace will operate. In cases where a workspace is cloud-hosted, the automation engine  302  may assemble and instantiate a remote workspace that may be accessed via a secure connection established via a web browser or other web-based component operating on the IHS  100 . In some embodiments, automation engine  302  may resolve configuration conflicts between a workspace definition and the user&#39;s inputs in the operation of a workspace. 
     The instantiated workspace is operated by user  201  at  211 , and new productivity and security context information related to the behavior or use of data is generated at  212 . This operation of a workspace may result in a change or new classification of data based upon what user  201  has done, accessed, and/or created, thus resulting in a change to the security context of the workspace. To the extent the user&#39;s behavioral analytics, device telemetry, and/or the environment has changed to a quantifiable degree, these changes in security context may serve as additional input for a reevaluation of the security and performance targets at  207  by automation engine  302 . Additionally, or alternatively, new workspace context, security target, and/or productivity target may be now measured against the initial targets, and the result may cause automation engine  302  to produce a new workspace definition at  208 , if appropriate. 
     Particularly, if the instantiated workspace(s) have parameters that fall outside of the range of the target indexes such that a difference between additional or updated context information and the initial or previous context information is scored below a threshold value, automation engine  302  may process the assembly of modifications to an existing workspace and deploy such modifications at  210 . Conversely, if the difference between the additional or updated context information and the initial or previous context information is scored above a threshold value, automation engine  302  may generate a new workspace at  210 . Session data metadata and context may be preserved by data aggregation engine  336 , and session data may be restored as applicable. 
     Additionally, or alternatively, method  200  may terminate or retire the initial or previous workspace at  213 , as part of termination phase  200 C. In some cases, user action may initiate the termination process (e.g., user  201  closes application or browser accessing data) and/or termination may take place automatically as part of an adjustment in workspace definition (e.g., the isolated environment is instructed to terminate by automation engine  302 ). Still as part of termination phase  200 C, workspace resources of IHS  100  and/or at workspace orchestration service  206  may be released. 
     As such, in various embodiments, method  200  enables secure user productivity even when a workspace operates on an IHS or cloud platform that is not under direct management. Method  200  also provides for dynamic or adaptive configurations and policies allowing for the best possible user experience while maintaining appropriate level of security. In some cases, the definition of a productivity environment and access requirements may be selected based upon productivity and security dependencies and targets, and the definition of capabilities related to the workspace may be adaptive in nature. Particularly, workspace definition attributes may be dynamically selected based upon historical productivity and security information, based upon each individual user or their respective persona groups&#39; behavior. 
       FIGS.  3 A and  3 B  show a diagram of an example of system components  300 A and  300 B (collectively referred to as “system  300 ”) configured to modernize workspace and hardware lifecycle management in an enterprise productivity ecosystem. Particularly, component system  300 A comprises workspace orchestration service  206 , and it may include one or more IHSs remotely located and/or networked having program instructions stored thereon that, upon execution, cause the one or more IHSs to perform various workspace orchestration operations described herein, including, but not limited to: the dynamic evaluation of security and productivity targets based upon updated context information received from IHS  100 , the calculation of risk scores and other productivity and security metrics based on ongoing collection of context information, the generation of workspace definitions, and the assembly of one or more files or policies that enable the instantiation of a workspace in accordance with a workspace definition at a cloud service and/or IHS  300 B. 
     Component  300 B includes IHS  100  may have program instructions stored thereon that, upon execution, cause IHS  100  to perform various local management operations described herein, including, but not limited to, the collection of productivity and security context information, the calculation of productivity scores and/or risk scores, the instantiation, execution, and modification of a workspace based upon files or policies, such as workspace definitions, received from workspace orchestration service  206 , etc. 
     Workspace orchestration service  300 A and IHS  300 B may be coupled to each other via any suitable network technology and/or protocol, which allows workspace orchestration service  300 A to be remotely provided with respect to IHS  300 B. As described with regard to  FIG.  1   , an IHS according to embodiments may include a component such as a trusted controller that may support certain secure out-of-band communications that are independent from the operating system of IHS  100 . In some embodiments, such a trusted controller may be configured to support deployment and operation of workspaces on  300 A and to report changes in context information to the workspace orchestration service  300 A. 
     As illustrated in component  300 A of  FIG.  3 A , workspace orchestration service  206  may include a number of sub-components that support deployment and ongoing evaluation and adaptation of workspaces on an IHS  300 B. Embodiments of the workspace orchestration service  300 A may include systems that may support: web services  306 , manufacturer integration  317 , and analytics  323 . Moreover, web services  306  may comprise application services  301  and user interface (UI) and automation services  302 . 
     Analytics services  323  may be configured to receive and process context information from IHS  300 B, both during initial configuration of a workspace and in ongoing support of workspaces, and to provide that information, along with any analytics generated, to context logic  303  of application services  301 . Based on information collected during the deployment and ongoing support of workspaces, support assistance intelligence engine (SATE)  324  may be configured to generate and/or analyze technical support information (e.g., updates, errors, support logs, etc.) for use in diagnosing and repairing workspace issues. Workspace insights and telemetry engine  325  may be configured to analyze and/or produce device-centric, historical, and behavior-based data (e.g., hardware measurements, use of features, settings, etc.) resulting from the operation of workspaces. Workspace intelligence  326  may include any suitable intelligence engine for processing and evaluating context data in order to identify patterns and tendencies in the operation of workspaces and in the adaptation of workspaces based on context changes. 
     As illustrated, an application services  306  system of the workspace orchestration service  300 A includes an UI and automation services  302  system that may include context logic or engine  303 , classification policy  304 , and condition control module or engine  305 . Context logic or engine  303  may support processing of context information in making risk assessments (e.g., evaluating the risk associated requests by the user against the context of the user&#39;s behavior, history of the user&#39;s IHS, capabilities of the user&#39;s IHS, and environmental conditions). For instance, as described with regard to  FIGS.  4  and  5   , security context information collected by IHS  300 B may be provided to workspace orchestration service  300 A where it may be used, such as by context logic  303 , to calculate a risk score associated with a request for use of a managed data source and/or application. Classification policy  304  may include administrator and machine-learning defined policies describing risk classifications associated with different security contexts, such as risk classifications for specific data, locations, environments, IHSs, logical environments, or user actions (e.g., use of high-risk data requires use of a workspace definition suitable for use with a risk score above a specific value). Condition control module or engine  305  may include intelligence providing automated decision making for appropriately aligning risk and context. In some cases, condition control module or engine  305  may dynamically deploy a solution to address any detected misalignment of risk and context. For instance, upon requesting access to a highly classified data source that results in a significant increase in risk score, the condition control engine may select workspace definition modifications that implement security procedures that are suitable for the higher risk score. 
     Application services  301  may include a set of web services  306  called on by UI and automation services  302  to support various aspects of the orchestration of workspaces. Particularly, web services  306  may include application and workspace services  307  that may assemble and package applications for deployment in a workspace (e.g., an “.msix” file packaged and deployed to a MICROSOFT HYPER-V container). In some embodiments, a workspace definition may be used to specify whether a user will be provided access to an application in this manner. Web services  306  may also include a tenant subscription module  308 , that performs dynamic configuration of an IHS and deployment of the described workspace orchestration services at the point-of-sale (POS) of an IHS. A license tracking module  309  may be used to maintain and track license information for software, services, and IHSs. An access control module  310  may provide top level access controls used in controlling access to data and applications by authorized users. A Unified Endpoint Management (UEM) module  311  may be configured to support the described orchestration of workspaces on various different IHSs that may be utilized by a particular user. 
     Web services  306  that may be used in support of workspaces may further include resource provisioning services  312  for configuring an IHS or workspace with secrets/credentials necessary to access specific resources (e.g., credentials for use of VPNs, networks, data storage repositories, workspace encryption, workspace attestation, and workspace-to-device anchoring). In some cases, resource provisioning services  312  may include secrets provisioned as part of a trusted assembly process of IHS  300 B and, in some instances, associated with a unique identifier  348  of the IHS  300 B. Web services  306  may also include an authorization/token module that provides identity functions and may connect to various authentication sources, such as, for example, Active Directory. Endpoint registration module  314  may be configured to register IHSs and/or workspaces with management service that tracks the use of the described workspace orchestration. In some scenarios, a directory services  315  module may be configured to provide active directory services (e.g., AZURE ACTIVE DIRECTORY from MICROSOFT CORPORATION). Device configuration services  316  enable central configuration, monitoring, managing, and optimization of workspaces that in certain contexts may operate remotely from an IHS and may only present the user of the IHS with an image of the workspace output. In cooperation with resource provisioning services  312 , device configuration services  316  may also handle secret creation and IHS configuration, and it some cases, may be out-of-band capable and handle selected operations to the endpoint. 
     Still referring to  FIG.  3 A , manufacturer integration components  317  communicate with application services  301  and client IHS  300 B to provide features that are usable during workspace evaluation and instantiation, where these features are based upon information available to the manufacturer of client IHS  300 B. For instance, certificate authority  318  may include an entity that issues digital certificates that may be used in validating the authenticity and integrity of the hardware of IHS  300 B. Identity service module or engine  319  may be configured to manage the user&#39;s or owner&#39;s identity as well as brokering identification for use of customer directory  322 . Order entitlement module or engine  320  may be responsible for managing the entitlements purchased as well as the associated issued certificates signed by  318 . Ownership repository  321  may manage user entitlements associated with IHSs and their ownership and may provide support for users transferring ownership of an IHS and conveying the entitlements associated with that IHS. In certain scenarios, ownership repository  321  may use this transfer of ownership to decommission the secrets associated with the entitlements embedded in the IHS. Customer directory  322  may be configured to authenticate and authorize all users and IHSs in a network, such as assigning and enforcing security policies for all IHSs and installing or updating software (in some cases, customer directory  322  may work in cooperation and/or may be the same as directory services  315 ). 
     Referring now to IHS  300 B of  FIG.  3 B , in some embodiments, IHS  300 B may be configured to operate a local management agent  332  that may run within a secure execution environment  345  hosted by a trusted controller  341 , such as trusted controller  115  of  FIG.  1   . In other embodiments, the local management agent  332  may operate as a trusted and attestable process of the operating system of IHS  300 B. In some embodiments, local management agent  332  may include a workspace engine suitable for instantiating and managing the operation of one or more workspaces  331 A-N on IHS  300 B. As described, the capabilities of a workspace may be modified based on changes in the productivity and security contexts in which the workspace is operating. Accordingly, the workload(s) in each of the workspaces  331 A-N may be hosted in a public cloud, a private cloud, a specific server, or locally hosted on IHS  300 B, depending on the context in which the workspace is operating. These allocations of workspace computing for each particular workspace  331 A-N may be prescribed by the workspace definition that is used to build and operate each workspace. As described, the workspace definition may be created by workspace orchestration service  206  based upon context information provided by IHS  300 B, security targets for each workspace  331 A-N, and productivity targets for each workspace  331 A-N. 
     In some embodiments, local management agent  332  may be configured to host, launch, and/or execute a workspace hub  327  that provides a launch point  203  by which user&#39;s initiate workspaces through the selection of managed data and resources. In various embodiments, launch point  203  may be an agent, application, special-purpose workspace or web portal the provides an interface by which a user may select from an aggregated collection of data sources, applications, calendars, messages or other managed information or resources that are available to the user of IHS  300 B via operation of a workspace as described herein. In various embodiments, the launch point  203  may be provided in the form for textual, graphical and/or audio user interfaces that allow a user of IHS  300 B to select available data and/or resources. In some embodiments, workspace hub  327  may utilize a local environment management module  328  in providing the workspace interface that is presented to the user on IHS  300 B and doing so in a consistent manner across workspaces  331 A-N. Workspace hub  327  may also include a local intelligence logic or engine  329  used to support modeling the use of IHS  300 B in order to improve characterization of the actual risk associated with a risk context. User authentication and access control operations may be performed by a local identify module  330  that may interface with trusted controller  341  in providing user authentication. 
     In some cases, each instantiated workspace  331 A-N may be an environment that provides a user with access to requested data or applications, where the environment may be isolated in varying degrees from the hardware and software of IHS  300 B based on the security context and productivity context in which each workspace  331 A-N is operating. In some instances, the selection of a data source or resource that are available to user via launch point  203  may result in launching a new workspace. For instance, if a user launches a browser through selection of an icon displayed by launch point  203 , a new workspace may be created and launched according to a workspace definition that has been selected for providing the user access to a web browser in the security and productivity contexts in which the request has been made. In a scenario where the user double clicks on a confidential presentation file available from a data source that is provided by launch point  203 , an additional workspace may be instantiated with a presentation application providing access to the requested presentation file, where this new workspace is created based on a workspace definition that provided appropriate security for access to the confidential presentation). In other instances, a selection of the presentation file by a user may result in the presentation being made available through the existing workspace, in some cases using the existing workspace definition and, in other cases, using a workspace definition that has been modified to support the requested access to the confidential presentation file. 
     Although workspaces  331 A-N supported by IHS  330 B may each be isolated to varying degrees from the hardware and/or software of IHS  300 B and from each other, a user of IHS  330 B may expect to be able to operate the multiple workspaces  331 A-N in a manner that allows content to be transferred between the different workspaces  331 A-N. For instance, a user may select a portion of the data displayed in workspace  331 A and utilize operating system or other workspace functions to copy the data for copying to workspace  331 B. 
     In various embodiments, a local management agent  332  may operate in full or in part on a secure platform  345  hosted by trusted controller  341  that operates independent from the operating system of IHS  300 B. In some embodiments, all or part of local management agent  332  may operate as trusted components of the operating system of IHS  300 B. To execute the various operations described herein, local management agent  332  may include a command monitor  334  configured to provide instrumentation to receive commands from workspace orchestration service  300 A and thus enable access to IHS  300 B. Local management agent  332  may also include telemetry module  335  that may be configured for communicating collected information to the workspace orchestration service  300 A, including reporting changes in context that may warrant adjustments to workspaces  331 A-N. Data aggregator  336  may track all of the data source and other resources (e.g., applications, local or cloud-based services) that may be provided to the user via a workspace. 
     Local management agent  332  may utilize a resource manager module  337  that is configured to manage access to data, network configuration, such as for VPNs and network access, identity information, access control, and resource provisioning services. Security module  338  may be configured to provide various security services. BIOS interface  339  may provide a secure BIOS interface used for accessing and managing credentials in secure object storage. A BIOS analytics module  340  may be configured to perform forensic services for BIOS telemetry and health assessments. Persistence module  346  may be configured to support persistence of applications entitled at a POS or assigned by administrators and supported with required license tracking. Workspace attestation module  333  may provide a platform centric service layer on top of a container engine provided by local management agent  332  and may be used to measure and attest workspaces  331 A-N in any suitable manner defined or orchestrated by condition control  305 . 
     As part of secure platform  345 , native management module  347  may be configured to enable out-of-band management interface with workspace orchestration service  206 , where this OOB interface operates independent form the OS of IHS  300 B. In some embodiments, the OOB management interface supported by native management module  347  may be utilized by the device configuration services  316  of the workspace orchestration service to access the secure platform services  345  of IHS  300 B. 
     Digital device ID module  348  may provide a unique, unspoofable, cryptographically bound identifier. In embodiments supporting a secure platform  345 , secure embedded controller  341  may be a hardened hardware module that may include a root of trust module  342  configured as a trusted data store and, in some cases for cryptographic processing, that may be trusted within a cryptographic system. A device attestation service  343  may be configured to perform device assurance and trust services (e.g., secure BIOS and secure boot, etc.). A secure object store  344  may be provided that is configured to lock and access keys, hashes, and/or other secrets in an EC and/or trusted platform module (TPM). 
     In some scenarios, IHS  100  may be provisioned by a manufacturer that also controls manufacturer integration components  317 , workspace attestation module  333  may operate in conjunction with secure object store  342 , authenticated BIOS module  339 , and/or digital device identity module  348 , etc., to further secure and/or control productivity features available in any of workspaces  331 A-N based upon hardware devices and settings unique to that IHS and/or designed specifically by that manufacturer. 
     To further illustrate how the systems and methods described herein operate to modernize workspace and hardware lifecycle management in an enterprise productivity ecosystem, three non-limiting use-cases or examples are discussed in turn below. 
     Use-Case A 
     In use-case A, a given user may request access to a protected data source on the enterprise&#39;s premise using a corporate-owned and imaged notebook, such configured as described with regard to IHS  100  of  FIG.  1    and client IHS  300 B of  FIG.  3   . 
     In response to the request, a local management agent  332  operating on the user&#39;s notebook retrieves information describing the current context and calculates security and productivity targets based on the determined context. In this use-case, the local management agent may have been installed by IT, and it may be running in the background as a service. The confidential data may be associated with the local management agent on the local machine, based on file classification (e.g., file metadata/type/properties/permissions, folder location, encrypted region, etc.). Moreover, the local management agent may continuously collect current context information and send it to the orchestration service for use in scoring the risk and productivity of the workspace (this may also be done at the time of the user&#39;s access request or indication of intent). 
     When the user selects the confidential data, such as via a selection via the OS of the notebook, the local management agent notifies the workspace orchestration service of the request and for a workspace definition for a workspace by which the user may be provided access to the confidential data. 
     In this example, the workspace orchestration service may score an overall security risk to have a value of “2,” using a weighed, machine learning, or artificial intelligence algorithm, based upon the following context information or inputs, each of which is also given as a risk metric based upon a selected policy: locale: 1 (safe locale); user persona: 1 (known high-confidence in a reasonably sophisticated user classification—a user whom historically does not click on phishing emails); network risk: 1 (low risk because of on premise, wired connection detected); device risk: 1 (high level of control because of corporate owned/managed platform, known versions, security features enabled, etc.); regulatory: 1 (based on user, data, location combinations—e.g., No restrictions with respect to General Data Protection Regulation or “GDPR,” Health Insurance Portability and Accountability Act “HIPAA,” Payment Card Industry “PCI,” technology export, etc.); and data type: 8 (a confidential datafile is being requested). 
     The workspace orchestration service may also calculate a productivity score to have a value of “9,” using a weighed, machine learning, or artificial intelligence algorithm, based upon the following context information or inputs, each of which is also given as a resource metric based upon a selected policy: locale: 10 (office); user persona: 9 (a “skilled” classification based upon advanced compute tasks, proficiency, and/or speed); network speed/latency: 10 (fast, wired, Gigabit Ethernet, or direct to internal network); device performance: 8 (fast, expensive CPU, memory, graphics, but storage only needs—e.g., &lt;10 GB); and data type: 10 (the local, confidential file is easy to read/write with low latency and high performance on local storage). 
     Second, based upon the security score and/or context information, the workspace orchestration service builds a workspace definition file having any suitable structure with workspace definition attributes in a machine-readable format (e.g., JSON name-value, XML structured, etc.). In this example, the security target may be deemed to have a value of “1” based upon a combination of attributes values representing loads, needs, or demands on security controls and containment features that may include: threat monitoring: 1 (low demand); threat detection: 1 (low demand); threat analytics: 1 (low demand); threat response: 1 (low demand); storage confidentiality: 2 (low); storage integrity: 2 (low); network confidentiality: 1 (low); network integrity: 1 (low); memory confidentiality: 1 (low); memory integrity: 1 (low); display confidentiality: 1 (low); display integrity: 1 (low); user authentication: 1 (low, basic password is fine, non-multifactor authentication or “MFA,” no session expiration); IT administrator scope: 1 (administrator manages remotely but does not need heavy remediation software; and regulatory compliance: 1 (no GDPR, No HIPAA, no PCI, no tech export restriction, etc.). 
     Based upon the productivity target and/or context information, a productivity target for the workspace definition may be deemed to have a value of “9” (defining a high-quality, responsive user experience) based upon a combination of attribute values representing productivity requirements as follows: local storage: 7 (partial hard drive control, some storage reserved for IT load); CPU access: 10 (unlimited); local graphics: 10 (unlimited); and application stack: 10 (can use applications, install applications that the user needs, give them administrator rights, etc.). 
     Third, after the workspace definition is complete, the workspace orchestration service and the local management agent may assemble the workspace and instantiate it for the user. For example, the local management agent may receive definition files (e.g., JSON, XML, etc.) from the orchestration service, and it may parse the file to implement security risk controls such as: threat monitoring: 1 (local management agent does not install threat, detection, and response or “TDR” software); threat detection: 1 (local management agent does not install TDR software); threat analytics: 1 (orchestration does not need to gather detailed telemetry from the system, OS will not be enrolled in logging); threat response: 1 (local management agent does not install security threat response agent); storage confidentiality: 2 (local management agent deploys a local file-system encryption product that the user can optionally enable on specific files as needed with right-click context menus); storage integrity: 2; network confidentiality: 1 (local management agent confirms basic firewall configuration is correct—e.g., IT GPO-controlled); network integrity: 1; memory confidentiality: 1 (local management agent confirms configuration—e.g., No SGX, TXT, or container/sandbox software deployed); memory integrity: 1; display confidentiality: 1 (local management agent confirms graphics drivers installed, privacy screen and camera optionally managed by user); display integrity: 1; user authentication: 1 (local agent confirms basic GPO password rules are configured, and met by user—e.g., number of characters, no session expiration, etc.); IT administrator scope: 1 (local agent runs with system privilege, confirms IT admin accounts are listed in local admin user group—e.g., per GPO); and regulatory compliance: 1 (local agent does not install any compliance assistance software). 
     After confirming the configuration, the workspace orchestration service and the local management agent may give the user access to the requested local confidential file, and the user may begin working in a newly created workspace. 
     Use-Case B 
     In use-case B, a user may request access to a confidential datafile while at a coffee shop using an open public network and an IT-managed/owned PC, such configured as described with regard to IHS  100  of  FIG.  1    and client IHS  300 B of  FIG.  3   . 
     First, a local management agent ( 332 ) executed by a client IHS ( 300 B) retrieves the requested context and calculates security and productivity scores based on context. In this use-case, the local management agent may have been installed by IT, and it may be running in the background as a service. The confidential data may kept on a shared IT-managed network resource on-premises (e.g., back in a main corporate office), and the local management agent may be responsible for monitoring when this data path is requested by the user (e.g., the user hits a specific URL, IP, etc.). Moreover, the local management agent may continuously collect all current context and send it to the workspace orchestration service to assist in scoring processes later (this may also be done at the time of the user&#39;s access request or indication of intent, rather than a continuous collection). 
     When the user selects the desired confidential datafile, the client IHS ( 300 B)&#39;s OS calls the local management agent associated with the path to the confidential datafile and calls back to a remote workspace orchestration service ( 206 ) to request a workspace definition. 
     In this example, the workspace orchestration service may score an overall security risk to have a value of “4,” using a weighed, machine learning, or artificial intelligence algorithm, based upon the following context information or inputs, each of which is also given as a risk metric based upon a selected policy: locale: 5 (public, safe country); user persona: 5 (new user, classification data does not exist yet); network risk: 5 (medium, public but common location, wireless connection detected); device risk: 1 (high level of control, corporate owned/managed platform, known versions, security features enabled, etc.); and regulatory: 1 (based on user, data, location combinations—e.g., no restrictions with respect to General Data Protection Regulation or “GDPR,” Health Insurance Portability and Accountability Act “HIPAA,” Payment Card Industry “PCI,” technology export, etc.). 
     The workspace orchestration service may also calculate a productivity score to have a value of “5,” using a weighed, machine learning, or artificial intelligence algorithm, based upon context information or inputs, each of which is also given as a resource metric based upon a selected policy. For instance, security contexts inputs may include: locale: 6 (remote location but in USA major city, in a public area, non-employees are within visual/audio range of device); user persona: 5 (unknown confidence “null” classification, uses default onboarding assumptions); network speed/latency: 4 (medium, wireless but AC on shared network); and device performance: 8 (fast, expensive CPU, memory, graphics, but storage only needs ˜&lt;10 GB). 
     Second, based upon the security score and/or context information, the workspace orchestration service builds a workspace definition file having any suitable structure with workspace definition attributes in a machine-readable format (e.g., JSON name-value, XML structured, etc.). In this example, a security target may be deemed to have a value of “4” based upon a combination of attributes values representing loads, needs, or demands on security controls and containment features as follows: threat monitoring: 4 (medium demand); threat detection: 4 (medium demand); threat analytics: 4 (medium demand); threat response: 4 (medium demand); storage confidentiality: 4 (medium); storage integrity: 9 (high); network confidentiality: 5 (medium); network integrity: 2 (low); memory confidentiality: 4 (medium); memory integrity: 8 (high); display confidentiality: 7 (medium/high—worried about “shoulder surfers” reading data from an adjacent seat or table nearby, public location) display integrity: 2 (low); user authentication: 4 (medium, two-factor authentication using a hardware token, session expiration upon sleep, screen lock, or logout); IT administration scope: 3 (administrator can monitor, manage, and remediate remotely if the user calls them for help with IT issues); and regulatory compliance: 1 (no GDPR, No HIPAA, no PCI, no tech export restriction, etc.). 
     Based upon the productivity target and/or context information, a productivity target for the workspace definition may be deemed to have a value of “7” (defining a high-quality, responsive user experience) based upon a combination of attribute values representing productivity requirements as follows: local storage: 7 (partial hard drive control, some storage reserved for IT load); CPU access: 10 (unlimited); local graphics: 10 (unlimited); and application stack: 7 (can use applications, can install some IT-approved applications that the user needs, but no administrator rights, because the user cannot be trusted to install only valid/safe productivity software, but can install pre-approved IT applications as needed). 
     Third, after the workspace definition is complete, the workspace orchestration service and the local management agent may assemble the workspace and instantiate it for the user. For example, the local management agent may receive definition files (e.g., JSON, XML, etc.) from the orchestration service, and it may parse the file to implement security risk controls such as: threat monitoring: 5 (local management agent installs or confirms prior installation/configuration of TDR software); threat detection: 5 (local management agent installs or confirms prior installation/configuration of TDR software); threat analytics: 5 (orchestration confirms telemetry is accessible, OS will be enrolled in logging if not already enrolled); threat response: 2 (local management agent downloads but does not run remote incident response application-preparation in case incident is detected); storage confidentiality: 5 (local management agent deploys a local container technology, such as sandbox, with restricted “save” permissions such that the confidential files will not be allowed to save locally on the PC, but can be accessed as long as the session is active in memory); storage integrity: 5; network confidentiality: 5 (local management agent steps up firewall protections, disabling all unnecessary ports, and establishes a VPN back to the corporate office for protecting traffic to the local sandbox); network integrity: 5; memory confidentiality: 5 (local management agent configures sandbox container to isolate application and data from other applications/threats that may infiltrate the host OS); memory integrity: 5; display confidentiality: 7 (local management agent confirms graphics drivers installed, enforces privacy screen and uses camera to detect specific onlooker threats); display integrity: 7; user authentication: 4 (local agent confirms basic GPO password rules are configured, and met by user—e.g., number of characters, no session expiration, etc., but also adds in a requirement for hardware token to log in and again to establish network); IT administrator scope: 4 (local agent runs with administrator and remote access privilege, confirms IT admin accounts are listed in local admin user group—e.g., per GPO); and regulatory compliance: 4 (local agent installs state specific rule enforcement or monitoring software). 
     After confirming the configuration, the workspace orchestration service and the local management agent may give the user access to the requested local confidential file, and the user may begin working in a newly created workspace. 
     Use-Case C 
     In use-case C, a user may request access to a confidential datafile in a web hosted remote portal using a browser from Kazakhstan, while at an internet café with a borrowed/rented PC, such configured as described with regard to IHS  100  of  FIG.  1    and client IHS  300 B of  FIG.  3   , on an open WiFi network. 
     First, a remote workspace orchestration service ( 332 ) intercepts the access request and evaluates the browser and user context, and calculates security and productivity scores. In this use-case, there is no local management agent; all that is known is the browser and any telemetry returned or garnered through the HTTP/S session. Assume, for sake of this example, that the confidential data may kept on a shared IT-managed network resource on-premises (e.g., back in a main corporate office) and that the datafile will remain there with only remote rendering/access privileges. Web-based context may be gathered through the browser session or supplied by the user. Moreover, user context may also be collected for the workspace orchestration service through alternate side-channels (e.g., travel calendar information, recent user billing activity on corporate credit card, phone call logs, and/or location data). 
     When the user selects the desired confidential datafile from the web browser, the back-end web server infrastructure calls back to the workspace orchestration service to request a workspace definition. 
     In this example, the workspace orchestration service may score an overall security risk to have a value of “9,” using a weighed, machine learning, or artificial intelligence algorithm, based upon the following context information or inputs, each of which is also scored as a risk metric based upon a selected policy: locale: 9 (Kazakhstan); user persona: 1 (user was expected to be there, the timing seems right based upon past logins, and he has a biometric watch communicator proving he is alive, himself, and located where he says he is—so that IT can always trust him); network risk: 9 (high, public and in a very obscure place); device risk: 9 (zero trust); and regulatory: 8 (based on user, data, location combinations). 
     The workspace orchestration service may also calculate a productivity score to have a value of “5,” using a weighed, machine learning, or artificial intelligence algorithm, based upon the following context information or inputs, each of which is also given as a resource metric based upon a selected policy: locale: 3 (internet café device without great performance); user persona: 9 (known high-confidence and “skilled” classification—advanced compute tasks, proficiency, and speed); network speed/latency: 3 (low quality—Wireless G from a long way away); and device performance: 3 (have to be able to tolerably browse web pages but based on what the service believes the capabilities will be, the service should build simple ones). 
     Second, based upon the security score and/or context information, the workspace orchestration service builds a workspace definition file having any suitable structure with workspace definition attributes in a machine-readable format (e.g., JSON name-value, XML structured, etc.). In this example, a security target may be deemed to have a value of “9” based upon a combination of attributes values representing loads, needs, or demands on security controls and containment features as follows: threat monitoring: 10 (high demand, to be handled on the server side); threat detection: 10 (high demand, to be handled on the server side); threat analytics: 10 (high demand, to be handled on the server side); threat response: 10 (high demand, to be handled on the server side); storage confidentiality: 10 (high demand, to be handled on the server side); storage integrity: 8; network confidentiality: 10 (high demand, to be handled on the server side); network integrity: 9; memory confidentiality: 10 (high demand, to be handled on the server side); memory integrity: 9; display confidentiality: 10 (high, “shoulder surfers” may read datafile from an adjacent seat or table nearby in a public location); display integrity: 9; user authentication: 10 (high, three-factor authentication using login, hardware token, and biometric satellite watch—session expiration and refreshes every 30 seconds); IT administrator scope: 8 (administrator may monitor, manage, and remediate remotely if the user calls them for help or anything unexpected happens); and regulatory compliance: 10 (all network traffic is securely monitored as will the data presented). 
     Based upon the productivity target and/or context information, a productivity target for the workspace definition may be deemed to have a value of “3” (defining a usable secure user experience primarily built for consumption and not productivity) based upon a combination of attribute values representing productivity requirements as follows: local storage: 1 (cache only); CPU access: 3 (build for limited expectations); local graphics: 3 (build for limited expectations); and application stack: 1 (web browser experience on a kiosk mode device, limited data entry capability, limited read access to need-to-know only information through VDI rendered kiosk). 
     Third, after the workspace definition is complete, the workspace orchestration service and remote cloud web portal (e.g., session the user logged into through the browser) may assemble the workspace and instantiate it for the user in the browser. For example, the web portal may receive definition files (e.g., JSON, XML, etc.) from the orchestration service, and it may parse the file to implement security risk controls such as: threat monitoring: 9 (data center based management agent installs or confirms prior installation/configuration of TDR software); threat detection: 9 (data center based management agent installs or confirms prior installation/configuration of TDR software); threat analytics: 9 (orchestration confirms telemetry is accessible, server hosting web server may be enrolled in logging if not already enrolled—user behavioral telemetry from side channels may also be continuously monitored for suspicious/anomalous activity); threat response: 10 (data center-based management agent sets up watchdog timer to kill session automatically without periodic check-ins from orchestration, user telemetry, and web browser); storage confidentiality: 9 (data center-based management agent builds a progressive web application that may be used to display the data through a secure TLS link—the data will be rendered but only the as-needed portions of visualization presented to the user, and nothing can be saved); storage integrity: 10; network confidentiality: 9 (route traffic through best effort to secure locations—do not allow anything except bitmap renderings through the enforceable network); network integrity: 4; memory confidentiality: 9 (web page viewer only—no data leaves the data center, no confidential input is taken from the rented PC, no keyboard input is allowed, and all input may be captured from randomized virtual keyboard using mouse click coordinates); memory integrity: 8; display confidentiality: 8 (best effort to ensure confidentiality—prompt user at least—adjustable font sizes, but defaults to small fonts, obfuscated text, etc.); display integrity: 2; user authentication: 9 (local agent confirms basic password rules are configured, and met by user—e.g., number of characters, no session expiration, etc., but also adds in a requirement for hardware token and biometric, satellite watch to log in and again to establish network, requiring frequent reconfirmation from user); IT administrator scope: 7 (data center-based remote environment); and regulatory compliance: 8 (local agent does not exist but data center-based agent monitors/blocks data not appropriate). 
     After confirming the configuration, the workspace orchestration service and the local management agent may give the user access to the requested rendered data, and the user may begin working in a newly created workspace. 
       FIG.  4    is a flowchart describing certain steps of a process according to various embodiments for securing a dynamic workspace in an enterprise productivity ecosystem. The illustrated embodiment begins at block  405  with the user, using an IHS such as described with regard to  FIGS.  1  and  3   , selecting data or an application managed by an enterprise productivity ecosystem, such as described with regard to  FIGS.  2  and  3   , and made available via a launch point. For instance, a user may request access to a data source managed via the enterprise productivity ecosystem. Such a data source may include a remote drive located on a specific server, a remote virtual drive accessed via a cloud system or a data source located on the user&#39;s IHS. In some instances, the data source may be particular folder or file that is located in one of these locations. In other instances, the user may initiate the process of  FIG.  4    by requesting access to an application or service that is available via a launch point provided by a local management agent. 
     Upon detecting a request for access to managed data or managed resource, at block  410 , the workspace orchestration service may authenticate the identity of the user making the request. In some embodiments, the local management agent may have previously authenticated the user in order to grant the user access to the launch point and to determine the managed data sources and applications to present to the user via the launch point. In some instances, results from such an authentication by the local management agent may be provided to the workspace orchestration service. In some embodiments, additional authentication may be required in order to evaluate a user&#39;s request and to determine a risk score for the user&#39;s request. Accordingly, additional authentication factors may be required to determine the identity of the user at block  410 . 
     The identity information for the user may be collected by the local management agent and provided to the workspace orchestration service. At block  415 , the workspace orchestration service may evaluate one or more attributes describing the level of risk presented by the user. For instance, the user may be identified as a high-risk guest user, a high-risk employee with a history of security issues, a normal-risk employee user, a moderate-risk invited guest user, a moderate-risk contract employee user, a low-risk expert employee user with no history of security issues, or a low-risk administrative user. 
     Additionally, or alternatively, persona groups may be utilized in categorizing the level of risk presented by user, such as whether the user is a full-time or part-time employee, or a business department (e.g., finance, human resources, engineering, sales, technical support, legal, etc.) to which the user belongs. In certain instances, different levels of risk may be associated with different persona groups. For instance, finance users may be associated with a low risk since they almost access few types of data and do so from a fixed location within a corporate facility, whereas sales users may be associated with a high-risk since they access various types of data from varied locations. 
     In some embodiments, the level of risk presented by a user may be evaluated based on the length of time the user has been affiliated with the provider of the workspace orchestration service or the length of time the user has been an employee of a particular company. Additionally, or alternatively, the level of risk presented by a user may be evaluated based on historical or behavioral information associated with a particular user, such as whether the user was previously determined to have violated security policies or failed to follow best practices utilized by the enterprise productivity ecosystem. 
     In additional embodiments, a privilege status classification associated with a user (e.g., admin, guest, etc.) may indicate a level of risk. In such embodiments, changes in privilege status classifications may also indicate risk context information. For instance, historical privilege status classifications may indicate a recent change of a user&#39;s privilege classification from a regular user to an administrative user. Such a scenario may indicate a possible security breach using this account, thus warranting an elevated risk score for a workspace request from this user. 
     In addition to authenticating the identity of the user making the request, the identity of the IHS used to make the request may also be authenticated. In some embodiments, the identity of the IHS may be determined based on a unique identifier associated with the IHS, such as a service tag or serial number or device ID of  FIG.  3   . Based on such unique identifiers, an IHS may be particularly identified by the workspace orchestration service and, in certain instances, may be used to determine specific hardware and software capabilities of the IHS. 
     As described with regard to IHS  100  of  FIG.  1   , the integrity of various components of an IHS may be confirmed using reference signatures generated for these components during a trusted manufacturing process of an IHS or during trusted administration of an IHS. In such embodiments, the identity of an IHS may be authenticated as being a particular IHS that includes components that can be confirmed as being non-compromised. At block  420 , the local management agent of an IHS may collect identity information that is provided to the workspace orchestration service where, at block  425 , the hardware identity information may be used to determine risk attributes associated with the hardware of the IHS. 
     The risk attributes of the IHS hardware may indicate a level of risk associated with a particular IHS. A highest risk level may be assigned to an IHS for which little or no hardware information is available, such as a guest user operating an unrecognized IHS. A high-risk level may also be assigned to an IHS that can be confirmed as being previously compromised, such as based on log information associated with that particular IHS. 
     A moderate risk level may be assigned to an IHS from a first manufacturer with a history of security issues, while a lower risk level may be assigned to an IHS from a second manufacturer with fewer security issues. An IHS utilizing internal hardware components with outdated firmware may be assigned a higher risk level than an IHS utilizing the latest firmware for internal hardware components. A medium risk level may be assigned to an IHS that has been configured in a non-recommended manner, such as configuring UEFI attributes to disable secure boot procedures on the IHS or enabling use of certain USB or other I/O ports. A lowest risk level may be assigned to a recognized IHS that can be confirmed as utilizing non-compromised hardware elements, such as based on verification of firmware signatures. 
     At block  430 , the software identity of the IHS used to make the request may be determined. The software identity of the IHS describes the logical environment in which a workspace may be deployed. In certain instances, the software identity of an IHS may be indicated by the operating system of the IHS and may include version information for the operating system and updates and patches that have been applied to the operating system. The software identity of the IHS may also identify security-related software applications supported by the operating system, including security applications such as firewalls, anti-virus software and security suites such as DELL DATA GUARDIAN that may be configured to securely manage credentials and other security information stored in a secure component such as the trusted controller  115  supported by IHS  100  of  FIG.  1   . 
     The software identity of the IHS may also identify all applications and/or processes operating within the operating system of the IHS. In such embodiments, the software identity information may further include version information and update information for some or all of the applications presently running in the operating system of the IHS. The update information may indicate whether specific patches (e.g., patches addressing specific security vulnerabilities) have been installed on the IHS and/or the date of the most recent patch to the IHS or to an application of the IHS. As described, in some embodiments, the local management agent may operate in full or in part within a secure execution environment running on a trusted controller that operates separate from the OS of the IHS. The software identity of the IHS may thus also include the level of isolation of the local management agent. 
     As with the hardware identity information of the IHS, the software identity information may be provided to the workspace orchestration service. At block  435 , the software identity information may be used in determining risk attributes associated with the logical environment of the IHS from which the user has requested access to a managed data source or other resource. For instance, a high-risk logical environment may be indicated based on the lack of updates to the operating system of the IHS. 
     A lower-risk logical environment may be indicated when the applications operating within the operating system are predominantly for providing the user with media outputs, such as a media player or gaming application, where user inputs are not used for data entry. A moderate-risk logical environment may be indicated by an updated operating system in which several other applications are in use, including applications that support user inputs, such as a word processing application, that may be used to manually reproduce information provided via a workspace that would also operate within the operating system. A moderate-risk logical environment may also be indicated any time an application, such as an email client or FTP client, is operating that supports transmission of data files. A higher-risk logical environment may be indicated when one of the applications is a web browser that may provide a user with a wide range of web-based tools and applications, such as web-based email and file transfer, that may not be readily monitored or tracked. 
     In many scenarios, the physical environment in which the IHS is located may be indicative of risk. At block  440 , the physical location of the IHS may be determined. As described with regard to  FIG.  1   , an IHS according to embodiments may be configured to collect various types of location information. For instance, geographic coordinates of an IHS may be collected from available sensors or generated based on triangulation information. Location information may also be ascertained based on the identity of network broadcast signals that are detected by the network interfaces of the IHS. In some embodiments, the precision of determined location information may be improved based on the strengths of various wireless signals that are detected by the IHS, thus providing an ability to identify the location of an IHS within a specific room or other area. In some embodiments, such location information may be collected by the local management agent operating on IHS as part of a request for access to a managed data sources or other resources. 
     At block  445 , the location information reported by a local management agent may be utilized by workspace orchestration service in order to determine risk attributes associated with the physical location of the IHS. The workspace orchestration service may utilize the received location information in order to determine a risk attribute associated with that location. A low-risk physical location may be indicated by determining that the IHS is located at the user&#39;s work location based on network information broadcast by a wireless network provided by the user&#39;s employer. A moderate-risk physical location may be indicated by location information indicating the IHS is located at a regularly used location, such as a coffee shop in the vicinity of the user&#39;s employment, via a public wireless network. A moderate-risk physical location may also be indicated by location information indicating the IHS is in use while the user is a passenger in an airplane, vehicle or public transit and is utilizing any available cellular or public wireless networks. A higher-risk physical location may be indicated by location information indicating the IHS is located at an unrecognized location and using a public wireless network with multiple additional wireless networks also detected by the IHS. A high-risk physical location may also be indicated by location information indicating the IHS is located in a country, city, geo-fenced area, facility, postal code, area code, or other geographic area that has been categorized as being indicative of a high-risk area. A high-risk physical location may also be indicated by location information indicating a suspicious change in location of the IHS. For instance, IHS may be identified as being located at the user&#39;s regular place of employment in the United States during the morning but, later that afternoon, location information is received that asserts the IHS is now located in Europe. 
     At block  450 , risk attributes may be determined for the data source or other resource that has been requested. In some scenarios, a risk classification may be determined directly based upon a classification associated with a data source, application, service or other resource, such as using a designation of data as being confidential, secret, public or privileged. A risk classification may also be determined based on a type of data that is being requested. For instance, a file type associated with financial information or with detailed engineering schematics may indicate high risk data, whereas a request for a streaming media file may indicate low risk data. Risk classification may also be determined based on the location in which requested data is stored. For instance, high risk data may be indicated by its storage in a secured memory of the IHS or another local storage that is integral to the IHS and has been designated for use in storing important managed data. Moderate risk data may be indicated by storage in a local or remote storage that has been designated for general use. Moderate risk data may be indicated by a storage in a trusted and recognized cloud resource, whereas higher risk data may be indicated by a storage in an unrecognized cloud resource. 
     In various embodiments, risk attributes such as described above may be generated in any suitable combination of the sequence of operations described above such that the steps of  FIG.  4    may be performed in any order and/or concurrently. Embodiments may utilize any or all of the collected information describing the context in which a workspace will be instantiated in order to generate risk attributes. In some embodiments, data used in generating risk attributes may collected by a local management agent operating on the IHS and may be communicated to the workspace orchestration service for evaluation and calculation, at  455 , of a risk score associated with the request. In some embodiments, a risk score may be of numerical value within a defined range or scale, such as a risk score between zero and one hundred, or a rating between one and ten. 
     Embodiments may utilize machine learning techniques in the calculation of risk scores. For instance, the various security attributes that evaluate the levels of risk associated with the user, physical environment, logical environment, IHS, and data may be provided as inputs to machine learning algorithms. In such embodiments, a numerical risk score may be generated as an output of the machine learning. The training of machine algorithms used in this manner may be accomplished through use of training sets of requests for data or other resources, where each request in the training data is associated with context information and risk attributes for that context. Such manual training sets may also associate specific risk scores with different combinations of risk attributes. Once trained, the machine learning capabilities may be used to generate risk course for various contexts that not included in the training set and using new types of risk attributes, such as risk levels associated with new types of managed data sources, or with new types of physical locations, or with new metrics specifying levels of risk associated with users. 
     The generated risk score associated with a request may be utilized, at  460 , in order to determine the security characteristics for a workspace that supports complying with the request. For instance, a lowest risk score may be associated with a request by an authenticated user of a recognized IHS at a trusted location, where the request seeks access to an application such as a web browser, gaming application or a streaming media player. In response to a request with a such a low risk score, a workspace definition may be selected that specifies minimal isolation of the workspace, places no restrictions on the protocols that may be used in the transmission of data to and from the workspace, requires no additional authentication and places no restrictions on the transfer of data to or from workspace. A moderate risk score may be associated with a request for regularly accessed data by an authenticated user of a recognized IHS that is at an unrecognized location within a vicinity of the user&#39;s employment. In such a scenario, a workspace definition may be selected that specifies minimal isolation of the workspace but places requirements on encryption levels that must be utilized and requires periodic reauthentication of the user. In a higher risk scenario, the same user may now request access to rarely used financial information while at an unrecognized location that is located in another country. In such a scenario, a workspace definition may be selected that specifies a greater degree of isolation, places stringent requirements on the use of encryption, requires confirmation of the user&#39;s identity using additional authentication factors and requires periodic authentication of the user and requires the user remain in close proximity to the IHS. A higher risk scenario may be presented by a newer user utilizing an IHS that is unrecognized or that cannot be validated as using non-compromised hardware. Such a risk score may be associated with a workspace definition that requires use of a secured and isolated memory by the workspace. A high-risk scenario may also be presented by a recognized user requesting access to high risk data while utilizing an unrecognized IHS from an unrecognized location. In such a scenario, a workspace definition may be selected that requires maximum isolation of the workspace in which the workspace is instantiated on a cloud resource and only an immutable image of the requested data is provided via the IHS and maximum use of available authentication factors is required in order to positively confirm the identity of the user. 
     In this manner, risk score may be utilized in selecting a workspace definition that provides protections that are suited to the context in which managed data or other resources will be used. Workspaces generated in this fashion thus promote providing users with maximum productivity in scenarios where risk levels are low and appropriately reducing productivity in order to enforce additional security requirements as the risk levels associated with requests increase. Upon determining security requirements for a workspace complying with the user&#39;s request and generating a workspace definition that specifies the security requirements, at  465 , the workspace orchestration service may transmit the workspace definition to the IHS, where the definition may be used by the local management agent to build and operate a workspace that provides the user with access to the requested data or other resource. 
       FIG.  5    is a flowchart describing certain steps of an additional process according to various embodiments for securing a dynamic workspace on an ongoing basis in an enterprise productivity ecosystem. The embodiment of  FIG.  5    may begin, at block  505 , with the instantiation of a workspace on IHS based on requirements set forth in a workspace definition selected as described in  FIG.  4    based on a risk score calculated based on risk attributes describing the context in which the workspace will be used. At block  510 , the user operates the workspace in use of managed data or other resources requested by the user. Being that the workspace definition that governs the operation of a workspace is selected based on the context at the time of the user&#39;s request, changes to the context may alter the risk score, now associated with the ongoing use of the requested data and/or application. Accordingly, at blocks  515 ,  520 ,  525 ,  530  various changes in the context of the ongoing use of the requested data or other resource may be detected. 
     For instance, at block  515 , the workspace orchestration service may receive notifications from the local management agent of changes to the logical environment in which a workspace is operating. In a scenario where a workspace operates as an isolated application within the operating system of the IHS, the initialization of certain operating system applications may warrant reevaluation of the risk associated with ongoing access to managed data via the workspace. For example, a workspace may provide the user with access to proprietary technical information, such CAD drawings, and use of an application for manipulating the technical information, such as a CAD application. Upon receiving notification that the user has initialized an email application or gained access to a data store not managed by the enterprise productivity ecosystem, reevaluation of the risk score associated with the ongoing use of the proprietary technical information may be warranted. Accordingly, at block  535 , the risk attributes associated with the ongoing use of the proprietary technical information may be determined, such as by upgrading the level of risk associated with the logical environment in which the workspace operates. 
     Similarly, at block  520 , the detection of requested access to additional data or other resources may be detected and provided to the workspace orchestration service. In certain instances, a workspace may have been generated to provide a user access with public or otherwise unprotected information. However, upon detecting an additional user request for access to confidential information, reevaluation of the security requirements for the workspace may be warranted. In another scenario, a workspace may provide the user with access to managed data and an application for viewing the managed data, but detection of a request for access to an application by which the managed data can be modified may require reevaluation of the workspace security requirements. At block  540 , updated risk attributes may be determined for the updated set of data or other resources that are being requested, such as by upgrading the level of risk associated with the data to be accessed via the workspace. 
     At block  525 , any modifications to the hardware identity of the IHS may be reported to the workspace orchestration service. For instance, coupling a removable storage device to the IHS may indicate a change in the security context. The coupling of a recognized storage device, such as a regularly used external hard drive, may result in only a minor change in the risk score for the ongoing use of data, whereas the coupling of an unrecognized thumb drive may result in a significant change in the risk score. At block  545 , updated risk attributes for the hardware environment in which the workspace operates may be determined. In another example, the detection of the coupling of the IHS to a recognized external display may result in a minor change in the risk score for ongoing use of data, whereas the coupling of the IHS to an unrecognized projection display may result in a significant change in the risk attributes associated with the hardware identity of the IHS. As described, in some embodiments, an IHS may support attestation of firmware used by hardware components. In such embodiments, any inability to attest previously validated firmware or the detection of unattested components may result in a significant change to the hardware identity of the IHS, resulting in a large change in risk scores. 
     Any detected changes in the physical environment of the IHS may be reported, at block  530 , to the workspace orchestration service. For instance, if the sensors of the IHS provide indications that the IHS is in transport, the security context may be expected to change based on the different networks that may be utilized while the IHS is mobile. Accordingly, any changes from a trusted network to a non-trusted network may result in significant changes to the risk attributes, determined at  550 , associated with the physical environment in which the IHS is located. In some embodiments, an IHS configured according to embodiments may detect when the user is present in proximity to the IHS and may also detect the presence of additional individuals in close proximity to the IHS. In such embodiments, the detection of additional individuals, and any available identity information associated with those individuals, may be reported to the workspace orchestration service. In some scenarios, continued access to confidential data may be contingent on the user providing additional authentication information when additional individuals are detected in proximity to the IHS. In other scenarios, the use of external displays may be disabled by a workspace in response to the detection of additional individuals in proximity to the IHS. 
     At block  560 , the updated risk attributes are utilized to generate an updated risk score for the ongoing access to requested data and/or applications in light of the detected change in context. As described with regard to  FIG.  4   , machine learning algorithms may be trained to calculate numerical risk cores based on inputs that characterize the various risk attributes that describe the context in which a workspace is deployed or will be deployed. At block  565 , the security characteristics of the currently deployed workspace, as specified by its workspace definition, are evaluated based on the updated risk score resulting from the change in security context. If the current workspace definition does not provide adequate security for the updated level of risk, at block  570 , an updated workspace definition is determined and transmitted for use by the local management agent in adapting or reinitializing the workspace based on the updated workspace definition. 
     In various embodiments, a user&#39;s workspace may be dynamically created and adjusted based on user requirements and environment context—which may result in greater productivity but it may also increase the security risk by producing a greater attack surface. For example, in some situations, a user may be allowed to install and execute non-vetted applications (e.g., to perform selected tasks) in a workspace, instead of being limited only to applications that have already been vetted, trusted, and/or recommended by Information Technology (IT) administrators and/or the workspace orchestration service  206 . In those situations, however, there is a higher probability that an unknown and/or non-vetted application may fail or get compromised, resulting in loss of workspace session, data, and productivity of the user. 
     To address these, and other issues, workspace orchestration service  206  may be configured to create an alternative or parallel workspace definition in the background (i.e., unbeknownst to, or unsolicited by, the user of client IHS  300 B), such that the alternative workspace definition is associated with or otherwise identifies a vetted application that corresponds to the non-vetted application. In some cases, the vetted application may be automatically identified, and it may have similar (or better) features for performing the user&#39;s workload, compared to the non-vetted application executed by the user in the original workspace. For example, an IT administrator may maintain a list or pool of vetted applications by continuously learning about the types of applications used (e.g., by employees in an organization) and security risks associated with the application, and a vetted application may be automatically selected from that pool. In some cases, the vetted application pool may be dynamic, applications may be added and removed from the pool based upon how vulnerable or patched they are. 
     In some implementations, a non-vetted application may include any software application that is identified on a blacklist (e.g., a list of forbidden applications) associated with, or part of, a workspace definition. In other implementations, a non-vetted application may include any software application that is not identified in, or is missing from, a whitelist (e.g., an exclusive list of allowed applications) associated with, or part of, the workspace definition. Additionally, or alternatively, a non-vetted application may also be a known unpatched version of the application. 
     When a user&#39;s original workspace with a non-vetted application gets compromised or fails, it may trigger the creation of a new workspace definition that includes an identification of a corresponding trusted or vetted application. Additionally, or alternatively, the criteria for initiating a workspace transition or migration may be an increase in the security risk score of the original workspace—which may be calculated by observing workspace behavior or large changes in the workspace from a baseline or threshold value. 
     Moreover, all (or a subset of all) user actions, data, and targets may be copied or cloned from the original workspace and used to create or populate attribute values in the new workspace definition. A new workspace may be instantiated using the new workspace definition, and the user may be transitioned or migrated smoothly to the new workspace, with the vetted application installed or executing, and with the same or similar session state as the original workspace immediately prior to the triggering event. 
     When the user is transitioned from an untrusted workspace (i.e., a workspace that has been compromised or that has a security risk score above a threshold) to a trusted workspace (i.e., the parallel, alternative workspace built or for the vetted application), the user does not lose any data or actions, and the session can be continued or handed off between the two workspaces without loss of productivity. 
     In some cases, the original, compromised workspace may be evaluated for identifying the reason for the failure. For instance, snapshots of the original workspace may be taken at multiple points during the original workspace&#39;s lifetime; e.g., when the security risk score crosses any of set of one or more threshold values. These snapshots may be used for security analysis of the compromised workspace using an ML or AI algorithm, and/or for automatic rollback in case of failure or compromise for faster remediation. 
     On the other hand, if the original workspace, despite executing a non-vetted application, does not fail or is not compromised until the end of the workspace session and/or until the unvetted application is closed, the transition or migration does not take place. Furthermore, this information (e.g., a statistical indication of success of execution) may subsequently be used by the IT administration to reduce the security risk score of the non-vetted application, and eventually move it into the vetted application pool, for example, after being evaluated from a productivity and security perspective. 
     As such, systems and methods described herein may enable the creation of alternative parallel workspace definitions with vetted applications for fast swapping in case of security compromise, failure, or increase in security risk score of the original, untrusted workspace. Moreover, these systems and methods may also enable the cloning of user actions and data, as well as of productivity and security targets, from the original workspace into the alternative workspace to enable the frictionless migration of a session between the two workspaces. 
       FIG.  6    is a diagram depicting an example of a method for workspace continuity and remediation. In various embodiments, method  600  may be performed through a cooperation between workspace orchestration service  206  and local management agent  332 . Particularly, at  601 , workspace orchestration service  206  creates a first workspace definition (“Z”). In some cases, the first workspace definition may list as an attribute, or otherwise be associated with, an unvetted or untrusted application (e.g., when the application is part of the user&#39;s originating access request). In other cases, the first workspace definition may be devoid of any attributes that restrict the user&#39;s execution of any unvetted application in an instantiated workspace. 
     As a result of client IHS  300 B&#39;s instantiation of a first workspace based upon the first workspace definition, the resulting workspace  602  allows the installation or execution of the non-vetted application. Then, at  603 , in response to the execution of the non-vetted application, local management agent  332  detects and transmits copied or cloned workspace session data, including, but not limited to: user actions (e.g., keystrokes, clicks, commands, menu selections, etc.), data context (e.g., identification of a datafile, current state of the data within the datafile, etc.), productivity target, and security target, to workspace orchestration service  206 . In response to receiving the copied or cloned session data, workspace orchestration service  206  creates a second workspace definition (“A”) at  608 , which identifies a vetted or trusted application (e.g., selected from a vetted application pool) that corresponds to the non-vetted or untrusted application of the first workspace. 
     In some embodiments, the vetted and non-vetted applications may each be offered by different software developers, but the two applications may be identified as being of a same type (e.g., two different web browsers, two different email clients, two different document processors, two different media editors, etc.). As a result, the two applications may perform similar operations to execute or facilitate the user&#39;s workload. For example, different web browsers may render web content subject to the same commands or features (e.g., back, forward, home, favorites, history, etc.), which may then be captured as the user actions portion of the workspace session data and translated between the web browsers to enable frictionless migration. 
     When the security risk score of untrusted workspace  607  increases above a threshold value, and/or the workspace fails or is compromised, local management agent  332  of client IHS  300 B issues a fast swap request to workspace orchestration service  206 . Workspace orchestration service  206  transmits one or more other files or policies configured to enable local management agent  332  at  609  to instantiate a second workspace based upon the second workspace definition, such that the second workspace definition allows immediate execution of a vetted application corresponding to the non-vetted application. Moreover, at  609 , session data previously collected by workspace orchestration service  206  may also be transmitted to local management agent  332  to maintain session continuity. 
     In an enterprise, the discovery of new and useful applications, as well as the re-definition of workspaces based on the requirement to load those applications for different users, may be performed manually. Typically, a user finds an application (e.g., via the Web, etc.) and submits a request to a procurement entity, which then purchases licenses for that application. Subsequently, IT manages and deploys licenses and software to the user who requested it. Other users would have to learn about the new application by navigating a catalog, getting training from IT, or through word of mouth. The inefficiencies involved in finding and launching new software can lead to “shadow IT” behaviors, where users take actions in conflict with IT policy because it would be faster than using proper channels, but which lead to potential security risks. Traditionally, it has been difficult for IT to evaluate, for each new application, whether a given user&#39;s needs outweigh the additional security risks. 
     To address these, and other issues, workspace orchestration service  206  may allow the execution of arbitrary, user-selected applications while continuously monitoring user installations and application behavior. If a new application is deemed safe (e.g., a security risk score calculated based upon security context information remains under a threshold value during execution of the application), the application may be automatically deployed to other users discovered through similar behavioral patterns (e.g., using k-means clustering, ML, or AI algorithms) and application usage, with cross-organizational evaluation of user context, to enhance productivity. In some cases, systems and methods described herein may evaluate installed applications in a workspace, aggregate context data, and evaluate security risks, and then use this information to help target the deployment of new applications to other users in real-time. 
       FIG.  7    is a diagram of an example of a method for dynamic workspace targeting with crowdsourced user context. In various embodiments, method  700  may be performed through a cooperation between workspace orchestration service  206  and local management agent(s)  332 . Particularly, at  701 , workspace orchestration service  206  creates first workspace definition  701 A, second workspace definition  701 B, and third workspace definition  701 C. These workspace definitions  701 A-C may be used to instantiate three different types of workspaces  703 A-C for different types of users or persona groups operating client devices  702 A-C (instances of  300 B). 
     In some cases, types of users or persona groups  702 A-C may be created based upon user profiles and/or other context information. For example, first persona group  702 A may include only software developers, second persona group  702 B may include only business users, and third type of persona group  702 C may include only customer support personnel across one or more enterprises. In this case, first type of workspace  703 A may be configured to execute base applications  704  (e.g., email client, calendar, document processor, etc.), which are the same across all users of the organization, as well as application  705 A (e.g., a command line terminal, etc.), available only to users of first persona group  702 A (e.g., software developers). Second type of workspace  703 B may be configured to execute base applications  704 , as well as application  705 B (e.g., accounting software, etc.) available only to users of second persona group  702 B (e.g., business users). And third type of workspace  703 C may be configured to execute base applications  704 , as well as application  705 C (e.g., a communication application, etc.) available only to users of third persona  702 C (e.g., customer support personnel). 
     As noted above, workspaces  703 A-C may be made flexible to accommodate changes in the needs of users in persona groups  702 A-C. In this example, workspace definitions  701 A and  703 C have attributes that allow users of their respective workspaces to download  706  new applications, install them, and execute them; whereas workspace definition  701 B does not allow users of persona group  702 B to download new applications. Accordingly, at least one of users of persona group  702 A executes new application  707 A in its respective instantiated workspace  703 A, and at least one of users of persona group  702 C executes new application  707 C in its respective instantiated workspace  703 C. 
     New applications  707 A and  707 C may be evaluated by workspace orchestration service  206  at  708  for various productivity context information (e.g., number of downloads, type of user, clustering of behavior, etc.) and security context information (e.g., code static or dynamic analysis for security, a risk metric associated with a locale of the client IHS, a risk metric associated with a user of the client IHS, a risk metric associated with a network of the client IHS, a risk metric associated with hardware of the client IHS, a risk metric associated with a requested datafile, or a regulatory risk metric associated with the user, the locale, and the requested datafile, etc.). 
     To validate a new application at  708 , workspace orchestration service  206  may determine that a productivity score calculated based upon the productivity context information meets or exceeds a productivity threshold associated with a corresponding workspace definition. Additionally, or alternatively, workspace orchestration service  206  may determine that a security risk score calculated based upon the security context information does not meet or exceed a security risk threshold associated with the corresponding workspace definition. Upon validation, initially non-vetted or untrusted applications  707 A and/or  707 C may be re-classified as vetted or trusted applications  708 A and/or  708 C. 
     After the evaluation, validated applications may be targeted for deployment in appropriate workspace definitions depending on the user persona&#39;s needs. For example, workspace orchestration service  206  may create new workspace definitions  709 A-C to be deployed to users of persona groups  702 A-C. In this case, new application  708 C is executed in each of workspaces  710 A-C to all users in all persona groups  702 A-C, and new application  708 A is executed in workspace  710 A to all users of persona group  702 A (but it is not distributed to users of other groups). 
     In various systems and methods described herein, persona groups  702 A-C may be created and/or assigned to each user based not only on the user&#39;s static role in an enterprise, but also on other contextual information collected during a user&#39;s operation of a given workspace, such that changes in a user&#39;s behavior (e.g., with respect to historical and/or expected behavior for members of a given persona group) are reflected in the contextual information. 
     For example, in some cases contextual information may be used to classify the user as belonging to another existing persona group. Alternatively, contextual information may be used to create a new persona group. In response to the user being assigned to another persona group, the workspace may be terminated and another workspace may be deployed using a different workspace definition associated with the other persona group. 
     Moreover, these systems and methods may be configured to migrate users to temporary persona groups based on outlier behaviors. For example, if a user&#39;s calendar event indicates that they are traveling but the user&#39;s geolocation does not match the travel destination, the behavior may be considered an outlier behavior, and in response the user may be migrated to a very high-security persona group. Upon the user&#39;s return to the office after the calendar event, the user&#39;s workspace may also be returned to its original persona group (e.g., if the user belongs to an “executive” or other persona group expected to have more outlier behaviors than other groups in an enterprise). 
     In various implementations, in response to a change in user behavior, systems and methods described herein may determine whether to: (a) modify a workspace definition for the user&#39;s current persona group, (b) move the user to another persona group with a more appropriate workspace definition, (c) make a permanent or temporary adjustment to a persona group, (d) add a new persona group, and/or (e) alert the orchestration owner of a potential security attack. 
     Particularly, workspace orchestration service  206  may modify an existing persona group in response to detecting users within a persona group exhibiting new yet similar behavior. Alternatively, workspace orchestration service  206  may assign the user to another existing persona group in response to detecting that a user&#39;s behavior matches example behavior of the other existing persona group members. Alternatively, workspace orchestration service  206  may create a new persona group in response to identifying that the user&#39;s behavior matches that of a selected number of users, distinct from the behavior of users in existing persona groups, and thus needs a new persona group to be established. 
     Outliers by process of elimination may be classified as security threats, and their workspaces may be terminated to protect the overall environment from individuals that may be behaving erratically relative to all other persona groups. For example, systems and methods described herein may apply User and Event Behavior Analytics (UEBA), which uses machine learning and deep learning to model the behavior of users on corporate networks and highlights anonymous behavior that may be the sign of a security attack. 
     In some embodiments, workspace orchestration service  206  may enforce a persona group management policy (e.g., JSON name-value, XML structured, etc.) that identifies, by applying selected rules to the context information, whether a behavior change is characteristic of a malicious insider or early adopter of a technology. Based upon persona group management policy thresholds (e.g., minimum number of users displaying a certain behavior, minimum changes to security or productivity metrics, etc.), workspace orchestration service  206  may also identify: changes in an individual user&#39;s behavior (in a new way that does not match their current persona group), changes to persona group behavior (multiple users in a class of users behaving in a new way that does not match their existing persona group), changes to a user&#39;s device (user takes on different personas on different device workspace contexts, such as OS context, physical hardware instances, Web/Native code, etc.), and/or workspace modifications (based on users switching personas) to entitle new software and/or unlock hardware. 
       FIG.  8    is a flowchart of an example of method  800  for migrating users and modifying workspace definitions of persona groups. In various embodiments, method  800  may be performed, at least in part, by workspace orchestration service  206  in communication with local management agent  332  of a user&#39;s client device. Particularly, at  801 , workspace orchestration service  206  may distribute workspace definitions to all users based on their best fit to existing persona groups, each persona group associated with a different workspace definition (or set of workspace definitions). 
     At  802 , user&#39;s behavior drifts or deviates from the expected and/or historical behavior of other members of its persona group, thus triggering evaluation by workspace orchestration service  206  at  803 . Behavior drift may be detected during the user&#39;s execution of a workspace, for example, by analyzing any of the aforementioned contextual information (e.g., location, calendar event information, user presence, IHS posture, etc.), alone or in combination, against settings, threshold, and/or selected values prescribed by the persona group management policy. 
     In some cases, the change in user behavior may be reflected as a change in a security metric (e.g., a risk metric associated with a locale of the client device, a risk metric associated with the user, a risk metric associated with a network of the client device, a risk metric associated with hardware of the client device, a risk metric associated with a requested datafile, or a regulatory risk metric associated with the user, the locale, and the requested datafile). Additionally, or alternatively, the change in user behavior may be reflected as a change in a productivity metric (e.g., a number of application installations, a number or volume of downloads, or a number of application executions) associated with the workspace. 
     At  803 , workspace orchestration service  206  evaluates the user&#39;s behavior change to determine whether to modify their existing persona group and request local management agent  332  to re-instantiate the user&#39;s workspace with a modified workspace definition for the modified persona group. 
     Alternatively, at  804 , workspace orchestration service  206  may migrate the user to a different, existing persona group and request local management agent  332  to re-instantiate the user&#39;s workspace with a different workspace definition for the different persona group. To determine whether to migrate the user to the different, existing persona group, workspace orchestration service  206  may determine that a changed user behavior matches a behavior of another user of the different persona group based upon the persona group management policy and/or a machine learning algorithm. 
     Alternatively, at  805 , workspace orchestration service  206  may establish a new persona group and workspace definition (due to significant user behavior deviation) and request local management agent  332  to re-instantiate the user&#39;s workspace with a new workspace definition for the new persona group. To determine whether to create the persona group, workspace orchestration service  206  may determine that a changed user behavior does match the behavior of other users of existing persona groups, for example, based upon the persona group management policy and/or a machine learning algorithm. 
     Additionally, workspace orchestration service  206  may determine that the user&#39;s changed behavior matches the behavior of a selected number of other users in the original persona group. In some cases, the number of other users may be selected based upon a relationship (e.g., a ratio) between a number of persona groups and a total number of users. 
     Alternatively, at  806 , workspace orchestration service  206  may identify a potential security threat, for example, when the new user behavior is considered to be outlier behavior. 
     Accordingly, systems and methods described herein enable the dynamic creation, modification, and/or user assignment/membership of persona groups for configuration and security policy assignments. In various implementations these systems and methods may be facilitated by the workspace orchestration service&#39;s ability to perform fast user migration between workspaces. These systems and methods may perform user assignment to persona based on behavior and needs, and it may create and manage persona definitions created based upon membership needs. 
     It should be understood that various operations described herein may be implemented in software executed by processing circuitry, hardware, or a combination thereof. The order in which each operation of a given method is performed may be changed, and various operations may be added, reordered, combined, omitted, modified, etc. It is intended that the invention(s) described herein embrace all such modifications and changes and, accordingly, the above description should be regarded in an illustrative rather than a restrictive sense. 
     The terms “tangible” and “non-transitory,” as used herein, are intended to describe a computer-readable storage medium (or “memory”) excluding propagating electromagnetic signals; but are not intended to otherwise limit the type of physical computer-readable storage device that is encompassed by the phrase computer-readable medium or memory. For instance, the terms “non-transitory computer readable medium” or “tangible memory” are intended to encompass types of storage devices that do not necessarily store information permanently, including, for example, RAM. Program instructions and data stored on a tangible computer-accessible storage medium in non-transitory form may afterwards be transmitted by transmission media or signals such as electrical, electromagnetic, or digital signals, which may be conveyed via a communication medium such as a network and/or a wireless link. 
     Although the invention(s) is/are described herein with reference to specific embodiments, various modifications and changes can be made without departing from the scope of the present invention(s), as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention(s). Any benefits, advantages, or solutions to problems that are described herein with regard to specific embodiments are not intended to be construed as a critical, required, or essential feature or element of any or all the claims. 
     Unless stated otherwise, terms such as “first” and “second” are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements. The terms “coupled” or “operably coupled” are defined as connected, although not necessarily directly, and not necessarily mechanically. The terms “a” and “an” are defined as one or more unless stated otherwise. The terms “comprise” (and any form of comprise, such as “comprises” and “comprising”), “have” (and any form of have, such as “has” and “having”), “include” (and any form of include, such as “includes” and “including”) and “contain” (and any form of contain, such as “contains” and “containing”) are open-ended linking verbs. As a result, a system, device, or apparatus that “comprises,” “has,” “includes” or “contains” one or more elements possesses those one or more elements but is not limited to possessing only those one or more elements. Similarly, a method or process that “comprises,” “has,” “includes” or “contains” one or more operations possesses those one or more operations but is not limited to possessing only those one or more operations.