SSH to the core switch is network access, and MFA applies to it

Inside the LAN still counts as network access

Most teams put the extra scrutiny on the VPN. The engineer in the NOC who opens an SSH session to the core switch is treated as local, because they’re inside. SP 800-53 Rev. 5 draws the line somewhere else. AC-17 covers remote access, meaning access through “external networks such as the Internet.” Everything else that crosses a network lands in AC-6(3), whose discussion is one sentence long: “Network access is any access across a network connection in lieu of local access (i.e., user being physically present at the device).”

So SSH from a jump host, from the admin VLAN or from a laptop on the office LAN is network access to privileged commands. AC-6(3) asks you to “Authorize network access to [Assignment: organization-defined privileged commands] only for [Assignment: organization-defined compelling operational needs] and document the rationale for such access in the security plan for the system.” For network gear the need is rarely in doubt, since nobody drives to the data center to change an ACL. The work is writing it down: which commands, for whom, and from where.

MA-4 reaches the same place from the maintenance side. Its discussion says “Nonlocal maintenance and diagnostic activities are conducted by individuals who communicate through either an external or internal network.” The control asks you to “Employ strong authentication in the establishment of nonlocal maintenance and diagnostic sessions” and to “Maintain records for nonlocal maintenance and diagnostic activities”, and it defines strong: “Strong authentication requires authenticators that are resistant to replay attacks and employ multi-factor authentication.” Whether routine configuration work counts as maintenance is a scoping decision your organization makes and documents. Firmware upgrades and vendor diagnostics clearly fit.

MFA covers every privileged path, console included

IA-2(1) is short: “Implement multi-factor authentication for access to privileged accounts.” The IA-2 discussion removes any doubt about where it applies: “Regardless of the type of access (i.e., local, network, remote), privileged accounts are authenticated using multi-factor options appropriate for the level of risk.” Rev. 4 had a separate enhancement for local access to privileged accounts. In Rev. 5 IA-2(3) is withdrawn and incorporated into IA-2(1). If your control mapping cites IA-2(3) for console access, it points at a control that no longer exists.

That leaves break-glass accounts. AC-2 recognizes them as “local logon accounts used for special tasks or when network resources are unavailable (may also be known as accounts of last resort)”, and notes they aren’t subject to automatic disabling. They exist because AAA can fail, which is a good reason to have them and a poor reason to leave them loose. Treat each one as a documented exception: one per device, a sealed credential, an alert every time it’s used, and a new password afterwards.

Shared logins are the other gap. IA-2(5) says: “When shared accounts or authenticators are employed, require users to be individually authenticated before granting access to the shared accounts or resources.” A local “admin” account with the same password on two hundred switches fails that test unless people reach it only after signing in as themselves somewhere else.

Being inside the building doesn’t make an SSH session local.

Put the management plane behind one door

SC-7(15) asks you to “Route networked, privileged accesses through a dedicated, managed interface for purposes of access control and auditing.” In practice that means a short, known list of places admin sessions can come from, enforced by a management ACL or policy on every device. It doesn’t have to be a separate out-of-band network. MA-4(4) asks you to separate maintenance sessions from other network sessions by physically or logically separated paths, and its discussion says “Communications paths can be logically separated using encryption.” An admin VRF with a tight ACL and encrypted protocols is a common way to address both.

Timeouts, banners and cleartext protocols

Two controls cover idle sessions, and they’re easy to mix up. SC-10 asks you to “Terminate the network connection associated with a communications session at the end of the session or after [Assignment: organization-defined time period] of inactivity.” AC-12 covers the user session itself, “in contrast to SC-10, which addresses the termination of network connections.” On network gear both usually come down to the idle timeout on the CLI and the web interface. Pick the period, write it down, and check it’s set everywhere.

Login banners (AC-8) are for people. Its discussion says “Notifications are not required when human interfaces do not exist”, so API collectors and automation accounts don’t need one.

For the protocols, SC-8(1) lists the cryptographic mechanisms that protect information in transit, and they “include TLS and IPSec.” SSH and HTTPS on the device follow the same logic. Turning off the cleartext ones falls under CM-7. The old AC-17(8), which disabled nonsecure network protocols, was withdrawn into CM-7 in Rev. 5. CM-7(1) only names “Bluetooth, FTP, and peer-to-peer networking” as examples, so Telnet, HTTP and SNMPv1 and v2c belong on the prohibited list you write for CM-7 yourself.

A management-plane checklist

1. List who can reach each management interface. Per the configured routes and policies, it should be a short list of jump hosts and admin networks. Anything else is a finding.
2. Write the AC-6(3) rationale. Which privileged commands, for which roles, from where, recorded in the security plan.
3. Put MFA in front of AAA. Devices authenticate against TACACS+ or RADIUS, and the AAA side enforces the second factor. Verify it there, not on the switch.
4. Use named accounts. No shared login without individual authentication first.
5. Handle break-glass as an exception. One local account, a sealed credential, an alert on use, and rotation afterwards.
6. Set idle timeouts to the period you defined for SC-10 and AC-12.
7. Turn off cleartext management. Telnet, HTTP and SNMPv1 and v2c, listed in your CM-7 prohibitions.

Where SAMURAI fits, and where it doesn’t

SAMURAI reads the management side of each device from its configuration: management ACLs, AAA server settings, local accounts, enabled protocols and timeouts. Every change to those lines shows up in a diff with the admin who made it, so an edit made under a shared account or a break-glass login is visible under that name. You can alert on changes to local accounts or management ACLs, run fleet-wide checks for cleartext protocols with waivers for the exceptions, and use path simulation to see which networks can reach a management interface per the configured routes and policies. That’s evidence for AC-6(3), SC-7(15), SC-10 and CM-7 reviews. It isn’t the control.

1. It can’t verify the second factor. The device points at an AAA server. Whether that server enforces MFA is a question for the AAA side.
2. It doesn’t see accounts that live only on the AAA server. Those need their own access review.
3. It doesn’t record sessions or commands. AAA accounting does; see our post on logging settings as audit information.
4. It can’t disconnect anyone. It’s read-only, so ending a session or removing an account is a person’s job.
5. Attribution stops at the account. A change made as the shared “admin” is attributed to “admin”, which is itself the IA-2(5) finding.

Which of these enhancements your system must meet depends on the baseline you tailor from SP 800-53B. Whatever it is, the management plane is usually the smallest list of settings with the biggest consequences. Check 9 of our firewall audit checklist covers the same ground for firewalls, and the docs cover deployment and requirements.