- The blocker in most UAE bank environments is not the concept, it is decades of flat network segmentation around core banking systems.
- Identity sprawl across on-premises Active Directory, Entra ID and vendor SaaS makes a single policy decision point impossible without consolidation work first.
- Service accounts and break-glass credentials are usually the least controlled part of the estate, and the part attackers actually use.
- Assessors want evidence of enforced controls and logging, not a zero trust label on a network diagram.
- A phased rollout starting with identity and privileged access beats a rip-and-replace network project every time.
Zero trust is an access model, not a network redesign
Most zero trust proposals in the region are pitched as a network project: buy a next generation firewall, add microsegmentation, done. That framing is why so many stall. Zero trust is fundamentally about identity and policy decisions made per request, using signals like user identity, device posture, location and behaviour. Network controls enforce the decision; they do not make it. A bank that segments its network well but still authenticates users with a single factor and standing admin rights has not implemented zero trust, it has implemented microsegmentation.
Why UAE bank environments make this genuinely hard
Core banking and legacy segmentation debt
Core banking platforms in this market are frequently legacy systems, running on infrastructure that was never designed for per-request authorisation. Flat VLANs connecting the core to branch networks, ATM switches and payment gateways are common, because segmenting a live core banking environment carries real transaction risk. Every segmentation change needs a change window, a rollback plan and sign off from a system owner who did not build the original network and is understandably cautious about breaking something that processes settlement.
Identity sprawl across on-premises AD, Entra ID and vendor SaaS
Zero trust needs one place to make the access decision. Most banks here have three or four: on-premises Active Directory for legacy apps, Entra ID for Microsoft 365 and modern SaaS, a separate directory for the core banking application, and vendor-managed identity for outsourced systems like card processing or trade finance platforms. Conditional access policies configured in Entra ID only govern the identities that actually live there. Anything authenticating against the legacy directory or a vendor's own identity store sits outside that policy entirely, which is why identity consolidation, not a new gateway appliance, is usually the real first project.
Privileged and service accounts nobody owns
Interactive human logins get the attention. Service accounts, scheduled task accounts and API keys used for system to system integration rarely do, and in most environments I have reviewed they carry standing privileged access with passwords that do not rotate. A functioning privileged access management programme that vaults these credentials, enforces just in time elevation and records sessions closes more real risk than most of the zero trust network tooling sold alongside it, because these accounts are exactly what lateral movement techniques target once initial access is gained.
Third-party and vendor connectivity
Outsourced card processing, managed print, HVAC monitoring and audit firms all need some form of network access, and that access was often provisioned years ago with a site to site VPN and never revisited. Zero trust asks a harder question for every one of these connections: what does this specific vendor account need to reach, for how long, and who reviews that access on a schedule. Answering it for dozens of vendor relationships is administrative work, not a technology purchase, and it is usually where a programme's timeline actually slips.
What assessors actually check
Regulatory reviewers under CBUAE guidance and ISO 27001 audits are not looking for the phrase zero trust on an architecture diagram. They ask for evidence: multi-factor authentication enforced on privileged and remote access, logging that shows access decisions and denials, a current inventory of who and what can reach the core banking segment, and a documented review cycle for third-party access. A bank that can produce that evidence with conventional segmentation and strong identity controls will pass more comfortably than one with a zero trust label and gaps in the underlying logging.
A sequencing that actually ships
Treating this as one programme instead of one project changes what gets funded first.
- Consolidate identity sources where possible, and put conditional access and MFA in front of everything that touches sensitive data, starting with admin and remote access.
- Vault and rotate privileged and service account credentials before touching network architecture; this is the highest risk reduction per dollar spent.
- Map and formally review every third party connection into the environment, cutting standing access that is not actively used.
- Segment around the core banking platform in stages, using logging and monitoring to validate each change before the next one, rather than one large cutover.
- Only then extend policy enforcement into the network layer with segmentation gateways, once identity and privilege are already under control.
Vendors will happily sell steps four and five first because that is where the licence revenue sits. Steps one and two cost less and are what auditors ask about first. A fuller phased zero trust network access rollout covers how to scope this by phase, and the common zero trust questions page covers the terminology gaps that usually surface in vendor conversations.
The tradeoff nobody puts in the vendor deck
Zero trust adds friction. Continuous verification means more authentication prompts, more device compliance checks, and more support tickets from users whose devices fail posture checks for reasons that have nothing to do with security, an expired certificate or an unmanaged personal laptop used for email. Budgeting for that support load, and for a phased rollout that does not break existing transaction processing, matters as much as the security architecture itself. A programme that ignores user experience gets quietly rolled back once complaints reach the board, which sets the next attempt back further than doing nothing would have.
Where to start this quarter
If nothing else changes this year, fix these two things: enforce MFA and conditional access on every privileged and remote access path, and get service account credentials into a vault with rotation. Both are achievable without touching the core network, both close the access paths attackers use most, and both give an assessor something concrete to look at. Everything else in a zero trust programme builds on that foundation, not the other way round.
