Least Privilege, AAA, Passwords, and MFA

Identity and Access Basics

Security is not only blocking packets; it is deciding who may use systems, what they may do, and how activity is recorded. The principle of least privilege is the rule behind most access decisions: give a person, service, or device only the permission needed for the task. A receptionist needs the scheduling app, not firewall administration. A printer needs print jobs, not file-share access. A guest phone needs Internet, not router management.

AAA in one table

AAA stands for Authentication, Authorization, and Accounting.

A user can authenticate successfully yet still be denied an action — that denial is authorization, not a login failure. In larger networks a RADIUS server (Remote Authentication Dial-In User Service) provides centralized AAA for VPN, switch admin, and enterprise Wi-Fi, so credentials live in one directory instead of being copied onto every device. This matters on the exam because it explains how enterprise Wi-Fi can hand each employee a personal login rather than one shared key, and how an administrator can revoke a single person's access instantly without touching any access point.

Password hygiene

A strong passphrase is long, unique, and hard to guess. Length matters more than forced symbol rules that push users toward Password1! patterns or sticky notes; modern guidance (for example NIST SP 800-63B) favors long passphrases and screening against breached-password lists over arbitrary 90-day rotation. Reuse is the central danger: one breached site exposes every account sharing that password. Default credentials on routers, access points, cameras, printers, and NAS units must be changed before the device is trusted on a network.

Technician rules of conduct:

• Never ask a user to tell or paste their password — use the approved reset workflow.
• Never store passwords in tickets, screenshots, chat, or plain-text notes.
• Verify identity before a reset per organizational procedure.
• If a device ships with a vendor default login, document that it must be changed during installation.
• For repeated lockouts, collect times and affected services instead of clearing the symptom over and over.

MFA — factors and abuse

Multi-factor authentication (MFA) requires at least two of three factor types:

• Something you know — password or PIN.
• Something you have — authenticator-app approval, one-time code, or a hardware FIDO2/U2F security key.
• Something you are — fingerprint or face scan.

MFA matters because a stolen password alone may not be enough to sign in. But it is not magic. MFA fatigue (push bombing) floods a user with prompts hoping they tap approve. Train users to reject unexpected prompts and to report repeated unexplained requests immediately — these often mean an attacker already has the password. Phishing-resistant methods (hardware keys, passkeys) defeat fake login pages that defeat one-time codes.

Least privilege for devices

Least privilege also governs infrastructure. Management interfaces should be reachable only from trusted networks or a VPN, never from guest Wi-Fi or the public Internet. Administrative accounts must be separate from everyday accounts, departed-staff accounts disabled promptly, and service accounts kept narrow with documented owners. You may not own the identity system, but you should ask the right questions: who needs access, what exact access, for how long, and who approved it?

Accounting and accountability in practice

Accounting is easy to overlook but it is what turns a vague "something happened" into a timeline. Sign-in logs reveal when an account authenticated and from where; configuration-change history reveals who altered a switch or router and what changed; session records reveal how long a connection lasted. When a manager asks "did this user access the file share last Tuesday?", accounting answers it. When investigating a possible compromise, accounting shows whether the attacker's logins succeeded and what they touched.

This is why shared accounts are dangerous: if five people log in as admin, accounting can no longer attribute an action to one person, and the audit trail becomes useless.

A least-privilege walk-through

Suppose a new contractor needs to upload files to one project folder for three months. The least-privilege answer is a new individual account (not a shared one), granted write access to that one folder only (not the whole share), with an expiration date set to the contract end, and a named approver recorded. Compare that to the lazy answer — adding the contractor to an existing admin group "so they can get in" — which violates every part of the principle and leaves access lingering after they leave. The CCST mindset is to ask the four questions every time: who needs access, what exact access, for how long, and who approved it.

Common traps

• Treating an authorization denial as a broken login and resetting the password needlessly.
• Assuming MFA makes phishing impossible — code-based MFA is still phishable; only passkeys/security keys are phishing-resistant.
• Leaving a vendor default password "until later," then forgetting it.
• Using one shared admin account, which destroys the accounting trail.