Microsoft setup guide: IA.L2-3.5.3

3.5.3: Check MFA for cloud and Windows sign-ins

Check how privileged accounts sign in locally and over the network, then check ordinary users on the network. Test Microsoft 365, the AVD service and Windows sign-in separately.

Sources reviewed October 22, 2026. These instructions have not been tested in a Microsoft tenant.

Choose the instructions for your cloud. If you use AVD, also read the notes for AD DS-only, hybrid joined or Entra joined hosts, according to how your hosts are joined.

NIST SP 800-171 Revision 2

The requirement and official objectives

Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
Official assessment objectives from NIST SP 800-171A, June 2018. Determine if:
ObjectiveOfficial text
3.5.3[a]privileged accounts are identified.
3.5.3[b]multifactor authentication is implemented for local access to privileged accounts.
3.5.3[c]multifactor authentication is implemented for network access to privileged accounts.
3.5.3[d]multifactor authentication is implemented for network access to non-privileged accounts.

The steps below explain how to configure and check settings related to this requirement. The table above contains the official objective text. Following these steps does not establish a MET finding. Read the official assessment procedures.

Before you start

  • List every privileged account covered by the review and how it connects locally and over the network. Include administrators, emergency accounts, support accounts and separate accounts used for administration. List the ways ordinary users connect over the network too.
  • Record the tenant, cloud, licenses, authentication methods and any federated sign-in provider. Record how hosts are joined, which clients are allowed, where policies apply and any exclusions. For each kind of sign-in, say what requires MFA and how you will test it.
  • Use a Conditional Access Administrator to change those policies and an account authorized to read the logs. Use the appropriate domain or device administrator for Windows authentication changes. Choose a small test group and write down how to restore access if a change goes wrong.
  • Before changing anything, check the security defaults, per-user MFA settings and Conditional Access policies already in use. Keep working protections in place while adapting these steps to your tenant.

If you need to identify CUI first, start with the identification guide. Before putting CUI in a cloud service, check that the service, your contract and the handling rules permit it.

Put the requirement into practice

Check three things: whether users have registered an MFA method, whether a policy requires MFA and whether the sign-in records show that the user met that requirement. A later connection may accept an earlier MFA claim, so a new prompt is not always needed.

Review local administrator access separately. A cloud Conditional Access policy does not automatically protect signing in as a local administrator, elevating privileges in Windows, using a recovery account or connecting to every other network service.

  1. List the sign-ins covered by each objective

    List the privileged accounts for 3.5.3[a]. For each account, record local privileged access under [b] and network privileged access under [c]. Record ordinary users' network access under [d]. For every relevant way to connect, write down how authentication works, what enforces MFA, any exceptions and the evidence to check. Include accounts that run without an interactive prompt and emergency accounts in the review.

  2. Check what the cloud MFA policy needs

    Confirm that you have Entra ID P1 or another eligible plan that includes Conditional Access. Check which authentication methods are allowed and whether the test users have registered them. Security defaults and Conditional Access cannot be used together. If you move from security defaults, approve a replacement plan that preserves protection during the change. Test the replacement for administrators, ordinary users and older access methods.

  3. Create a policy for the test group

    In the correct tenant, open Conditional Access > Policies > New policy. Name the policy, select the approved test users and intended resources, then configure Grant access > Require multifactor authentication. Check the other grant conditions: make sure another condition cannot satisfy the rule without MFA. Record every exclusion and how the excluded account or connection is protected.

  4. Review the report-only results, then turn on the test policy

    Report-only mode shows how a policy would apply; it does not enforce MFA. Where your existing policies allow you to use it, review the results to find likely access problems. Then enable the approved test policy and try the sign-ins. Read the authentication details and Conditional Access result in the sign-in record. A report-only success, a count of registered users or a screenshot of a saved policy does not show that MFA is enforced.

  5. Check older methods and sign-ins outside the cloud

    If a network connection cannot use your chosen MFA method, find a supported replacement or remove that way of connecting through an approved change. Use the host sections below to review local Windows authentication separately. Add any sign-in still missing MFA to the action list.

Commercial: Microsoft 365 and Azure

Use the commercial Entra tenant for Microsoft 365 Commercial and Azure Commercial. Check which Microsoft 365 resources and administrator portals the policy covers. Check the tenant license and whether the policy is on; installed Office applications do not tell you either.

  1. Protect each stage of the AVD connection

    For access to the AVD service, Microsoft identifies the Azure Virtual Desktop application, ID 9cdead84-a844-4324-93f2-b2e6bb768d07. When supported Entra SSO is enabled, signing in to the session host also uses Windows Cloud Login, ID 270efc09-cd0d-444b-a71f-39af4910ec45. Follow the documented policy setup for both stages and test every permitted client.

  2. Review the other policies and sign-in records

    Alongside the AVD policies, check policies for all resources and any conditions based on devices or locations. Do not target the Azure Virtual Desktop Azure Resource Manager Provider application for MFA. Read the test user's sign-in records for the service and, where used, Windows Cloud Login. Check which policy applied and which authentication requirement the sign-in met.

Government: GCC High and Azure Government

These government instructions use GCC High identities and an Azure Government tenant. Confirm that you are in the government portal. Before applying a commercial example, check which authentication methods, licenses, applications and clients your government deployment supports.

GCC and GCC High use different arrangements. GCC identity pairs with Azure Commercial, while GCC High identity pairs with Azure Government. If you use GCC, check its service description and support for each feature. Neither set of instructions here applies to every GCC setup.

  1. Use the identities and resources in the government tenant

    Read the government service description and check the national-cloud endpoints. Create the test policy for resources that exist in that tenant. Confirm the available service principals and supported features. If a government feature is missing, record the limitation. Do not guess an application ID or switch to a commercial tenant as a workaround.

  2. Check how the Government AVD connection is supported

    Read the current AVD authentication and SSO prerequisites for your host join type, operating system, client and cloud. If the documented SSO option is supported, cover access to the service and SSO to the session host, then read the sign-in records for both. If SSO is unavailable, record how users currently sign in and which stages still lack MFA. Perform these checks in the government deployment itself.

Check how your session hosts are joined

Check which account the user signs in with, how the host is joined and which local device and client they use. Then choose the matching instructions below. Confirm that your cloud supports the features you plan to use.

AD DS-only session hosts

On AD DS-only hosts, users first authenticate to the AVD service through Entra, then sign in to Windows through the domain. These are separate stages. AD DS-only hosts do not support this Entra SSO path. Record every stage of the connection. Adding an SSO setting does not change how the host is joined.

  1. Check administrator access to the host

    List domain and local administrators. Record their permitted remote connections and ways to sign in locally, including the console. Check how Windows authenticates each sign-in. Enabling Microsoft 365 MFA leaves a password-only local administrator sign-in unchanged.

  2. Choose a supported way to require MFA in Windows

    If you already use smart cards, check the certificates, account mapping, readers, PIN and domain connection. Confirm support for the Windows sign-in you intend to test, then test it with the intended administrator account. Windows Hello for Business has its own requirements for an on-premises deployment. Follow its planning guide; an ordinary local-account PIN is a different setup. Check permitted fallback methods and recovery before turning on a new requirement.

Microsoft Entra hybrid joined session hosts

Confirm that the host itself is hybrid joined. A synchronized user account does not establish that. To use supported Entra SSO, meet the documented requirements for the host operating system, client, domain and trust.

  1. Check SSO and the domain requirements together

    Follow the current SSO prerequisites, including the Kerberos and domain requirements that apply. Keep domain-admin password replication restrictions in place. Use a test account with only the permissions it needs, and separately review how administrators will perform their work.

  2. Test local administrator access as well as SSO

    If you choose Windows Hello for Business for Windows MFA, select a supported hybrid trust design and deploy its prerequisites through your approved management tools. Test with the privileged account that will actually be used. Check the intended sign-in or elevation and any permitted fallback. A successful AVD SSO test for a user does not verify MFA for local privileged access.

Microsoft Entra joined session hosts

Check which tenant the host belongs to, which client is supported, whether SSO is enabled and which VM login roles are needed. Use the authentication instructions for Entra joined hosts; the AD DS-only steps do not describe this setup.

  1. Review SSO and legacy per-user MFA

    Microsoft documents conflicts between legacy per-user MFA and the Conditional Access setup for Entra joined hosts. Before changing it, verify that the replacement protects the same access and that recovery works. Do not remove MFA across the board. An application exclusion from an example without SSO may be wrong for a setup using SSO; review the full connection before using it.

  2. Check whether Windows Hello for Business fits the Windows sign-in

    For a supported Windows device, choose the documented cloud-only or hybrid deployment according to the users and resources it needs. Windows Hello for Business combines a credential bound to the device with a PIN or biometric gesture. Check enrollment, the policy that took effect, the privileged account and the exact way it connects. One PIN setup does not cover every VM, Windows Server, local account or way to elevate privileges.

  3. Test AVD, Windows sign-in and the applications

    Start a fresh AVD connection, then check the reconnect or unlock behavior you permit. Read the service and SSO sign-in records where they apply. Test the applications used inside the session too. Record where a previous MFA claim is accepted and where users can still connect with a password alone.

Fictional example. No tenant test performed.

Two cloud administrators and an unchecked local account

A fictional contractor has configured MFA for two Entra administrators. The team has not yet checked all exclusions, a local administrator account or how users authenticate when signing in to the AVD host.

The team assigns separate checks for privileged local access, privileged network access and ordinary network access. It expects the cloud test policy, once enabled, to require MFA and record that the user completed it. Local privileged access stays unverified until the team tests the Windows control and permitted fallback methods. This is a fictional plan. No test results are reported.

Check the settings with sample data

Create a file or record with made-up contents and label it Sample data. Not CUI. Before testing, agree with the system owner on what should be allowed and what should be denied. The table describes the results to look for. These tests have not been run in a Microsoft tenant.

Repeat the checks that apply to each cloud, host join type and client you use.
What to tryWhat should happen
Start a fresh approved sign-in with a privileged test cloud account that has no reusable MFA claim.The enabled policy requires an allowed MFA method. The authentication details and policy result confirm that it applied.
Try that connection without completing the required MFA. Use only sample data.Access is denied. Use the test account and planned procedure; keep production protections in place and avoid deliberately locking out an administrator.
Use an ordinary test account to try each relevant network connection.The test verifies MFA for each of those connections. The administrator test alone does not verify them.
Connect to AVD with the approved client and authentication method for your host join type.Each stage matches the approved design. Check access to the service, supported host SSO if used and access inside the session separately.
Test an approved local privileged sign-in and any relevant way to elevate privileges or recover access.The documented Windows MFA method protects the access being tested. Check it directly; a cloud policy does not show the result for Windows.
Check permitted reconnects, accepted MFA claims, exclusions and emergency access.The behavior and protections match the approved design. If there is no new prompt, check whether an earlier MFA claim was accepted. Confirm how every exclusion is protected separately.

Write down what happened, when you tested, the type of account, client, host, policy version and where the evidence is kept. A passed test shows the result only for the connection and settings you tested. Keep failed checks and connections you have not tested on the action list.

Records to keep and work to assign

  • Keep the privileged-account list and a map of the ways accounts connect. Cover local privileged access, network privileged access and ordinary users' network access.
  • Save the authentication settings and policy assignments. Record which policies are enforced, any exceptions, replacement protections and the agreed recovery steps.
  • Keep the relevant sign-in authentication details and Conditional Access results. For connections those logs do not cover, keep the Windows policy and test evidence.
  • Record what each test showed, the type of account, tenant, client, host join type and date and time. Reference evidence held in a location with restricted access. Keep tokens and authentication secrets out of the workbook.

Fictional workbook entry

For 3.5.3[c], choose Evidence to check and enter MFA-PILOT-01 as the reference. Assign the IT owner to check every way privileged accounts connect over the network, including exceptions. Record the local-access review under 3.5.3[b] separately. A passed cloud test does not complete that row.

Use the free Level 2 readiness worksheet to record what is missing for each objective, who will address it and what happens next. Keep the evidence itself in an approved location with restricted access. Put a reference to that location in the workbook.

Download the Excel worksheet ↓

When a check fails or access breaks

  1. If an approved user cannot connect

    Confirm the tenant, target application and client. Read the authentication details and find which policy blocked access. For AVD, check whether the failure occurred at the service or when signing in to the host. Use the approved recovery account and saved test settings. Then test both the connection that should work and the attempt that should be denied.

  2. If MFA succeeds but Windows logon fails

    Check how the host is joined, who may sign in, the SSO prerequisites, the domain connection and the required login roles. Completing MFA does not grant permission to sign in to Windows. Fix the host permission problem while keeping the intended MFA protection in place.

  3. If you find a bypass or fallback method

    Record exactly how it works and limit it through an approved change. Review a supported replacement authentication method or remove that way of connecting. Keep the objective open until you have verified protection for the relevant access. Write down how to handle lost factors, emergency accounts and offline recovery. Do not turn a recovery need into an undocumented permanent exception.

Costs, licenses and existing tools

  • You do not have to buy the Microsoft Authenticator app. Using it does not give you a Conditional Access license, policies based on risk or MFA protection for privileged Windows access.
  • Conditional Access requires Entra ID P1, and policies based on risk require P2. Microsoft 365 Business Premium includes P1. Check the actual subscription; having basic Office products does not show that P1 is included. Confirm the government offering separately.
  • Security defaults provide a free baseline for supported cloud protections. They do not let you configure every kind of access covered by this requirement, and they do not verify MFA for local privileged access. Before removing them, verify that the replacement protects the required access.
  • Windows Hello for Business is supported on eligible Windows editions. You still need to check the hardware, identities, management tools and setup requirements for the chosen deployment. Smart cards may need readers, cards and a public key infrastructure (PKI). Allow time to deploy and test the method, including fallback and recovery.
  • Budget for AVD licenses and Azure infrastructure separately. Check the current service and licensing documentation before buying or changing a plan.

Check your subscription against the documentation for Conditional Access licensing and AVD access licensing and costs. Confirm what your government plan includes separately; a product name or commercial bundle does not establish those rights.

What else you need to review

Use this guide to start configuring and checking MFA. Follow the linked deployment guidance for the complete tenant, PKI or Windows Hello setup you need. Keep any way of connecting that still lacks the required protection listed in the worksheet.

You still need approved access, least privilege, processes for issuing and retiring credentials, remote-session restrictions and audit review. The requirement sentence displayed here omits footnote markers. Read the official NIST source for the full notes.

Sources and review date

Sources reviewed October 22, 2026. These guides use the Level 2 baseline of NIST SP 800-171 Revision 2 and the June 2018 assessment procedures. Reviewing documentation does not verify the settings in your system.

This series follows the structure of Microsoft's 2024 preview reference guide. It suggests which Microsoft products can help with each requirement. Use those suggestions as a starting point; they do not prove current compliance. The steps here refer to the linked product documentation.

For a correction or general question, email cmmc@purposefulsecurity.com and describe it in general terms. Do not send CUI, contracts, credentials, network diagrams, security evidence or completed worksheets.