The Evaluation Nobody Publishes: What Analyst Reports Won't Tell You About Zero Trust

Part of the “Integration Is The Architecture” series

Since publishing the architecture series, I’ve received dozens of messages all circling the same question: “How did you actually decide?” The interest wasn’t focused on the vendor shortlist - it was about the evaluation framework itself. How we structured it, what criteria we weighted, and why. This article is that answer.

We evaluated vendors across every major analyst report before making our Zero Trust Edge architecture decision at Swiss Post.

This isn’t a vendor comparison. It’s a methodology piece - because the framework we built changed our understanding of what we were actually buying.

---

1. Why Analyst Reports Aren’t Enough

Let me start with an uncomfortable truth. Analyst reports rank vendors in isolation. They evaluate capabilities within categories - identity, endpoint, network, edge. They score features, market presence, and vision.

What they don’t score is integration potential. How well does Vendor A’s identity signal flow into Vendor B’s enforcement point? Can Vendor C’s posture data be consumed programmatically at the edge? Does Vendor D’s API actually expose the telemetry you need for correlation - or does it expose a curated summary that hides the granular signals?

To be fair, most analyst firms offer tools to customize these reports - disable irrelevant domains, redistribute weighting, filter by your specific requirements. But how many of you have actually used those - or even have access to them? In practice, the vast majority consume the general report that gets passed around in LinkedIn posts - the one with the default weightings that may have nothing to do with your environment.

In a generic report, capabilities that are completely irrelevant to your strategy still inflate a vendor’s ranking. If your direction is cloud migration, on-premises deployment capability is noise - but it scores just the same. A vendor that ranks high because it covers every deployment model doesn’t help you if you only need one.

And naturally, the “Leader” and “Visionary” titles from those generic reports are exactly what ends up in sales decks and LinkedIn posts. You won’t see anyone marketing “We’re a Leader when you adjust the criteria to match your actual needs.” The quadrant that looks best is the one that travels.

And analyst categories are backward-looking by definition. A SASE evaluation scores SASE capabilities. It doesn’t score agentic AI infrastructure, edge compute, or post-quantum readiness - emerging capabilities that your chosen platform may or may not deliver as part of its evolution. The capabilities you inherit from a platform over the next three years matter as much as the capabilities it has today. No analyst report evaluates that.

These are the questions that determine whether your architecture works. And no analyst report answers them.

---

2. What We Needed Instead

We needed a framework that evaluated vendors not as standalone products, but as components of a system - where the value comes from how they interact, not just what they do alone.

And we needed a framework that evaluates trajectory, not just current state. Where is this platform going? Does its evolution align with where we need to be in three to five years?

Answering that requires something most evaluations skip entirely: understanding your own enterprise strategy. Not just today’s pain points, but your mid- and long-term aspirations - the strategic goals your platform choices will either enable or obstruct for years after the contract is signed.

---

3. Zero Trust Isn’t One Problem

But before defining the criteria, we had to define the problem space correctly. Here’s the architectural insight that shaped everything. Zero Trust is at least two fundamentally different problems that share a name.

North-South is traffic between your organization and the outside world. Users accessing applications. Customers hitting your APIs. Partners connecting to shared services.

The enforcement challenge: how do you verify trust for entities you don’t fully control, at global scale, in milliseconds?

East-West is traffic between systems you own. Service-to-service communication. Database access. Internal APIs.

The enforcement challenge: how do you prevent lateral movement inside a perimeter that no longer exists?

These domains have different traffic patterns, different trust models, different latency requirements, and different vendor landscapes. Evaluating them with one scorecard is like evaluating a sports car and a cargo ship on the same criteria. They’re both vehicles. That’s where the similarity ends.

East-West - microsegmentation and SD-WAN - is a separate evaluation track at Swiss Post that’s still in progress. This article focuses on the Zero Trust Edge: the North-South domain where external threats meet your architecture.

---

4. The Criteria That Matter

We ran a traditional RFP to establish the functional baseline - feature coverage, deployment models, compliance. But alongside the usual criteria, we embedded requirements you’d never see in a standard Zero Trust RFP - this is where our evaluation framework made all the difference. Here are the five mandatory framework dimensions we evaluated.

1. Integration depth, not integration existence. Every vendor claims integrations. We tested them. Can we consume identity signals at the enforcement point in real-time? Not “we support SAML” - that’s table stakes. Can we verify device compliance, risk scores, and behavioural signals at the moment of access - and revoke access mid-session when those signals change?

2. Programmability. When the native integration doesn’t cover our use case, can we build it? A platform with a comprehensive API and edge compute capabilities means missing integrations are a development task, not a vendor dependency. A platform without programmability means every gap is a feature request with no timeline.

3. Entity coverage. Most platforms optimise for employees on managed devices. We need to protect five entity types - employees, customers, partners, suppliers, and external services - with the same architectural rigor. If a vendor excels at workforce access but requires entirely separate products for customer-facing applications and API security, that’s not a unified architecture. That’s three architectures wearing a trenchcoat.

4. Signal contribution. What unique telemetry does this vendor generate that no other vendor in the stack provides? If two vendors generate the exact same telemetry from the same perspective, one of them is shelfware. We wanted vendors with complementary visibility - one that sees identity and device deeply, another that sees network and behaviour deeply. Excessive overlap means waste. Gaps mean blind spots.

5. Platform trajectory. Where is this platform heading over the next three to five years - and does that direction align with where we need to be? A vendor that scores well today but whose roadmap diverges from your strategy is a migration waiting to happen. We evaluated not just current capabilities, but platform-adjacent optionality - edge compute, agentic AI infrastructure, post-quantum readiness. The capabilities you inherit matter as much as the capabilities you buy.

---

5. Why Single-Vendor Fails the Framework

A single vendor controlling both signal generation and enforcement collapses trust boundaries.

If the same platform that issues the verdict also controls all the evidence, you don’t have consensus - you have a monologue.

When a single platform owns both observation and action, a compromise of its control plane simultaneously blinds you and opens the door. Independent signal sources mean a compromised component in one domain still triggers detection in another. The blast radius of any single failure stays contained because no single system holds all the keys.

Run any single vendor through these five framework dimensions and a pattern emerges. The identity leader has shallow network telemetry. The edge leader has shallow device posture. The endpoint leader has no edge presence. And even vendors that score well across multiple dimensions deliver that excellence in isolation - buy the full stack or lose the coherence.

But enterprises have existing contracts, established infrastructure, and strategic investments they cannot or don’t want to replace. They need a platform that integrates into their world, not one that replaces it.

The framework demands architectural consensus. If you read Part 1, you already know what that looks like. If you didn’t - no single system makes that determination alone.

---

6. What the Framework Revealed

When we applied these five criteria across the vendor landscape, the field narrowed fast.

Entity coverage eliminated the most candidates. When we asked “how does this platform protect a customer accessing a public API with the same rigor as an employee on a managed device?” - most answers involved buying a second product from a different business unit.

Programmability was the second filter. Beautiful consoles with limited extensibility failed immediately.

Signal contribution forced the multi-vendor decision. No single vendor produces all the signals we need - and the architecture needs them from independent sources, because consensus requires independence.

The vendors that dominate traditional RFP criteria? The framework exposed gaps they never had to answer for. Two platforms that each own their domain deeply - and integrate openly - create a stronger system than any single platform could alone.

The integration isn’t a nice-to-have. The integration IS the architecture.

---

7. The Cost of Multi-Vendor

“Multi-vendor is expensive” is the objection you’ll hear from every sales team pushing consolidation. And sometimes they’re right.

But let’s talk about where you’re actually coming from. Count the boxes in your perimeter today. Firewall. Proxy. VPN. DLP. CASB. WAF. DDoS. IDS. IPS. Bot management. And the list goes on. That’s double-digit vendors, consoles, policy languages, and renewal cycles.

Here’s what the consolidation conversation misses: “multi-vendor” means something completely different in Zero Trust than it did in perimeter security.

In the perimeter world, multi-vendor meant easily 20+ point solutions - each solving one narrow problem, none talking to each other. That was multi-vendor by accident.

In Zero Trust, multi-vendor means a few tightly integrated platforms - each owning a strategic domain. That’s multi-vendor by design. The number goes down dramatically. The intentionality goes up.

At Swiss Post, going from double-digit point solutions to a few integrated platforms isn’t “multi-vendor complexity.” It’s the most aggressive consolidation we’ve ever done.

So why not go all the way and consolidate to one?

Because no single vendor today clears all five framework dimensions in one stack. They might pass the traditional checklist, but they hit a wall when confronted with ours. You may simplify procurement - but you risk downgrading architectural resilience.

We don’t pay for redundancy. We pay for the truth.

---

The Bottom Line

Here’s what it comes down to. The evaluation nobody publishes is more valuable than the decision it produces. Vendor selections change. Contracts expire. Platforms get acquired. But a sound evaluation framework survives all of that - because it encodes why you made a decision, not just what you decided.

If your Zero Trust Edge evaluation is a feature-comparison spreadsheet, you’re optimizing for the wrong thing. Features change quarterly. Integration depth, programmability, signal contribution, entity coverage, and platform trajectory - those are architectural properties that define whether your security model works as a system or fails between components.

The evaluation nobody publishes is the one everyone needs.