Part IV: Identity and Access Management

"The fake portal had her password and got nothing — because identity, done right, asks for something an attacker cannot steal from a thousand miles away."

Recall how the Meridian phishing attack actually failed. The attacker had a valid username and a valid password — and it did not matter, because the bank's authentication asked for a hardware security key the attacker could not produce. That is the whole argument for Part IV in a single sentence. In a world where the perimeter has dissolved and most breaches begin with stolen or abused credentials, identity is the new perimeter. The question "who is allowed to do what, and how do we know it's really them?" is no longer an IT housekeeping chore — it is the central control plane of modern security.

This part follows identity through its full lifecycle and across every kind of actor. We start with authentication — proving who you are — because that is where the Meridian story turned, and because phishing-resistant MFA is the single highest-leverage control most organizations can deploy. We then separate authentication from authorization (proving you are someone versus being allowed to do something — two ideas people conflate constantly), and build the access-control models that decide who gets what. From there we scale up: governing identity across thousands of accounts, federations, and directories; locking down the privileged accounts that are every attacker's ultimate objective; and finally securing the non-human identities — service accounts, API keys, certificates, workloads — that now vastly outnumber the human ones and are routinely the weakest link.

The recurring themes here are least privilege and the asymmetry of attack and defense. An attacker who compromises one over-privileged account, or finds one orphaned admin login left behind by a departed contractor, can turn a minor foothold into a domain-wide catastrophe. Identity is where "assume breach" gets operationalized: you design so that compromising a single credential is survivable, not fatal.

What you will learn

Chapter 16 — Authentication. Explain authentication factors and NIST 800-63 assurance levels; deploy phishing-resistant MFA and passkeys/FIDO2; store passwords correctly with bcrypt/argon2; and defend against credential stuffing, spraying, and push fatigue.
Chapter 17 — Authorization and Access Control. Distinguish authentication from authorization; design RBAC and ABAC alongside DAC and MAC; apply least privilege at scale; and prevent privilege creep and toxic permission combinations.
Chapter 18 — Identity Governance. Explain SSO, federation (SAML/OIDC/OAuth), and directory services; run the joiner-mover-leaver lifecycle and access reviews; and hunt down orphaned and over-privileged accounts.
Chapter 19 — Privileged Access Management. Inventory and vault privileged accounts; implement just-in-time access, session recording, and credential rotation; defend admin paths with tiering and privileged access workstations; and detect privileged-account abuse.
Chapter 20 — Secrets and Machine Identity. Manage secrets with vaults, dynamic secrets, and rotation; secure service accounts and workload identity; run certificate lifecycle at scale; and detect leaked secrets in code and logs.

Advancing the Meridian program

Part IV builds Meridian's identity backbone — the control plane that every other control ultimately depends on. Chapter 16 writes the authentication standard and circles back to the security key that saved the bank in Chapter 1, now formalized as policy. Chapter 17 designs the access-control policy, separating teller from administrator entitlements and enforcing separation of duties for wire transfers. Chapter 18 cleans up Meridian's Active Directory and Entra ID hygiene and closes the contractor-offboarding gap that left orphaned accounts behind. Chapter 19 locks down domain-admin access with vaulting, JIT, and tiering. Chapter 20 confronts the hard-coded key discovered in a Meridian code repository and establishes a secrets-management standard. The bluekit toolkit gains the identity modules: authn.py (password strength, breached-prefix checks via HIBP k-anonymity), authz.py (rbac_check, abac_eval), idgov.py (orphan-account and access-review detection), pam.py (privileged inventory, JIT windows), and secrets.py (secret scanning, certificate-expiry checks).

Prerequisites

Read Part I (especially Chapter 3's least-privilege and separation-of-duties principles, and Chapter 4's cryptography, which underpins password hashing, certificates, and mTLS). Parts II and III are strongly recommended — identity controls plug into the networks, hosts, and cloud you secured there. Within Part IV, the chapters are tightly sequential: each builds on the one before, and Chapter 20 in particular assumes Chapters 18, 19, and the crypto of Chapter 4. This part is the engineering track's core; engineers should read all five in order.

Time investment

Chapter	Title	Estimated hours
16	Authentication	6
17	Authorization and Access Control	5–6
18	Identity Governance	5–6
19	Privileged Access Management	5
20	Secrets and Machine Identity	5–6
Part IV total		26–29

Engineering-track readers should treat the entire part as essential. SOC-track readers will get the most operational value from Chapters 16, 19, and 20 (the detection of credential and privilege abuse). GRC-track readers should focus on Chapters 17 and 18, where access policy and certification reviews live.

Where this leads

You have now decided who may act and protected the credentials that prove it. But controls only matter if you can tell when they are being tested or bypassed. Part V moves into the Security Operations Center — the logging, detection, hunting, incident response, and forensics that turn all the architecture you have built into an organization that can actually see and respond to attacks in progress.