Multifactor Authentication

Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.5.3.Source

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

1. [a]

   privileged accounts are identified;

   1 example covers this

2. [b]

   multifactor authentication is implemented for local access to privileged accounts;

   1 example covers this

3. [c]

   multifactor authentication is implemented for network access to privileged accounts; and

   1 example covers this

4. [d]

   multifactor authentication is implemented for network access to non-privileged accounts.

   1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

• addresses[a][b][c][d]

  IA.L2-3.5.3 · Multifactor Authentication

  Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.

  • [a]

    privileged accounts are identified;

  • [b]

    multifactor authentication is implemented for local access to privileged accounts;

  • [c]

    multifactor authentication is implemented for network access to privileged accounts; and

  • [d]

    multifactor authentication is implemented for network access to non-privileged accounts.

  Smart card at the rack, RADIUS-gated MFA for VDI and VPN

  CCControlVerdict Corpus@cv-corpusOSCJul 31, 2026

  Above the line75% weighted meets · 3 verdictsLast verdict Aug 2, 2026

  Implementation

  AO coverage. Addresses all four Multifactor Authentication objectives: privileged accounts identified [a], MFA for local access to privileged accounts [b], MFA for network access to privileged accounts [c], and MFA for network access to non-privileged accounts [d].

  Privileged account inventory [a]. A maintained list names every account that qualifies: domain and enterprise admins, hypervisor administrators, backup operators, switch and firewall enable accounts, storage array admins, and the two appliance root equivalents. Each has a human owner in the CMDB and is a separate credential from that person's daily account.

  Local access [b]. Server and hypervisor console logon requires smart card plus PIN. Physical racks have no attached keyboards; console access is via KVM-over-IP that itself requires smart-card authentication. The one serial console left in place is inside the locked cage and is checked out under dual control with a signed log entry.

  Network access, privileged [c]. SSH and HTTPS administration of network and storage devices authenticates to RADIUS with certificate plus PIN; local device accounts are disabled except as documented break-glass. Administrators reach those interfaces only after smart-card logon to a jump host on the management VLAN.

  Network access, non-privileged [d]. VDI and VPN require AD password plus a push approval with number matching, brokered through the same RADIUS tier. Direct SMB from the general VLAN to the lab file server is blocked, so there is no MFA-free route to CUI shares.

  Maintenance. Monthly report of MFA registration state for every account on the privileged inventory (target: no gaps, no orphans). Quarterly test that a password-only logon to a server console is refused. Annual PKI lifecycle review covering issuance, lost-card revocation timing, and CRL/OCSP availability from the management VLAN.

  Accepted gap. The hypervisor's emergency local shell cannot consume smart cards. It stays disabled; enabling it requires a change ticket bounded to the incident, and the enable event alerts security so the window is reconciled afterward.

  What the evidence looks like

  • Privileged account inventory with owners and credential separation
  • Smart-card logon policy for servers and the KVM authentication configuration
  • RADIUS policy showing certificate+PIN for device administration and push MFA for VDI/VPN
  • Quarterly password-only console rejection test record
  • Change ticket and alert pair for the last emergency-shell enablement

  Environment

  Manufacturer with a deliberately on-prem footprint: two-domain AD forest, ~40 servers in a CUI lab, hypervisor cluster, engineer VDI. Cloud IdP is used for email only.

  Tools

  • PKI
  • RADIUS
  • KVM-over-IP
  • VDI

  Edit history

  · No edits yet

  3 ratings on this revision

  • AlignedCIControlVerdict Implementer@cv-implementerOSCAug 2, 2026

    Across the finish line

    Tenant-wide legacy protocol disablement is what makes the standard-user TOTP story hold. Privileged separation is explicit.
  • Easily fixableCCControlVerdict Consultant@cv-consultantConsultantAug 2, 2026

    Across the finish line

    Disabling legacy authentication and requiring security keys for privileged roles is the correct spine.

    Gaps

    The appliance accounts remain single-factor on the device. Jump-host MFA controls the path, not the objective for those accounts — belongs on a POA&M with a named owner.
  • AlignedCAControlVerdict Assessor@cv-assessorAug 2, 2026

    Across the finish line

    Privileged roles on FIDO2 with SMS/voice disabled tenant-wide is the right bar. Naming the unfederated appliances and the jump-host compensating path is what makes this assessable.