Zero trust is a security model in which no user, device or network location is trusted by default, and every access request is verified explicitly against identity, device health and context. It is implemented in phases rather than purchased — identity first, then device, network, application and data — because each phase depends on the controls established before it.
Key Takeaways
- Zero trust is an architecture and a sequence of decisions, not a product you can buy.
- Identity is the first phase, because every later control depends on knowing who is asking.
- Attempting all pillars at once is the most common cause of stalled programmes.
- Each phase should deliver standalone security value, not only progress toward an end state.
- Legacy applications that cannot support modern authentication need a planned exception route.
What zero trust actually means
The traditional model trusted the internal network: get inside the perimeter and you were broadly trusted. That assumption broke with cloud adoption, remote work and supply chain access.
Zero trust replaces it with three principles. Verify explicitly — authenticate and authorise on every request using identity, device health, location and behaviour. Use least privilege — grant minimum access, just in time, for just enough duration. Assume breach — design so a compromise in one place does not grant access everywhere.
Nothing here is a product. Vendors sell components that support the model, but the architecture, sequencing and policy decisions are yours. That is why two organisations with identical tooling can end up with very different security outcomes.
Phase 1 — Identity
Identity comes first because every later control depends on knowing who is making a request. Attempting device or network controls before identity is sound produces policies that cannot be enforced.
- Consolidate identity providers — multiple directories make consistent policy impossible.
- Deploy phishing-resistant MFA across all users, starting with privileged accounts and remote access.
- Implement conditional access based on user risk, device state and location.
- Eliminate standing privileged access in favour of just-in-time elevation. See privileged access management.
- Clean up identity hygiene: orphaned accounts, stale access, over-privileged service accounts.
For Microsoft estates this is largely Entra ID work — conditional access, Privileged Identity Management and identity protection. This phase alone usually delivers the largest single risk reduction in the entire programme.
Phase 2 — Device
Once you know who is asking, the next question is what they are asking from. An authenticated user on a compromised or unmanaged device is still a risk.
- Establish a device inventory covering corporate, BYOD and contractor endpoints.
- Enforce compliance policies — encryption, patch level, endpoint protection present and healthy.
- Feed device compliance state into conditional access so unhealthy devices lose access automatically.
- Extend coverage to mobile through Intune or equivalent MDM.
- Decide the contractor and unmanaged device position explicitly, rather than leaving it as an unexamined exception.
The hard conversation in this phase is usually BYOD. Policy needs to be decided at executive level, because the security position and the employee experience genuinely conflict.
Phases 3–5 — Network, application and data
Network. Replace broad VPN access with per-application access, segment internal networks, and remove the implicit trust that comes with being on the corporate LAN. Our network architecture and segmentation team treats this as the phase where lateral movement is finally constrained.
Application. Bring applications behind the identity provider with modern authentication, apply per-application access policy, and handle the legacy systems that cannot support it through brokered access or a documented exception with compensating controls.
Data. Classify what matters, apply labelling and protection that follows the data, and control sharing. For Microsoft estates this is Purview territory. This phase is last not because it matters least, but because it depends on everything before it.
Sequencing mistakes to avoid
- Starting with network. Buying a ZTNA product before identity is sound produces a VPN replacement rather than zero trust.
- Running all pillars in parallel. Resource contention, contradictory designs and change saturation — the classic cause of a programme that stalls at sixty percent.
- No legacy exception route. Every enterprise has applications that cannot do modern auth. Plan the compensating controls rather than letting them quietly break the model.
- Ignoring change capacity. Conditional access and device compliance are visible to every employee. Push too fast and you generate resistance and workarounds.
- No measurement. Define what improves at each phase — MFA coverage, standing privilege eliminated, applications behind modern auth — or you cannot show progress.
Most UAE enterprises we work with run this as a twelve to twenty-four month programme in quarterly increments. Our programme management practice sequences it by dependency rather than by funding order, which is usually the difference between posture improving and eight disconnected deployments.
Frequently Asked Questions
What is zero trust security?
A model in which no user, device or network location is trusted by default. Every access request is verified explicitly against identity, device health and context; access is granted at least privilege for limited duration; and systems are designed on the assumption that a breach will occur somewhere.
Can you buy zero trust as a product?
No. Vendors sell components that support the model — identity platforms, device management, network access brokers, data protection — but the architecture, policy and sequencing decisions determine whether you achieve zero trust. Identical tooling in two organisations can produce very different outcomes.
Where should zero trust implementation start?
Identity. Consolidate identity providers, deploy phishing-resistant MFA, implement conditional access and eliminate standing privileged access. Every subsequent control depends on reliably knowing who is making a request, and this phase delivers the largest single risk reduction.
How long does a zero trust programme take?
For a mid-size to large enterprise, typically twelve to twenty-four months delivered in quarterly increments. Programmes planned as a single multi-year push tend to be overtaken by technology or organisational change before completing.
What about legacy applications that cannot support modern authentication?
Plan for them explicitly. Options include brokering access through an application proxy, isolating them in a tightly segmented zone with additional monitoring, or accepting a documented exception with compensating controls and a review date. What fails is leaving them unaddressed.
Does zero trust help with UAE regulatory compliance?
It supports it substantially. NESA, DESC ISR, ADHICS and CBUAE expectations all emphasise access control, least privilege, segmentation and monitoring — the core of zero trust. The architecture does not discharge a regulatory obligation by itself, but it produces much of the control evidence those frameworks require.
Talk to a UAE Cybersecurity Team
Cybersecurity MEA designs and delivers zero trust programmes for UAE enterprises — architecture and roadmap, Microsoft zero trust implementation, and programme management that sequences the work by dependency. Talk to us about where your organisation genuinely sits today.