20 — Identity and Access Defence
Level: Intermediate · Time: ~20 min · Prerequisites: Lesson 19 — Endpoint Security
Why this matters
Lesson 13 established the uncomfortable fact that attackers would rather log in than break in. A stolen credential produces no exploit to match on, arrives from a real user account at a plausible hour, and travels through every control you built for outsiders. That makes identity the control plane: the place where a handful of decisions — who must use a second factor, which device may reach which application, which account holds privilege, and how quickly access disappears when someone leaves — determine the shape of most incidents before they happen. The good news is that identity defence is mostly configuration and process rather than engineering, which means a small team can genuinely deliver it.
The mental model: four questions, four levers
| Question | The lever | The failure mode it removes |
|---|---|---|
| Is this really the user? | strong authentication (MFA, passkeys) | password spraying, stuffing, phishing |
| Should this login be allowed here, now, from this device? | conditional access | stolen credentials used from anywhere on anything |
| What may this identity reach? | least privilege, RBAC, PAM | one compromised account reaching everything |
| Is the access still justified? | joiner-mover-leaver, access reviews | dormant accounts, privilege that outlived its reason |
Notice that only the first lever is what people mean when they say "security". The other three are what decide how bad a compromise becomes, and they are the ones most organisations never finish.
MFA that actually resists phishing
Not all second factors are equal, and the differences are not academic — attackers have industrialised the defeat of the weak ones.
| Factor | Resists | Defeated by | Use it for |
|---|---|---|---|
| SMS code | password guessing only | SIM swapping, real-time phishing proxies | legacy or low-risk accounts while you migrate |
| Email code | very little more | anyone who can read the mailbox | avoid; it collapses to a single factor |
| Push notification | most password attacks | push fatigue, real-time proxies | acceptable with number matching |
| Push with number matching | push fatigue | real-time proxies | the practical default for most staff |
| TOTP app code | SIM swapping, push fatigue | real-time proxies that relay the code | good, cheap, no telephony dependence |
| Passkey / hardware key (FIDO2) | real-time proxies, session theft, most phishing | nothing practical — the credential is bound to the origin | administrators, finance, email, anything privileged |
The argument for phishing-resistant factors is simple and worth stating plainly: a credential bound to the origin cannot be replayed on an attacker's lookalike domain, and there is no code to relay. Everything above it in that table can be defeated by a proxy that sits between the user and the real login page. That is why administrators and anyone who can move money should be on hardware keys or passkeys first.
Roll out MFA without a rebellion:
- Start where the risk is concentrated — email, VPN, cloud console, admin accounts, finance and banking, and the password manager itself.
- Communicate before you enforce: what changes, when, what the fallback is, who to call.
- Provide a fallback that works on day one for people who lose their phone or key. A second enrolled factor, not a helpdesk bypass.
- Enforce in stages, and measure enrolment and failure rates as you go — a rollout nobody can complete is a rollout that gets switched off.
Passwordless and passkeys remove the shared secret altogether: the device holds a private key, the service holds the public key, and authentication is a signed challenge. Passkeys sync across a user's devices through their platform account, which is convenient and is also the trade-off — the platform becomes part of your trust story. Hardware keys are not synced, so they are the stronger choice for privileged identities. Neither removes the need for account recovery design; both remove the password database as an attractive target.
Conditional access: zero trust that you can actually configure
Lesson 16 described zero trust as an idea. Conditional access is where it becomes a policy: every sign-in is evaluated against a set of conditions, and the decision is allow, allow with a requirement, or block.
sign-in ──► evaluate: user | group | device state | location | risk | application
│
├── allow
├── allow, but require MFA / compliant device / compliant app
└── block
Concrete policies worth having on day one:
| Policy | Effect | Why |
|---|---|---|
| Block legacy authentication | stops protocols that cannot do MFA | most credential-stuffing traffic uses them because they bypass the second factor |
| Require MFA for all administrator roles, always | no exceptions, no remembered devices | admin accounts are the ones that matter |
| Require a compliant or managed device for finance applications | unmanaged personal laptop cannot open the ledger | turns device management into an access decision |
| Block sign-ins from countries you do not operate in | removes most of the background noise | pair with a documented exception path for travellers |
| Require re-authentication for risky sign-ins | stolen sessions do not live forever | closes the gap lesson 13 called session-token theft |
Conditional access is a feature of a licensed identity platform — Microsoft Entra ID is the common one. Open-source identity providers such as Keycloak or Authentik can express some of the same ideas, with a shorter list of conditions available. The concept matters more than the vendor: a decision based on who, what device, where from, and how risky.
Federated identity and privileged access
Single sign-on means one identity, one login, many applications. The security argument is not convenience, it is subtraction: fewer passwords per person means less reuse, less password fatigue, and one place to enforce MFA and revoke access. The trade-off is that your identity provider becomes the most critical system you own. Plan for it explicitly — harden it, back up its configuration, restrict its administrators, and treat an outage as a business continuity event rather than an IT ticket.
Privileged access management
Shared administrator accounts and a spreadsheet of passwords are the root cause of most privilege abuse. The fix is a set of practices, not a product:
| Practice | What it removes |
|---|---|
| Vaulting and rotation | passwords written down, shared, and never changed; rotate automatically, check out individually |
| Separate admin identity | the everyday account that reads email is not the account that holds privilege |
| Session brokering and recording | nobody knows who did what; now every privileged session is attributable and reviewable |
| Jump hosts and admin workstations | admin access from a machine that browses the web; administrative work happens from a hardened host, through a controlled entry point |
| Just-in-time elevation | permanent standing privilege; grant the right for the hours it is needed, then take it back |
| Managed service accounts | service credentials that never rotate; where the platform offers a managed account type, use it |
Open-source options exist for most of this: HashiCorp Vault or a self-hosted password manager for secrets and vaulting, Teleport for brokered and recorded access, a hardened bastion host for the jump point, and your platform's own privileged-role feature for time-boxed elevation. Lesson 33 covers secrets management in more depth.
Access hygiene: the process that protects you
Most identity breaches are process failures that a tool is then blamed for. The joiner-mover-leaver cycle is where that process lives.
| Stage | The checklist | Why it matters |
|---|---|---|
| Joiner | account created from a request with an owner and a role; access granted by group, not by hand; MFA enrolled before first use; manager confirms the role | every hand-granted permission is a permission nobody will ever review |
| Mover | old access removed before new access is added; manager re-confirms what is still needed; privileged access re-approved rather than carried over | the most common source of excess privilege: yesterday's job plus today's job |
| Leaver | disable the account first; revoke sessions and tokens; transfer data ownership; recover devices; record who holds the mailbox; delete or anonymise after the retention period | the last day matters most, because a leaver's credentials are exactly what a departing or disgruntled person has, and often sells |
Access reviews turn that from a one-off into a rhythm: twice a year, list the members of every privileged group and every application, and ask each owner to confirm or remove. Reviewers who approve everything are the risk — give them the last-login date and the created date next to each account.
[!IMPORTANT] Disable the account on the last day before you collect the laptop, and revoke the sessions in the same sitting. Access removed in the wrong order leaves a live token on a device that is walking out of the building.
Dormant accounts are the cheapest win. Query last logon dates across the directory, then disable anything that has not authenticated in 90 days, with a documented exception process. Include service accounts and accounts belonging to systems, and check them again after every leaver.
Service accounts deserve their own paragraph. They usually have non-expiring passwords, high privilege, no MFA and nobody's name next to them. Fix the pattern rather than the instances: use the platform's managed service account type where it exists, give them only the permissions the service needs, block interactive logon, and put the credential in a vault rather than in a script.
Session security
Access that has been revoked on paper may still be live on the wire. Sessions and tokens outlive the password change unless you revoke them.
| Setting | Practical value |
|---|---|
| Idle timeout and screen lock at the endpoint | a walk-away is not a compromise |
| Short access-token lifetime with refresh | limits how long a stolen token is useful |
| Absolute session lifetime | forces periodic re-authentication regardless of activity |
| Explicit revocation on incident | "revoke all sessions" for that user, not just a password reset |
When you revoke access during an incident, revoke the sessions and refresh tokens as well as the password, and remember that many systems hold their own separate sessions.
Break-glass access
You need a way in when the identity provider is down or misconfigured. That path must not become a permanent backdoor: one or two emergency accounts, excluded from conditional access by design, with a long randomly generated password, stored split in a physical safe, documented to the people who may use it, monitored so that any use raises an alert, and tested on a calendar. A break-glass account that nobody has tested is a plan, not a capability.
What to watch, and what to fix in what order
Alert on the actions that change an identity's power, not only on failed logins. The specific queries belong in Lesson 44; the list of what matters belongs here.
| Alert | Why it is high-signal |
|---|---|
| MFA disabled, reset or a factor re-enrolled for a user | frequently the first step in account takeover |
| A new administrative account, or a new member of a privileged group | privilege change is the whole point of the attack |
| Impossible travel, or a first-ever login from an unusual country | stolen credentials used from elsewhere |
| A dormant account suddenly active | the classic sign of an unmanaged or forgotten credential |
| Mass group or role changes | bulk change is either a bulk mistake or an attacker setting up |
| Sign-in from a non-compliant or unmanaged device to a sensitive application | conditional access being bypassed, or not configured |
Putting it together as a priority order for a small team:
| Control | What it stops | Effort |
|---|---|---|
| MFA on email, VPN, cloud console, admin accounts, finance | the majority of credential-based intrusion | medium — mostly rollout and support |
| Remove dormant accounts, review privileged groups | attackers using credentials nobody is watching | low |
| Separate admin accounts; no admin on email accounts | the standard privilege-escalation chain | low |
| Conditional access: block legacy auth, require MFA for admins, require managed devices | token theft, replay, unmanaged devices | medium |
| PAM: vaulting, rotation, jump host, session recording | shared passwords and unattributable privileged activity | high |
| Phishing-resistant factors for privileged and finance users | real-time phishing proxies and session theft | medium, per user |
| Joiner-mover-leaver process with a written checklist | the whole class of "access that should not exist" | low, and needs discipline |
Attack it / Defend it
| The attack | How it works | The control that stops it |
|---|---|---|
| Password spraying | one common password tried across many accounts | MFA, banned-password lists, alerting on distributed failures |
| Credential stuffing | passwords reused from other breaches | MFA, breach-password screening, phishing-resistant factors |
| Push fatigue | repeated approval prompts until one is accepted | number matching, prompt rate limits, training to deny and report |
| Real-time phishing proxy | relays password and code from a lookalike page | FIDO2 keys and passkeys, conditional access, URL filtering |
| Session-token theft | steals the cookie after authentication | short token lifetimes, device compliance requirements, re-authentication on risk |
| MFA reset by an attacker | takes over the account, then re-enrols their own factor | alert on MFA change, require a verified process for factor resets |
| Shared admin credentials | the same password for a whole team | vaulting with checkout, per-person admin accounts, session recording |
| Standing privilege | an admin role held permanently, used once a year | just-in-time elevation, access reviews with dates visible |
| Dormant account abuse | uses an account nobody monitors | disable after 90 days of inactivity, review after every leaver |
| Brute force on a service account | a non-expiring password on an unmonitored identity | managed service accounts, non-interactive logon, vaulted credentials |
| Leaver retaining access | the account is never disabled, or sessions are left alive | disable and revoke on the last day, as a checklist item |
Key takeaways
- Identity is the control plane, because attackers log in rather than break in. Configuration and process here beat almost any purchase elsewhere.
- "We have MFA" is a spectrum, not a yes. SMS, push, TOTP and passkeys stop very different attacks; put the strongest factor on the identities that matter.
- Conditional access is zero trust made concrete: a decision based on the user, the device, the location, the risk and the application.
- The leaver checklist matters most. Access that is not removed is access an attacker will eventually find and use.
- Sessions outlive passwords. Revocation means revoking tokens, not just changing a credential.
- Keep break-glass access deliberate, tested and alerted — an emergency path is fine, a forgotten backdoor is not.
Check yourself
- Your organisation has push-based MFA everywhere. Which attack still works, and which change to the factor removes it?
- Why is blocking legacy authentication one of the highest-value conditional access policies you can write?
- A user changes roles internally. What is the order of operations for their access, and what happens if you get it wrong?
- Why does rotating a service account's password manually tend to fail, and what does the platform's managed account type change?
- You revoke a compromised user's access during an incident. Name two things beyond the password that must also be dealt with.