What is zero trust security? Never trust, always verify

The castle and moat: the model zero trust replaces

Traditional network security was built like a castle: a hardened perimeter — firewalls, VPN gateways — separating a hostile outside from a trusted inside. Getting past the moat was hard, but once inside, you were trusted: internal systems accepted connections from other internal systems largely because of where they were. The perimeter was the security model.

Three shifts broke it. Cloud computing moved data and workloads outside the castle walls, so the perimeter no longer enclosed the things worth protecting. Remote work and mobile devices moved the people outside too — a workforce connecting from homes and cafés makes “inside the network” a fiction maintained by VPNs. And attackers learned that the moat only has to fail once: phish one employee or steal one credential, and the castle’s own logic — trust everything inside — becomes the attacker’s superpower, letting them move laterally from an unimportant foothold to the crown jewels. Zero trust starts from the admission that there is no longer a meaningful inside.

The three core principles

Zero trust is usually summarised in three principles — Microsoft’s guidance states them in almost exactly this form, and other vendors’ framings map onto them:

• Verify explicitly — authenticate and authorise every request based on all available signals: who the user is, what device they are on and its health, where they are connecting from, and what they are asking for. Never infer trust from network location.
• Use least-privilege access — grant the minimum access needed, for the shortest time needed. Prefer just-in-time and just-enough access over standing permissions, so any single compromised identity can do as little damage as possible.
• Assume breach — design as if an attacker is already inside, because one day one will be. Segment systems so compromise cannot spread laterally, encrypt traffic internally as well as externally, and monitor continuously so intrusions are detected rather than discovered.

How zero trust is implemented, conceptually

No single control delivers zero trust; it emerges from several working together. Strong identity is the anchor: every user and service has a verified identity, protected by multi-factor authentication, because if requests are judged on who is asking, knowing who is asking must be reliable. Device posture comes next — access decisions can consider whether the connecting device is known, patched and healthy, not just who is holding it. Micro-segmentation replaces the single moat with many small ones: the network is divided so each workload only accepts the specific connections it genuinely needs, and an attacker who compromises one segment finds walls, not open corridors. Cloud platforms make this unusually practical — security groups, network policies and identity-based service permissions are segmentation tools that exist by default.

The remaining ingredients are least privilege — applied through the IAM machinery of roles, temporary credentials and tightly scoped policies — and continuous verification: access is re-evaluated rather than granted once and remembered forever, sessions expire, and unusual behaviour can trigger a fresh challenge. Notice how much of this list is identity machinery. That is the quiet headline of zero trust: when location no longer confers trust, identity becomes the perimeter, and the quality of your identity and access management — covered in our IAM explainer — sets the ceiling on everything else.

Why the cloud makes zero trust necessary — and achievable

The cloud forced the issue: once your infrastructure runs in someone else’s data centres and is reached over the internet, pretending a network boundary defines trust is untenable. But the cloud also supplies the tools the model needs. Cloud platforms are identity-first by construction — every API call is authenticated and authorised individually, exactly the per-request verification zero trust prescribes. Fine-grained network segmentation is configuration rather than hardware. Managed identity services handle MFA, conditional access and short-lived credentials. Comprehensive logging makes continuous monitoring feasible.

In AWS terms, the raw materials are IAM roles and policies, security groups and VPC segmentation, and the platform’s pervasive per-call authentication. In Azure terms, Microsoft Entra ID (formerly Azure Active Directory) provides the identity core, with conditional access evaluating each sign-in against user, device and location signals, and Microsoft publishes an explicit zero-trust architecture built around it. On both platforms, a well-configured cloud estate is closer to zero trust out of the box than most traditional networks ever were — the model formalises what good cloud practice already does.

A journey, not a product

An honest caution: “zero trust” appears on a great deal of vendor marketing, attached to products that promise to deliver it in one purchase. No product can. Zero trust is an architecture and a set of principles applied across identity, devices, networks, applications and data — you adopt it incrementally, by strengthening identity, enforcing MFA, shrinking standing privileges, segmenting networks and expanding monitoring, usually over years. A tool can help with any one of those; the model is the sum of them.

The practical corollary is that zero trust is not all-or-nothing, and partial adoption is still valuable. Requiring MFA everywhere, replacing long-lived credentials with roles, and tightening network rules each remove real attack paths on their own. Treat vendor claims accordingly: the question is never “does this buy us zero trust?” but “which specific principle does this help us enforce?”.

Zero trust in certification study

Zero trust rewards study because it is a lens as much as a topic: once you hold the three principles, dozens of individually taught controls — MFA, least-privilege policies, security groups, private connectivity, encryption in transit — snap into a single picture. On the AWS side, the Security – Specialty (SCS-C03) is where the model is most at home: identity-centric controls, segmentation and the assume-breach mindset run through its domains, and the Solutions Architect – Associate (SAA-C03) expects secure-by-design architectures that embody the same instincts. On the Microsoft side, the Azure Administrator Associate (AZ-104) covers the building blocks — Entra ID, conditional access concepts, network security groups and RBAC — and Microsoft frames its whole security story in zero-trust terms. A dependable habit: whenever an exam scenario offers an answer that grants trust based on network location alone, be suspicious of it — the modern, and usually correct, answer verifies identity explicitly.