IA.L2-3.5.3Multifactor 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
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
Tools
3 ratings on this revision
Across the finish line
Tenant-wide legacy protocol disablement is what makes the standard-user TOTP story hold. Privileged separation is explicit.
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.
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.
Was this example useful?
Quick reaction — no account needed. For reasoning that moves the community meter, cast a full verdict below.
Discussion(0)
No discussion on this example yet
Verdicts capture a conclusion. Use a thread when the interesting part is the argument.
Sign in to start a thread.