Zero Trust and SASE Rollout for a Retail Chain
A retail chain has 1,200 stores, 18,000 employees, and a legacy flat network. Store traffic backhauls through two data centers, and VPN concentrators are at 95% capacity. The company is migrating e-commerce to AWS and has piloted a SASE service in 120 stores. The pilot added about 40ms of latency and coincided with a 7% checkout failure increase, which store operations blamed on security. Identity is fragmented: 14 identity providers remain after acquisitions, and 30% of accounts are local. The board has announced a zero trust target for 2026. The CIO wants a phased architecture, a fix for the pilot before expansion, and a credible identity consolidation plan. Store network refreshes are scheduled annually, so timing matters.
1. Define the target architecture and a phased roadmap. Explain what zero trust means in this environment and what it does not mean.
Read the worked answer
Target architecture: identity-centric access with a single workforce identity provider and a separate customer identity platform; device posture checks for corporate and managed store devices; local internet breakout at stores through a SASE security stack; microsegmentation of data-center workloads and store-to-data-center paths; centralized policy with distributed enforcement.
Zero trust here does not mean removing all network controls or buying a single product. It means no implicit trust from network location, least-privilege access, and continuous verification. Stores still need resilient connectivity and local failover.
Phase 1: stabilize the pilot. Separate checkout traffic from general browsing; measure latency at the store edge, not the data center. Phase 2: consolidate identity for the top 20% of privileged and remote accounts, then workforce accounts. Phase 3: expand SASE to store cohorts aligned with annual refresh, starting with high-bandwidth or high-risk locations. Phase 4: microsegment the e-commerce AWS environment and data-center crown jewels.
Sequencing matters: identity and device posture must precede broad policy enforcement, or the program will produce outages and lose business support. Publish exit criteria for each phase and roll back on defined latency and checkout thresholds.
2. The pilot's latency and checkout failures are being blamed on security. How do you diagnose and fix this, and what metrics would you present to the CIO?
Read the worked answer
First, separate correlation from causation. Pull store-level checkout logs, network latency, SASE PoP selection, TLS inspection policy, and failure timestamps. Check whether failures occur only on inspected traffic, only at peak hours, or only in stores homed to a distant PoP. A 40ms average can hide tail latency that breaks payment timeouts.
Likely fixes: enable local breakout closer to stores; exclude payment terminals from unnecessary inspection where compliant; right-size TLS inspection; tune proxy timeouts; add local failover. Do not simply disable security controls; change where they execute.
Metrics to present: checkout success rate by store cohort, p50 and p95 latency for payment and POS flows, SASE availability, mean time to detect and resolve store connectivity incidents, and percentage of traffic inspected versus bypassed. Compare pilot and control stores before and after each change.
Governance: give store operations a joint sign-off on expansion criteria, for example checkout failure rate no worse than baseline and p95 latency within agreed threshold for four consecutive weeks. Publish a rollback plan. This converts a blame dispute into a shared service-level decision.
3. Design an identity consolidation strategy across 14 identity providers. What do you consolidate first, and how do you avoid breaking store operations?
Read the worked answer
Inventory all 14 providers by user population, application dependencies, authentication protocols, and privileged access. Classify into workforce, customer, and machine identities. Target two strategic platforms: one workforce IdP and one customer IdP, with federation for exceptional cases.
Consolidate first the highest-risk, lowest-disruption population: privileged administrators and remote vendors. These accounts are few, high impact, and can tolerate a managed migration. Next, corporate workforce accounts with SSO to SaaS. Store associates and local accounts come later, because shift-based access and shared devices create operational risk.
Use standards: SAML or OIDC for applications, SCIM for provisioning, phishing-resistant MFA for privileged users. Run pilots by region and store cohort. Keep a break-glass path and local fallback for store opening. Map each application owner and require them to test before cutover.
Avoid big-bang migration. Set a hard freeze on new local accounts and a decommission date per provider. Track percentage of active accounts on the strategic IdP, application coverage, and authentication failure rate by store. If a store cannot open, the migration has failed regardless of directory elegance.