Every vendor sells Zero Trust now. Most of them sell something else under that name. After watching three banks and two telecoms in the Maghreb stand up Zero Trust programmes over the last 18 months, we have a clear view of which framing actually delivers the security improvement people thought they were buying, and which framing is a VPN renamed.
This piece is about the practitioner's read: what Zero Trust really requires architecturally, what the current ZTNA tool landscape actually provides, the three failure modes we have seen ship to production, and the specific things the Moroccan and Maghreb context changes about the deployment.
The framing trap
The original Zero Trust idea, from Forrester in 2010 and BeyondCorp in the years that followed, is structural: stop trusting the network. Replace location-based access (you are on the corporate LAN, so you can talk to the database) with identity-and-context-based access (this specific user, on this specific device, with this specific posture, can make this specific request to this specific resource).
That is a deep change. It requires:
- Strong device identity (every device has a cryptographic identity, not "is on the VPN")
- Strong user identity (SSO with phishing-resistant MFA, not username + password + SMS)
- Per-request authorisation (every API call, every database connection, every file fetch goes through a policy decision point)
- Continuous posture evaluation (device drifts from compliant, access narrows or revokes)
- Encrypted transport everywhere, including inside the network
What most vendors sell as Zero Trust today is item 3 only, narrowed to "we will intermediate HTTP requests at our gateway and check an OIDC token". That is useful. That is not Zero Trust. It is a SaaS-delivered ingress proxy, which is materially better than a VPN for the specific case of "internal web app reachable from outside" and approximately the same as a VPN for everything else.
If a vendor pitches "Zero Trust" and the demo is a polished SSO login page, you are looking at the proxy. Ask them how they handle device posture for an SSH connection, a Postgres connection from a developer's laptop, and a service-to-service gRPC call inside your VPC. If the answer is "we don't, that's out of scope", you are looking at a VPN replacement.
What the current vendor landscape actually does
The tools we have evaluated or run in production on Maghreb projects:
| Tool | What it actually is | Where it earns its keep |
|---|---|---|
| Cloudflare Access | Identity-aware HTTPS proxy + app launcher | Internal web apps for distributed teams. Cheap. Setup in hours. |
| Zscaler Private Access | Identity-aware proxy for HTTP + TCP + UDP | Larger enterprises with explicit ZT mandate. Expensive. |
| Tailscale | WireGuard mesh with identity + ACL | Developer access to infra. Small teams. Approaches BeyondCorp shape via ACLs + tagging. |
| Twingate | Identity-aware mesh with policy engine | Mid-size. Hybrid mesh + proxy. |
| Cisco Duo + ISE | MFA + network access control | If you already run Cisco at the edge, the ZT layer extends. |
| AWS Verified Access | Per-request identity check for ALB-fronted apps | AWS-native shops. Limited scope. |
| Google BeyondCorp Enterprise | Closest to the original BeyondCorp paper | Full-coverage, but a Google ecosystem commitment. |
| OpenZiti | Open source overlay network with identity | Self-hosted, growing community. The non-vendor option. |
| Teleport | Identity-aware proxy for SSH + Postgres + Kubernetes + web | Strong for developer-to-infra access. Audit trail is excellent. |
Note what is missing from this table: device posture is universally under-implemented. Cloudflare Access can check a few signals via WARP. Zscaler does posture via ZCC. Tailscale does basic device authorisation. But "this Mac has FileVault on AND a current patch level AND no risky software installed AND the WireGuard cert was minted by our MDM" is something nobody in this table does end-to-end without a separate MDM (Jamf, Kandji, Intune, Microsoft 365 Endpoint Manager).
The realistic 2026 architecture for a serious deployment is: identity layer (Entra ID, Okta, or self-hosted Keycloak) + MDM for device posture (Jamf for Mac, Intune for Windows, optionally Kandji or Mosyle) + ZTNA tool for application access (one of the above) + service mesh (Istio, Linkerd, or Consul Connect) for internal service-to-service auth + secret manager (HashiCorp Vault, AWS Secrets Manager, or 1Password Business) for the credentials that machines still need.
That is five vendor categories. Anyone telling you they cover all of it under one Zero Trust brand is either lying or selling you each piece thinly.
What works in the Maghreb financial sector
Moroccan and Tunisian banks have specific constraints that change the deployment shape: BAM and BCT regulatory pressure on personal data localisation, the operational reality that branch banking still matters (every regional branch has a network), legacy core banking systems that have not seen a security review since their 2008 deployment, and the fact that physical access controls (badge readers, CCTV) are still considered first-line security rather than the secondary line they have become elsewhere.
Three things we have seen actually work:
1. Phased rollout starting at remote access. The fastest credible Zero Trust win is replacing the legacy VPN for remote workers with a ZTNA proxy. Cloudflare Access plus Microsoft Entra ID is a 6-week deployment for a typical regional bank, costs about $7-12 per user per month, and reduces the attack surface measurably. It is not full Zero Trust. It is a real win and it earns budget for the next phase.
2. Identity-first, network second. The biggest single uplift in security posture comes from getting phishing-resistant MFA enrolled on every privileged account: FIDO2 security keys for the IT admin team, Microsoft Authenticator app with number matching for everyone else, no SMS fallback anywhere. This delivers more security improvement than the network redesign, faster, and is a prerequisite for the rest of the programme anyway.
3. Auditable service-to-service auth before service mesh. Before introducing a service mesh, get to the state where every internal service-to-service call uses short-lived workload identity (SPIFFE, AWS IAM roles, GCP service accounts) rather than long-lived API keys. This is achievable in 3-4 months with discipline. A service mesh sitting on top of long-lived shared keys is not Zero Trust, it is a more complex VPN.
Three failure modes we have seen ship
Failure mode 1: The proxy is the wall.
Team buys Cloudflare Access, points the internal HR app behind it, declares Zero Trust complete. Two months later, an attacker phishes a session cookie from a developer, lands in the proxy as that developer, and reaches everything that developer could reach. Which is everything, because per-request authorisation was never built. The proxy authenticated; it did not authorise per resource.
Fix: every protected resource needs its own authorisation policy, expressed in terms the proxy can evaluate (user attributes, device posture, request shape) and updated when the resource's sensitivity changes. The proxy is the policy decision point, not the policy.
Failure mode 2: The MDM lies.
Device posture comes from the MDM. The MDM reports last-check-in from the device, the patch level the device reported on that check-in, and the compliance state the MDM evaluated against its own rules. Three of those are second-hand information. A device that was compliant 3 hours ago and just downloaded a malicious browser extension is reported as compliant until the next check-in cycle, which is 4-24 hours later.
Fix: short check-in intervals (15-30 minutes), out-of-band signals from EDR (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) feeding into the access decision, and a hard rule: any posture signal more than 1 hour stale forces a re-authentication.
Failure mode 3: The audit trail nobody reads.
ZTNA tools produce excellent logs. Per-request access decisions, identity context, device context, denied attempts, suspicious patterns. These logs accumulate at gigabytes per day for a mid-size organisation and end up in a SIEM that nobody queries until an auditor asks.
Fix: at minimum, automated weekly review of denied-access patterns (an authentic user being denied is a signal of misconfiguration; an anomalous identity being denied is a signal of attack). Better: a small set of SIEM correlation rules that fire on the patterns that matter (privilege escalation attempts, unusual geographic access for an account, multiple session establishments from different devices in a short window). Wazuh is free and capable; for paid, Sentinel and Splunk both run these rules well.
What this means for you
If you are at the start of a Zero Trust programme: pick one application, deploy an identity-aware proxy in front of it, enforce phishing-resistant MFA on the identity layer, and run it for two months. You will learn more about your environment from that one deployment than from six months of architecture diagrams. Use the learning to plan phase two.
If you are mid-programme and discovering that the vendor pitch oversold the coverage: that is normal. Build the explicit gap analysis (we have identity, we have proxy access for HTTP, we do not have posture, we do not have service-to-service auth) and budget the next phase against the actual gaps, not against the next vendor's pitch.
If you are being asked whether to buy Zero Trust X or Zero Trust Y for your organisation: the question is wrong. The question is which of the five categories (identity, MDM, ZTNA, service mesh, secret management) you have today and which you need next. Pick the next category, then choose the vendor inside it.
What we got wrong
We have, on at least two engagements, treated Zero Trust as primarily a network problem. It is primarily an identity-and-policy problem with a network layer at the bottom. The teams that ship the cleanest implementations start from the identity side and work down. The teams that struggle the longest start from the network side and try to retrofit identity onto it.
The 2026 lesson is not new. It was in the original BeyondCorp paper. We just had to learn it again.