Cisco Certified Network Associate (CCNA) 200-301 · Free study guide

Objective 5.3 — Configure local device access control

Local access control protects a device when centralized identity services are unavailable or out of scope. It should provide named identities, protected privileged access, authenticated console and VTY lines, and an encrypted remote transport. Local authentication is a useful control, but it creates a credential lifecycle on every device that operators must manage.

Protect privilege and identity

Use a protected enable secret for privileged EXEC access. A legacy enable password is weaker and should not be preferred when a secret is available. Create a local username with an appropriate secret rather than relying on one shared line password. Named accounts improve accountability, although local logs and synchronized time are still needed to connect activity to an event.

Commands that obscure clear-text passwords in configuration output provide limited protection and are not equivalent to strong one-way password storage. Do not mistake visual scrambling for cryptographic strength. Control access to backups because configuration files may contain sensitive material even when some values are hashed or encrypted.

Bind authentication to access paths

The console line controls direct local sessions; VTY lines control remote terminal sessions. Configure each intended path explicitly. A local user database has no effect on a line unless that line uses local authentication. Restrict remote transport to SSH so the login is not sent in clear text.

A basic SSH setup also needs a stable hostname, domain context where required, cryptographic keys, and supported SSH settings. Source restrictions can further limit which management networks reach the VTY lines. Timeouts and session limits reduce unattended exposure but do not replace authentication.

IOS command map

In an isolated lab, use enable secret <training-secret> for privileged access, and username lab-operator secret <different-training-secret> for a named local identity. Under line console 0 or line vty 0 4, login local binds that line to the local user database. Remote VTY lines also need transport input ssh; the SSH key and device-identity prerequisites are covered in Objective 4.8.

Use show running-config section line to review line authentication and transport, show users for current sessions, and a second authorized session to test both a valid and invalid login before closing the recovery session. Do not paste real secrets into a command transcript, and do not mistake service password-encryption for strong storage of every credential.

Worked scenario

A switch has a strong local user but its VTY configuration still accepts Telnet with a shared line password. The local account does not protect that active path. The operator enables local login on all VTY lines, allows only SSH, restricts sources to the management subnet, and confirms console recovery with authorized credentials. They preserve an out-of-band recovery process before ending the existing session.

Change safely

Keep one authorized session open while testing a second session through the intended path. Verify both normal and privileged access. Confirm that an invalid credential fails and an unapproved source cannot connect. Save the intended configuration only after recovery access is understood. An access-control change that locks out every operator is not a successful hardening action.

Verification evidence

Inspect local usernames, privilege configuration, line authentication, allowed transport, management ACL attachment, and active sessions. Test the exact console and remote paths in scope. Review logs with synchronized timestamps and confirm backups are protected. Avoid displaying real secrets in screenshots or support tickets.

Common traps

• Configuring a local username without applying local login to a line.
• Leaving Telnet enabled beside SSH.
• Equating reversible password obfuscation with strong storage.
• Hardening all paths before proving a recovery route.
• Sharing one named account among many operators.

Readiness checklist

• I can separate enable, console, and VTY authentication.
• I know why SSH and source restrictions work together.
• I can test a change without locking out operators.
• I recognize the operational limits of per-device accounts.