Case Study 1: Meridian Rolls Out Phishing-Resistant MFA

"The key saved us once by accident. The second time, it's going to be on purpose, for everyone who can move money." — Dana Okafor, CISO, Meridian Regional Bank (constructed)

Executive Summary

The hardware security key that stopped the phishing attack in Chapter 1 protected exactly one group: the loan officers, who happened to be in a pilot. Everyone else at Meridian — tellers, branch managers, the wire-transfer desk, the system administrators with the keys to the kingdom — was still authenticating with a password and, at best, a phishable second factor. The near-miss had been luck wearing the costume of a control. This case study follows Meridian's project to make that luck deliberate: a staged rollout of phishing-resistant authentication, prioritized by the value of what each group can reach, governed by the authentication standard the team drafts in this chapter's Project Checkpoint. You will watch security engineer Sam Whitfield design the tiers, GRC analyst Elena Vasquez map them to regulation, SOC analyst Theo Brandt build the detections that watch the gaps during migration, and the whole team confront the problem every phishing-resistant rollout creates: when you make the front door unpickable, the attacker walks around to the help desk. All names, figures, and logs are constructed for teaching (Tier 3).

Skills applied: AAL-by-asset-tier design; phishing-resistant MFA (FIDO2/passkey) deployment planning; authentication-standard authoring; account-recovery threat modeling; detection of MFA-bypass and credential attacks during a migration; communicating authentication risk to a board.

Background

Six weeks after the phishing near-miss, Dana Okafor has the budget conversation she has wanted for two years. The board's Audit Committee, freshly reminded that a single click nearly became a breach, is unusually receptive. But Dana does not ask for "MFA everywhere" — that request has died in budget meetings before, drowned in objections about cost, user friction, and the 2.5 million customers who cannot be handed hardware keys. Instead she asks for something the board can reason about: phishing- resistant authentication for the people and systems where a compromised login would be catastrophic, first; stronger-but-affordable MFA for everyone else; and a plan to retire the weakest factors over time. Risk-matched, staged, and measurable.

Meridian's authentication landscape, honestly inventoried, is a patchwork — which is normal, and the point of the inventory is to stop pretending otherwise:

🔗 Connection: Notice that authentication strength is currently inversely correlated with what the population can reach. The administrators — who can touch everything — have only TOTP, a phishable factor; the wire desk that moves money has bare push, vulnerable to fatigue. The one group with phishing-resistant keys is the loan-officer pilot, which is how the bank got lucky. The first job of the project is to invert this back to sense: the more you can reach, the stronger your authentication must be. That is the §16.1 AAL-matching idea applied to a real org chart.

Sam frames the design constraint to the team: "We have three currencies — security, money, and friction — and we can't max all three. So we spend the security where a breach is worst, spend the money where the hardware is justified, and spend the friction budget carefully so people don't route around us."

The Project

Phase 1 — Tiering by what a compromise would cost

Sam starts where the Project Checkpoint says to: AAL-by-asset-tier. Rather than argue about each of the six populations, he sorts the systems by the damage a compromised login would do, then assigns each population the AAL of the highest-value system it can reach.

TIER 3 (AAL3, phishing-resistant REQUIRED): money movement; domain/system admin;
        anything touching the core banking system or the cardholder data environment (CDE)
   -> wire/treasury desk (25), administrators (40)
TIER 2 (AAL2, MFA; migrating to passkeys): customer account access; teller systems
   -> tellers/branch (1,400), retail customers (2.5M)
TIER 1 (AAL2 minimum; number-matching + context required on push): workforce productivity
   -> general corporate staff (250), loan officers (already AAL3-capable)
TIER 0 (AAL1; password OK): public marketing site, read-only information

The decision that matters most — and the one Dana will defend to the board — is that Tier 3 is non-negotiable phishing resistance, no exceptions. The wire desk and the administrators get FIDO2 hardware keys (device-bound, so the private key physically cannot leave the device), because these are the identities whose compromise turns a foothold into a disaster. Forty administrators plus twenty-five wire-desk staff is sixty-five people; sixty-five hardware keys (and backups) is a rounding error against the cost of a single fraudulent wire or a domain-wide compromise. This is the §16.1 lesson made budgetary: you do not need phishing-resistant MFA for all 1,800 employees on day one; you need it for the sixty-five who can end the company.

🛡️ Defender's Lens: Sam deliberately resists "boil the ocean." A common failure mode is to announce "passkeys for everyone" as a two-year program, deliver nothing for eighteen months, and leave the crown-jewel accounts on TOTP the whole time. The risk-matched approach delivers the highest-value protection in the first sprint — the sixty-five Tier-3 identities — and treats the broad 2.5-million- customer passkey migration as a longer, parallel track. Attackers go for the money and the admins; protect those first, visibly, and the rest is steady-state engineering.

Phase 2 — Deploying phishing-resistant MFA to Tier 3

For the sixty-five Tier-3 users, the team rolls out FIDO2 hardware keys with WebAuthn. Sam walks the team through what actually changes, mapping each step to the protocol from §16.4:

1. Enrollment. Each Tier-3 user enrolls two keys — a primary they carry and a backup stored in a safe — so that a lost key is an inconvenience, not a lockout. At enrollment, each key generates a fresh key pair per relying party (the SSO portal, the wire system); the private keys never leave the hardware, and Meridian's identity provider stores only the public keys.
2. Authentication. At login, the identity provider sends a challenge; the user taps the key (with a PIN or on-key biometric as the local unlock gesture); the key signs challenge + origin; the IdP verifies against the stored public key and checks the origin. No code, no push, nothing to relay.
3. Policy enforcement. Conditional-access policy is set so that Tier-3 applications will accept only phishing-resistant authenticators — not password+TOTP, not push. This is the crucial step: a key is worthless as a control if the system still also accepts a weaker factor an attacker can phish.

⚠️ Common Pitfall: Deploying hardware keys but leaving a phishable fallback enabled. If the wire system accepts a FIDO2 key or password+SMS, the attacker simply phishes the SMS path and the key protects nothing. The control is not "issue keys"; it is "require phishing-resistant authentication and disable the weaker alternatives for this tier." Meridian's first internal red-team test of the rollout found exactly this gap on one application that still permitted TOTP as a backup — closed before go-live. The rule: a phishing-resistant requirement is only as strong as the weakest factor you still accept.

To validate the design before go-live, Theo scripts a small check (illustrative, hand-traced) that audits each Tier-3 application's permitted authenticators against the standard:

# Illustrative conditional-access audit: does each Tier-3 app REQUIRE phishing-resistance?
# (Hand-traced teaching logic; not executed.)
PHISHING_RESISTANT = {"fido2", "webauthn-platform", "smartcard-piv"}

def tier3_gap(app_name, accepted_factors):
    """Flag a Tier-3 app that accepts ANY non-phishing-resistant factor."""
    weak = [f for f in accepted_factors if f not in PHISHING_RESISTANT]
    return (app_name, weak) if weak else None

apps = {
    "WireTransfer":  ["fido2"],
    "CoreAdmin":     ["fido2", "totp"],         # <-- leftover weak fallback
    "EntraAdmin":    ["fido2", "webauthn-platform"],
}
for name, factors in apps.items():
    gap = tier3_gap(name, factors)
    if gap:
        print(f"GAP  {gap[0]}: still accepts {gap[1]}")
    else:
        print(f"OK   {name}")

# Expected output:
# OK   WireTransfer
# GAP  CoreAdmin: still accepts ['totp']
# OK   EntraAdmin

The audit immediately surfaces CoreAdmin as the gap — the application still accepts TOTP as a fallback, exactly the weakness the red team found. The fix is a one-line policy change, but the finding is the point: a phishing-resistant rollout must be enforced and audited, not merely deployed.

Phase 3 — Hardening Tier 2 and the broad customer base

The 1,400 tellers and 2.5 million customers cannot all get hardware keys, so Tier 2 takes a different shape. For the workforce (tellers, general staff), the team enables number matching and rich context on every push prompt immediately — a same-week change that neutralizes the push-fatigue risk the wire desk had been carrying — and begins enrolling synced passkeys as the path off passwords, since passkeys are phishing-resistant and self-recoverable from the user's cloud account (no hardware logistics for 1,400 people). For customers, the bank launches passkey support in the mobile app and online banking, makes it the default offered at next login, and keeps SMS OTP available only as a fallback during the transition — with a published sunset for SMS as the sole high-value factor.

🔗 Connection: The synced-passkey choice for the broad population, versus device-bound hardware keys for Tier 3, is exactly the tradeoff from §16.4's table. Synced passkeys win on usability and self-service recovery (decisive for 1,400 staff and 2.5M customers); device-bound keys win on assurance and the guarantee that a private key cannot leave the device (decisive for admins and money movement). Meridian uses both, matched to tier — which is the recommended real-world pattern, not a compromise.

Elena, meanwhile, does the GRC half: she maps the standard to Meridian's obligations so the board sees authentication as risk reduction with regulatory dividends, not just a security expense.

⚠️ Common Pitfall — compliance as the ceiling: Elena is careful in her board memo to note that PCI-DSS only requires MFA for the CDE and administrative access — it does not require phishing-resistant MFA. Meridian is going beyond the regulation for Tier 3 because the regulation's floor (any MFA) would still leave the wire desk vulnerable to the very push-fatigue and relay attacks this chapter described. "We could pass the audit with phishable push," she writes, "and still lose a wire to a fatigue attack. The standard is built to the threat, then checked against the regulation — not the other way around."

Phase 4 — The attacker walks around the front door

Here the project hits the problem every phishing-resistant rollout discovers, and the team's handling of it is the most transferable lesson. Three weeks after Tier-3 keys go live, Priya Nair's threat-hunting turns up a probe that is not against the login at all. An attacker, having presumably failed to phish a wire-desk user's FIDO2 login, has called the IT help desk impersonating that user, claiming a lost key, and requested an emergency re-enrollment. The help-desk agent, trying to be helpful, was one identity- verification question away from enrolling an attacker's key as a "replacement."

This is the unphishable-login paradox: when you make the login unphishable, the account-recovery path becomes the new front door. A FIDO2 key the attacker cannot relay is no help if the attacker can simply ask the help desk for a new one. The team responds by treating recovery as a Tier-3 control in its own right:

RECOVERY HARDENING for Tier-3 identities
  - No help-desk-initiated authenticator reset for Tier 3 without:
      (a) in-person verification OR a video call with government ID, AND
      (b) a second-person approval (a manager or security), AND
      (c) a mandatory cool-down + notification to the user's known-good channel.
  - Backup hardware key (enrolled at onboarding) is the PRIMARY recovery path,
      so "lost my key" rarely needs the help desk at all.
  - Every Tier-3 authenticator change generates a high-priority SOC alert.

🚪 Threshold Concept: You have not secured authentication until you have secured re-authentication. Every account has at least two ways in: the front door (login) and the back door (recovery — "forgot password," "lost my key," "call the help desk"). Attackers attack the weaker of the two. Hardening the login to phishing-resistant strength while leaving a chatty, single-agent recovery flow doesn't raise the bar; it just moves it. Mature identity programs make recovery as strong as the login it restores — which is why this project's most important slide is not about keys at all, but about the help desk.

🛡️ Defender's Lens: Theo builds the detection layer that watches the gaps during migration, when the environment is most mixed and most vulnerable. His three highest-value Tier-3 alerts: (1) any authenticator enrollment or reset on a Tier-3 account (should be rare and pre-approved); (2) a Tier-3 login that somehow used a non-phishing-resistant factor (means a policy gap like CoreAdmin); (3) impossible-travel or new-device success on a Tier-3 account. During migration these fire on the exceptions — exactly the events an attacker needs to create to bypass the new standard.

Phase 5 — The board conversation

Dana's board update reframes the whole project in the language of risk, not technology. She does not show the board a WebAuthn diagram. She shows them three numbers and a sentence:

• 65 Tier-3 identities (money movement + admin) are now on phishing-resistant MFA — the accounts whose compromise could end the bank.
• 0 phishable fallback factors remain enabled for Tier 3 — the control is enforced, not just deployed.
• The recovery path has been hardened to match, because an unphishable login with a chatty help desk is a locked door next to an open window.

"The phishing email in [the Chapter 1 incident]," Dana tells the Audit Committee, "failed because one group happened to have the right control. We have now made that not an accident. For the sixty-five people who can move money or administer our systems, an attacker can have the password, can have the phone, can even fool the user — and still cannot log in. For everyone else, we have closed the fatigue and SIM-swap gaps and we are moving steadily to passkeys. We did not buy our way out of the problem; we matched the strength of the control to the value of what it protects, and we are watching the seams while we migrate." It is the board narrative the Chapter 1 near-miss earned — and the authentication standard from this chapter's Project Checkpoint is its written form.

Discussion Questions

1. Sam assigned each population the AAL of the highest-value system it could reach. What are the advantages of tiering by what a compromise would cost rather than by job title or department?
2. The team made Tier-3 phishing resistance non-negotiable but accepted AAL2 (with number matching) for the 1,400 tellers. Defend this as a risk decision. Under what change would you raise the tellers to phishing-resistant?
3. Elena went beyond PCI-DSS for Tier 3. Construct the strongest argument a cost-conscious CFO could make for doing only what PCI requires, then rebut it using a specific attack from this chapter.
4. The help-desk recovery gap nearly undid the entire rollout. Why is account recovery so often weaker than login, and what organizational (not just technical) changes hardened it here?
5. During migration the environment is mixed — some Tier-3 apps briefly still accepted TOTP. Why is the migration window the most dangerous period, and which of Theo's three detections matters most during it?

Your Turn

Take an organization you know (or invent a small one) and reproduce Meridian's Phase 1 and Phase 2. First, list four to six populations and the highest-value system each can reach; assign each an AAL (0–3) and justify it in a phrase. Second, for your Tier-3 population, write the enrollment, enforcement, and recovery plan — including the one rule that prevents a phishable fallback from undermining the keys, and the recovery hardening that prevents the help-desk bypass. Keep it to one page. If you cannot name why a population is in its tier, that is a signal you have not yet found what it can actually reach.

Key Takeaways

• Match assurance to value: assign each population the AAL of the highest-value system it can reach; protect the few crown-jewel identities (money movement, admins) with phishing-resistant MFA first.
• Enforce, don't just deploy: a phishing-resistant requirement is only as strong as the weakest factor you still accept — disable phishable fallbacks for the protected tier and audit that you did.
• Synced passkeys for breadth, device-bound keys for the crown jewels — use both, matched to tier; the tradeoff is usability/recovery versus maximum assurance.
• Compliance is the floor: PCI/GLBA/FFIEC require MFA, not phishing-resistant MFA; build to the threat, then check against the regulation — not the reverse.
• Secure re-authentication, not just authentication: when the login becomes unphishable, account recovery and the help desk become the new front door — harden them to match (verification, second-person approval, cool-downs, backup keys, and an alert on every Tier-3 authenticator change).
• Watch the seams during migration: the mixed-factor window is the most dangerous; alert on Tier-3 authenticator changes, weak-factor logins, and impossible travel while you transition.