Zero Trust: The Gap Between Strategy and Implementation

Every enterprise has a zero trust strategy. Most have had one for years. Very few have actually implemented it.

The gap between "we're adopting zero trust" and "we've deployed zero trust" is enormous—and it's where initiatives go to die. After implementing zero trust architectures at Fortune 500 financial services firms, we've learned what actually works versus what sounds good in a strategy deck.

Why Zero Trust Stalls

The typical zero trust initiative dies in one of three ways:

1. Analysis Paralysis

The team spends 18 months on "discovery" and "current state assessment." They produce beautiful Visio diagrams and 200-page reports. Nothing ships.

2. Big Bang Ambition

Leadership wants to "transform everything" at once. The project becomes so large it's impossible to staff, fund, or complete. Nothing ships.

3. Vendor Lock

A security vendor sells a "complete zero trust platform." The organization spends a year deploying it, only to find it doesn't integrate with their actual systems. A lot of money ships, but no working security.

What Actually Works

The teams that successfully implement zero trust share a few characteristics:

Start with Identity

Everything else is noise without a solid identity foundation. If you can't definitively answer "who or what is making this request?" then nothing else matters.

# Identity maturity checklist
- Single source of truth for user identities: required
- Service account inventory: required
- Machine identity management: required
- MFA everywhere (including service accounts): required
- Just-in-time access provisioning: strongly recommended
- Continuous authentication: nice to have initially

The order matters. Don't try to implement continuous authentication before you've solved basic identity hygiene.

Micro-Segment Where It Matters

You don't need to segment everything on day one. Start with:

1. Crown jewels — Your most sensitive data and systems
2. Blast radius limiters — Choke points that prevent lateral movement
3. Compliance boundaries — Segments required by PCI, HIPAA, etc.

A working implementation of three critical segments beats a planned implementation of three hundred.

Policy as Code

If your security policies exist only in Word documents and Confluence pages, they're not policies—they're suggestions.

# Example: Service-to-service authorization policy
@policy
def authorize_service_request(request: ServiceRequest) -> Decision:
    # Explicit deny takes precedence
    if request.source_service in BLOCKED_SERVICES:
        return Decision.DENY
 
    # Check if this communication path is allowed
    allowed = is_communication_allowed(
        source=request.source_service,
        destination=request.destination_service,
        action=request.action
    )
 
    if not allowed:
        log_violation(request)
        return Decision.DENY
 
    # Verify source service identity
    if not verify_service_identity(request):
        return Decision.DENY
 
    return Decision.ALLOW

Policies that live in code get tested, versioned, and deployed. Policies that live in documents get ignored.

The 9-Month Framework

We've refined an approach that delivers working zero trust in 9 months for most enterprise environments:

Months 1-2: Foundation

• Identity source audit and cleanup
• Service account inventory
• Initial microsegmentation design (5-10 critical segments)
• Policy framework selection

Months 3-5: Core Implementation

• Identity provider hardening
• MFA deployment (users and privileged accounts)
• Initial microsegmentation deployment
• Policy engine implementation

Months 6-8: Expansion

• Service account MFA/cert-based auth
• Additional microsegmentation
• Continuous monitoring integration
• Incident response updates

Month 9: Hardening

• Security testing and validation
• Runbook finalization
• Team training
• Metrics and reporting

Common Mistakes to Avoid

Don't Boil the Ocean

The goal is working security, not perfect security. A 70% implementation that's actually deployed beats a 100% plan that never ships.

Don't Ignore Legacy

Your 1990s COBOL system probably can't support modern authentication. Plan for exceptions and compensating controls rather than pretending legacy doesn't exist.

Don't Forget Operations

The team that deploys zero trust is not the team that operates it. Build for operability from day one. If your SOC can't respond to alerts, the alerts are useless.

Don't Skip Change Management

Zero trust changes how people work. Applications break. Access gets denied. If users and developers don't understand what's happening and why, they'll find workarounds that undermine everything.

The Bottom Line

Zero trust isn't a product you buy or a project you complete. It's an architectural approach that takes years to fully mature. The organizations that succeed are the ones that:

1. Ship early — Get something working in months, not years
2. Iterate continuously — Improve security posture over time
3. Operate effectively — Build for the team that has to run it
4. Communicate clearly — Help the organization understand the changes

The goal isn't a perfect zero trust architecture. The goal is a significantly better security posture than you had before—and a foundation you can build on.

Struggling with your zero trust implementation? Let's talk about what's actually blocking progress.