5.3.3. Approvals, Audit History, and Break-Glass Accounts
💡 First Principle: A privilege system needs a memory and an exception. The memory is PIM's request/approval trail and audit history — every activation attributable, every approval accountable. The exception is the break-glass account: deliberately outside PIM, CA, and MFA dependencies, because the emergency it exists for is precisely those systems failing.
Approvals in practice: approvers (users or groups; multiple approvers race — first decision wins per stage) act in the PIM portal or from notification email; requests time out if unanswered; approvers see justification and ticket data. Design guidance stems reflect: approvers should not be able to approve their own requests (use a separate approver population for the highest roles), and approval adds latency — reserve it for the roles whose misuse is catastrophic, use MFA+justification alone for routine tiers.
Audit history: PIM's resource audit logs every assignment, activation, approval/denial, and setting change (who, what, when, justification text) — exportable, and duplicated into the Entra audit logs (5.4.1) for SIEM pipelines. PIM alerts watch hygiene: roles activated too frequently (why is this eligible role active daily? make the duty a task role or fix the workflow), administrators aren't using their privileged roles (remove them), roles assigned outside PIM (someone bypassed governance — investigate), too many Global Administrators. Each alert carries severity and remediation guidance; "review activity" stems often resolve to reading these alerts.
Break-glass (emergency access) accounts — the exam's favorite paradox: two cloud-only accounts (*.onmicrosoft.com, no federation/sync dependency), Global Administrator assigned permanently and actively (not eligible — activation might be the broken thing), excluded from every Conditional Access policy and from MFA requirements that depend on phone/network availability (current guidance: phishing-resistant credentials like FIDO2 keys in a safe, rather than no second factor at all), credentials physically secured, and monitored: any sign-in triggers alerts (log-based alert on the account's sign-ins routed via 5.4's pipeline). Test them quarterly.
⚠️ Exam Trap: Every rule this phase taught inverts for break-glass accounts: permanent active beats eligible, excluded from CA beats governed by it, and their use should page humans. Stems that "fix" break-glass accounts by adding them to PIM eligibility or MFA-enforcing CA policies have broken the fire escape.
Reflection Question: Justify each break-glass property by naming the specific outage it survives: cloud-only, permanent active GA, CA-excluded, FIDO2-in-a-safe. Which monitoring configuration keeps the exception honest?
