Apply authentication, MFA and least privilege so each person and service gets only the access it needs.
Why it matters
Most breaches involve an identity: a stolen password, a phished session, an over-powered service account or an old account nobody removed. Attackers increasingly "log in" rather than "break in". Identity and access management (IAM) is how organisations decide who someone is, what they may do, and how to prove what they did. It is a core skill for security, cloud and systems roles alike.
The core idea: four steps (IAAA)
- Identification: claiming an identity, such as a username or email.
- Authentication: proving the claim, such as with a password plus a second factor.
- Authorization: deciding what that identity is allowed to do.
- Accounting (auditing): recording what it did, so actions can be reviewed and traced.
Authentication answers "who are you?" Authorization answers "what may you do?" Mixing them up causes many access-control bugs: a system that checks you are logged in but never checks that the record belongs to you.
Authentication factors and MFA
Factors fall into three classic groups:
- Something you know: a password or PIN.
- Something you have: a phone app, a hardware security key, a smart card.
- Something you are: a fingerprint or face.
Multi-factor authentication (MFA) combines factors from different groups. A password plus a security question is still one factor (two things you know). A password plus a code from an authenticator app is two.
Not all MFA is equally strong:
| Method | Strength | Weak spot |
|---|---|---|
| SMS code | Better than nothing | SIM-swap fraud, interception, phishing |
| Authenticator app code (TOTP) | Good | Can be phished by a fake login page in real time |
| Push approval | Good with number matching | "MFA fatigue": users approve a flood of prompts to make them stop |
| Security key or passkey (FIDO2/WebAuthn) | Strongest, phishing-resistant | Needs device support and a backup method |
Passkeys and security keys are phishing-resistant because the key checks the website's real domain before answering; a look-alike site gets nothing useful.
Authorization models
- Role-based access control (RBAC): permissions are attached to roles (viewer, editor, admin), and people get roles. Easy to understand and review.
- Attribute-based access control (ABAC): rules use attributes such as department, location or time ("managers can approve expenses from their own department").
- Discretionary access control: the owner decides who can access their resource, as with file sharing.
Most real systems combine RBAC with a few attribute rules.
Least privilege and its friends
Least privilege means every person, program and service gets only the access needed for its job, and only for as long as needed. Related practices:
- Separation of duties: no single person can complete a sensitive action alone. The person who creates a supplier cannot also approve payments to it.
- Just-in-time access: admin rights are granted for a short window when needed and removed automatically.
- Separate admin accounts: admins browse and read email with a normal account and use a privileged account only for admin work.
- Joiner, mover, leaver process: grant access when people join, change it when they move roles (and remove the old access), and disable it the day they leave.
- Access reviews: managers regularly confirm who still needs what.
Service accounts and API keys need the same care. They often have broad rights, never log in interactively, and are forgotten. Give each one a single purpose, the narrowest permissions, and a known owner; store their secrets in a secrets manager, not in code.
Worked example: access for a small team
A five-person team runs a web app in the cloud.
| Person or service | Needs | Grant |
|---|---|---|
| Developer (x3) | Deploy to staging, read production logs | Developer role on staging; read-only logs role on production |
| Team lead | Approve and run production deploys | Deployer role on production, used through a separate admin account with a security key |
| Support agent | Look up a customer's account status | Read-only support role limited to the customer table, no export |
| CI pipeline | Push a container image and update one service | A service identity that can update only that service, no human login |
| Former intern | Nothing | Account disabled on the last day; keys rotated |
Before this review, all three developers had full admin rights "to save time" and the intern's account was still active. Each change is small, but together they mean a single phished developer password can no longer take down production or read every customer record.
Common mistakes
- Shared accounts. Five people using
adminmakes accounting impossible. - Privilege creep. People collect access as they change roles and nothing gets removed.
- MFA everywhere except the most important place, such as email, the domain registrar or the cloud root account.
- Checking authentication but not authorization on every request.
- Long-lived keys in code. Rotate keys, prefer short-lived credentials, and scan repositories for leaked secrets.
Quick recap
- IAAA: identification, authentication, authorization, accounting.
- MFA means factors from different groups; phishing-resistant methods (passkeys, security keys) are strongest.
- Least privilege, separation of duties, just-in-time access and regular reviews keep access small.
- Remove access on role changes and departures, and treat service accounts as identities with owners.