What is zero trust security? A plain-English guide
Zero trust means your network stops assuming anyone inside it is safe, and checks every user and device every single time.
Zero trust is a security model where no user, device, or system is automatically trusted, even if it sits inside your corporate network. Every access request gets verified before it goes through. The phrase was coined by Forrester analyst John Kindervag around 2010 and has since been codified by NIST into a full architectural standard.
Why does the old "castle and moat" approach fail?
The traditional model trusts anything already inside the network perimeter, the way a castle trusts anyone who got past the drawbridge. The failure mode here is that once an attacker gets one foothold, they can move freely to every other system inside.
In practice, modern work broke the perimeter long before attackers did. Employees on AWS, contractors on personal laptops, and SaaS apps like Salesforce all sit "outside" the old walls by definition. NIST SP 800-207 describes this as the death of the implicit trust zone, and it is the core reason zero trust exists.
What does zero trust actually check?
Every request gets evaluated against at least four signals: who the user is, what device they are on, what they are asking to access, and whether that request looks normal for them. All four have to pass before access is granted.
Identity gets confirmed through multi-factor authentication (MFA), meaning you prove who you are with two or more methods, such as a password plus a code from your phone. Device health gets checked through endpoint management tools. Azure Active Directory, now called Microsoft Entra ID, and Google Cloud's BeyondCorp Enterprise both run these checks continuously, not just at login.
What is "least privilege" and why does it matter here?
Least privilege means a user or system gets access only to the specific resources they need for their job, nothing more. It is one of the three core principles NIST SP 800-207 defines for zero trust, alongside verifying explicitly and assuming breach.
Assuming breach is the uncomfortable one. It means you design your systems as if an attacker is already inside. That mindset pushes teams to segment networks (break them into small isolated zones so one compromised machine cannot reach everything else) and to log every action so you can trace what happened. AWS calls this approach micro-segmentation inside a VPC, or Virtual Private Cloud, using security groups to restrict which services can talk to which.
How is zero trust different from a VPN?
A VPN (Virtual Private Network) encrypts your traffic and drops you inside the corporate network, then trusts you like a local employee. Zero trust never drops you inside anything. It evaluates each individual request to each individual resource separately.
One thing the post-mortem will say after a VPN-related breach is that the attacker grabbed one set of credentials and walked everywhere. Zero trust limits that blast radius because each hop requires a fresh check.
| Approach | Grants access to | Re-checks during session | Limits lateral movement |
|---|---|---|---|
| Traditional VPN | Entire internal network | No | No |
| Zero trust (e.g. BeyondCorp) | Single resource per request | Yes | Yes |
| Zero trust with MFA + device health | Single resource per request | Yes, continuously | Yes, strongly |
| Perimeter firewall alone | Everything inside the zone | No | No |
What does a real zero trust rollout look like?
Start with identity. Get MFA turned on for every account, especially privileged admin accounts. CISA's Zero Trust Maturity Model breaks the journey into five pillars: identity, devices, networks, applications, and data, and rates your maturity as traditional, initial, advanced, or optimal.
Cloud-native teams often begin with an identity provider like Microsoft Entra ID or Google Cloud Identity feeding into a policy engine that decides yes or no on each request. GCP's Access Context Manager lets you write rules like "only allow access to this Cloud Storage bucket if the request comes from a managed device in an approved country." That is zero trust in a concrete, clickable form.
The honest answer on timeline: a full rollout across a mid-sized organization takes years, not months. Teams that try to do everything at once usually stall. Pick identity first, get device management in place second, then segment your most sensitive data.
Common questions
Does zero trust mean you never trust anyone?
Not exactly. It means trust is never assumed in advance and is always based on verified signals. A user who passes MFA, has a healthy managed device, and is requesting something appropriate for their role gets access quickly and with little friction.
Is zero trust only for large enterprises?
No. Small businesses using Microsoft 365 can enable Conditional Access policies in Microsoft Entra ID to block logins from unrecognized devices, which is a basic zero trust control available on business-tier plans.
Does moving to the cloud automatically give you zero trust?
No. Cloud services like AWS or Azure extend your attack surface if you do not configure them deliberately. Misconfigured S3 buckets and overly permissive IAM roles (Identity and Access Management, the system controlling who can do what in AWS) are the opposite of zero trust thinking.
