NIST 800-171 3.5.3 (IA.L2-3.5.3): Multifactor Authentication

What 3.5.3 means in practice

Privileged accounts need multifactor authentication for every sign-in, including at the console, and everyone needs it for network sign-ins. Assessors start from the list of privileged accounts and then look for the gaps: local administrator logons, legacy protocols that skip the second factor, and accounts left out of the multifactor policy.

SPRS points and the CMMC POA&M

What an assessor checks for 3.5.3

NIST SP 800-171A gives 4 determination statements for 3.5.3, each found satisfied or other than satisfied. Determine if:

1. 3.5.3[a] privileged accounts are identified.
2. 3.5.3[b] multifactor authentication is implemented for local access to privileged accounts.
3. 3.5.3[c] multifactor authentication is implemented for network access to privileged accounts.
4. 3.5.3[d] multifactor authentication is implemented for network access to non-privileged accounts.

NIST SP 800-171A (June 2018), assessment objectives for 3.5.3

Evidence that shows 3.5.3 is met

• The list of privileged accounts.
• Identity provider policies requiring multifactor authentication for all users and all applications, with any exclusions explained.
• How administrators' local logons to servers require a second factor.
• Sign-in logs showing multifactor authentication satisfied.

How PolicyCortex gathers the evidence

PolicyCortex reads this evidence with the collectors below, read only, and grades 3.5.3 from it. Each line says what the product checks.

• Microsoft Entra ID: Conditional Access. Checks that Conditional Access requires multifactor authentication of every administrator role and of everyone who signs in to Azure management, and of all users on all cloud applications.
• Okta: Policies · Directory. Checks that Okta requires a second factor at every sign-in and that every user and every administrator has one enrolled.
• AWS: IAM. Checks that IAM console users and the root account have an MFA device.