Zero Trust in 2026: Identity Is the New Perimeter

TL;DR: Quick Takeaways

•NIST SP 800-207 defines zero trust architecture as a security model that eliminates implicit trust and enforces continuous verification — your network perimeter no longer protects you.
•84% of organizations cite cross-network and hybrid-environment risks as their primary security concern, yet 53% still manually transfer sensitive data between systems.
•Zero trust rests on five pillars: identity, device, network, application, and data — with identity serving as the primary control plane in 2026.
•Zero trust controls map directly to SOC 2 CC6, ISO 27001 Annex A, NIST CSF PR.AC, and CMMC Level 2 and Level 3 access control domains.
•LowerPlane tracks zero trust control implementation status across all five major compliance frameworks from a single dashboard.

The firewall is dead. Not metaphorically — literally obsolete as a primary security boundary. In 2026, the users accessing your systems are remote, your applications live in multiple clouds, your devices span corporate and personal hardware, and your data moves constantly across environments your network perimeter was never designed to protect. The organizations that understood this early adopted zero trust architecture. The rest are discovering the hard way why identity is now the only perimeter that matters.

Zero trust is not a product you buy or a checkbox you tick. It is a security philosophy, codified in NIST Special Publication 800-207, that replaces the old "trust but verify" model with "never trust, always verify." Every access request — regardless of whether it originates inside or outside your network — is treated as potentially hostile until proven otherwise. Verification is continuous, context-aware, and identity-anchored.

This guide covers everything security and compliance teams need to know about zero trust in 2026: the NIST SP 800-207 standard that defines it, the five architectural pillars that structure implementation, the statistical reality of how unprepared most organizations remain, a practical implementation roadmap, and — critically for compliance professionals — how zero trust controls map to SOC 2, ISO 27001, NIST CSF, and CMMC requirements.

What NIST SP 800-207 Actually Says About Zero Trust

NIST Special Publication 800-207, "Zero Trust Architecture," is the authoritative federal standard defining what zero trust means and how it should be implemented. Published in 2020 and substantively referenced in all subsequent federal cybersecurity mandates — including the Biden and Biden-to-Trump transition executive orders on cybersecurity — it provides the definitional and architectural foundation that compliance frameworks now build upon.

The publication defines zero trust as "an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources." A zero trust architecture assumes that the network environment is always hostile — that breaches will occur, that attackers may already be inside the network, and that every access decision must therefore be made explicitly based on all available signals rather than network location.

The Seven Tenets of Zero Trust

NIST SP 800-207 articulates seven foundational tenets that a genuine zero trust architecture must embody. These are not aspirational goals — they are the measurable characteristics against which implementation is evaluated:

All data sources and computing services are resources

Every network-connected device — including personal devices accessing corporate resources — is treated as a resource to be verified, not a trusted endpoint by virtue of its physical location.

All communication is secured regardless of network location

Traffic within the corporate network receives no implicit trust advantage over external traffic. All sessions must be authenticated and encrypted.

Access to individual resources is granted on a per-session basis

Trust is evaluated anew for each resource request. Gaining access to one resource does not confer access to adjacent systems or data.

Access to resources is determined by dynamic policy

Access decisions incorporate user identity, device health, behavioral signals, and environmental context — not just static role assignments.

The enterprise monitors and measures the integrity of all owned and associated assets

Continuous device health monitoring ensures that devices meeting access requirements at time of authentication remain compliant throughout the session.

All resource authentication and authorization is dynamic and strictly enforced

Authentication is not a one-time event at login. Continuous re-evaluation triggers step-up authentication when risk signals change during a session.

The enterprise collects as much information as possible and uses it to improve security posture

Zero trust generates rich telemetry across identity, device, network, and application layers — this data fuels continuous improvement and threat detection.

The Policy Decision Point and Policy Enforcement Point Model

NIST SP 800-207 describes zero trust architecture using a logical component model centered on the Policy Decision Point (PDP) and Policy Enforcement Point (PEP). The PDP evaluates access requests against enterprise policy — considering user identity, device posture, requested resource sensitivity, and behavioral context — and issues access decisions. The PEP acts as the gatekeeper between subjects and enterprise resources, allowing or denying access based on those decisions.

In practice, modern identity providers, privileged access management platforms, and cloud-native security services implement these logical components. The architectural clarity NIST provides is valuable precisely because it is technology-agnostic: organizations can map their existing tooling to the NIST model and identify gaps without being vendor-constrained.

The State of Zero Trust in 2026: The Numbers Are Sobering

Despite years of industry conversation about zero trust, adoption remains uneven and implementation depth is shallow at most organizations. The gap between what security teams know they should do and what they have actually implemented is where breaches live.

84%

of organizations

cite cross-network and hybrid-environment risks as their primary cybersecurity concern, yet most have not implemented continuous identity verification across all access paths.

53%

of organizations

still manually transfer sensitive data between systems — a practice that creates unmonitored data movement pathways that zero trust data controls are specifically designed to eliminate.

61%

of breaches in 2025

involved compromised credentials — the exact attack vector that identity-first zero trust architecture is purpose-built to detect and contain through continuous verification and anomalous access signals.

Why the Network Perimeter Failed

The traditional network perimeter model assumed a clear inside and outside. Corporate resources lived on-premises behind firewalls. Employees worked from corporate offices on corporate devices. Partners accessed systems through tightly controlled VPN tunnels. This model had weaknesses even when it was current best practice. In 2026, it is entirely disconnected from operational reality.

SaaS adoption means that your most sensitive business applications — CRM, HR systems, financial platforms, collaboration tools — live outside any network perimeter you control. Multi-cloud deployments distribute workloads across AWS, Azure, and GCP environments with different network boundaries that your on-premises perimeter never touches. Remote and hybrid work means that users are accessing systems from home networks, coffee shop WiFi, and hotel networks that you have no visibility into or control over.

The attackers understood this shift before many defenders did. Lateral movement — where an attacker who gains initial access to one system traverses the network to reach more valuable targets — exploits exactly the implicit trust that network perimeters extend to "inside" traffic. Zero trust eliminates lateral movement by removing the implicit trust that makes it possible: every east-west request between internal systems requires the same explicit verification as external access.

The Five Pillars of Zero Trust Architecture

The Cybersecurity and Infrastructure Security Agency (CISA) Zero Trust Maturity Model, which operationalizes NIST SP 800-207 for federal agencies and serves as the de facto implementation reference for enterprise programs, organizes zero trust across five pillars. Each pillar represents a domain of control, and mature zero trust programs advance across all five simultaneously — though most organizations begin with identity as the highest-leverage starting point.

Pillar 1: Identity — The Primary Control Plane

Identity is the foundation of zero trust in 2026. Every access decision begins with answering one question: who (or what) is requesting this access, and can that identity be verified to the degree the requested resource demands? This sounds simple but requires a fundamentally different approach to identity management than most organizations have historically employed.

Zero trust identity controls include strong multi-factor authentication enforced universally — not just for sensitive systems or privileged accounts, but for every user, every access path. Phishing-resistant MFA using hardware security keys (FIDO2/WebAuthn) or certificate-based authentication is the 2026 standard for sensitive resource access; TOTP-based authenticator apps are no longer considered sufficient for high-value targets.

Identity governance covers the full lifecycle: provisioning, entitlement review, and deprovisioning. Just-in-time access — where users receive elevated permissions for specific tasks on a time-limited basis rather than holding standing elevated access — reduces the blast radius of credential compromise. Privileged identity management ensures that administrative accounts are heavily controlled, monitored, and subject to session recording.

Key Identity Controls

•Phishing-resistant MFA (FIDO2/WebAuthn) for all users and privileged accounts
•Conditional access policies evaluating risk signals at each authentication event
•Just-in-time and just-enough-access for elevated permissions
•Continuous access evaluation that revokes sessions when risk signals change
•Quarterly access reviews and automated deprovisioning for departing users
•Non-human identity management for service accounts, APIs, and machine-to-machine flows

Pillar 2: Device — Health as an Access Signal

A verified identity on a compromised device provides weaker security assurance than the identity verification alone suggests. Device health must be an active input to access decisions, not a one-time enrollment check. Zero trust device controls create a posture-aware access model where the compliance status of the requesting device influences what the authenticated user can access.

Endpoint detection and response (EDR) platforms provide continuous device health signals: patch status, disk encryption state, presence of required security software, absence of known-malicious indicators, and behavioral anomalies. Modern mobile device management (MDM) and unified endpoint management (UEM) platforms can enforce device compliance requirements as a gate on corporate resource access — a device that falls out of compliance loses access until remediated.

Key Device Controls

•Device inventory with continuous health monitoring via EDR
•MDM/UEM enrollment as a prerequisite for corporate resource access
•Automated patch management with compliance enforcement
•Device posture signals integrated into conditional access policies
•BYOD policies with containerization to separate corporate and personal data

Pillar 3: Network — Micro-Segmentation Replaces Perimeters

Zero trust does not mean no network controls — it means that network controls enforce the principle of least privilege at a granular level rather than granting broad internal network access based on physical location. Micro-segmentation divides the network into small zones with explicit allow-list controls on traffic between zones. An attacker who compromises one segment cannot traverse to adjacent segments without triggering access decisions that their credentials cannot satisfy.

Software-defined perimeters and cloud-native network policies replace legacy firewall rules. Zero Trust Network Access (ZTNA) solutions replace traditional VPNs by providing application-specific connectivity rather than broad network access — a user connecting through ZTNA gets access to the specific application they need, not a tunnel into the corporate network that adjacent systems can also be reached through.

Key Network Controls

•Micro-segmentation with deny-by-default inter-segment policies
•ZTNA replacing traditional VPN for remote access
•Encrypted traffic inspection at network boundaries
•DNS filtering and secure web gateway controls
•Network traffic analysis for anomalous east-west movement detection

Pillar 4: Application — Least Privilege at the App Layer

Zero trust at the application layer means enforcing fine-grained access controls within applications, not just at the network level. Role-based access control (RBAC) and attribute-based access control (ABAC) determine what authenticated users can do within an application, not just whether they can reach it. API security extends these controls to machine-to-machine interactions — every API call carries authentication and authorization signals, not just session cookies inherited from initial login.

Application-layer zero trust also encompasses threat protection integrated into the application access path: secure access service edge (SASE) platforms inspect application traffic for malware and data exfiltration attempts, while cloud access security brokers (CASBs) enforce DLP policies on SaaS applications that organizations do not control at the network level.

Key Application Controls

•Least-privilege RBAC with regular entitlement reviews
•API authentication and authorization using short-lived tokens
•Web application firewall (WAF) and runtime application self-protection (RASP)
•CASB controls for SaaS application data governance
•Continuous application security testing integrated into CI/CD pipelines

Pillar 5: Data — Protect the Asset That Actually Matters

All other zero trust pillars exist to protect data. The data pillar closes the loop by applying controls directly to the data itself — not just the systems that contain it. Data classification determines what protection level applies. Data loss prevention enforces that classified data cannot leave authorized contexts. Encryption at rest and in transit ensures that data is protected even if access controls are bypassed. Rights management extends protection to documents that travel outside organizational boundaries.

The 53% of organizations still manually transferring data between systems represent a critical data pillar failure. Manual transfer processes create unmonitored data movement that bypasses DLP controls, produces undocumented copies in transit locations, and eliminates chain-of-custody visibility. Automated, API-driven data pipelines with built-in classification and logging replace manual processes in mature zero trust programs.

Key Data Controls

•Data classification labels applied at creation and enforced throughout the lifecycle
•DLP policies covering email, endpoint, cloud, and SaaS data paths
•Encryption in transit (TLS 1.3) and at rest using managed key services
•Data inventory and discovery to identify unknown sensitive data stores
•Automated data pipelines replacing manual transfer processes
•Rights management for documents shared externally

Track Your Zero Trust Controls Across Every Framework

LowerPlane maps zero trust control implementation to SOC 2, ISO 27001, NIST CSF, and CMMC requirements — so your identity and access controls count toward every audit simultaneously. See how multi-framework control tracking works in a live demo.

Book a Demo See the Platform

Zero Trust Implementation Roadmap

Zero trust is a journey measured in months and years, not a deployment completed in a sprint. Organizations that try to implement all five pillars simultaneously typically succeed at none of them. The roadmap below reflects how organizations that have achieved mature zero trust programs actually built them: starting with identity, building cross-pillar foundations, then advancing maturity level by level.

Phase 1: Identity Foundation (Months 1-3)

Establish the primary control plane before building anything else

The identity pillar is the starting point for every successful zero trust program. Without robust identity verification, the other pillars cannot function — device posture checks, micro-segmentation, and data controls all depend on knowing with confidence who is making the access request.

Deploy phishing-resistant MFA across all user accounts — start with privileged accounts, then expand to all users

Consolidate identity providers to a single authoritative source of truth where possible

Implement single sign-on (SSO) for all SaaS and internal applications

Audit all service accounts and machine identities — eliminate shared credentials

Establish a formal joiner/mover/leaver process with automated provisioning and deprovisioning

Enable identity protection policies that alert on anomalous sign-in behavior

Phase 2: Device and Network Visibility (Months 3-6)

Build the observability foundation that enables trust decisions

You cannot enforce zero trust policies for devices and network access you cannot see. Phase 2 focuses on establishing the asset inventory and monitoring infrastructure that makes policy enforcement possible.

Deploy EDR on all managed endpoints and establish a compliant device baseline

Implement MDM/UEM and create device compliance policies tied to conditional access

Conduct a network asset discovery and map all internal traffic flows

Begin micro-segmentation planning — identify the highest-risk lateral movement paths to address first

Deploy ZTNA to replace or augment legacy VPN access paths

Establish centralized logging across identity, endpoint, and network telemetry

Phase 3: Application and Data Controls (Months 6-12)

Extend least-privilege enforcement to applications and data flows

With identity and device foundations in place, Phase 3 extends zero trust principles into the application and data layers — where most of the sensitive information your organization needs to protect actually lives.

Conduct access entitlement reviews across all critical applications and remove excess privileges

Implement API authentication and authorization standards (OAuth 2.0, mTLS) for service-to-service communication

Deploy data classification tooling and label sensitive data across cloud storage and collaboration platforms

Implement DLP policies covering the highest-risk data exfiltration paths

Deploy CASB for SaaS application data governance visibility

Replace manual data transfer processes with monitored, automated pipelines

Phase 4: Automation and Continuous Improvement (Year 2+)

Move from reactive to predictive security posture management

Mature zero trust programs do not rely on manual enforcement of hundreds of policies. Phase 4 builds the automation and analytics capabilities that allow zero trust to scale and improve continuously without proportional increases in security team headcount.

Deploy security information and event management (SIEM) with UEBA for behavioral anomaly detection

Implement security orchestration, automation, and response (SOAR) for automated incident triage

Build automated access certification workflows to replace manual quarterly reviews

Develop zero trust metrics dashboard: MFA adoption rate, device compliance rate, access policy coverage, mean time to revoke

Conduct regular purple team exercises to test zero trust controls against real-world attack techniques

Advance CISA Zero Trust Maturity Model assessment from Initial to Advanced level

Zero Trust Maps to SOC 2, ISO 27001, NIST CSF, and CMMC

One of the most valuable and underappreciated aspects of zero trust architecture is that the controls required for genuine zero trust implementation satisfy large portions of the requirements in every major compliance framework. This is not coincidence — the frameworks were built around the same security principles that zero trust operationalizes. Organizations that implement zero trust for security reasons find that they have simultaneously addressed significant portions of their compliance obligations.

The control overlap is particularly dense in access control, authentication, monitoring, and audit logging domains — the same domains where zero trust provides the most security value. Organizations that implement zero trust first and map to frameworks second are generally better positioned than those who implement discrete framework-specific controls without an underlying security architecture.

SOC 2 Mapping

SOC 2 Type II audits evaluate the operating effectiveness of controls over a period — typically 6 to 12 months. Zero trust controls map most directly to the Common Criteria (CC) category, particularly CC6 (Logical and Physical Access Controls) and CC7 (System Operations). The CC6 series — CC6.1 through CC6.8 — covers logical access security, authentication controls, authorization, access restriction, transmission encryption, removal of access, and prevention of unauthorized access. A mature zero trust identity program satisfies CC6.1 through CC6.6 comprehensively. CC7.1 through CC7.5 cover system monitoring, anomaly detection, vulnerability management, and incident response — addressed by zero trust telemetry and SIEM/SOAR capabilities.

ISO 27001 Annex A Mapping

ISO 27001:2022 Annex A controls in the Access Control (A.5.15 through A.8.5), Authentication (A.8.5), and Logging and Monitoring (A.8.15 through A.8.17) domains align directly with zero trust requirements. Annex A.8.2 (Privileged Access Rights) maps to just-in-time access and privileged identity management. A.8.3 (Information Access Restriction) maps to least-privilege application controls. A.8.5 (Secure Authentication) maps to MFA and phishing-resistant authentication requirements. The ISO 27001 certification scope typically includes access control as a high-maturity control domain, making zero trust implementation directly audit-relevant.

NIST CSF Mapping

The NIST Cybersecurity Framework (CSF) 2.0 — updated in 2024 — added a Govern function and reorganized the original five functions. Zero trust controls span multiple functions but are most densely concentrated in Protect (PR). PR.AC (Identity Management, Authentication, and Access Control) is essentially a description of the identity and device zero trust pillars. PR.DS (Data Security) maps to the data pillar. DE.CM (Security Continuous Monitoring) maps to the telemetry and analytics capabilities that mature zero trust programs generate. Because NIST CSF is referenced in CISA guidance, DoD requirements, and state-level cybersecurity regulations, zero trust implementation provides broad federal and regulatory compliance coverage.

CMMC Mapping and MFA Requirements

The Cybersecurity Maturity Model Certification (CMMC) is the DoD's contractor cybersecurity program, and it has among the most explicit zero trust and MFA requirements of any compliance framework. CMMC Level 2 (117 practices derived from NIST SP 800-171) and Level 3 (additional 24 practices from NIST SP 800-172) both have direct zero trust control mappings.

The Access Control (AC) domain covers 22 practices including least privilege, session controls, remote access with MFA, and wireless access control. The Identification and Authentication (IA) domain covers 11 practices including password policies, authenticator management, and — critically — multi-factor authentication for all access to systems containing Controlled Unclassified Information (CUI). CMMC explicitly requires MFA for local and network access to privileged accounts and network access for non-privileged accounts — a requirement that aligns exactly with the identity pillar of zero trust.

Zero Trust Control	SOC 2	ISO 27001	NIST CSF	CMMC
MFA Enforcement	CC6.1, CC6.3	A.8.5	PR.AC-7	IA.3.083, IA.3.084
Least Privilege Access	CC6.3	A.8.2, A.8.3	PR.AC-4	AC.1.002, AC.2.006
Privileged Access Management	CC6.3	A.8.2	PR.AC-4	AC.2.007, AC.3.017
Access Reviews / Recertification	CC6.2	A.5.18	PR.AC-1	AC.2.006
Session Monitoring / Logging	CC7.2	A.8.15, A.8.16	DE.CM-3	AU.2.041, AU.2.042
Network Segmentation	CC6.6	A.8.22	PR.AC-5	SC.3.177, SC.3.180
Endpoint Security (EDR/MDM)	CC6.8	A.8.7	PR.DS-6	SI.1.210, SI.2.214
Data Encryption in Transit	CC6.7	A.8.24	PR.DS-2	SC.3.177
DLP Controls	CC6.7	A.8.12	PR.DS-5	MP.2.061
Incident Detection and Response	CC7.3, CC7.4	A.5.25, A.5.26	DE.AE-2, RS.AN	IR.2.092, IR.2.093

MFA Requirements Across All Four Frameworks

Multi-factor authentication is the single zero trust control with the most consistent and explicit requirements across compliance frameworks. Every major framework now mandates MFA for at least some access scenarios, and the trend across framework revisions is toward expanding MFA scope and increasing authentication strength requirements.

SOC 2

Strongly Expected

CC6.1 and CC6.3 require logical access controls that include authentication. While SOC 2 does not mandate specific authentication methods, auditors increasingly expect MFA for all administrative access and external-facing systems. Organizations with MFA gaps receive exceptions from auditors.

ISO 27001

Risk-Based Requirement

Annex A.8.5 (Secure Authentication) requires authentication mechanisms commensurate with the information sensitivity and risk. The ISO 27001 implementation guidance explicitly references multi-factor authentication for remote access, privileged accounts, and sensitive system access.

NIST CSF

Risk-Tiered Mandate

PR.AC-7 specifies that users, devices, and other assets are authenticated commensurate with the risk of the transaction. NIST SP 800-63B (the companion guideline on authentication assurance) defines three authenticator assurance levels, with AAL2 and AAL3 requiring MFA for access to sensitive systems.

CMMC

Explicit Mandate

IA.3.083 explicitly requires MFA for local and network access to privileged accounts. IA.3.084 requires MFA for network access to non-privileged accounts. These are not optional or risk-adjusted — they are required practices for CMMC Level 2 and Level 3 certification.

How LowerPlane Tracks Zero Trust Controls Across Frameworks

Implementing zero trust across five pillars while simultaneously managing compliance obligations across SOC 2, ISO 27001, NIST CSF, and CMMC creates a documentation and evidence management challenge that quickly overwhelms manual tracking. The same MFA control that satisfies SOC 2 CC6.1 also satisfies ISO 27001 A.8.5, NIST CSF PR.AC-7, and CMMC IA.3.083 — but without a system that maps these relationships, compliance teams end up collecting duplicate evidence and running parallel workstreams for controls that should be unified.

LowerPlane's compliance platform is built around exactly this multi-framework control mapping. The control library covers zero trust domains across all five frameworks, with pre-built mappings that show which controls satisfy which framework requirements. When your team implements phishing-resistant MFA and uploads the relevant configuration evidence, that evidence automatically registers against every applicable framework requirement simultaneously.

The zero trust control dashboard gives security and compliance teams a unified view of implementation status across all five pillars — identity, device, network, application, and data — with direct links to the framework controls each pillar satisfies. Gap analysis identifies which zero trust controls are missing and which framework obligations those gaps create. The remediation roadmap prioritizes gaps by the number of framework requirements affected, directing teams toward the highest-leverage improvements first.

For organizations pursuing CMMC certification — where MFA requirements are explicit and auditable — LowerPlane's CMMC module tracks the specific IA domain practices against your implementation evidence, with audit-ready documentation packages that accelerate assessment timelines. The same evidence collection workflow satisfies your SOC 2 audit and ISO 27001 surveillance assessment, reducing duplicate effort by an average of 40%.

Key Takeaways

1
The network perimeter is dead. Identity is the new perimeter — every access decision in a zero trust architecture begins with verified identity, and that verification must be continuous, context-aware, and strong. NIST SP 800-207 provides the authoritative architecture definition.
2
The statistics reveal a dangerous gap: 84% of organizations acknowledge cross-network risks, yet 53% still manually transfer data in ways that zero trust data controls are designed to eliminate. Awareness without implementation creates false confidence.
3
Start with identity. Phishing-resistant MFA, SSO, just-in-time access, and continuous access evaluation in the identity pillar deliver the highest security return and the broadest compliance coverage of any zero trust investment.
4
Zero trust controls satisfy major portions of SOC 2, ISO 27001, NIST CSF, and CMMC simultaneously. Organizations that implement security-first and map to frameworks second achieve better compliance posture with less redundant effort than those who pursue frameworks independently.
5
MFA is the one zero trust control with explicit requirements across all four major frameworks. Every framework requires it, every auditor looks for it, and phishing-resistant MFA is rapidly becoming the minimum expected standard for sensitive system access.
6
Zero trust is a multi-year journey. A realistic roadmap — identity foundation first, then device and network visibility, then application and data controls, then automation — delivers measurable security and compliance improvements at each phase without requiring a complete overhaul before any value is realized.

Frequently Asked Questions

What is zero trust architecture according to NIST SP 800-207?

NIST SP 800-207 defines zero trust architecture as a security model based on the principle that no implicit trust should be granted to any subject, asset, or resource — regardless of network location. The publication identifies seven core tenets: treating all data sources as resources, securing all communication regardless of network location, granting per-session access to individual resources, determining access by dynamic policy incorporating multiple signals, monitoring asset integrity continuously, enforcing dynamic authentication and authorization, and collecting telemetry to improve security posture. The architectural model centers on a Policy Decision Point that evaluates access requests and a Policy Enforcement Point that implements access decisions — logical components that map to modern identity providers, privileged access management tools, and cloud-native security services.

Why is identity considered the new security perimeter?

Identity has become the primary security boundary because the traditional network perimeter no longer encompasses the systems, data, and users it once protected. SaaS applications, multi-cloud workloads, and remote workers all operate outside network boundaries that on-premises firewalls can control. What remains constant across all these environments is the identity of the user or service making an access request. When identity verification is strong, continuous, and context-aware — incorporating device health, behavioral signals, and requested resource sensitivity — it provides a security boundary that travels with the subject regardless of where the access originates. The 61% of breaches that involve compromised credentials in 2025 demonstrate both why identity is the primary attack surface and why identity-first zero trust provides the most direct security value.

Does implementing zero trust satisfy SOC 2 requirements?

Zero trust implementation satisfies significant portions of SOC 2 requirements, particularly within the Common Criteria (CC) category. The identity pillar directly addresses CC6.1 (logical access security software and infrastructure), CC6.3 (role-based access and authentication), and CC6.6 (security measures against threats from outside system boundaries). Device controls address CC6.8 (prevention of unauthorized physical and logical access). Network monitoring and SIEM capabilities address CC7.1 (anomaly detection) and CC7.2 (system monitoring). DLP and data encryption address CC6.7 (data transmission controls). A mature zero trust program — one that encompasses identity, device, network, application, and data pillars — will address the majority of CC6 and CC7 controls. SOC 2 auditors do not evaluate zero trust as a framework, but they evaluate the underlying control behaviors that zero trust implements.

What are the CMMC MFA requirements for zero trust?

CMMC Level 2 and Level 3 include explicit, non-negotiable MFA requirements in the Identification and Authentication (IA) domain. Practice IA.3.083 requires multi-factor authentication for local and network access to privileged accounts. Practice IA.3.084 requires multi-factor authentication for network access to non-privileged accounts. These apply to any system that processes, stores, or transmits Controlled Unclassified Information (CUI). Unlike SOC 2 and ISO 27001, where MFA is an expectation grounded in risk assessment, CMMC treats these as objective requirements — either implemented or not. Third-party assessors (C3PAOs) will verify MFA implementation through configuration review, system documentation, and testing. Organizations pursuing CMMC certification should ensure MFA is deployed across all access paths to CUI systems before engaging an assessor.

What is the difference between zero trust and a traditional VPN?

A traditional VPN grants authenticated users broad access to the corporate network — once connected, users can reach any system on the network that their routing permits. This creates exactly the broad implicit trust that zero trust eliminates. Zero Trust Network Access (ZTNA), the zero trust replacement for VPN, grants application-specific access rather than network-level access. A user connecting through ZTNA is authenticated, their device posture is checked, and they receive a connection specifically to the applications they are authorized to access — not a tunnel into the broader network. This means that a compromised ZTNA session cannot be used for lateral movement to adjacent systems, because no broad network access was granted. ZTNA also provides continuous session monitoring and can terminate access when risk signals change during a session — a capability traditional VPNs do not offer.

How long does it take to implement zero trust architecture?

A full zero trust implementation across all five pillars typically takes two to four years for enterprise organizations, though meaningful security improvements are achievable within the first three to six months by focusing on the identity pillar. The timeline depends on organizational size, existing technology stack maturity, the number of legacy systems requiring integration or replacement, and the scope of the environment being secured. The CISA Zero Trust Maturity Model describes three maturity levels — Traditional, Advanced, and Optimal — that organizations progress through over time. Most organizations beginning their zero trust journey in 2026 can reach the Advanced maturity level within 18 to 24 months with sustained investment. Federal agencies were directed toward Advanced maturity for most CISA pillar categories by the end of fiscal year 2024, though many continue to progress. The key is beginning with a sequenced roadmap — identity first — rather than attempting to implement all pillars simultaneously, which typically leads to superficial implementation across all areas rather than deep implementation in the highest-priority domains.

How does zero trust address insider threats?

Zero trust is uniquely effective against insider threats because it eliminates the broad implicit trust that makes insider threats dangerous. In a traditional network perimeter model, a malicious or compromised insider has access to everything on the internal network — their legitimate presence inside the perimeter grants them reach far beyond what their job function requires. Zero trust's least-privilege model means that each user has access only to the specific resources their role requires, and that access is continuously monitored for behavioral anomalies. User and entity behavior analytics (UEBA), integrated with zero trust identity and access telemetry, can detect when a legitimate user is accessing resources outside their normal pattern, accessing data at unusual times, or exfiltrating data through monitored channels — triggering step-up authentication or session termination before harm is complete. The data pillar's DLP controls create additional barriers against data exfiltration even for users with legitimate access to classified data.

Get Security and Compliance Insights Weekly

Join 5,000+ security and compliance professionals receiving actionable insights on zero trust, framework changes, and compliance automation every week.

No spam. Unsubscribe anytime.

Compliance Guides