Zero trust projects rarely fail because the firewall rules were wrong. They fail because three years in, the security team realizes the policy engine, the agent fleet, and the risk scores are all welded to one vendor's console, and moving means rebuilding identity, logging, and enforcement from scratch. Buying carefully is cheaper than escaping later.

Evaluating tools with lock-in in mind is not about distrusting vendors. It's about designing an architecture where the parts that matter — identity, policy decisions, telemetry — stay legible to you and replaceable by you.

Separate the decision layer from the enforcement layer

Every zero trust platform has at least two jobs: deciding whether a request should be allowed, and enforcing that decision somewhere in the path. A product that does both tightly can be excellent, until you want to change one half.

Ask which part you are actually buying. If the answer is a policy engine, the enforcement points should be things you already own: your identity provider, your service mesh, your cloud load balancer, your EDR agent. If the answer is an enforcement point, make sure it consumes policy in a documented format instead of only its own.

A useful test: describe a realistic access decision — a contractor on an unmanaged laptop reaching an internal admin panel — and ask where each piece of that decision lives. The more of it that sits in formats and systems you can inspect, the more room you have later.

Twelve questions that expose lock-in

Put these in a spreadsheet and ask every shortlisted vendor. Score the answers honestly, and treat vague ones as no.

1. Which identity standards do you support natively — OIDC, SAML, SCIM — and which need a connector?
2. Can I export policies, rules, and objects in a machine-readable format, and is that export documented?
3. Where does my telemetry live, in what schema, and can I stream it to my own SIEM or data lake in real time?
4. Do you support an open event format such as the Open Cybersecurity Schema Framework, or only proprietary fields?
5. What happens to agents and enforcement points if my subscription lapses — do they fail open, fail closed, or stop working?
6. Is the management API first-class and documented, or is the web console the real interface?
7. Can I run a subset of the product in my own tenancy, or only in yours?
8. Which components are proprietary versus built on open standards like mTLS, SPIFFE, or OPA?
9. What does a tenant migration or exit look like, and is there a documented process and fee?
10. Which parts of your pricing depend on something I cannot easily shrink later?
11. How long do you commit to supporting the current policy schema after you change it?
12. Can I speak with a customer who has actually left your platform?

That last one is less rhetorical than it sounds. Vendors with a real answer have usually thought about exit. Vendors who deflect have not.

Standards are the exit ramp

Lock-in is a function of how much translation work a migration requires. Standards reduce translation work, so weight them heavily — but weight them accurately.

For identity, OIDC and SAML for authentication plus SCIM for lifecycle is table stakes. For workload identity, look for SPIFFE/SVID, or at least certificate issuance you control. For authorization, check whether rules can be expressed in a portable form such as Rego, or whether the product can consume decisions from an external policy decision point.

For telemetry the practical question is simpler than any acronym: can I get raw events, with a stable schema, into my own storage, and can I reconstruct a decision after the fact? If the only answer is a vendor dashboard, you have rented visibility rather than owning it.

An "integration" is not always interoperability

A connector that syncs data into a proprietary model is a one-way door with a nice diagram. Ask which direction data flows, whether it flows continuously, and whose schema is the source of truth.

Price the exit before you price the entry

Licensing shapes exit more than architecture does. Per-user pricing is easy to model and easy to shrink. Per-device pricing grows quietly as your estate grows. Pricing tied to decision volume, protected workloads, or ingested data becomes a negotiating trap when you want to consolidate.

Ask for a written statement of what happens at renewal if you drop half your users, keep the agents but disable enforcement, or want to run the policy engine yourself. Get it in the contract or the order form, not in an email from your account manager.

Also ask about data egress and retention. Platforms that make it free to send data in, and slow or costly to get it out, are selling a lock-in mechanism with a billing label on it.

Make the proof of concept a two-way test

Most pilots test whether the product works. Yours should also test whether you can leave it.

During the pilot, do four things. Export a representative policy set and try to express it in a neutral format such as a spreadsheet or Rego. Route the platform's events into your existing SIEM and confirm the fields you need arrive intact and documented. Disable the agent or policy engine on one test host and watch exactly how it fails. Then ask the vendor to walk you through a hypothetical migration off their product — the quality of that conversation tells you more than the feature matrix.

A short closing checklist

Before you sign, confirm that identity lifecycle is SCIM-driven and standards-based; that policies and events export in documented, open formats; that enforcement points are yours or readily replaceable; that the API is complete enough to rebuild the console; and that the contract states migration and egress terms. If two or more of those are missing, you are not buying a platform — you are buying a dependency.

None of this argues against an integrated platform. Focused products solve real problems, and rebuilding everything in-house is its own trap. The goal is narrower: keep the seams visible, documented, and on your side of the line. Tools will change. A well-drawn architecture gives you the option to change with them.

Photo: cagper / Pixabay