# NIST800 171 3.5.3 — Multi-Factor Authentication

- Source: https://support.icompaas.com/support/solutions/articles/a_gen_nist800171_353_4cf02e821a-nist800-171-353-multi-factor-authentication
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [NIST SP 800-171 Readiness](https://support.icompaas.com/support/solutions/c_gen_nist800171) › [Identification and Authentication](https://support.icompaas.com/support/solutions/folders/f_gen_cgennist800171_identificationandauthentication)
- Last updated: 2026-05-30
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

NIST800 171 · Control 3.5.3 · Priority: critical · Component: Identification and Authentication

### What this control covers

This control mandates the implementation of multi-factor authentication (MFA) for both privileged and non-privileged accounts. MFA requires the use of at least two distinct authentication factors, such as something the user knows (PIN), has (physical authenticator), or is (biometric). MFA can be applied at both the system and application levels to enhance security. This control supports the Multi-Factor Authentication capability within the Identification and Authentication (3.5) family.

### Why it matters

Identity is the new perimeter — most breaches start with a stolen credential or over-privileged account, so this control is one of the single highest-leverage items you can implement.

### How to implement

#### AWS

Use **IAM Identity Center** (formerly AWS SSO) as the single source of truth for human access; back it with your corporate IdP via SAML/SCIM. Avoid IAM users for people — they don't get MFA-by-default, rotation, or session lifetimes. For workloads, use **IAM Roles** (assumed by EC2/Lambda/EKS service accounts via IRSA) and never long-lived access keys. Run [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer.html) weekly to surface unused access and external-account exposure.

#### Azure

Centralize identity on **Microsoft Entra ID** (formerly Azure AD). Require **Conditional Access** policies: MFA for all admin roles, block legacy auth, location/device gating. Use **Privileged Identity Management (PIM)** to make admin roles just-in-time and time-bound. For Azure resources, prefer **Managed Identities** over service principals with secrets.

#### GCP

Use **Cloud Identity** (or Workspace) as the IdP and **IAM** for resource access. Grant roles at the lowest scope (project > folder > org) using **Workload Identity Federation** for CI/CD and **service accounts** for workloads — never download service-account keys when avoidable. Enable **Policy Intelligence** recommenders to right-size privileges and detect dormant identities.

#### Google Workspace

Enforce **2-Step Verification** (preferably hardware keys for admins) for the entire org, set session length to ≤ 12 hours, and disable less-secure-app access. Use **Context-Aware Access** levels to restrict admin sign-in by IP/device posture. Provision and de-provision users via **SCIM** from your HRIS so leavers lose access on day one.

#### GitHub

Require **SSO + SCIM** from your IdP on the organisation; enforce **2FA** org-wide and use **fine-grained PATs** (or, better, GitHub Apps) instead of classic tokens. Restrict **outside collaborators**, require signed commits on protected branches, and use **OIDC** from Actions to short-lived AWS/GCP/Azure credentials rather than stored secrets.

#### Zoho Mail

Make **two-factor authentication** mandatory for all users (TOTP, OneAuth, or YubiKey) in _Admin Console → Security_. Configure **SAML SSO** against your IdP and disable password-based logins for admins. Use **role-based privileges** (Admin / Spam Moderator / Mail Account Admin) and review the _Login history_ report monthly for anomalies.

### Evidence to collect

-   `identity_scan` — See the iCompaas Evidence library for the canonical source for this evidence type.

Identity analytics (Okta, SailPoint, Access Analyzer) demonstrates least-privilege. Focus: Multi-Factor Authentication.

### Quick checklist

-   Access — Management / Authentication
-   Least — Management / Authentication
-   System — Management / Authentication
-   Multi-Factor — Management / Authentication
-   Authentication — Management / Authentication
-   Authenticator — Management / Authentication

### Related articles on this site

-   [Ensure that 'Multi-Factor Auth Status' is 'Enabled' for all Non-Privileged Users](https://support.icompaas.com/support/solutions/articles/62000219680-ensure-that-multi-factor-auth-status-is-enabled-for-all-non-privileged-users)
-   [NIST 800-171 3.5.3 Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.\[24\] \[25\].](https://support.icompaas.com/support/solutions/articles/62000229291-nist-800-171-3-5-3-use-multifactor-authentication-for-local-and-network-access-to-privileged-accounts)
-   [NIST 800-171 3.5.4 Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.](https://support.icompaas.com/support/solutions/articles/62000229292-nist-800-171-3-5-4-employ-replay-resistant-authentication-mechanisms-for-network-access-to-privileged)
-   [CMMC 2.0 IA.3.083 Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.](https://support.icompaas.com/support/solutions/articles/62000229476-cmmc-2-0-ia-3-083-use-multifactor-authentication-for-local-and-network-access-to-privileged-accounts-)

## Related compliance guidance

- [NIST SP 800-171 and CMMC: a practical guide to protecting CUI in the cloud](https://support.icompaas.com/compliance/nist-sp-800-171-rev-3): The CUI requirements CMMC Level 2 assesses, the SPRS score, POA&M rules and the phased DFARS rollout.
- [NIST SP 800-53 Rev. 5: a practical implementation guide for cloud teams](https://support.icompaas.com/compliance/nist-sp-800-53-rev-5): The federal catalogue 800-171 is derived from — useful when a contract also cites a FedRAMP baseline.