Remove SCRIL messaging

windows/security/identity-protection/passwordless-strategy/index.md

@@ -36,7 +36,7 @@ Deploy Windows Hello for Business or FIDO2 security keys is the first step towar
 
 With a password replacement option and passwords coexisting in the environment, the next step is to reduce the password surface area. The environment and workflows need to stop asking for passwords. The goal of this step is to achieve a state where the users know they have a password, **but they never use it**. This state helps decondition users from providing a password anytime a password prompt shows on their computer. This behavior is how passwords are phished. Users who rarely, if at all, use their password are unlikely to provide it. **Password prompts are no longer the norm**.
 
-In this phase, deploy *Windows passwordles experience* to reduce the password surface area by hiding the password credential provider from the user.
+<!--In this phase, deploy *Windows passwordles experience* to reduce the password surface area by hiding the password credential provider from the user.-->
 
 :::row:::
    :::column span="1":::

windows/security/identity-protection/passwordless-strategy/journey-step-1.md

@@ -33,12 +33,12 @@ A successful transition relies on user acceptance testing. It's impossible for y
 
 ## Deploy Windows Hello for Business or FIDO2 security keys to test users
 
-Next, you'll want to plan your password replacement deployment. Your test users will need an alternative way to sign-in during step 2 of the journey to becoming passwordless. Use the [Windows Hello for Business planning guide](..\hello-for-business\hello-planning-guide.md) to help learning which deployment is best suited for your environment. Next, use the [Windows Hello for Business deployment guides](..\hello-for-business\hello-deployment-guide.md) to deploy Windows Hello for Business. With the Windows Hello for Business infrastructure in place, you can limit Windows Hello for Business enrollments to the targeted work personas. The great news is that you'll only need to deploy the infrastructure once. When other targeted work personas need to start using Windows Hello for Business, add them to a group. You'll use the first work persona to validate your Windows Hello for Business deployment.
+Next, you'll want to plan your password replacement deployment. Your test users will need an alternative way to sign-in during step 2 of the journey to becoming passwordless. Use the [Windows Hello for Business planning guide](..\hello-for-business\deploy\index.md) to help learning which deployment is best suited for your environment. Next, use one of the deployment guides to deploy Windows Hello for Business. With the Windows Hello for Business infrastructure in place, you can limit Windows Hello for Business enrollments to the targeted work personas. The great news is that you'll only need to deploy the infrastructure once. When other targeted work personas need to start using Windows Hello for Business, add them to a group. You'll use the first work persona to validate your Windows Hello for Business deployment.
 
 If you decide to use FIDO2 security keys, follow the [Enable security key sign-in to Windows guide](/entra/identity/authentication/howto-authentication-passwordless-security-key-windows) to learn how to adopt FIDO2 security keys.
 
 > [!NOTE]
-> Deployments vary based on how the device is joined to Microsoft Entra ID. Review the planning guide and deployment guide to learn the type of infrastructure required to support your devices.
+> Deployments vary based on how the device is joined to Microsoft Entra ID. Review the planning guide to learn the type of infrastructure required to support your devices.
 
 ## Validate passwords and Windows Hello for Business or FIDO2 security keys
 
@@ -48,9 +48,9 @@ In this first step, passwords and your password replacement choice must coexist.
 
 ## Next steps
 
-Before you move to step 2, make sure you've:
-
 > [!div class="checklist"]
+> Before you move to step 2, make sure you've:
+>
 > - Selected your targeted work persona
 > - Identified your test users who represent the targeted work persona
 > - Deployed Windows Hello for Business or FIDO2 security keys to test users

windows/security/identity-protection/passwordless-strategy/journey-step-2.md

@@ -54,7 +54,7 @@ Mitigating password usage with applications is one of the more challenging obsta
 
 The ideal mitigation for applications that prompt the user for a password is to enable those applications to use an existing authenticated identity, such as Microsoft Entra ID or Active Directory. Work with the applications vendors to have them add support for Microsoft Entra identities. For on-premises applications, have the application use Windows integrated authentication. The goal for your users should be a seamless single sign-on experience where each user authenticates once when they sign-in to Windows. Use this same strategy for applications that store their own identities in their own databases.
 
-Each scenario on your list should now have a problem statement, an investigation as to why the password was used, and a mitigation plan on how to make the password usage go away. Armed with this data, one-by-one, close the gaps on user-visible passwords. Change policies and procedures as needed, make infrastructure changes where possible. Convert in-house applications to integrate in your Microsoft Entra ID tenant, use federated identities, or use Windows integrated authentication. Work with third-party software vendors to update their software to integraate in Microsoft Entra ID, support federated identities, or use Windows integrated authentication.
+Each scenario on your list should now have a problem statement, an investigation as to why the password was used, and a mitigation plan on how to make the password usage go away. Armed with this data, one-by-one, close the gaps on user-visible passwords. Change policies and procedures as needed, make infrastructure changes where possible. Convert in-house applications to integrate in your Microsoft Entra ID tenant, use federated identities, or use Windows integrated authentication. Work with third-party software vendors to update their software to integrate in Microsoft Entra ID, support federated identities, or use Windows integrated authentication.
 
 ## Repeat until all user password usage is mitigated
 
@@ -63,7 +63,7 @@ Some or all of your mitigations are in place. You need to validate that your sol
 ## Remove password capabilities from Windows
 
 You believe you've mitigated all the password usage for the targeted work persona. Now comes the true test: configure Windows so the user can't use a password.
-Windows provides three ways to prevent your users from using passwords. The following table describes the options and their pros and cons:
+Windows offers different options to prevent users from using passwords. The following table describes the options and their pros and cons:
 
 | Option | Description | Supported on | Pros | Cons |
 | -|-|-|-|-|

windows/security/identity-protection/passwordless-strategy/journey-step-3.md

@@ -53,32 +53,15 @@ Resolve the issues per your service level agreements. Higher severity items may
 
 You transitioned all the users for the targeted work persona to a passwordless environment and you've successfully validated all their workflows. The last step to complete the passwordless transition is to remove the user's knowledge of the password and prevent the authenticating authority from accepting passwords.
 
-### Users defined in Active Directory
+### Password scrambling
 
-If your users are defined in Active Directory, you can change their password to random data and prevent interactive password sign-ins using an account configuration on the user object.
+If your users are defined in Active Directory, you can scramble their password to a random value.
 
-:::row:::
+### Password expiration
-   :::column span="2":::
-   The account options on a user account include the option **Smart card is required for interactive logon**, also known as *SCRIL*.
-
-    > [!NOTE]
-    > Do not confuse the Interactive Logon security policy for SCRIL. Security policies are enforced on the client (locally). A user account configured for SCRIL is enforced at the domain controller.
-   :::column-end:::
-   :::column span="2":::
-   :::image type="content" source="images/user-properties-aduc.png" alt-text="Example user properties in Active Directory Users and Computers that shows the SCRIL setting on Account options." lightbox="images/user-properties-aduc.png" border="false":::
-   :::column-end:::
-:::row-end:::
-
-When you configure a user account for SCRIL:
-
-- Active Directory changes the affected user's password to a random 128 bits of data
-- Domain controllers don't allow the user to sign-in interactively with a password
-- Users no longer need to change their password when it expires, because passwords for SCRIL users don't expire
 
 The users are effectively password-less because:
 
 - They don't know their password
-- Their password is 128 random bits of data and is likely to include non-typable characters
 - The user isn't asked to change their password
 - Domain controllers don't allow passwords for interactive authentication
 
@@ -93,16 +76,8 @@ The following image shows the message on the Windows lock screen when a SCRIL-en
 
 :::image type="content" source="images/lock-screen-scril.png" alt-text="Screenshot of the Windows lock screen showing the SCRIL message." border="false":::
 
-#### Automatic password change for SCRIL configured users
+### Password rotation
 
-Domains configured for Windows Server 2016 or later domain functional level can further secure the unknown password for SCRIL-enabled users by configuring the domain to automatically change the password for SCRIL users.
-
-In this configuration, passwords for SCRIL-configured users expire based on Active Directory password policy settings. When the SCRIL user authenticates from a domain controller, the domain controller recognizes the password has expired, and automatically generates a new random 128-bit password for the user as part of the authentication. This feature is great because your users don't experience any change password notifications or any authentication outages.
-
-:::image type="content" source="images/domain-properties-adac.png" alt-text="The Active Directory Administrative Center on Windows Server 2016 showing the domain setting for SCRIL." border="false":::
-
-> [!NOTE]
-> Some components within Windows, such as *Data Protection APIs* and *NTLM authentication*, still need artifacts of a user possessing a password. The SCRIL option provides interoperability by reducing the password usage surface, while Microsoft continues to close the gaps to remove the password completely.
 
 ### Cloud-only users