8.3 Defense in Depth: Identity, Access Management, and Authentication
Key Takeaways
Defense in depth layers identity, authentication, authorization, network, data, detection, and recovery controls so a single failure does not expose personal data.
Least privilege is implemented with RBAC or ABAC, just-in-time elevation, privileged access management, separation of duties, and periodic access reviews.
SMS codes and typed one-time passwords can be intercepted or phished; FIDO2 security keys and passkeys are phishing-resistant because they are bound to the real site's domain.
NIST SP 800-63-4 (July 2025) requires AAL2 providers to offer a phishing-resistant option and AAL3 to use phishing-resistant, hardware-protected non-exportable keys.
Segmentation, short-lived scoped credentials, and per-tenant or per-user keys limit the blast radius of a compromise.
8.3 Defense in Depth: Identity, Access Management, and Authentication
Quick Summary: Defense in depth layers independent controls so that one failure does not expose personal data. The BoK highlights identity and access management (IAM) and authentication mechanisms as the core layers for protecting personal data during dissemination. Strong designs give every person and service the least access it needs, verify identity with phishing-resistant methods, segment networks and keys so a breach stays small, and log access so misuse is detected.
No single control is perfect. Passwords leak, employees make mistakes, and software has bugs. Defense in depth assumes each layer can fail and asks what the next layer does when it does.
The Layers Around Personal Data
| Layer | Example Controls | What It Stops |
|---|---|---|
| Identity | Single sign-on, unique accounts, workload identities for services | Shared accounts that make actions untraceable |
| Authentication | Multifactor authentication, passkeys, certificate-based service authentication | Stolen or guessed passwords |
| Authorization | Role-based (RBAC) and attribute-based (ABAC) access, least privilege, purpose checks | Over-broad access by legitimate users |
| Network | Segmentation, private endpoints, egress allowlists, zero trust | Lateral movement after a compromise |
| Data | Encryption with separate keys, tokenization, masking | Readable data after a store is copied |
| Detection | Access logs, anomaly alerts, data loss prevention | Undetected misuse or exfiltration |
| Recovery | Key rotation, credential revocation, incident runbooks | Prolonged exposure after an incident |
Identity and Access Management (IAM)
Least privilege means each identity gets only the permissions its task requires, for only as long as needed. Practical techniques:
- Role-based access control (RBAC) groups permissions by job function. It is simple but coarse: a "data scientist" role may allow queries that are fine for fraud work and inappropriate for marketing.
- Attribute-based access control (ABAC) evaluates attributes of the user, resource, action, and context (including declared purpose), which supports purpose limitation (Section 7.5).
- Just-in-time (JIT) access grants elevated rights for a short window after approval, instead of permanent administrator accounts.
- Privileged access management (PAM) vaults administrator credentials, records sessions, and requires approval for sensitive actions.
- Separation of duties prevents one person from both requesting and approving access, or from both exporting data and deleting the audit log.
- Access reviews (recertification) periodically confirm that each person still needs each permission, and joiner-mover-leaver processes remove access when people change roles or leave.
- Break-glass access for emergencies records who opened sensitive records and why, and triggers review.
Service accounts and APIs need the same discipline: short-lived tokens, narrowly scoped OAuth scopes, workload identities instead of embedded keys, and mutual TLS between services.
Authentication Mechanisms
Authentication factors fall into three categories: something you know (password, PIN), something you have (security key, phone, smart card), and something you are (fingerprint, face). Multifactor authentication (MFA) combines at least two categories.
Not all MFA is equal. One-time codes sent by SMS can be intercepted through SIM swapping, and codes typed into a fake login page can be relayed in real time by phishing proxies. Phishing-resistant authenticators, such as FIDO2/WebAuthn security keys and passkeys, bind the login to the real website's domain, so a look-alike site cannot reuse them.
NIST's SP 800-63-4 Digital Identity Guidelines, finalized in July 2025 and replacing SP 800-63-3, set three Authenticator Assurance Levels (AALs):
| Level | Requirement (summary) |
|---|---|
| AAL1 | Single-factor or multifactor authentication |
| AAL2 | Multifactor authentication, and providers must offer a phishing-resistant option; synced passkeys can qualify |
| AAL3 | Phishing-resistant authentication with a hardware-protected, non-exportable key |
Privacy Considerations in Authentication
Authentication systems themselves collect personal data, so privacy technologists check them too:
- Biometrics: prefer on-device matching (the template never leaves the phone's secure hardware) over central biometric databases (Section 11.3).
- Risk-based authentication uses signals such as device, location, and behavior; collect only what the risk model needs, disclose it, and keep it briefly.
- Identity proofing often demands identity documents; retain the verification result rather than copies of documents where rules allow.
- Account recovery is frequently the weakest link; recovery by security questions or SMS can undo strong MFA.
- Federation (OpenID Connect, SAML) can limit what each relying party learns, for example by releasing only needed claims or pairwise identifiers that differ per service.
Reducing Incident Blast Radius
In systems engineering, the blast radius represents the maximum scope of compromise if a specific component, credential, or microservice is breached. Monolithic architectures possess an unconstrained blast radius: compromising a single web application server grants access to global database credentials, exposing all historical records across all users and tenants.
Privacy-preserving architectures minimize blast radius through defense-in-depth controls:
+-------------------------------------------------------------------------+
| BLAST RADIUS CONTAINMENT |
| |
| [Compromised Web App] |
| | |
| v (Blocked by Micro-segmentation & ZTNA) |
| x - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| | Direct Database Access BLOCKED | |
| x - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| | |
| v (Must request short-lived, scoped token via OAuth 2.0) |
| [Token Issuance Broker] |
| | |
| v (Returns ephemeral token scoped to single tenant / record) |
| [Isolated Microservice with Row-Level Security] |
| | |
| v (Accesses encrypted partition with tenant-specific KMS key) |
| [Target Data Partition] (Max breach: 1 tenant, 1 transaction) |
+-------------------------------------------------------------------------+
- Micro-Segmentation and Zero Trust Network Architecture (ZTNA): Services communicate exclusively over mutual TLS (mTLS) with cryptographically attested identities (e.g., SPIFFE/SPIRE). Analytical clusters cannot establish physical or logical TCP connections to the PII identity vault.
- Ephemeral Scoped Access: Services do not maintain long-lived static database credentials with broad table permissions. Operations utilize short-lived security tokens (e.g., AWS STS, Vault dynamic secrets) scoped strictly to the current tenant and transaction context.
- Decoupled Key Hierarchies: By using distinct cryptographic keys per tenant or per user in Key Management Services (KMS), the compromise of a single key reveals only an isolated slice of ciphertext, rather than decrypting the global database.
A customer support platform protects agent logins with passwords plus one-time codes sent by SMS. Attackers have begun using look-alike login pages that relay codes in real time. Which change most directly strengthens this authentication layer?
Increase the SMS code length from six to eight digits.
Move agents to phishing-resistant authenticators such as FIDO2 security keys or passkeys.
Add a CAPTCHA to the login page.
Require agents to change their passwords every 30 days and prohibit reuse of the last ten passwords.
An analyst who moved from the fraud team to marketing six months ago still has query access to the fraud team's transaction tables. Which IAM process failed?
Joiner-mover-leaver processing and periodic access reviews, which should have removed access no longer needed for the new role
Encryption at rest, which should have hidden the tables from the analyst
Multifactor authentication, which should have blocked the analyst from logging in to the transaction database
Network segmentation, which should have placed marketing on a different subnet
Which design best limits the blast radius if one web application server in a multi-tenant SaaS platform is compromised?
A single database administrator credential stored in the application's configuration file so all services can connect quickly
Daily full backups of all tenants' data to the same server
Short-lived tenant-scoped credentials, segmentation around the vault, and per-tenant keys
A larger, more expensive firewall at the network perimeter, with no internal segmentation between application servers and databases
Sections you finish are checked off in the contents.