Meridian Community Bank: FIDO2 on Shared Branch Workstations
Meridian Community Bank is rolling FIDO2 security keys to 6,200 employees across 900 branches. Tellers share Windows workstations in open lobbies and use a 3270 mainframe application that cannot speak SAML or OIDC; the mainframe team estimates 18 months for modernization. Two weeks after pilot, helpdesk volume rose 40% to 3,100 calls per week, 12% of branch staff are locked out weekly, and supervisors report keys left in drawers and shared 'team' keys. The IdP vendor recommends federation-only; the mainframe team proposes keeping shared logins for tellers 'temporarily.' The bank's fraud team reports three attempted logins using a terminated teller's credentials. Branch uptime and customer queue time are executive metrics, and the program sponsor wants a go/no-go decision for the remaining 700 branches in 30 days.
1. Recommend a go/no-go decision and an authentication architecture for the shared workstations and the mainframe. Justify the choices against the stated constraints.
Read the worked answer
Conditional go, not federation-only. Federation-only leaves the mainframe untouched and effectively endorses shared teller logins, which conflicts with non-repudiation and with the fraud team's evidence that terminated credentials were used. Shared logins also make session attribution impossible during an investigation.
For the mainframe, use an identity broker or privileged-access gateway that maps each employee's enterprise identity to a unique mainframe user ID, injects the credential after strong authentication, and logs the session. This avoids waiting 18 months for SAML support and removes shared IDs. If the gateway cannot cover all transactions immediately, scope it to teller transactions first and keep a documented compensating control for the remainder.
For shared Windows workstations, do not use a team key. Use per-user FIDO2 roaming keys with PIN user verification and fast user switching, so each teller authenticates individually and the session locks on key removal or a short idle timeout. Windows Hello for Business is unsuitable as the sole factor on a shared kiosk because it binds to the device profile. Pair the key with a badge tap for workstation assignment, but do not treat the badge as the authenticator.
Proceed to the remaining branches only after the pilot fixes enrollment and unlock workflows, because 12% weekly lockouts will otherwise scale to an operational crisis.
2. Design controls for key lifecycle and shared-device use, and define metrics that tell the sponsor whether the rollout is safe to scale.
Read the worked answer
Key lifecycle: issue two keys per employee, one primary and one sealed spare held by the branch supervisor; bind keys to the individual at enrollment after identity verification; require PIN change at first use; support self-service reset only after a verified callback; revoke keys within one hour of termination through the HR feed; and reconcile issued keys against the identity store weekly. Track lost and unreturned keys as security incidents, not inventory discrepancies.
Shared-device controls: enforce individual authentication for every session, disable credential caching on the workstation, set a 2-minute lock on inactivity and immediate lock on key removal, and prohibit browser password storage. Place keys on a lanyard or badge reel and audit for keys left in USB ports during floor checks. Use kiosk mode to restrict access to approved applications. A supervisor override should create its own logged event, not a shared login.
Metrics for the go/no-go: authentication success rate by branch; helpdesk tickets per 1,000 logins, with a target below the pre-rollout baseline; median time to unlock; percentage of staff with two enrolled keys; key loss rate; shared-login count, which must trend to zero; mainframe sessions attributable to a unique user; and fraud attempts traced to terminated identities. Add a customer queue-time metric because the executive cares about branch service. Scale only if success exceeds 95%, lockouts fall below 5% weekly, and every mainframe teller session is attributable.
3. How would you reduce helpdesk load without weakening assurance? Address the temptation to reinstate shared logins and the risk trade-offs of each fallback.
Read the worked answer
Reduce load by fixing the causes of lockout, not by lowering assurance. First, instrument the calls: if most are PIN resets, enrollment errors, or forgotten keys, the remedy is a supervised self-service reset kiosk in the branch, a second enrolled key, and clearer first-use training. If calls come from slow authentication, move the IdP closer to branches and test mainframe gateway latency.
Second, stage the rollout by branch profile. High-turnover branches get on-site enrollment support and a spare-key cabinet; low-turnover branches can use remote enrollment with identity verification. Publish a one-page unlock procedure for supervisors so routine resets do not reach the helpdesk.
Fallbacks must preserve individual accountability. A one-time bypass code issued to a named employee, logged and expiring in 15 minutes, is acceptable. SMS fallback is weaker and should not be used for mainframe access. Reinstating shared teller logins is not acceptable: it defeats attribution, makes the terminated-employee fraud pattern invisible, and would likely fail an access-control review. If operations truly cannot continue, a documented emergency procedure with supervisor present, session recording, and 24-hour review is a compensating control, not a permanent design.
Trade-off: a fast unlock path increases the risk of social-engineering resets. Require supervisor identity verification and log every bypass, then review bypass frequency as a leading indicator.