Zero Trust for the Mid-Size Enterprise

Who this paper is for

Zero trust literature has a scale problem.

The canonical implementations — Google’s BeyondCorp being the famous one — were built by organizations that could assign platform teams to the problem for years. The mid-size enterprise, 500 to 5,000 users, gets the same conference talks and the same vendor pitches, but has perhaps three to eight infrastructure engineers, a security function that may be two people, and a legacy estate that includes at least one application nobody dares touch.

I lead technology for accounts in this band and run infrastructure for organizations smaller still, and my position is the opposite of defeatist: zero trust is more achievable at mid-size than the literature suggests, because the essential components map onto products these organizations already license. What mid-size programs lack is not budget but sequencing. This paper supplies the sequencing.

What zero trust actually requires

NIST SP 800-207 defines zero trust with three abstractions: a policy engine that decides access, a policy administrator that establishes or kills sessions, and policy enforcement points that sit in the data path. Every request — regardless of source network — is evaluated against identity, device state, and context before access is granted, and access is granted to individual resources, not networks.

Strip the abstraction and a mid-size implementation needs exactly four capabilities:

800-207 concept	Mid-size implementation
Policy engine / administrator	Your identity provider’s conditional access engine (Entra ID, Okta, etc.)
Enforcement point — web apps	IdP-federated SSO; identity-aware proxy for internal web apps
Enforcement point — network/legacy	ZTNA connector or per-app VPN; firewall zones behind it
Device state signal	MDM/EDR compliance feeding the policy engine

Notice what is absent: no requirement for microsegmentation platforms, no requirement to rewrite applications, no service mesh. Those are optimizations available to organizations that finish the fundamentals — and most vendor zero trust conversations start with them precisely because the fundamentals do not require a purchase order. The identity-first security argument is the philosophical core here — the perimeter’s job moves to identity, and the network’s job narrows to containment.

The architecture

 User + managed device
        |
        v
 [ Identity Provider ]  <--- device compliance (MDM/EDR)
 [ conditional access ] <--- risk signals, location, MFA
        |
        +--> SaaS apps ............ SSO federation
        |
        +--> internal web apps .... identity-aware proxy
        |
        +--> legacy / thick apps .. ZTNA connector (per-app tunnel)
        |
        v
 [ Segmented network zones ]  <-- containment when the above fails
 [ logging + SIEM ]           <-- every decision recorded

Design decisions worth stating explicitly:

1. One policy engine. Resist running separate policy logic in the IdP, the ZTNA product, and the firewall. Pick the IdP as the brain; everything else enforces its decisions. Two policy engines means policy drift, and policy drift means the exception nobody can explain during an incident.
2. The VPN dies by attrition, not decree. Publish applications through the identity-aware path one at a time and shrink the VPN’s reachable scope after each move. The VPN architecture patterns piece covers the interim states — the important discipline is that full-tunnel, flat-network VPN access ends, even if a narrow per-app tunnel survives for the ERP system.
3. Segmentation stays. 800-207 is explicit that ZTA and perimeter controls coexist; network segmentation remains the layer that limits blast radius when a token is stolen or a policy is misconfigured. Zero trust changes what segmentation is for — containment, not primary access control.
4. Log every decision. The policy engine’s allow/deny stream is the richest security telemetry a mid-size org will ever own. It goes to the SIEM from day one, because tuning policy without decision logs is guesswork.

The five-phase plan

Ordered by risk reduction per unit of effort, not by architectural purity. Each phase has an exit test; do not start the next phase until you pass it.

Phase 1 — Identity foundation (months 0–6). Consolidate on one IdP. Enforce MFA everywhere, phishing-resistant for admins and finance first. Build the first conditional access policies: block legacy authentication protocols, require managed devices for admin access. Exit test: no user can authenticate to email or SSO with password alone, and legacy auth attempts are blocked, not just reported.

Phase 2 — Device signal (months 3–9, overlaps). Enroll the fleet in MDM; deploy EDR if absent; wire device compliance into conditional access so an unhealthy device loses access to sensitive applications automatically. Unmanaged personal devices get browser-only access to a defined app subset, or nothing. Exit test: a device that falls out of compliance measurably loses access within an hour, and you have tested this on purpose.

Phase 3 — Application publishing (months 6–18). Inventory applications — the real inventory, including the ones running under someone’s desk. Federate SaaS to SSO. Put internal web apps behind an identity-aware proxy. Move thick-client and legacy apps to per-app ZTNA tunnels. Shrink VPN scope after every migration. Exit test: a new hire’s laptop, on any network, reaches every sanctioned app through the identity path — and the flat VPN profile no longer exists.

Phase 4 — Privilege and lateral movement (months 12–24). Just-in-time admin elevation, admin workstation separation, service account inventory with credential rotation, and network segmentation tightened behind the identity layer — identity infrastructure and backups into restricted zones with deny-by-default posture. Exit test: standing domain admin count is single digits, and a workstation cannot reach a domain controller on any port except what authentication requires.

Phase 5 — Refine and measure (ongoing). Risk-based policies (impossible travel, session anomaly), automated access reviews, decision-log analytics, and — only now, if the blast radius justifies it — workload microsegmentation. CISA’s Zero Trust Maturity Model is a reasonable yardstick for this phase; mid-size “advanced” is a genuine achievement, and “optimal” is often not worth its marginal cost.

Where mid-size programs fail

I have watched more zero trust programs stall than succeed, and the failure modes repeat:

• Big-bang ambition. A two-year architecture document, no Phase 1 quick wins, sponsorship evaporates. The counter is boring: MFA and conditional access first, visible risk reduction inside a quarter.
• Legacy denial. The program pretends the AS/400, the badge system, and the lab instruments do not exist, then dies on contact with them. Put legacy systems in the architecture from the start: per-app tunnels and tight network zones are legitimate zero trust enforcement for systems that will never speak SAML.
• Buying the brain twice. A ZTNA product with its own policy engine gets deployed alongside IdP conditional access, and within a year the two disagree. One brain. Everything else is hands.
• No decommissioning discipline. The VPN, the old RADIUS server, and the exception firewall rules all survive “temporarily.” Every phase must end with something turned off, or the program adds attack surface instead of removing it.

What to write down

Before Phase 1 starts, record the decisions an auditor, an incident commander, or your successor will need: which system is the policy engine of record; the device-trust tiers and what each tier can reach; the sanctioned exception process and its expiry policy; and the legacy application register with the compensating control for each entry. A security architecture review at the end of each phase keeps the paper model and the deployed model honest with each other.

Zero trust at mid-size is not a diluted version of the hyperscaler program. It is the same architecture with harder prioritization — and prioritization is the one input that does not require a bigger budget.

That is the broader lesson, and it is older than the term zero trust: architectures succeed at the scale where their sequencing was designed, not the scale where their slideware was written. Trust decisions moved to identity long before the industry named it; the mid-size enterprise’s job is simply to catch its infrastructure up to that fact, one turned-off legacy path at a time.