The era of "trust but verify" is over. While this is particularly true since CMMC enforcement began on November 10, 2025, the end was signalled much earlier. 

In August 2020, NIST published Special Publication 800-207 on Zero trust architecture (ZTA), a new security paradigm that fundamentally reshaped how organizations approach cybersecurity. For defense contractors facing CMMC requirements, understanding and implementing Zero trust isn't just a best practice. It's a necessary foundation for compliance and contract eligibility.

This guide breaks down what NIST SP 800-207 really means, why Zero trust matters for your organization, and how implementing this framework can help you fast-track CMMC certification while building a more resilient security posture.

What is Zero Trust Architecture?

As defined in NIST SP 800-207, Zero trust architecture (ZTA) is an evolving security model that shifts the focus from defending static, network-based perimeters to defending users, assets, and resources instead.

Unlike traditional security models which assume everything inside the corporate network perimeter can be trusted, Zero trust assumes there is no implicit trust based on physical location, network location, or asset ownership alone. It therefore operates on a fundamentally different principle: never trust, always (and continuously) verify.

Here’s what Zero trust means in practical terms:

• Your corporate laptop on the office WiFi has no more inherent trust than a device connecting from a coffee shop.
• Being authenticated five minutes ago doesn't mean you're authenticated now.
• Access to one resource doesn't automatically grant access to others.
• Every access request is evaluated based on multiple real-time factors before being granted.

Let’s take a closer look at how Zero trust differs from the perimeter-based security model that preceded it.

Source: NIST blog: Zero Trust Cybersecurity: ‘Never Trust, Always Verify’

History of zero trust: The shift from perimeter-based security to zero trust

Before zero trust, the traditional security model was perimeter-based. Meaning, an enterprise’s infrastructure was built with a hard outer shell (the network perimeter) and a soft interior. So while it was difficult to get in, once inside, users could move relatively freely. 

This security model became increasingly ineffective as enterprise infrastructure grew increasingly complex. Remote users, bring your own device (BYOD), Internet of Things (IoT), and cloud-based assets are only a few trends that fundamentally changed enterprise IT. These trends made it difficult to identify a single network perimeter in the first place, and to stop attackers from moving laterally once inside. As a result, organizations could no longer assume that “inside the network” meant secure or trustworthy.

Zero trust was designed to flip this security model, assuming that the network is compromised instead of secure. Based on this assumption, every user, device, and network flow should be treated as potentially hostile and their access and permissions should be limited until proven otherwise through authentication and authorization. And not just once but continuously.

This cybersecurity paradigm is designed to meet the new reality of enterprise network security. Employees work from home and use their own devices, applications live in the cloud, contractors need selective access to systems, and cyber attackers have proven they can breach any perimeter. Zero trust acknowledges that breaches will happen and designs security around resources themselves, not network segments, in order to limit damage rather than prevent all entry.

These principles of zero trust form the basis of many federal frameworks today, including FISMA, NIST RMF, and CMMC. These frameworks are just one part of a larger, decades-long effort to get federal agencies to embrace zero trust principles. 

Zero trust timeline

Here’s a brief timeline of how zero trust was developed and is continuing to be enforced today:

• 2004: The Jericho Forum publicized the idea of deperimeterization, focusing on the limitations of relying on single, static defenses over a large network segment and the importance of organizations limiting implicit trust based on network location.
• 2007: The Defense Information Systems Agency (DISA) and the Department of Defense first introduced the concept of “black core” [BCORE], a more secure enterprise strategy that focused on securing individual transactions, rather than perimeters. 
• 2010: John Kindervag officially coined the term zero trust while at Forrester.
• 2015: The Office of Personnel Management (OPM) announces it experienced a data breach that exposed 22.1 million records, making it one of the largest breaches of U.S. government data in history.
• 2017: The American Technology Council is established and produces a report on ways to modernize federal IT and strengthen cybersecurity, including adopting zero trust.
• 2020: NIST released the general guidance document NIST SP 800-207, zero trust Architecture, for adoption of ZTAs in the federal government. 
• 2021: E.O. 14028, “Improving the Nation’s Cybersecurity,” emphasizes the need for agencies to adopt zero trust cybersecurity principles and adjust their network architectures accordingly.
• 2022: The Office of Management and Budget (OMB) published Memorandum (M)-22-09 titled, “Moving the U.S. Government Toward zero trust Cybersecurity Principles.” 
• 2022: The DoD developed a zero trust Strategy to assist defense agencies as they implement zero trust architectures and complement the OMB Memorandum.

Is zero trust architecture required by CMMC?

While zero trust architecture isn’t explicitly required by CMMC, CMMC codifies many security practices that ZTAs implement by design:

• Access Control (AC): Zero trust's least privilege and continuous authorization directly address CMMC access control requirements including AC.L2-3.1.1 (limit access to authorized users), AC.L2-3.1.2 (limit access to authorized transactions), and AC.L2-3.1.3 (control information flow).
• Identification and Authentication (IA): Zero trust's principle of verifying explicitly emphasizes that every attempt at accessing the network must be authenticated and authorized, requiring continuous validation of users, devices, and access requests. This satisfies CMMC requirements for unique user identification, multifactor authentication, and device authentication.
• Audit and Accountability (AU): Zero trust's comprehensive logging of all access requests, policy decisions, and resource interactions provides the audit trail CMMC demands. The granularity of zero trust logging often exceeds CMMC minimums.
• System and Communications Protection (SC): Zero trust's requirement to encrypt all communications regardless of network location directly supports CMMC's cryptographic protection requirements.
• System and Information Integrity (SI): Continuous monitoring and threat intelligence integration in zero trust architectures align with CMMC's requirements for flaw remediation and malicious code protection.

That makes sense given both zero trust and CMMC’s shared mission of federal data protection and emphasis on verification over implicit trust. 

As Katie Arrington, lead architect of CMMC, emphasized in an interview with Breaking Defense, zero trust and CMMC together are necessary to create a culture of cybersecurity where security isn't just claimed or assumed but continuously demonstrated. 

NIST SP 800-207 zero trust architecture summary

The NIST SP 800-207 is a comprehensive guide that spans 59 pages. We’ve broken down the key elements so you can read our summary, or the more in-depth guide. 

7 tenets of zero trust

NIST SP 800-207 defines zero trust through seven core tenets that form the philosophical and operational foundation. Understanding these tenets is essential for proper implementation:

1. All data sources and computing services are considered resources.

Every asset in your environment, from databases to IoT sensors to user workstations, is a resource that requires protection. No exceptions based on location or perceived importance.

2. All communication is secured regardless of network location. 

Whether data traverses your internal network, the public internet, or a partner's environment, it must be encrypted and authenticated. Network location confers no security advantage.

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

Each access request is evaluated independently. Previous authentication doesn't guarantee future access. Sessions have defined lifetimes and must be re-established, not assumed to persist.

4. Access is determined by dynamic policy including observable state.

Decisions factor in user identity, device health, requested resource, time of day, location, behavioral analytics, and real-time threat intelligence. These policies adapt based on risk.

5. The enterprise monitors and measures the integrity and security posture of all assets. 

Continuous monitoring isn't optional—it's foundational. You must know the state of every asset at all times to make informed access decisions.

6. All authentication and authorization are dynamic and strictly enforced before access. 

No implicit trust. Every access attempt must complete both authentication (who are you?) and authorization (what can you do?) before gaining access to resources.

7. The enterprise collects and uses information about assets, network infrastructure, and communications. 

Comprehensive logging, monitoring, and analysis provide the intelligence needed to improve security posture, detect threats, and refine policies.

6 basic assumptions of zero trust

Before diving into implementation tenets, NIST SP 800-207 establishes six assumptions about the modern enterprise environment. These assumptions reflect the reality of today's security landscape and explain why traditional perimeter-based security no longer works:

1. The entire enterprise private network is not considered an implicit trust zone and therefore all communication must be secured using authenticated connections and encryption.
2. Devices on the network may not be owned or configurable by the enterprise but still need secure access to enterprise resources, such as BYOD devices.
3. No resource is inherently trusted and therefore every access request must be authenticated and authorized continuously. 
4. Not all enterprise resources are on enterprise-owned infrastructure, such as remote workers and cloud services. 
5. Remote enterprise subjects and assets cannot fully trust their local network connection, meaning all connection requests from remote workers using their local network (such as coffee shop WiFi or home internet) should be authenticated and authorized, and all communications should be done in the most secure manner possible.
6. Assets and workflows moving between enterprise and nonenterprise infrastructure should have a consistent security policy and posture. Meaning, a laptop that was secure in the office must maintain that security posture when the employee works from home. 

Core Architectural Components

NIST SP 800-207 describes several key components that work together to create a zero trust architecture:

• Policy Engine (PE): Makes the ultimate decision about granting access based on policy and input from multiple sources including threat intelligence, activity logs, data access policies, and device compliance status.
• Policy Administrator (PA): Executes decisions from the Policy Engine by establishing or terminating communication paths between subjects and resources.
• Policy Enforcement Point (PEP): Sits between the subject and the resource, enabling, monitoring, and terminating connections based on directives from the Policy Administrator. By leveraging a zero trust Policy Enforcement Point, organizations can create, encrypt, and monitor data communication flows and define workflows for CUI management.
• Continuous Diagnostics and Mitigation (CDM) System: Collects information about the enterprise asset's current state and applies updates to asset configurations to better enforce security policies.
• Industry Compliance System: Ensures that the enterprise maintains compliance with relevant regulations and standards.
• Threat Intelligence Feed: Provides information about new attacks, vulnerabilities, and malicious actors to inform policy decisions.

Common misconceptions about zero trust

Here are some common challenges that organizations face and must overcome on their journey to zero trust architecture:

"Zero trust means zero usability"

Done right, zero trust simplifies access by removing VPNs and unnecessary friction. Modern zero trust implementations use risk-based authentication that challenges users only when their context changes or risk increases. For routine access from known devices in expected locations, the user experience can actually improve.

"It's only for large enterprises"

Any organization with cloud workloads, remote workers, BYOD policies, or contractor services benefits from zero trust. Sometimes, smaller businesses even have an advantage because they can implement zero trust more quickly without legacy infrastructure constraints. 

"Zero trust replaces all existing security"

Zero trust complements and orchestrates existing security controls, rather than replaces them. Your firewalls, endpoint protection, encryption, and monitoring systems remain valuable, but zero trust integrates them into a cohesive architecture with centralized policy enforcement.

“Legacy systems are incompatible”

Many organizations worry that legacy applications can't support modern authentication or fine-grained access controls. This is often true, but zero trust can still be implemented through:

• Network-level segmentation around legacy systems
• Proxy-based access controls
• Privileged access management for administrative access
• Scheduled modernization or replacement as part of your roadmap

“It's not worth the investment”

Zero trust implementation requires investment in technology, people, and time, but it is often more costly not to implement zero trust. This is particularly true for defense contractors, where a lack of implementation of zero trust principles means potential CMMC compliance issues and contract ineligibility, increased risk of breaches and reputational damage, and more.

Simplify the path forward to zero trust and CMMC with Secureframe

Zero trust architecture under NIST SP 800-207 represents more than a security model. It's the foundation for modern defense contractor operations. As CMMC enforcement accelerates and the DoD moves toward full zero trust implementation across its enterprise by 2027, contractors must adapt or risk exclusion from the DIB.

The good news is that implementing zero trust not only better positions you for CMMC compliance and future requirements like NIST SP 800-171 Rev 3. It also creates a more secure, resilient, and competitive defense ecosystem. 

Here's how Secureframe can help, whether you're a federal agency, contractor, critical infrastructure provider, or public sector company: s

• Automated compliance with federal frameworks:  Secureframe accelerates readiness with mandatory and voluntary federal frameworks, including CMMC, FedRAMP (and FedRAMP 20x), NIST 800-53, NIST 800-171, and NIST RMF by automating key compliance tasks, including evidence collection, control mapping, documentation generation and management, continuous control monitoring, and more.
• Automated continuous monitoring and remediation: Secureframe continuously monitors your infrastructure, applications, and vendor ecosystem to detect misconfigurations and vulnerabilities in real time and streamlines remediation of these issues with easy task management and step-by-step guidance or infrastructure-as-code fixes generated by Comply AI—before they escalate into security incidents or audit failures.
• Secure cloud configuration: For federal agencies looking to expand their cloud environment or contractors supporting federal workloads, Secureframe automatically provisions secure federal cloud environments, including Azure Government, GCC High, Google Workspace, Intune, and AWS GovCloud.
• Asset, vendor, and risk management: Secureframe integrates with your infrastructure to automatically discover in-scope assets and link them to framework requirements. You can also inventory and track vendors—especially those storing or transmitting sensitive information like CUI or providing security functions—to ensure they meet contractual requirements. And you can assess, manage, and remediate risk to those assets and vendors using Secureframe’s automation and AI workflows. 

Private- and public-sector organizations like the energy startup ElectricFish and defense contractor Adyton use Secureframe to modernize their security programs, meet increasing and evolving compliance requirements, and become more resilient against sophisticated cyber threats targeting governments and businesses worldwide.

Talk to an expert to learn how Secureframe can help you achieve these goals.