Case Study 1: Meridian's Three-Year Zero-Trust Roadmap

"We are not going to buy zero trust. We are going to become it — one defensible phase at a time, and I want each phase to pay for itself in risk reduction before we start the next." — Dana Okafor, CISO, Meridian Regional Bank (constructed)

Executive Summary

After years of bolting controls onto a fundamentally perimeter-shaped network, Meridian Regional Bank commits to a zero-trust architecture. This case study follows security architect Sam Whitfield and CISO Dana Okafor as they turn the abstract tenets of NIST SP 800-207 into a sequenced, budgeted, three-year program — and as they defend that program to a skeptical board and a nervous core-banking operations team. The work is design-and-build heavy: a maturity assessment, a target architecture, a phased roadmap with dependency logic, and the hard accommodations real environments force (a mainframe that cannot run an agent, a VPN that the business loves, a flat network nobody fully understands). By the end you will have seen how the chapter's architecture survives contact with budget, politics, and legacy. The scenario and all figures are constructed for teaching (Tier 3).

Skills applied: zero-trust maturity assessment (CISA pillars); target-architecture design (PDP/PEP, ZTNA, microsegmentation); dependency-driven roadmap sequencing; legacy-system accommodation; framing zero trust to a board as a maturity direction; tying access decisions to identity, device, and context.

Background

Meridian's environment, frozen across this book, is a textbook case of why the perimeter died. Roughly 1,800 employees across 120 branches. A hybrid estate: an on-prem data center running a legacy core-banking mainframe, a twenty-year-old Active Directory domain, and VMware; plus AWS and a Microsoft 365 / Entra ID tenant. A flat internal LAN where, once a device is on the network, it can reach far more than it should. A remote-access VPN that deposits work-from-home staff straight onto that LAN. MFA exists but is uneven — some staff still log in with passwords alone. The crown jewels are unambiguous: the cardholder data environment (CDE) (in scope for PCI-DSS), Active Directory / Entra ID (the keys to everything), and the core-banking system (the ledger).

The trigger is twofold. First, a peer institution suffered a breach that began with a phished VPN credential and ended, nineteen days later, in ransomware — the exact pattern of §32.1. Second, Meridian's regulators (FFIEC examiners) have begun asking pointed questions about lateral-movement containment and "modern access architecture." Dana sees the opening she has wanted: a chance to fund a real architectural shift, not another point product. She gives Sam a charge: "Design us a zero-trust target and a path to it that I can defend to the board — phased, dependency-aware, and honest about what we cannot change."

Sam's first move is not to draw an architecture but to confront the political and operational reality of the bank. Zero trust touches everyone — every employee's login, every device, every application, and the data center the operations team guards jealously. A migration that ignores those stakeholders fails regardless of how elegant its architecture is. He maps the people he will need on his side: the operations team that owns the core-banking system and fears any change to it; the network team that built and operates the VPN and the flat LAN; the help desk that will absorb the support load of a FIDO2 rollout; the business units whose daily work cannot be interrupted; and the board, whose appetite for a multi-year spend depends entirely on how the program is framed. The architecture is the easy part. The sequencing — technical and political — is the work.

📟 War Story: A constructed but representative vignette. At a bank much like Meridian, a security architect once presented a flawless zero-trust design to the board and asked for three years of funding in a single vote. The board balked: it was too big, too abstract, and too far from anything they could measure. The program died on the vine. The lesson Sam takes from such failures is that how you sequence and frame zero trust matters as much as the design itself — a perfect architecture with no phased, fundable, measurable path to it is just a diagram. Dana's insistence on independently-valuable phases is not bureaucratic caution; it is the difference between a funded program and a dead one.

🔗 Connection: Notice this is the same near-miss-turned-initiative pattern that started the whole Meridian program in Chapter 1. A real incident at a peer, costing Meridian nothing, becomes the political capital to fund architecture. Sam is not starting from zero: he is reframing the authentication standard (Chapter 16), access-control policy (Chapter 17), identity governance (Chapter 18), and network segmentation (Chapters 6–7) the bank already built into a single coherent architecture. Zero trust ties the existing program together.

The Analysis

Phase 0 — An honest maturity assessment

Sam refuses to design a target before measuring the starting point, so he runs Meridian against the CISA Zero Trust Maturity Model pillars. He is deliberately pessimistic — a flattering self-assessment produces a roadmap that skips the work that matters.

⚠️ Common Pitfall: Sam's first instinct was to rate Identity "Advanced" because "we have SSO and MFA." Dana pushed back: "Partial MFA with legacy passwords still in the building is not Advanced — an attacker phishes the password-only accounts and your whole zero-trust story collapses, because every decision rests on identity." The assessment is only useful if it is honest about the weakest links; flattering scores produce roadmaps that skip the foundational work.

The assessment makes the dependency obvious. Identity is the weakest foundational pillar, and every other pillar's decisions depend on it. You cannot gate on device posture if you cannot trust who the user is; you cannot broker per-app access if you cannot trust identity and device; you cannot safely microsegment a network whose legitimate flows you have never mapped. The maturity assessment is not bureaucracy — it is the thing that determines the order of the work.

The target architecture

Before sequencing the work, Sam draws the destination — the target architecture that all four phases move toward. It is the logical model of Figure 32.1, instantiated with Meridian's actual components, so that every phase can be understood as "building one more piece of this picture."

MERIDIAN ZERO-TRUST TARGET ARCHITECTURE (destination of the roadmap)

  CONTROL PLANE                          POLICY INPUTS
  ┌──────────────────────────┐          - Entra ID (identity / IdP)
  │ POLICY ENGINE (PE)        │◄─────────- MDM/UEM + EDR (device posture)
  │  + POLICY ADMINISTRATOR   │          - SIEM risk score / threat intel
  │  (Meridian's conditional- │          - context: time, geo, resource sensitivity
  │   access + ZTNA control)  │
  └───────────┬──────────────┘
              │ configures / issues sessions
              ▼
  DATA PLANE  ┌─────────────────────────┐
  remote user │  ZTNA BROKER (PEP)       │   <- replaces the VPN
  + branch ──►│  + microseg enforcement  │
              └──────┬──────────┬────────┘
                     │ one app  │ one flow
            ┌────────▼───┐  ┌───▼──────────────────────────┐
            │ M365 / SaaS│  │  MICROSEGMENTED CROWN JEWELS  │
            │ web apps   │  │  CDE  |  AD/Entra  |  CORE-   │
            └────────────┘  │       (default-deny between)  │
                            └──────────────────────────────┘

Figure CS1.1 — Meridian's target. The control plane (PE + PA) draws on Entra ID, device posture, and risk signals to decide; the ZTNA broker and microsegmentation enforcement form the data-plane PEP. The crown jewels — CDE, Active Directory, core-banking — sit behind default-deny microsegmentation. The VPN is gone. The roadmap's four phases each build one region of this diagram: identity feeds the PE (Phase 1), device posture feeds the PE (Phase 2), the ZTNA broker replaces the VPN (Phase 3), and the crown-jewel microsegmentation is drawn last (Phase 4).

🔗 Connection: Sam deliberately makes the target architecture one diagram the whole team and the board can hold in their heads. A roadmap without a destination is a list of projects; a roadmap with one is a story — "here is where we are going, and here is the order in which we build it." This is the difference between a security program that gets funded for three years and one that gets reprioritized away after the first phase.

Phase 1 — Identity foundation (months 0–9)

Sam sequences identity first, because it is the substrate of every later decision. The work:

• Phishing-resistant MFA (FIDO2) for all staff, and — the politically hard part — eliminating password-only authentication. This extends the authentication standard from Chapter 16 from "most staff" to "every account, no exceptions."
• Entitlement cleanup: an access review (the access_review/orphan_accounts work of Chapter 18) to remove orphaned accounts and reduce over-privilege. In a zero-trust system that grants access by verified identity, an over-privileged account is no longer a hygiene problem — it is a wide-open door wearing a verified badge.
• ABAC policy (Chapter 17) for the most sensitive apps, so policy can later fold in device and context, not just role.

PHASE 1 DELIVERABLE — identity foundation
  [x] FIDO2 keys issued to all 1,800 staff; password-only auth disabled
  [x] orphaned/contractor accounts disabled; admin rights reduced
  [x] ABAC policy framework stood up for wire-approval and core-admin apps
  RISK REDUCED (standalone): credential-phishing -> near-zero for covered apps;
                             lateral movement via stale accounts -> sharply reduced
  DEPENDENCY UNLOCKED: every later phase can now trust the identity signal

🛡️ Defender's Lens: Dana insists Phase 1 be framed to the board as independently valuable. Even if the bank never finished the rest of the roadmap, phishing-resistant MFA everywhere plus clean entitlements is the single largest risk reduction in the program — it directly closes the attack that breached the peer institution. This framing is also the funding strategy: each phase is a defensible budget line with measurable risk reduction, not a down payment on an all-or-nothing future.

Phase 2 — Device posture (months 6–15)

With identity trustworthy, Sam adds the second signal. The work is to make device health a gate:

• Enroll all endpoints (not just mobile) in MDM/UEM (Chapters 11 and 14).
• Build a posture pipeline that, at access time, can answer: managed? patched to the required baseline? disk-encrypted? EDR present and healthy (Chapter 11)? configuration matching the hardening baseline (the audit_baseline check)?
• Feed posture into the policy engine as an input signal, so the most sensitive resources can require a managed, healthy device — and so posture can be re-checked during a session (continuous verification), not just at login.

🔗 Connection: Phases 1 and 2 together deliver two of the three signals from §32.3. Only now can Meridian make real zero-trust decisions, because a decision that blends a trustworthy identity with a measured device posture is qualitatively different from a network-location guess. Context (Phase 3's policies) is the third signal; the architecture is becoming able to evaluate all three.

Phase 3 — ZTNA for applications (months 12–24)

This is the phase the business feels, because it retires the VPN. Sam stands up a PDP/PEP broker and fronts internet-facing and remote-accessed applications with ZTNA:

• The broker hides applications behind a software-defined perimeter — unauthorized users cannot even scan for them.
• Remote access becomes per-app brokered access: a user is granted a connection to one application after a per-request decision, and is never placed on the network. This is the single change that would have contained the peer's breach.
• Context-aware policy (location, time, computed risk) now joins identity and device in the decision, exactly as in the §32.3 worked example.

The VPN does not vanish overnight. Sam runs ZTNA and VPN in parallel, migrating applications behind the broker one at a time, highest-risk first, until the VPN can be retired. The migration is itself a journey.

BEFORE (Phase 0)                      AFTER (Phase 3)
 remote user --VPN--> [FLAT LAN] -->   remote user --> [ZTNA BROKER / PDP-PEP]
   any internal app reachable             |  per-request: identity+device+context
   lateral movement: trivial              v
                                       ONE authorized app only; SDP hides the rest;
                                       lateral movement: blocked

⚠️ Common Pitfall: The operations team's first reaction was "ZTNA will break remote work and flood the help desk." Sam's answer was parallel running and phased migration, not a big-bang cutover: keep the VPN alive, move apps behind the broker one at a time starting with the riskiest, prove each works, and only then retire the VPN. A forced cutover is how ZTNA projects acquire a reputation for breaking production — and how the whole zero-trust program loses credibility.

Phase 4 — Microsegmentation of crown jewels (months 18–36)

The hardest, riskiest phase comes last by design, because it imposes default-deny on the data center itself — and you do not do that to a flat network whose legitimate flows you have never mapped. Sam's disciplined approach:

1. Map flows first. Observe and baseline real east-west traffic for weeks (the kind of visibility the network monitoring of Part II provides) so that "default-deny" does not mean "deny things production actually needs."
2. Start with the crown jewels. Microsegment the CDE, Active Directory, and core-banking first — segment the cardholder database before the print server — because risk reduction should be front-loaded.
3. Default-deny between workloads, using identity-based segmentation where possible (policy in terms of workload identity, Chapter 20, which survives the constantly-changing IPs of the AWS estate).
4. Expand outward iteratively from the highest-value assets, tightening as flow maps mature.

CROWN-JEWEL MICROSEGMENTATION (illustrative)
  CDE-app  --(allow:443)-->  CDE-db        [explicitly permitted]
  AD-DC    --(allow:replication ports)-->  AD-DC   [DC-to-DC only]
  core-gw  --(allow:fixed port)-->  core-banking   [single broker path]
  ANY other workload --> CDE-db / AD-DC / core-banking  =>  DENY (and ALERT)

🛡️ Defender's Lens: Sam points out a bonus to the SOC: every denied flow into the CDE, AD, or core-banking is now a high-signal alert. A workstation suddenly trying to reach the CDE database — a flow policy denies and that should never occur — is a near-certain indicator of compromise, and it feeds straight into the SIEM (Chapter 21) and detection program (Chapter 22). The flat network produced no such signal; microsegmentation turns every illegitimate pivot attempt around a crown jewel into a loggable, alertable denial.

The legacy problem: the mainframe that cannot participate

The core-banking mainframe is the hardest single object in the environment. It cannot run a posture agent, cannot speak modern identity protocols, and cannot be rewritten on any timeline the bank will fund. A purist roadmap would stall here. Sam's pragmatic zero-trust treatment, which falls in Phase 4:

• Wrap it behind a PEP/broker. No one reaches the mainframe directly; all access flows through an enforcement point that can make modern identity/device/context decisions on the mainframe's behalf.
• Microsegment tightly around it. A single, explicitly-allowed path from a hardened broker; default- deny everything else; alert on any denied attempt.
• Compensate for what it lacks. Where the mainframe cannot enforce least privilege or posture itself, the surrounding controls (the broker, segmentation, privileged-access controls from Chapter 19, and heavy monitoring) substitute for the capability.

🔗 Connection: This accommodation is a direct rehearsal for Chapter 33. In operational technology, "the system cannot be patched, cannot run an agent, cannot be modernized" is not an edge case — it is the central fact of the environment. Sam's treatment of the mainframe — wrap it behind enforcement, segment tightly, monitor heavily, compensate around it — is precisely the playbook OT security uses for a thirty-year-old programmable logic controller. Zero trust's pragmatism toward the un-modernizable is exactly what makes it usable in the physical world.

The Outcome

After the first eighteen months — Phases 1 and 2 complete, Phase 3 well underway — Meridian's posture is measurably different. Phishing-resistant MFA everywhere has closed the credential-phishing path that breached its peer. Entitlement cleanup has removed the stale and over-privileged accounts that fuel lateral movement. Device posture gates access to the most sensitive apps. And the first applications behind ZTNA mean those users are no longer dumped onto a flat LAN. The crown-jewel microsegmentation of Phase 4 is in flight, with the CDE and AD segmented first.

Crucially, Dana never told the board "we are now zero trust." She reported a maturity trajectory: the CISA pillars moving from Traditional/Initial toward Advanced, phase by phase, each with a risk-reduction story and a metric. When an FFIEC examiner asks about lateral-movement containment, Meridian can show a real architecture and a real roadmap, not a product invoice. The program is funded for year three because each completed phase demonstrably paid for itself — which is the whole point of sequencing by dependency and front-loading risk reduction.

The metrics that kept it funded

What turned "trust us, it's working" into a defensible board narrative was a small set of metrics Dana reported each quarter — a preview of the measurement discipline of Chapter 36. She deliberately chose metrics that track the architecture's actual risk reduction, not vanity numbers:

🔗 Connection: Notice the last row is a detection metric, not a prevention one. Microsegmentation gave the SOC a brand-new, high-signal data source — denied flows around the crown jewels — that the flat network never produced. Dana reports it to the board not as "we blocked X attacks" but as "we can now see lateral-movement attempts we were previously blind to," which is exactly the structural detection benefit of §32.5. The architecture improved both halves of defense: it prevents more and reveals more.

What went wrong (and what they learned)

An honest case study does not pretend the migration was frictionless. Three things bit Meridian, and each is a lesson worth carrying:

1. A rushed ZTNA pilot broke a legacy reporting app. Sam's team initially put a brittle internal reporting tool behind the broker without fully mapping how it called back to a database, and the app broke for a week. The fix — and the lesson — was parallel running and flow mapping before migration, applied thereafter to every app. ZTNA migration is itself a phased journey, not a switch.
2. The first microsegmentation attempt around AD was too aggressive. A default-deny policy written from an incomplete flow map blocked a legitimate replication path between domain controllers and caused an authentication hiccup. The team rolled back, observed real DC-to-DC traffic for two more weeks, and re-applied policy from an accurate map. Map flows before you default-deny stopped being a slogan and became muscle memory.
3. Help-desk volume spiked during the FIDO2 rollout. Issuing hardware keys to 1,800 people generated a wave of "I lost my key / I'm locked out" tickets. The lesson was operational, not architectural: a zero-trust program needs a people-and-process plan (break-glass procedures, key replacement workflow, training) alongside the technology — the people/process/technology triad from Chapter 1, exactly as relevant here as anywhere.

⚠️ Common Pitfall: Each of Meridian's three stumbles came from treating a phase as a flip of a switch rather than a careful migration. The meta-lesson of the whole roadmap: zero trust is a journey not only at the program level (four phases over three years) but at the task level — every individual migration (an app behind ZTNA, a workload into a microsegment, a user onto FIDO2) is itself something you stage, observe, and tighten. Big-bang anything is how zero-trust programs acquire a reputation for breaking production.

Discussion Questions

1. Sam sequenced identity before microsegmentation despite lateral movement being a "network" problem. Restate the dependency argument in your own words. What specifically would have gone wrong if Meridian had started with Phase 4?
2. Dana refused to promise the board a zero-trust "finish line." What are the concrete risks — technical, political, and budgetary — of framing zero trust as a one-time project with an end date?
3. The mainframe cannot participate in modern identity or posture. Defend Sam's "wrap, segment, compensate" treatment against a purist who says "if it can't do zero trust, it shouldn't be in scope."
4. Phase 1 (MFA + entitlement cleanup) was framed as "independently valuable even if we stop here." Is it ever rational to plan to stop after Phase 1? Under what budget or risk circumstances?
5. Every denied flow around a crown jewel becomes a SOC alert. How does this change the relationship between the architecture team (who built the segmentation) and the detection team (who consume its denials)? What new false-positive risk does it introduce, and how would you tune it?

Your Turn

Take an organization you know (or invent a mid-size one) and produce a one-page zero-trust roadmap: (1) run a quick CISA-pillar maturity assessment (Identity, Devices, Networks, Applications, Data), rating each Traditional/Initial/Advanced/Optimal with a one-phrase justification; (2) define a target for each pillar; (3) sequence the work into 3–4 dependency-ordered phases, stating for each transition why it depends on the prior phase; (4) identify one legacy or un-modernizable system and describe its pragmatic treatment; and (5) write a two-sentence board framing that promises a maturity direction, not a finish line, and names one quarterly metric. If you cannot justify a phase ordering by dependency, that is a signal your identity/device foundation is not yet clear — note what you would assess first.

Key Takeaways

• Zero trust is a multi-year program, not a purchase; a roadmap sequenced by dependency, with independently-valuable phases, is what survives budget and politics.
• Start from an honest maturity assessment (CISA pillars). Flattering scores produce roadmaps that skip the foundational work — and identity is almost always the foundational pillar.
• Sequence: identity → device → ZTNA → microsegmentation of crown jewels. Each phase's decisions depend on the trustworthiness of the prior phase's signals; front-load risk reduction.
• Replace the VPN with ZTNA by parallel running and phased migration, highest-risk apps first — never a big-bang cutover, which breaks production and discredits the program.
• Microsegment crown jewels first, map flows before you default-deny, and treat every denied flow as a detection signal feeding the SIEM.
• Accommodate legacy pragmatically — wrap the un-modernizable behind an enforcement point, segment tightly, monitor heavily, compensate around it. This is also the OT-security playbook of Chapter 33.
• Frame it to the board as a maturity direction, reported as movement across the pillars with a risk-reduction story per phase — never as a finish line.