Resetting an 18-Month Zero Trust Plan at a Mid-Sized Bank
Northbridge Financial is a 2,400-employee bank with 1,400 remote workers, 14 business units, three data centers, and 22 line-of-business applications that predate its current identity provider. Peak VPN utilization is 85%, the internal network is a flat /16, and no complete device inventory exists. In a recent tabletop, an attacker moved from a phishing workstation to a core banking subnet in 40 minutes. The board approved $3.2M over 18 months for zero trust, contingent on quarterly evidence of risk reduction. PCI DSS and GLBA apply to card and customer data. The CISO has executive sponsorship and nine security engineers, but no dedicated zero trust program staff; business units control their own application roadmaps and resist changes that affect availability. A vendor proposal leads with network microsegmentation across all 14 business units in the first six months. The CISO asks you to reset the plan.
1. What outcomes and metrics should the first 90 days commit to, and why those rather than a microsegmentation coverage target?
Read the worked answer
The first 90 days should buy evidence and reduce the most exposed paths, not claim enterprise segmentation. A defensible set: 100% of privileged and administrative accounts for the 22 legacy apps inventoried and protected by phishing-resistant MFA, or by a compensating control with session recording; 90% of remote endpoints enrolled in a device inventory with OS version and EDR status; SSO and centralized authorization for the five applications that touch cardholder data; a tested access-revocation workflow with median time under 15 minutes for leavers and contractors; and a policy decision log for at least one critical application.
Reasoning: the tabletop showed credential misuse and rapid lateral movement, while the bank lacks identity and device visibility. Microsegmentation coverage would be attractive, but the flat /16 and missing device inventory mean policy would be based on guesses, producing either outages or false assurance. Metrics should include a baseline and a target, not just a percentage. The board needs trend lines: number of standing VPN accounts removed, number of implicit trust paths documented, and exceptions with owners and expiry dates. Avoid measuring zero trust maturity by vendor features; measure risk reduction in paths the bank can actually control.
2. Sequence identity, device, network, workload, and data capabilities for the 18 months. Justify why network microsegmentation should not lead.
Read the worked answer
Sequence: months 0-3 identity and visibility; 3-6 device posture and privileged access; 6-12 network segmentation for a small number of high-value enclaves; 9-15 workload and application identity; 12-18 data controls and continuous verification.
Identity first because the bank already has an IdP and the attack path depended on credentials; consolidating SSO, MFA, and privileged access management reduces blast radius and creates logs the policy engine needs. Device second because remote endpoints are the new perimeter and cannot be evaluated without inventory. Network third, but scoped to the PCI cardholder environment and core banking, not all 14 business units. Workload and data follow because they require application owners to classify data and expose APIs.
Microsegmentation should not lead because a flat /16 with incomplete inventory makes policy authoring speculative. A bank-wide first phase would create availability risk and business-unit resistance. Starting with the PCI enclave gives a regulatory driver, a bounded scope, and a measurable outcome. Use the first six months to build flow telemetry and application dependency maps, then enforce in monitor mode before blocking. This ordering also matches NIST SP 800-207 logic: the policy engine needs identity, device, and resource context before enforcement can be trustworthy.
3. How should the team handle the 22 legacy applications that cannot support SSO or endpoint agents?
Read the worked answer
Treat each legacy app as a risk decision, not an exception to hide. First classify: does it process cardholder data, customer data, or only internal low-risk data? For high-risk apps, place a network policy enforcement point in front and require access through a managed jump host or reverse proxy that enforces MFA, source allow-listing, and session recording. For apps with local accounts, vault credentials, rotate them, and remove standing user knowledge. For endpoints that cannot run an agent, require a managed virtual desktop or browser isolation for access, so device posture is inherited from the managed environment. For vendor support tunnels, require time-bound, approved sessions through the same PEP, with a sponsor and post-session review.
Publish an exception register with owner, compensating controls, review date, and migration path. The reasoning: zero trust does not require every app to be modernized; it requires that access decisions be explicit and enforced as close to the resource as possible. The bank should not accept cannot support SSO as a permanent bypass, because that recreates implicit trust. Set a 12-month target for the five highest-risk apps to adopt SSO or be replaced. This balances availability with a credible path to reduce standing access.