The Zero-Trust MSA Playbook: how we cut $40M in F500 security overhead

What zero-trust actually requires

The dirty secret of zero-trust frameworks: NIST SP 800-207, BeyondCorp, Google’s BeyondProd, even Microsoft’s adoption guide — they describe properties, not implementations.

The properties are:

• Every request to every service is authenticated and authorized, not just authenticated.
• Trust is never implicit from network position.
• Policy enforcement happens at the workload, not the perimeter.
• Every workload’s identity, posture, and behavior is continuously validated.
• All access is logged in an auditable, queryable, immutable ledger.

The implementation cost is in mapping those five properties onto a brownfield system with 1,000+ services that were built over 15 years with shifting assumptions.

The decision matrix we used

Before any architecture work, we built a 4-axis decision matrix per service:

Axis	Range	What it drives
Data sensitivity	Public → Restricted	Encryption, key custody, residency
Trust boundary distance	Edge-facing → Internal-only	Identity propagation strategy
Change velocity	Daily deploys → Annual change	Policy update cadence
Blast radius if compromised	Single tenant → Multi-tenant	Lateral-movement controls

Every microservice got scored on all four axes. The cross product produced four migration cohorts:

1. Hot path (high sensitivity, edge-facing, daily deploys, multi-tenant) — these went first, hardest, most carefully.
2. High blast radius (internal but multi-tenant) — these went second.
3. High velocity (daily deploys, low blast radius) — these got tooling investment.
4. Stable internal (low everything) — these got swept last with templated policies.

Cohort 1 had 47 services. Cohort 4 had 600+. The instinct is to start with cohort 4 because it’s “easier.” The cost of that mistake compounds: by the time you reach cohort 1, you’ve embedded assumptions that don’t hold for the high-stakes workloads.