done

windows/keep-secure/hello-implement-in-organization.md

@@ -363,11 +363,49 @@ Configuration Manager and MDM provide the ability to manage Windows Hello for Bu
 Azure AD provides the ability to register devices with your enterprise and to provision Windows Hello for Business for organization accounts.
 
 
-## Windows Hello for BYOD
+## Approaches for a Windows Hello for Business deployment
 
-Windows Hello can be managed on personal devices that your employees use for work purposes using MDM. On personal devices, users can create a personal Windows Hello PIN for unlocking the device and used this PIN for access to work resources.
+Different organizations will necessarily take different approaches to the deployment of Windows Hello depending on their capabilities and needs, but there is only one strategy: deploy Windows Hello for Business throughout the organization to get maximum protection for the maximum number of devices and resources. Organizations can take one of three basic routes to accomplish that strategy:
+
+- Deploy Windows Hello for Business everywhere according to whatever device or user deployment strategy works best for the organization.
+- Deploy Windows Hello for Business first to high-value or high-risk targets, by using conditional access policies to restrict access to key resources only to users who hold strong authentication credentials.
+- Blend Windows Hello for Business into an existing multi-factor environment, using it as an additional form of strong authentication alongside physical or virtual smart cards.
+
+### Deploy Windows Hello for Business everywhere
+
+In this approach, you deploy Windows Hello throughout the organization in a coordinated rollout. In some ways, this method is similar to any other desktop deployment project; the only real difference is that you must already have the Windows Hello infrastructure in place to support device registration before you can start using Windows Hello on Windows 10 devices.
+
+You can still upgrade to Windows 10 or add new Windows 10 devices without changing your infrastructure. You just can’t use Windows Hello for Business on a device until the device joins Azure AD and receives the appropriate policy. The major benefit of this approach is that it provides uniform protection for all parts of the organization. Sophisticated attackers have shown a great deal of skill in breaching large organizations by identifying weak points in their security, including users and systems that don’t have high-value information but that can be exploited to get it. Applying consistent protection across every device that an attacker could use to access enterprise data is excellent protection against these types of attacks.
+
+The downside to this approach is its complexity. Smaller organizations may find that managing the rollout of a new operating system across all devices is beyond the scope of their experience and capability. For these organizations, users can self-upgrade, and new users may end up with Windows 10 because they get new devices when they join. Larger organizations, especially those that are highly decentralized or have operations across many physical sites, may have more deployment knowledge and resources but face the challenge of coordinating rollout efforts across a larger user base and footprint.
+
+For more information about desktop deployment of Windows 10, visit the [Windows 10 TechCenter](https://technet.microsoft.com/windows/mt240567).
+
+One key aspect of this deployment strategy is how to get Windows 10 in users’ hands. Because different organizations have wildly differing strategies to refresh hardware and software, there’s no one-size-fits-all strategy. For example, some organizations pursue a coordinated strategy that puts new desktop operating systems in users’ hands every 2–3 years on existing hardware, supplementing with new hardware only where and when required. Others tend to replace hardware and deploy whatever version of the Windows client operating system ships on the purchased devices. In both cases, there are typically separate deployment cycles for servers and server operating systems, and the desktop and server cycles may or may not be coordinated.
+
+In addition to the issue of Windows 10 deployment to users, you must consider how and when (or if!) you’ll deploy biometric devices to users. Because Windows Hello can take advantage of multiple biometric identifiers, you have a flexible range of device options, which includes the purchase of new devices that incorporate your selected biometric, seeding select users with appropriate devices, rollout of biometric devices as part of a scheduled hardware refresh and using PIN gestures until users get devices, or relying on remote unlock as a second authentication factor.
+
+### Deploy to high-value or high-risk targets
+
+This strategy takes into account the fact that in most networks, not every asset is equally protected or equally valuable. There are two ways to think about this. One is that you can focus on protecting the users and services that are most at risk of compromise because of their value. Examples include sensitive internal databases or the user accounts of your key executives. The other option is that you can focus on areas of your network that are the most vulnerable, such as users who travel frequently (and thus run a higher risk of lost or stolen devices or drive-by credential theft). Either way, the strategy is the same: selectively and quickly deploy Windows Hello to protect specific people and resources. For example, you might issue new Windows 10 devices with biometric sensors to all users who need access to a sensitive internal database, and then deploy the minimum required infrastructure to support Windows Hello–secured access to that database for those users.
+One of the key design capabilities of Windows Hello for Business is that it supports Bring Your Own Device (BYOD) environments by allowing users to register their own devices with the organizational IDP (whether on premises, hybrid, or Azure AD). You may be able to take advantage of this capability to quickly deploy Windows Hello to protect your most vulnerable users or assets, ideally by using biometrics as an additional safety measure for the most valuable potential targets.
+
+### Blend Windows Hello with your infrastructure
+
+Organizations that have already invested in smart cards, virtual smart cards, or token-based systems can still benefit from Windows Hello. Of those organizations, many use physical tokens and smart cards to protect only critical assets because of the expense and complexity of their deployment. Windows Hello offers a valuable complement to these systems because it protects users who currently rely on reusable credentials; protection of all users’ credentials is an important step toward blunting attacks that seek to leverage compromise of any credential into a widespread breach. This approach also gives you a great deal of flexibility in scheduling and deployment. Some enterprises have deployed multi-use smart cards that provide building-access control, access to copiers or other office equipment, stored value for lunchroom purchases, remote network access, and other services. Deployment of Windows Hello in such environments doesn’t prevent you from continuing to use smart cards for these services. You can leave the existing smart card infrastructure in place for its existing use cases, and then register desktop and mobile devices in Windows Hello and use Windows Hello to secure access to network and Internet resources. This approach requires a more complicated infrastructure and a greater degree of organizational maturity because it requires you to link your existing PKI with an enrollment service and Windows Hello itself.
+
+Smart cards can act as a useful complement to Windows Hello in another important way: to bootstrap the initial logon for Windows Hello registration. When a user registers with Windows Hello on a device, part of that registration process requires a conventional logon. Rather than using a traditional password, organizations that have previously deployed the necessary infrastructure for smart cards or virtual smart cards can allow their users to register new devices by logging on with a smart card or virtual smart card. After the user has proved his or her identity to the organizational IDP with the smart card, the user can set up a PIN and proceed to use Windows Hello for future logons.
+
+### Choose a rollout method
+
+Which rollout method you choose depends on several factors:
+
+- How many devices you need to deploy. This number has a huge influence on your overall deployment. A global rollout for 75,000 users has different requirements than a phased rollout for groups of 200–300 users in different cities.
+- How quickly you want to deploy Windows Hello for Business protection. This is a classic cost–benefit tradeoff. You have to balance the security benefits of Windows Hello for Business against the cost and time required to deploy it broadly, and different organizations may make entirely different decisions depending on how they rate the costs and benefits involved. Getting the broadest possible Windows Hello coverage in the shortest time possible maximizes security benefits.
+- The type of devices you want to deploy. Windows device manufacturers are aggressively introducing new devices optimized for Windows 10, leading to the possibility that you might deploy Windows Hello first on newly purchased tablets and portable devices, and then deploy it on the desktop as part of your normal refresh cycle.
+- What your current infrastructure looks like. The individual version of Windows Hello doesn’t require changes to your Active Directory environment, but to support Windows Hello for Business, you may need a compatible MDM system. Depending on the size and composition of your network, mobile enrollment and management services deployment may be a major project in its own right.
+- Your plans for the cloud. If you’re already planning a move to the cloud, Azure AD eases the process of Windows Hello for Business deployment, because you can use Azure AD as an IDP alongside your existing on-premises AD DS setup without making significant changes to your on-premises environment. Future versions of Windows Hello for Business will support the ability to simultaneously register devices that are already members of an on-premises AD DS domain in an Azure AD partition so that they use Windows Hello for Business from the cloud. Hybrid deployments that combine AD DS with Azure AD give you the ability to keep machine authentication and policy management against your local AD DS domain while providing the full set of Windows Hello for Business services (and Microsoft Office 365 integration) for your users. If you plan to use on-premises AD DS only, then the design and configuration of your on-premises environment will dictate what kind of changes you may need to make.
 
-The PIN is managed using the same Windows Hello for Business policies that you can use to manage Windows Hello for Business on organization-owned devices. The PIN can also be managed using DeviceLock policy. DeviceLock policy can be used to control length, complexity, history, and expiration requirements and can be configured using the [Policy configuration service provider](https://go.microsoft.com/fwlink/p/?LinkID=623244).
 
 ## Related topics