Case Study 1: Meridian's Identity Cleanup and the Contractor Who Never Left

"We didn't have an attacker problem. We had a memory problem — the bank could not remember who was allowed in." — Sam Whitfield, Security Engineer, Meridian Regional Bank (constructed)

Executive Summary

A routine audit of who could approve wire disbursements at Meridian Regional Bank surfaced a finding no bank wants in front of an OCC examiner: a contractor who had finished a six-week engagement eleven months earlier still had an enabled Active Directory account, still belonged to the loan-approval group, and could still log in to the bank's single sign-on portal from anywhere in the world. This case study follows Security Engineer Sam Whitfield and GRC Analyst Elena Vasquez through the eight-week identity governance project that followed — establishing ground truth by reconciling the directories against the systems of record, remediating roughly eighty orphaned accounts at the source, and then closing the root-cause gap so that contractor offboarding moved from "hope someone files a ticket" to "automatic and reviewed." It is a governance-and-build study: you will watch the joiner-mover-leaver lifecycle, access certification, and orphaned-account reconciliation stop being definitions and become a standing program. This is the program increment Chapter 18 contributes to Meridian's security program, and it is the direct retirement of risk R2 from the bank's very first risk register in Chapter 1. All details are constructed for teaching (Tier 3).

Skills applied: directory-vs-source-of-truth reconciliation; orphaned-account hunting; the JML lifecycle; access certification design; SCIM-driven deprovisioning; fail-safe controls (account expiration); disabling at the authoritative source in a hybrid environment; translating identity hygiene into a board-legible risk reduction.

Background

Recall Meridian's shape from Chapter 1: about 1,800 employees, 120 branches, a hybrid infrastructure with a legacy on-premises data center (a twenty-year-old Active Directory domain, meridianbank.example) plus Microsoft 365 and Entra ID in the cloud, and a compliance surface that includes GLBA, PCI-DSS, SOX, and FFIEC examinations. Identity at Meridian had grown the way identity grows everywhere — by accretion. AD had accumulated two decades of sediment: accounts created for projects long finished, groups whose purpose nobody could fully explain, and entitlements granted in a hurry and never revisited.

The bank had authentication under control after the Chapter 16 work — phishing-resistant FIDO2 keys on the SSO portal, the control that had defeated the Chapter 1 phishing attacker. It had authorization models from the Chapter 17 work — RBAC roles for tellers and loan officers, and a documented segregation of duties for wire transfers. What it did not have was governance: any systematic way to ensure that the accounts and entitlements in the directory still matched reality. Authentication proves who you are; authorization decides what you may do; but both assume the account should exist, and nobody at Meridian was checking that assumption.

The trigger was mundane. A wire-fraud analyst, doing periodic due diligence, pulled the membership of the Loan-Approvers group — the entitlement that lets a person approve wire disbursements from loan proceeds, one of the most sensitive capabilities in the bank. Forty-one accounts. She started matching names to the employee directory and within twenty minutes had a list of accounts she could not explain. She escalated to CISO Dana Okafor with a one-line message: "Why can a contractor who left last summer still approve wires?"

Dana's response set the tone for the whole project, and it is the tone of the discipline: she did not buy an identity-governance product that afternoon. She said, in effect, first tell me the truth about what we have — and assigned Sam and Elena eight weeks to find it and fix it.

🔗 Connection: This is risk R2 from Meridian's first risk register (Chapter 1) coming home to roost: "orphaned/over-privileged account enables lateral movement," scored 15 (CRITICAL). The bank wrote that risk down on day one knowing it was true and not yet knowing how bad. The audit finding is what "how bad" looks like in the concrete, and this case study is the treatment. Watch a risk named early get systematically retired — that is a security program working as designed.

The Project

Phase 1 (Weeks 1–2) — Establish ground truth: reconcile and find the orphans

You cannot govern what you cannot count, so Sam started by counting — honestly, which is harder than it sounds, because "how many accounts do we have?" has several different answers depending on which system you ask, and the gaps between those answers are the entire problem.

He exported three lists:

  1. Every enabled account in on-prem Active Directory — the accounts that can actually authenticate to the data-center systems and, via the hybrid sync, to the cloud.
  2. Every enabled account in Entra ID — the cloud identities for Microsoft 365 and SaaS.
  3. The systems of record for people: the HR system's roster of active employees, and — assembled with some embarrassment because it had never existed in authoritative form — a roster of currently engaged contractors and temporary staff.

Then he did the single most important operation in identity governance: he reconciled the directories against the systems of record. Any enabled account that did not correspond to an active, authorized person was a candidate orphan. The logic was exactly this chapter's idgov.py, run at scale:

RECONCILIATION — Meridian identity ground truth (Week 1)
  Enabled AD accounts ............................. 1,847
  Enabled Entra ID accounts ....................... 1,931   (more, due to cloud-only apps)
  Active employees (HR roster) .................... 1,792
  Active contractors (newly assembled roster) .....   140
  -------------------------------------------------------
  Accounts with NO matching active person ......... ~80     <-- CANDIDATE ORPHANS

Eighty accounts, give or take, were enabled and able to authenticate but matched no active person. Sam broke the orphans into categories, because the category drives the urgency:

ORPHAN TRIAGE (Week 2)  — sharpened with last-login telemetry
  Category                                  Count   Last-login signal      Urgency
  ----------------------------------------  -----   --------------------   --------
  Ex-employees disabled in SOME systems       ~50   mostly dormant         HIGH
    but not all (left in last 2 years)
  Ex-contractors, no leaver trigger ever       ~18   mostly dormant         HIGH
    fired (incl. CONTRACTOR_X)
  ACTIVELY USED orphans (logged in <90d)       ~12   recent SUCCESS         CRITICAL
  Unclaimed service accounts (no owner)         ~8   varies (Ch.20)         INVESTIGATE

The twelve actively used orphans were the ones that turned a cleanup project into something closer to an incident. An orphaned account that has been dormant for two years is a latent risk. An orphaned account that logged in last week is a live question: who, or what, is using an account for a person who left? Some turned out to be benign — a script someone had pointed at a departed employee's account rather than a proper service account, a shared mailbox accessed through an individual's stale credentials. But each had to be run down, because the alternative explanation for "a successful login on a departed person's account" is an attacker using exactly the foothold this chapter warns about.

🛡️ Defender's Lens: The reconciliation is the whole game, and its power is that it needs no fancy tooling — two lists and a comparison. The directory tells you who can get in; the system of record tells you who should; the difference is your orphan list. Most organizations have never run this comparison cleanly, which is why most organizations are carrying orphans right now. The actively-used subset is where you triage first, because those accounts are not theoretical risk — something is using them, and you need to know what before you decide it is safe.

Phase 2 (Weeks 3–4) — Remediate at the source, and reconcile entitlements

With the orphan list in hand, remediation had two parts: kill the accounts that should not exist, and strip the entitlements that should not exist on accounts that should.

Disabling the orphans — at the source, not the copy. Sam disabled the orphaned accounts in on-prem Active Directory, deliberately, for two reasons that are easy to get wrong:

  • Source, not copy. In Meridian's hybrid environment, on-prem AD is authoritative and syncs upward to Entra ID. Disabling an orphan only in Entra ID would have been undone by the next sync cycle, which faithfully copies the still-enabled state from AD. Disabling at the source propagates the disabled state to the cloud and makes it stick. (This is the §18.2 lesson, and the team had a near-miss with it: an early test disabled three accounts in Entra ID only, and they were all re-enabled within the day — a small, instructive failure that proved the principle.)
  • Disable, don't delete. Every orphan was disabled, not deleted. Disabling preserves the account and its history for forensic investigation (Chapter 25) — essential for the twelve actively-used orphans, whose login history is now evidence — and allows a quick reversal if a disable turns out to be a mistake. Deletion destroys both. The accounts will be deleted later, after a retention period, once investigation confirms they are safe to remove.

Reconciling entitlements — the privilege-creep sweep. In parallel, Elena ran the first real entitlement reconciliation, starting with the bank's most sensitive groups: anything touching wire transfers, the cardholder data environment (CDE), and domain administration. For each group she produced an enriched access-review report — the same shape as Figure 18.4 in the chapter — comparing each member's actual entitlement against their current role and HR status. The Loan-Approvers group that started it all came back ugly and instructive:

ACCESS REVIEW — Group: Loan-Approvers (approve wire disbursements)   Period: Q2 2026
  41 members reviewed
   33  KEEP   — active Lending staff, role-appropriate
    2  REVOKE — terminated employees, still enabled            (ORPHAN: ex-employee)
    1  REVOKE — contractor, engagement ended 11 months ago     (ORPHAN: contractor) [CONTRACTOR_X]
    2  REVOKE — transferred to Operations a year ago           (MOVER: privilege creep)
    1  REVOKE — teller who can ALSO initiate disbursements     (SoD: toxic combination)
    2  REVOKE — additional stale/mismatched grants
  ----
  ACTION: 8 entitlements removed; 3 ORPHAN ACCOUNTS disabled at source (AD);
          SoD conflict escalated to fraud review.

The single most important row, for compliance and for the examiner's question, was CONTRACTOR_X — found not by the leaver automation (which had never fired for him) but by the review, which is precisely the defense-in-depth point: the certification catches what the lifecycle automation misses. The two Operations transfers were textbook privilege creep — they had legitimately needed loan-approval access as loan officers, moved to a different department, and carried the entitlement with them because the mover process only ever added access and never reconciled it away. And the teller who could both initiate and approve a disbursement was a segregation-of-duties violation (Chapter 17) — one person able to push money out the door with no second party, the exact fraud-enabling combination a bank's controls exist to prevent — and it went straight to fraud review rather than being quietly removed.

The broader sweep across sensitive groups stripped hundreds of creped entitlements from long-tenured movers and surfaced four total SoD conflicts. Nobody had been malicious. The access had simply accreted, because for twenty years nothing had ever taken any of it away.

⚠️ Common Pitfall: The team's first draft of the entitlement reports listed raw group names like LN_APPRV_TIER2_PROD and expected managers to certify them. Elena killed that immediately: "No manager on earth knows what LN_APPRV_TIER2_PROD means, so they'll just approve it." The reports were rebuilt to show plain-language descriptions of what each entitlement actually allows ("approve wire disbursements up to \$250,000"), the member's HR status and last login, and an automatic flag on anything risky or anomalous. A review a human cannot understand is a review a human will rubber-stamp — and a rubber-stamp is not a control.

Not every flagged account is killed blindly. The reconciliation produced a list of candidates, and the team learned quickly that the candidate list and the kill list are not the same thing — the judgment in between is where governance lives. Three categories of ambiguity forced real decisions:

  • The service accounts. About eight of the orphan candidates were not human accounts at all but service accounts — non-human identities used by applications and scripts (the full subject of Chapter 20). A service account has no HR record by definition, so it trips the "no matching person" signal every time, yet many were legitimately in use by running systems. The team did not disable these on sight, because disabling a service account an application depends on can take down a production system. Instead they were routed to a separate process: each service account had to be claimed by an owning team that could explain what it was for, and any that no team would claim — genuinely orphaned service accounts for decommissioned applications — were disabled after a notification window. The lesson: an orphan signal is a question, not a verdict, and the answer for a non-human identity is different from the answer for a departed human.
  • The shared and role mailboxes. A handful of accounts looked like orphans but were shared mailboxes or functional accounts (branch-info, loan-intake) that intentionally belonged to no single person. These needed an owner assigned and proper governance, not disabling — another case where the naive "no person, kill it" rule would have caused an outage.
  • The leave-of-absence false positives. Two accounts flagged as stale (no login in over 180 days) belonged to employees on extended medical and parental leave — current staff who would return. Disabling them would have been both wrong and, handled carelessly, a discrimination and morale problem. The disable-after-inactivity control was adjusted to check leave status before acting, and to notify rather than immediately disable.

This phase is why the chapter insists that certification is human judgment supported by automation, not automation alone. The idgov.py reconciliation found every candidate flawlessly; deciding what to do with each candidate required knowing the difference between a departed contractor, a production service account, a shared mailbox, and an employee on leave — a distinction no reconciliation script can make and every reviewer must.

🛡️ Defender's Lens: The gap between "flagged" and "remediated" is itself an attack consideration. Move too slowly and the orphan stays exploitable; move too fast and you cause outages (disabling a live service account) or harm (disabling an employee on leave), which trains the organization to distrust and slow down the whole governance process — the worst outcome, because a governance process people resent is one that quietly dies. The craft is to remediate the unambiguous, high-risk orphans immediately (the actively-used ex-employee and contractor accounts) while routing the ambiguous candidates (service accounts, shared mailboxes, leave cases) through a fast but careful adjudication. Speed where the answer is obvious; care where it is not.

Phase 3 (Weeks 5–6) — Close the gap that created the problem

Finding and disabling orphans is detection and correction. It does nothing to prevent the next CONTRACTOR_X. The root cause was specific and nameable: contractors had no authoritative system of record, so the joiner-mover-leaver lifecycle had no leaver trigger for them — when a contractor's engagement ended, nothing in any system knew to deprovision the account. The fix was a layered set of controls, deliberately layered because the team assumed any single control would eventually fail (defense in depth applied to a process, not just a network):

  1. A system of record for contractors. Every contractor now has a record in an authoritative roster with a mandatory engagement end date — no record, no account. The roster fires leaver triggers exactly as HR does for employees, so a contractor's departure now flows into the same deprovisioning pipeline as an employee's.
  2. Mandatory account expiration (the fail-safe). Every contractor and temporary account is now created in AD with an expiration date matching the engagement end date. Even if every human forgets and every process fails, the account dies on schedule with no action required. This single control makes CONTRACTOR_X's eleven-month survival structurally impossible — the account would have expired the day the engagement ended.
  3. SCIM-driven deprovisioning to the SaaS applications that supported it, so a single leaver event fans out automatically to those apps rather than waiting on forty separate tickets. The apps that did not yet support SCIM were logged as a known gap for the certification cycle to cover.
  4. Disable-after-inactivity. Any account — employee, contractor, or otherwise — with no successful login for 90 days is automatically flagged and, after a grace period and notification, disabled. This is the safety net beneath all the others: whatever the triggers and expirations miss, prolonged silence eventually closes.
BEFORE                                   AFTER
  contractor offboarding                   contractor offboarding
  = "someone remembers to file a ticket"   = mandatory roster end date
                                             + account expiration (fail-safe)
  → tickets get missed                       + SCIM deprovisioning fan-out
  → CONTRACTOR_X survives 11 months          + disable-after-90-days net
                                             + quarterly certification catches the rest
                                           → CONTRACTOR_X is now impossible

🚪 Threshold Concept: The fix for a process that fails silently is to make it fail closed. A leaver process that depends on someone remembering is a process that fails open — when it is forgotten, the account stays alive and dangerous, and no alarm sounds. An expiration date inverts that: when the process is forgotten, the account dies. Mature defenders engineer their controls so that the default outcome of neglect is safe, not dangerous. Ask of any control you build: "if everyone forgets this exists, does it fail open or closed?"

Phase 4 (Weeks 7–8) — Make it recurring and provable

A cleanup is a one-time event; governance is a standing capability. Elena's final task was to ensure the bank never drifted back, and that it could prove it to an auditor.

  • Quarterly access certification of high-risk entitlements — wire approval, CDE access, domain admin — with the reports enriched (plain-language entitlements, HR status, last login, auto-flagged anomalies) so managers certify meaningfully. Annual certification for everything else. Crucially, every "revoke" decision now flows to an action that actually removes the access, and the removals are tracked — a certification that produces no removals is treated as a red flag, not a clean bill of health.
  • A documented orphaned-account hunt: the directory-versus-source-of-truth reconciliation Sam ran by hand in Week 1 is now a scheduled, repeatable job (the idgov.py logic), run monthly, with the actively-used subset triaged first.
  • The IGA process document — the program artifact this chapter contributes — written up and folded into the security program Dana is assembling for the board (Chapter 38). It defines the systems of record, the JML triggers and automation, the certification cadence, and the orphan hunt.

The before-and-after was the kind of result a CISO can present without flinching. Roughly eighty orphaned accounts eliminated. Hundreds of creped entitlements stripped. Four segregation-of-duties conflicts surfaced and sent to fraud review. Contractor offboarding moved from a hope to an automated, reviewed, fail-safe process. And the specific finding the auditor would have raised — a contractor able to approve wires eleven months after leaving — not merely fixed but made impossible to recur. When the OCC examiner did ask about identity controls the following quarter, Elena did not have a story about a scramble; she had a process, a cadence, and the evidence that it ran.

🔄 Check Your Understanding: The team disabled the orphaned accounts rather than deleting them, and disabled them in on-prem AD rather than in Entra ID. Explain the security reasoning behind each of those two choices, and what would have gone wrong if they had instead deleted the accounts in Entra ID only.

Answer

Disable, not delete: disabling preserves the account and its login history as forensic evidence (essential for the twelve actively-used orphans, whose history is needed to determine who was using them) and allows a fast reversal if a disable was a mistake; deletion destroys the evidence and the recovery path. At the source (on-prem AD), not the copy (Entra ID): because AD is authoritative and syncs upward, a change made only in Entra ID is overwritten by the next sync, which copies the still-enabled state from AD. Deleting in Entra ID only would have been the worst of both: the next sync could recreate/re-enable the identity from the still-present AD source, the account would survive, and the forensic history would be gone — accomplishing nothing while destroying the evidence.

Discussion Questions

  1. Sam's reconciliation needed no special product — just two lists and a comparison. Why do you think so many organizations, with far larger security budgets than Meridian, have never run this comparison cleanly? What organizational, not technical, factors keep orphaned accounts alive?
  2. The team treated the actively-used orphans (logged in within 90 days) as nearly an incident, while the dormant orphans were "merely" high priority. Defend this triage. When might a dormant orphan actually be the more dangerous one?
  3. Mandatory account expiration is a fail-safe that closes accounts even when everyone forgets. What is the cost or downside of this control, and how would you handle the case of a contractor whose engagement is legitimately extended past the original end date?
  4. The teller who could both initiate and approve disbursements was sent to fraud review, not just quietly de-provisioned. Why does a segregation-of-duties violation warrant investigation rather than silent correction, even when there is no evidence of actual fraud?
  5. Elena insisted that a certification producing no removals should be treated as a warning sign. Argue for and against this stance. Could a genuinely clean environment produce a no-removal review, and how would you tell the difference between "clean" and "rubber-stamped"?

Your Turn

Take an environment you can actually inspect — a personal Microsoft 365 or Google Workspace developer tenant, a lab Active Directory, your own cloud account's connected-apps list, or even a small organization you volunteer for — and run a miniature version of Meridian's Phase 1. (1) Export or list every account/identity that can authenticate. (2) List who or what should have access (the people and purposes you can justify). (3) Reconcile the two and identify every orphan or unexplained grant. (4) For each finding, decide disable/revoke or keep, and — for anything you disable — note where the authoritative source is. Write up the before count, the orphans found, and the one process change that would prevent the most common orphan you found from recurring. Keep it to one page. If you cannot explain why an account exists in one sentence, that is itself a finding.

Key Takeaways

  • Reconciliation is the core of identity governance: compare the directory (who can get in) against the systems of record (who should), and the difference is your orphan list. It needs two lists and a comparison, not a product.
  • Triage orphans by activity. A dormant orphan is latent risk; an actively-used orphan is a live question — something is logging into an account for a person who left, and you must find out what.
  • Disable at the source, and disable rather than delete. In a hybrid environment, change the authoritative directory (on-prem AD) so the state propagates and sticks; disabling (not deleting) preserves forensic evidence and allows reversal.
  • The certification catches what the automation misses. CONTRACTOR_X was found by the access review, not the leaver trigger — defense in depth applied to identity. Make reviews reviewable (plain-language entitlements, enriched context, auto-flagged anomalies) and act on the revocations.
  • Fix the process to fail closed. The root cause was a missing leaver trigger for contractors; the durable fix is a system of record plus a mandatory account-expiration date — a fail-safe that closes the account on schedule even when everyone forgets.
  • Identity hygiene is a board-legible risk reduction. Roughly eighty orphans eliminated and contractor offboarding made automatic is the concrete retirement of Chapter 1's risk R2 — a risk named on day one, driven down by a documented, recurring, provable process.