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

Objective 5.4 — Explain strong authentication policy

Authentication policy should make account takeover difficult while keeping recovery controlled and usable. Length, uniqueness, protected storage, multifactor authentication, certificates, and biometrics solve different parts of the problem. No single requirement should be treated as complete identity security.

Design practical password rules

Long, unique passwords or passphrases resist guessing and prevent a breach at one service from directly unlocking another. A password manager can help users maintain uniqueness. Block known-compromised values and protect stored credentials with an appropriate slow, salted one-way scheme when designing a service. Network operators should never place real passwords in scripts, tickets, lab files, or version control.

Forced complexity that encourages predictable substitutions adds less value than usable length and uniqueness. Frequent scheduled changes can cause weak patterns; change credentials when exposure is suspected, roles change, or policy demands it. Device capabilities and organizational requirements still matter, so document constraints instead of silently weakening the policy.

Understand factor types

Authentication factors are commonly something a user knows, has, or is. Two passwords are not two independent factors because both are knowledge. A password plus a hardware token combines different factor types. Multifactor systems must also protect enrollment, reset, backup codes, and help-desk recovery; attackers often target the easiest bypass rather than the strongest login screen.

Certificates use a trust model to associate an identity with a public key. Their value depends on private-key protection, trusted issuers, validation, expiration, and revocation handling. Biometrics are inherence factors. They are convenient, but they cannot be changed like a password after compromise and require a secure fallback plus appropriate privacy handling.

Worked scenario

Administrators use unique passphrases and a token for VPN access, but the help desk resets accounts after answering public biographical questions. The normal login is strong while recovery is weak. A better policy verifies recovery with approved, independently established evidence, alerts the account owner, limits help-desk privileges, records the event, and promptly invalidates exposed sessions or backup codes.

Lifecycle and scope

Authentication includes enrollment, issuance, use, rotation, revocation, recovery, and deletion. Offboarding must revoke credentials and active sessions. Service accounts need owners, limited permissions, noninteractive handling where possible, and controlled secret rotation. Emergency accounts should be tightly protected, monitored, and tested rather than forgotten.

Verification evidence

Review factor independence, enrollment proof, reset controls, certificate validity, disabled-account timing, and audit records. Test expired, revoked, and incorrect credentials. Confirm that sensitive values are redacted from logs and that authorized recovery works during a simulated outage.

Common traps

• Calling two knowledge secrets multifactor authentication.
• Ignoring enrollment and recovery paths.
• Treating a certificate as trustworthy without validation.
• Assuming biometrics are secret and easily replaceable.
• Reusing privileged credentials in automation.

Readiness checklist

• I can explain length, uniqueness, and protected storage.
• I distinguish knowledge, possession, and inherence factors.
• I can describe certificate and biometric tradeoffs.
• I include recovery and revocation in authentication design.