What Zero Trust actually means
Zero Trust is the principle that network location no longer determines trust. Being on “the corporate network” is not evidence you’re authorised. Every request — from anyone, to any resource — must be authenticated, authorised, and continuously verified.
The canonical definition is NIST SP 800-207: “Zero trust is a collection of concepts and ideas designed to minimise uncertainty in enforcing accurate, least-privilege per-request access decisions in information systems and services in the face of a network viewed as compromised.”
That last phrase matters: in the face of a network viewed as compromised. Zero Trust assumes attackers are already inside. The job is to limit what they can reach.
Why the perimeter model fails SaaS
The traditional model: a corporate firewall, employees inside (trusted), attackers outside (untrusted), VPN to bring remote workers “inside.” This model assumes:
- There is a definable network boundary.
- Most users are inside it.
- Resources sit behind it.
- Once authenticated at the perimeter, you’re trusted.
None of that is true for modern SaaS:
- Resources are in AWS, GCP, Snowflake, GitHub, Datadog, Slack — not behind your firewall.
- Users work from coffee shops, co-working spaces, and home networks the company doesn’t control.
- Vendors and contractors need access to specific resources, not the whole network.
- A compromised endpoint, phished credential, or supply-chain attack puts the attacker “inside” trivially.
VPN doesn’t solve this; it just gives the attacker network access too once they have credentials.
The six principles of Zero Trust
| Principle | What it means | How to implement |
|---|---|---|
| Verify identity | Every request authenticated to a known identity | IdP (Okta, Entra ID, Google Workspace) + SSO + MFA |
| Validate device posture | Device meets security baseline (encrypted, patched, MDM, EDR) | MDM compliance check + conditional access policy |
| Least-privilege access | User/service gets only the access needed for the task | RBAC + JIT elevation + scoped tokens |
| Assume breach | Design as if an attacker is already in | Micro-segmentation, encryption everywhere, logging |
| Micro-segmentation | Network access scoped to specific resources, not subnets | Software-defined perimeter, per-app access controls |
| Continuous verification | Trust re-evaluated mid-session, not just at login | Conditional access reassessment, short token TTLs |
ZTNA vs VPN: a practical comparison
| Capability | Traditional VPN | ZTNA |
|---|---|---|
| Architecture | Encrypted tunnel into network | Per-resource brokered access |
| Trust model | Authenticated user trusted on network | Continuous verification per request |
| User experience | VPN client, slow connections, disconnects | Browser-based or lightweight agent |
| Lateral movement risk | High once on network | Low — access limited to authorised resources |
| Implementation cost | Hardware/software + ongoing maintenance | Cloud-native SaaS subscription |
Note: ZTNA is not a replacement for all VPN use cases. If you have legacy on-prem systems that don’t support modern auth, you still need VPN for those. Most SaaS-native companies don’t.
Zero Trust for cloud-native SaaS
Most SaaS companies don’t need to buy a “Zero Trust platform.” The building blocks already exist in the tools you use:
- IdP as the perimeter: Okta, Google Workspace, Entra ID, JumpCloud. SSO to everything. SCIM provisioning where supported.
- Conditional access policies: require MFA, device compliance, trusted location for high-risk apps. Block legacy authentication protocols.
- ZTNA for internal admin tools: Cloudflare Access, Tailscale, AWS Verified Access, Google BeyondCorp Enterprise. Replaces “VPN to bastion” for most admin access.
- Service-to-service authentication: mTLS via service mesh (Istio, Linkerd) or signed JWTs. AWS IAM roles, GCP service accounts, Workload Identity Federation.
- Kubernetes NetworkPolicy: default-deny pod-to-pod traffic; explicit allow per service. Most clusters don’t enable this and pay the price during an audit or incident.
- SaaS Session Manager: AWS Systems Manager Session Manager, GCP IAP TCP forwarding. No open SSH/RDP ports; access logged per session.
Identity-centric access — the practical foundation
Identity is the new perimeter. That makes IdP hygiene the highest-leverage security investment for a Zero Trust posture:
- One identity per person, federated to all systems via SSO.
- MFA enforced at the IdP — phishing-resistant (passkeys / hardware keys) for admins.
- Conditional access policies that consider device, location, and risk score.
- JIT (just-in-time) privilege elevation rather than persistent admin roles.
- Quarterly access reviews — every user, every role, every system.
- Automated deprovisioning on departure — within minutes, not days.
If your IdP is solid, most of the rest of Zero Trust falls into place.
A practical Zero Trust maturity model
| Level | What it looks like | 6-month next steps |
|---|---|---|
| Traditional | Network-perimeter trust; VPN for remote; flat internal network; passwords + occasional MFA | Roll out SSO + MFA everywhere; document admin access patterns |
| Initial | SSO + MFA everywhere; identity-aware access for some apps; basic device posture | Deploy ZTNA for admin tools; require MDM enrollment; conditional access policies |
| Advanced | ZTNA for internal apps; device posture required; micro-segmentation in cloud; service mesh mTLS; quarterly access reviews | Continuous verification; phishing-resistant MFA for admins; risk-based conditional access |
| Optimal | Continuous verification per request; risk-adaptive access; phishing-resistant MFA; full micro-segmentation; identity for service-to-service | Maintenance, optimisation, and red-team exercise |
You do not need to be “Optimal” to claim a Zero Trust posture. “Advanced” is sufficient for SOC 2, ISO 27001, and most enterprise procurement requirements. Demonstrating a documented next step is what matters.
How Zero Trust satisfies compliance
| Framework | Requirement | How Zero Trust satisfies it |
|---|---|---|
| SOC 2 | CC6.6 — Logical Access from External Boundaries | ZTNA + MFA + device posture = strong evidence |
| SOC 2 | CC6.7 — Transmission of Confidential Information | mTLS, TLS 1.2+ everywhere, encrypted tunnels |
| ISO 27001 | A.8.20–A.8.22 — Network Security and Segregation | Micro-segmentation, identity-based access |
| NIS2 | Art. 21(2)(b) and (j) — Network security + MFA / continuous auth | Continuous verification + phishing-resistant MFA |
| NIST SP 800-207 | Zero Trust Architecture reference | The standard you’re aligning to |
| CISA Zero Trust Maturity Model | Five pillars: Identity, Devices, Networks, Applications/Workloads, Data | Maturity assessment maps directly |
Common Zero Trust mistakes
- Treating ZTNA as “just VPN replacement.” If you deploy ZTNA but still grant broad network access once authenticated, you’ve missed the point. Per-resource scoping is the value.
- No device posture check. A passkey on a malware-infected laptop still gets you in. Device compliance must be part of the access decision.
- Ignoring east-west traffic. Zero Trust at the perimeter is meaningless if your services trust each other implicitly. mTLS or signed tokens for service-to-service.
- No identity for service-to-service. Cloud IAM roles and Workload Identity Federation are the modern answer. Long-lived service account keys are the old way.
- Buying “Zero Trust” as a product without changing posture. The vendor sale doesn’t make you Zero Trust. Documented principles, implemented controls, and continuous verification do.
- Ignoring the data pillar. CISA’s maturity model includes data. Encryption, classification, DLP, and access logging matter.
Where to start: the 90-day plan
- Week 1–2: Inventory identities, devices, and apps. Where is access granted today? What’s the IdP coverage?
- Week 3–4: Enforce SSO everywhere it’s supported. Deprecate password-only access.
- Week 5–6: MFA everywhere; phishing-resistant MFA for admins.
- Week 7–8: MDM enrollment requirement; conditional access requiring compliant device.
- Week 9–10: Deploy ZTNA for internal admin tools (replace SSH bastion with Session Manager / Cloudflare Access).
- Week 11–12: First access review; document Zero Trust posture and roadmap; present to board.
Build your Zero Trust-aligned policy stack: Network Security Policy Generator, Remote Work Security Policy, Access Control Policy, Password & Authentication Policy.
Related reading: Network Security Policy Guide, Access Control Policy Guide, Remote Work Security Policy Guide, Password & Authentication Policy Guide.
⚠️ This guide is for informational purposes only and does not constitute legal or security advice. Zero Trust implementation depends on your specific environment, risk profile, and regulatory scope. Consult a qualified security professional for guidance tailored to your organisation.