Zero Trust is a security approach that assumes no user, device, or network location is trusted by default. Every access request is authenticated, authorized, and evaluated against policy before a session to a resource is allowed.
You will also see it called Zero Trust Architecture (ZTA), a Zero Trust model, or "never trust, always verify." In practice it shifts defenses away from a hard network perimeter and toward identity, device posture, and per-request decisions. The idea is not that you trust nothing forever. It is that trust is earned continuously for each session, based on signals you can check.
In simple terms, Zero Trust answers:
- Who (or what) is asking for this resource right now?
- Is the device and context healthy enough to allow it?
- What is the least access we can grant for this session, and can we prove the decision later?
This page defines the term. For a practical crosswalk of Zero Trust practices to SOC 2 evidence artifacts, see Mapping Zero Trust Controls to SOC 2 Evidence. Related glossary pages include access control, logical access, least privilege, and multi-factor authentication.
Why Zero Trust Matters
Traditional perimeter models assumed that traffic inside the corporate network was mostly trustworthy. That assumption weakens when people work remotely, apps live in many clouds, and contractors reach production from unmanaged devices.
Zero Trust matters because:
- Stolen credentials remain a common path into identity providers, admin consoles, and source control.
- Network location alone is a weak signal when VPN access or a compromised laptop can look "inside."
- Least privilege and per-session decisions shrink blast radius when an account is misused.
- Continuous checks (reauthentication, device posture, risk signals) catch change that a one-time login misses.
- Auditors and customers ask how you authenticate and authorize access to systems in scope, not whether you use a marketing label.
Calling a program "Zero Trust" does not prove controls operated. Dated policy configuration, access logs, and joiner-mover-leaver records still matter. See What Is SOC 2 Evidence?.
How Zero Trust Works
NIST SP 800-207, Zero Trust Architecture, describes zero trust as an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources. Authentication and authorization happen before a session to a resource is established. No account or device is trusted only because of its network location or who owns it.
NIST lists seven tenets. In short:
- All data sources and computing services are treated as resources.
- All communication is secured regardless of network location.
- Access to each resource is granted per session, with least privilege.
- Access is decided by dynamic policy that uses identity, device state, and other attributes.
- The organization monitors and measures the integrity and security posture of owned and associated assets.
- Authentication and authorization are dynamic and strictly enforced before access is allowed.
- The organization collects information about assets, network traffic, and access requests and uses it to improve security posture.
NIST also notes these tenets are an ideal goal, and not every tenet may be fully implemented in its purest form for a given strategy. Most companies run some Zero Trust practices, not all of them. Evidence should describe what you actually do.
Decision and enforcement
A common architecture pattern separates:
- Policy engine: decides whether to grant access based on identity, device, and other signals.
- Policy administrator: carries out the decision by setting up or closing the connection path.
- Policy enforcement point: enables, monitors, and ends the connection.
In many SaaS-first companies, the identity provider's sign-in and conditional access policies play a large part of the decision role, and an access proxy, gateway, or application setting enforces it.
Common building blocks
| Building block | What it does | Related AuditFlo pages |
|---|---|---|
| Strong identity and MFA | Verify who is asking with more than a password | Multi-factor authentication |
| Device posture | Check encryption, OS, endpoint agent before access | Logical access and monitoring themes |
| Least privilege / JIT | Grant only the access needed for the session or task | Least privilege, RBAC |
| Segmentation | Limit lateral movement between systems and networks | Access control |
| Continuous verification | Re-check risk, session lifetime, and anomalies | Monitoring |
| Encrypted communication | Protect data in transit regardless of network | Encryption |
Zero Trust vs Related Terms
| Term | What it means | How it relates to Zero Trust |
|---|---|---|
| Perimeter / castles-and-moat | Trust based largely on being inside the network | Zero Trust reduces reliance on location alone |
| VPN | Encrypted remote path into a network | Can coexist with Zero Trust, but VPN alone is not Zero Trust |
| SSO | Centralize login across apps via an identity provider | Often the hub for Zero Trust decisions; SSO without MFA is incomplete |
| MFA | Two or more distinct authentication factors | A common Zero Trust practice, not the whole model |
| Least privilege | Grant only the access needed for a task | A core Zero Trust tenet for each session |
| RBAC | Assign permissions through defined roles | A way to implement least privilege at scale |
| Continuous monitoring | Detect anomalies and control drift over time | Feeds continuous verification and improvement |
The short version: Zero Trust is an architecture mindset. MFA, least privilege, segmentation, and monitoring are practices that often implement it.
What Zero Trust Looks Like Day to Day
Concrete examples (labeled as common practice, not requirements):
- A workforce user signs into the identity provider with MFA. Conditional access allows the CRM only from a managed, encrypted laptop.
- An engineer requests temporary production admin access. The request is approved, elevated for a short window, then expires automatically.
- A contractor reaches a single application through an identity-aware proxy, not a flat VPN into the whole network.
- A service account authenticates with a short-lived credential and can call only the APIs listed in its role.
- Risk signals (impossible travel, new device) force reauthentication or block the session.
Weak examples that look modern but fail in practice:
- "Zero Trust" in a slide deck while admin consoles remain password-only.
- MFA for employees but not for contractors with production access.
- Broad Engineer-Admin roles that never expire.
- Device posture checks that are advisory only and never block noncompliant devices.
- No records of who approved a privileged elevation or when it ended.
Evidence Themes Auditors May Expect
Illustrative artifacts. Not a mandatory universal checklist:
| Activity | Example evidence to retain |
|---|---|
| Authentication policy | Dated identity provider MFA and conditional access exports |
| Device posture | Enrollment coverage, posture rules, blocked sign-in examples |
| Privileged access | Just-in-time requests with approval, start/end times |
| Network / segmentation | Security group or firewall rule exports with change tickets |
| Access lifecycle | Joiner and leaver tickets matching identity provider events |
| Monitoring | Alert rules and triage records for anomalous access |
| Policy change | Tickets or pull requests for access policy updates |
Prefer systems of record over reconstructed screenshots. For how these practices map to SOC 2 criteria themes and sample artifacts, use Mapping Zero Trust Controls to SOC 2 Evidence. For periodic entitlement checks, see How to Run a SOC 2 User Access Review and What Is a User Access Review?.
Framework Notes
NIST SP 800-207
NIST SP 800-207 is the primary public reference for Zero Trust Architecture. It defines tenets, logical components (policy engine, policy administrator, policy enforcement point), and deployment models. It is guidance, not a certification. Claiming "we follow NIST Zero Trust" still requires showing which practices you implemented and how you evidence them.
Related NIST access and account themes also appear in NIST SP 800-53 Rev. 5, including account management and least privilege style controls. Map your implementation carefully; do not invent control ID claims you have not verified.
SOC 2
SOC 2 does not require Zero Trust by name as a mandatory architecture. The AICPA 2017 Trust Services Criteria with revised points of focus (2022) describe outcomes for logical access, authentication, authorization, and monitoring. The 2022 revision of the points of focus mentions zero trust architectures as one technique alongside network segmentation under CC6.1 themes. Points of focus are illustrative, not a checklist.
Criteria that Zero Trust practices commonly support include CC6.1 (logical access security), CC6.2 and CC6.3 (user registration, authorization, modification, and removal with least privilege and segregation of duties themes), CC6.6 (threats outside system boundaries), CC6.7 (transmission and movement of information), CC6.8 (unauthorized or malicious software), and CC7.1 / CC7.2 (detection and monitoring). Your auditor tests the controls you describe, not the brand of architecture. See What Is SOC 2?, What Are the Trust Services Criteria?, and SOC 2 Trust Services Criteria Explained.
In a SOC 2 Type 2 audit, expect samples across the period: MFA policy history, privileged elevations, leaver deprovisioning, and monitoring responses. See SOC 2 Type 1 vs Type 2.
ISO 27001
ISO 27001 programs address related themes in access control and network security. Teams running SOC 2 and ISO 27001 often reuse one access model through control mapping. See also Mapping Controls Across SOC 2 and ISO 27001.
Common Failures
- Treating Zero Trust as a product purchase rather than operating practices with evidence
- MFA optional at the identity provider while marketing claims Zero Trust
- Standing privileged access with no expiry or approval trail
- Device posture that never blocks noncompliant access
- Flat network access after a single successful login
- Service accounts and break-glass users excluded from the model
- No link between HR termination and identity provider disablement
- Policy exports from kickoff with no later dated history for the Type 2 period
- Over-claiming ("we are Zero Trust, so all of CC6 is covered") without a criterion-level crosswalk
These gaps show up as diligence friction and as weak samples during fieldwork. See exception management and remediation when you find them.
Continuous Compliance Bridge
Zero Trust posture decays when people change devices, admins tweak conditional access, and exceptions linger. Continuous compliance means policy exports, enrollment coverage, elevation logs, and leaver evidence accumulate all year so the audit period story is boring. See also AuditFlo's continuous compliance resource and how to prepare for a SOC 2 audit.
How AuditFlo Helps
AuditFlo (auditflo.co) helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.
For Zero Trust related controls, that can mean dated history for access requests, approvals, and related tickets so you can show who was granted what and when without a last-minute screenshot hunt. Your identity provider, device management, and network tools remain where access decisions happen. AuditFlo does not implement Zero Trust architecture for you, does not configure MFA or conditional access, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.
To see the workflow for your stack, request a demo.
Key Takeaway
Zero Trust is a security approach that assumes no user, device, or network location is trusted by default, and that every access request is authenticated, authorized, and evaluated before a session is allowed. NIST SP 800-207 describes the tenets and architecture components. SOC 2 does not require Zero Trust by name, but Zero Trust practices often produce strong evidence for logical access and monitoring criteria when you keep dated records. For the evidence crosswalk, see Mapping Zero Trust Controls to SOC 2 Evidence.