NIST 800-207 Zero Trust. Never Trust. Always Verify.

NIST Special Publication 800-207, published in August 2020, defines Zero Trust Architecture (ZTA) as a cybersecurity paradigm that eliminates implicit trust from all computing infrastructure. In traditional perimeter-based security models, resources inside the network boundary receive elevated trust: once a user or device authenticates at the perimeter, lateral movement within the network proceeds with minimal additional verification. ZTA rejects this assumption. Every access request, regardless of the requester's network location, must be authenticated, authorized, and continuously validated before access is granted. The architecture treats every network as hostile, every device as potentially compromised, and every session as requiring independent verification. This is not a product category or a vendor feature. It is an architectural strategy that changes how organizations design, deploy, and operate their security infrastructure. The publication provides a vendor-neutral reference architecture that federal agencies and private organizations use as the authoritative definition of what Zero Trust means in practice.

NIST 800-207 defines seven tenets that form the foundation of Zero Trust Architecture. First: all data sources and computing services are considered resources. Second: all communication is secured regardless of network location. Third: access to individual enterprise resources is granted on a per-session basis. Fourth: access to resources is determined by dynamic policy, including the observable state of client identity, application, and the requesting asset, and may include other behavioral attributes. Fifth: the enterprise ensures all owned and associated devices are in the most secure state possible and monitors assets to ensure they remain so. Sixth: all resource authentication and authorization are dynamic and strictly enforced before access is allowed. Seventh: the enterprise collects as much information as possible about the current state of network infrastructure and communications, and uses it to improve its security posture. These seven tenets are not aspirational goals. They are architectural requirements that define whether a deployment qualifies as Zero Trust.

Zero Trust Architecture became a federal mandate through Executive Order 14028, signed in May 2021, which directed federal agencies to advance toward ZTA adoption. OMB Memorandum M-22-09, published in January 2022, established specific Zero Trust implementation requirements for federal agencies with a fiscal year 2024 deadline. The memorandum organizes Zero Trust into five pillars: identity, devices, networks, applications and workloads, and data. Each pillar has specific maturity targets that agencies must achieve. The Cybersecurity and Infrastructure Security Agency (CISA) published the Zero Trust Maturity Model to provide agencies with a roadmap for measuring progress across these pillars. For federal organizations, Zero Trust is not optional. For defense contractors operating on federal networks or processing federal data, Zero Trust requirements flow through contract vehicles, security requirements guides, and authorization conditions. For private sector organizations, ZTA represents the architectural direction that regulatory frameworks and cyber insurance requirements are converging toward.

Perimeter-based security operates on a foundational assumption that has not been valid for over a decade: that everything inside the network boundary is trusted. This model was designed for an era when all users sat at desks inside physical offices, all applications ran on servers in on-premises data centers, and the network boundary was a physical perimeter defended by firewalls. That era ended. Cloud computing moved workloads outside the perimeter. Remote and hybrid work moved users outside the perimeter. Software-as-a-service moved data outside the perimeter. Mobile devices move the access point outside the perimeter. The result is an architecture where the perimeter no longer contains what it was designed to protect. Adversaries who breach the perimeter, through phishing, credential theft, supply chain compromise, or exploitation of a public-facing service, move laterally with minimal resistance. The same implicit trust that lets legitimate users navigate internal resources lets attackers do the same. The breach is not the perimeter failure. The lateral movement that follows is the perimeter failure.

Organizations respond to Zero Trust mandates by declaring adoption without defining what adoption means in their specific environment. A vendor product is purchased and labeled "Zero Trust." A network segmentation project is renamed a "Zero Trust initiative." A multi-factor authentication deployment is described as "implementing Zero Trust." Each of these may contribute to a Zero Trust Architecture, but none of them constitutes one. ZTA is an architectural strategy that encompasses identity verification, device health assessment, microsegmentation, encrypted communications, dynamic policy enforcement, continuous monitoring, and data-centric access control. Implementing one component and declaring Zero Trust achieved is like installing a lock on one door and declaring the building secure. Without a structured approach to ZTA that accounts for all seven NIST tenets and measures progress across all five CISA maturity pillars, organizations mistake partial implementation for complete architectural transformation. The gap between the declared state and the actual state creates both security risk and compliance exposure.

The measurement problem compounds the implementation problem. Zero Trust maturity is a spectrum, not a binary state. CISA's Zero Trust Maturity Model defines four maturity levels across five pillars: Traditional, Initial, Advanced, and Optimal. Each pillar has specific capabilities and attributes at each maturity level. Without systematic measurement of where the organization sits on each pillar, Zero Trust remains aspirational rather than architectural. Federal agencies face OMB reporting requirements that demand specific evidence of progress. Defense contractors face Zero Trust requirements that flow through authorization conditions and contract vehicles. Private sector organizations face cyber insurance questionnaires that increasingly ask about Zero Trust implementation without defining what counts. In every case, the organization needs to measure its current state against a defined target, identify the gaps, prioritize remediation, and demonstrate progress with evidence. Without mapping ZT tenets to specific controls and measuring their implementation continuously, Zero Trust is a marketing term applied to a partially implemented strategy.

NIST 800-207 defines three core logical components of a Zero Trust Architecture. The Policy Engine (PE) makes the access decision: grant, deny, or revoke. It uses enterprise policy, external information sources (threat intelligence feeds, identity provider attributes, device health data), and the requesting context to compute the decision. The Policy Administrator (PA) executes the decision by establishing or shutting down the communication path between the subject and the resource. It generates session-specific authentication tokens or credentials and instructs the enforcement point to allow or deny the connection. The Policy Enforcement Point (PEP) is the system component that enables, monitors, and terminates connections between subjects and enterprise resources. Together, these three components form the control plane of a Zero Trust Architecture. The data plane carries the actual resource traffic, but only after the control plane has authorized it. This separation is fundamental: the access decision (control plane) is decoupled from the data transmission (data plane), allowing the policy engine to evaluate and revoke access independently of the resource being accessed.

NIST 800-207 describes several deployment models that organizations may adopt based on their existing infrastructure and operational requirements. The device agent/gateway model places agents on endpoints that communicate with gateway components in front of resources, creating an authenticated channel per session. The enclave-based model applies ZTA principles at the boundary of enclaves rather than individual resources, suitable for environments where per-resource enforcement is not yet feasible. The resource portal model routes all access through a centralized portal that acts as the PEP, authenticating and authorizing each request before proxying the connection. The device application sandboxing model isolates applications on the endpoint, treating each application as a separate resource consumer with independent access decisions. Most organizations implement a hybrid of these models, selecting the appropriate deployment approach for each resource category based on sensitivity, accessibility requirements, and infrastructure constraints. The deployment model is not a one-time decision. It evolves as the organization matures its ZTA implementation.

Rampart maps your organization's ZTA components to the NIST 800-207 reference architecture. For each logical component (PE, PA, PEP), Rampart identifies which infrastructure elements in your environment fulfill that role and assesses whether the implementation satisfies the architectural requirements. Identity providers serve as inputs to the Policy Engine. Conditional access policies and authorization rules implement the Policy Administrator's decision logic. Network access control lists, application-layer gateways, service meshes, and reverse proxies serve as Policy Enforcement Points. Rampart maps each component to the NIST 800-53 controls it satisfies (AC-3 for access enforcement, AC-4 for information flow enforcement, AC-17 for remote access), creating a traceable chain from your architectural implementation to the control framework. Artificer identifies gaps in the architecture: components that lack a Policy Enforcement Point, resources that bypass the Policy Engine, or communication paths that do not transit a PEP. Where your architecture does not yet cover all resource categories, Artificer recommends deployment model options based on the resource type, sensitivity level, and your existing infrastructure capabilities.

Each of the seven Zero Trust tenets carries specific implications for infrastructure design and security operations. Tenet one (all data sources and computing services are resources) means the organization must maintain a complete inventory of every asset that participates in the enterprise environment, including cloud services, SaaS applications, IoT devices, and employee-owned devices accessing enterprise resources. Tenet two (all communication is secured regardless of network location) means encryption is mandatory for all traffic, not just traffic that crosses the external boundary. Internal network segments must encrypt communications with the same rigor applied to internet-facing connections. Tenet three (per-session access) means access decisions are not persistent. A user authenticated at 9 AM does not retain access at 3 PM without re-evaluation. Session duration, scope, and permissions are constrained and re-assessed continuously. These three tenets alone require organizations to fundamentally rethink network architecture, asset management, and session management practices that most enterprises have operated for decades.

Tenets four through seven define the dynamic and adaptive characteristics of Zero Trust. Tenet four (dynamic policy) means access decisions incorporate real-time signals: user identity, device health, location, time of access, resource sensitivity, and behavioral patterns. A user accessing a sensitive resource from an unmanaged device on an unfamiliar network receives different access than the same user on a managed device from a known location. Tenet five (device integrity monitoring) means the organization continuously assesses the security posture of every device and takes action when posture degrades. A device that falls behind on patches, loses its endpoint protection, or exhibits anomalous behavior triggers a policy re-evaluation. Tenet six (dynamic authentication and authorization) means authentication is not a one-time gate. It is a continuous process where the level of assurance required scales with the sensitivity of the resource being accessed. Tenet seven (continuous improvement through data collection) means the organization collects telemetry from every component of the architecture and uses that data to refine policies, detect anomalies, and improve security posture over time. These tenets define a living architecture that adapts to conditions, not a static configuration that assumes a fixed threat model.

Rampart decomposes each tenet into assessable controls with measurable implementation criteria. Tenet one maps to asset inventory controls (NIST 800-53 CM-8, PM-5). Tenet two maps to communication protection controls (SC-8, SC-13, SC-23). Tenet three maps to session management controls (AC-12, SC-10). Tenet four maps to access control policy and enforcement controls (AC-3, AC-4, AC-24). Tenet five maps to configuration management and integrity monitoring controls (CM-3, CM-6, SI-7). Tenet six maps to identification and authentication controls (IA-2, IA-4, IA-5, IA-8). Tenet seven maps to audit and monitoring controls (AU-2, AU-6, SI-4). For each control, Rampart assesses defense effectiveness, evidence coverage, and evidence freshness. Artificer evaluates your tenet implementation holistically, identifying tenets where implementation is strong and tenets where architectural gaps remain. Artificer generates gap analysis reports that map each deficiency to the specific tenet, the specific control, and the specific infrastructure change required to close the gap. The result is a structured assessment of your Zero Trust posture against the authoritative NIST definition, not a vendor's interpretation of what Zero Trust means for their product category.

In a Zero Trust Architecture, identity replaces the network as the primary security boundary. The perimeter model granted access based on where you were: inside the network meant trusted, outside meant untrusted. ZTA grants access based on who you are, verified continuously. This shift has profound architectural consequences. The identity provider becomes the most critical security infrastructure component, because every access decision depends on it. Identity must be established with high assurance through multi-factor authentication that combines something the user knows (password or PIN), something the user has (hardware token, mobile device, smart card), and potentially something the user is (biometric). OMB M-22-09 specifically requires agencies to use phishing-resistant MFA for all staff accessing agency systems, excluding SMS and voice-based one-time passwords from qualifying methods. Identity is not limited to human users. Service accounts, application identities, machine identities, and automated processes all require identity verification proportional to the sensitivity of the resources they access.

Continuous authorization extends identity verification beyond the initial authentication event. Traditional models authenticate at login and maintain a persistent session until timeout or logout. Zero Trust requires ongoing evaluation of the user's context throughout the session. Did the user's device posture change during the session? Did the user's network location change? Did the user's behavior deviate from established patterns? Did the resource's sensitivity classification change? Each of these signals can trigger a re-evaluation of the access decision, potentially requiring step-up authentication, scope reduction, or session termination. Conditional access policies implement this continuous evaluation by defining rules that consider identity attributes, device compliance status, network location, application sensitivity, and real-time risk signals. Identity governance extends beyond authentication to encompass the full lifecycle: provisioning, access review, role management, privilege escalation controls, and deprovisioning when employment status changes or role assignments are modified.

Sentinel monitors your identity infrastructure continuously. It assesses MFA enforcement across all identity providers, verifying that multi-factor authentication is required for all users accessing enterprise resources and that the MFA methods in use meet phishing-resistance requirements. Sentinel evaluates conditional access policies against ZTA requirements: are policies evaluating device compliance, network location, and application sensitivity before granting access? Are session lifetimes appropriately constrained? Are step-up authentication triggers configured for sensitive resource access? When Sentinel detects a configuration change that weakens identity controls (an MFA exemption added, a conditional access policy disabled, a session timeout extended beyond policy), the change is flagged immediately and mapped to the affected ZTA tenets and NIST 800-53 controls. Rampart maps identity configurations to the specific controls they satisfy: IA-2 (Identification and Authentication), IA-5 (Authenticator Management), IA-8 (Identification and Authentication for Non-Organizational Users), AC-2 (Account Management), and AC-7 (Unsuccessful Logon Attempts). Your identity pillar maturity is measured from infrastructure evidence, not from policy documents that describe intended configurations.

Microsegmentation divides the network into isolated segments where each resource or group of resources has its own security boundary. In a perimeter model, a flat internal network allows any authenticated user to reach any internal resource. In a Zero Trust network, each segment enforces its own access policy through a Policy Enforcement Point. Traffic between segments is inspected, authorized, and logged. A compromised workstation in one segment cannot reach a database in another segment without traversing a PEP that evaluates the request against dynamic policy. The granularity of segmentation varies by maturity level: initial implementations may segment by application tier (web, application, database), while advanced implementations segment by individual workload or even by individual API endpoint. Each level of granularity reduces the blast radius of a compromise. Microsegmentation is not a single technology deployment. It is an architectural pattern implemented through a combination of network access control lists, security groups, service mesh policies, application-layer firewalls, and software-defined networking constructs.

NIST 800-207 Tenet Two requires that all communication be secured regardless of network location. This means TLS encryption for all HTTP traffic (internal and external), encrypted connections between services (mutual TLS or equivalent), encrypted DNS queries to prevent interception and manipulation, and encrypted management plane communications for infrastructure administration. The assumption is that the internal network is as hostile as the internet. An attacker who gains access to a network segment should not be able to passively observe traffic between services or intercept credentials transmitted in cleartext. Software-defined perimeters (SDP) implement this principle by creating point-to-point encrypted tunnels between authorized subjects and resources, rendering the resource invisible to unauthorized network participants. The resource does not respond to unauthorized connection attempts because the SDP controller has not opened the tunnel. This "dark cloud" approach means resources are undiscoverable by network scanning, reducing the attack surface to the access control decision itself rather than the network path to the resource.

Armory provides hardened infrastructure-as-code modules for implementing Zero Trust network architecture. Network segmentation modules deploy microsegmented environments with deny-by-default security group rules, inter-segment traffic inspection, and logging for all cross-segment communications. Encryption modules configure mutual TLS between services, encrypted DNS resolution, and certificate management with automated rotation. Each module maps to the specific NIST 800-53 controls it satisfies: SC-7 (Boundary Protection), SC-8 (Transmission Confidentiality and Integrity), AC-4 (Information Flow Enforcement), and SC-28 (Protection of Information at Rest). Sentinel monitors network configurations continuously. When a security group rule is modified to allow broader access than the microsegmentation policy permits, Sentinel detects the drift, maps it to the affected ZTA tenet and controls, and flags the deviation. For defined drift scenarios, Sentinel can auto-remediate by restoring the compliant configuration within your approved change windows. Each remediation event is logged as an immutable record with full provenance, providing evidence that the network segmentation control was maintained continuously rather than verified periodically.

Zero Trust Architecture's ultimate objective is protecting data. Networks, identities, devices, and applications are all means to that end. Data-centric security means access control decisions are made at the data layer, not just at the network or application layer. A user who has authenticated, passed device health checks, traversed the network PEP, and accessed the application may still be restricted from specific data sets based on their role, clearance level, data classification, or the sensitivity context of the specific records they are requesting. This requires data classification: every data asset must be categorized by sensitivity level, regulatory requirements, and access restrictions. Unclassified data may be accessible to all authenticated users. Sensitive data may require additional authorization. Regulated data (CUI, ePHI, PCI cardholder data) requires access controls that satisfy the specific regulatory framework governing that data type. Data classification is the foundation of data-centric access control. Without knowing what data exists and how sensitive it is, the organization cannot implement proportional access restrictions.

Encryption enforces data protection at every layer of the architecture. Data at rest must be encrypted with keys managed through a controlled key management service, with key rotation policies, access logging on key usage, and separation between the encrypted data and the encryption keys. Data in transit must be encrypted using current cryptographic standards, with certificate validation enforced on both endpoints to prevent interception. Data in use presents the most challenging protection requirement: technologies such as confidential computing, homomorphic encryption, and secure enclaves address this requirement at varying maturity levels. Beyond encryption, data protection in a Zero Trust Architecture includes integrity controls (ensuring data has not been modified by unauthorized parties), data loss prevention (preventing exfiltration through unauthorized channels), and data lifecycle management (ensuring data is retained only as long as required and destroyed securely when its retention period expires). Each of these protections operates independently but reinforces the others. Encryption without access control is insufficient. Access control without encryption is vulnerable to data-at-rest compromise.

Sentinel monitors data protection controls across your connected infrastructure. Encryption configurations on storage volumes, databases, object stores, and message queues are verified continuously against your defined policy. Key management configurations are assessed: are keys stored separately from encrypted data, is key rotation occurring on schedule, are key usage events logged and reviewed? Data access patterns are monitored for anomalies that could indicate unauthorized access or exfiltration attempts. When Sentinel detects a data protection control that has degraded (an encryption configuration removed, a key rotation policy disabled, an access control list modified to grant broader access than policy permits), the affected controls are re-evaluated immediately. Rampart tracks data protection controls against NIST 800-53 control families SC-12 (Cryptographic Key Establishment and Management), SC-13 (Cryptographic Protection), SC-28 (Protection of Information at Rest), MP-4 (Media Storage), and MP-6 (Media Sanitization). Each data protection control is scored across defense effectiveness, evidence coverage, and evidence freshness. The result is a continuously updated view of your data pillar maturity that reflects the actual state of your data protection infrastructure.

Zero Trust implementation proceeds in phases because no organization transitions from a perimeter model to a full ZTA overnight. The first phase focuses on the highest-impact foundations: deploying strong identity with phishing-resistant MFA across all users, establishing a complete asset inventory, and encrypting all communications. The second phase introduces microsegmentation for the most sensitive resource categories, implements conditional access policies that evaluate device health and location, and deploys continuous monitoring for identity and network events. The third phase extends microsegmentation to all resource categories, implements data-centric access controls based on classification, deploys software-defined perimeters for sensitive resources, and integrates real-time threat intelligence into policy decisions. Each phase builds on the previous one. Attempting to implement data-centric access controls before completing asset inventory and identity foundation creates gaps that undermine the architecture. The phased approach ensures each layer of defense is solid before the next layer is added.

Integration with existing infrastructure is a practical necessity. Most organizations cannot replace their entire security architecture simultaneously. Zero Trust implementation must coexist with legacy systems, existing network architectures, and current operational processes during the transition. Legacy applications that cannot support modern authentication protocols may require a resource portal deployment model where the portal handles ZTA enforcement on behalf of the application. On-premises systems that cannot participate in cloud-based identity providers may require identity federation or gateway-mediated access. Operational technology environments with specialized protocol requirements may require enclave-based approaches where ZTA principles apply at the enclave boundary rather than at each individual device. The implementation plan must account for these constraints explicitly, identifying which systems will be migrated to full ZTA, which will use intermediary enforcement models, and which may require infrastructure replacement before they can participate in the architecture.

Armory provides infrastructure-as-code modules for each phase of ZTA implementation. Identity modules deploy MFA configurations, conditional access policies, and identity governance workflows. Network modules deploy microsegmented environments, encrypted communication channels, and software-defined perimeter components. Data protection modules deploy encryption configurations, key management services, and access logging infrastructure. Each module is hardened with security parameters built in and maps directly to the NIST 800-53 controls it satisfies. Vanguard scans deployed infrastructure continuously to verify that implementations operate as intended. Static analysis identifies misconfigurations in infrastructure code before deployment. Runtime scanning verifies that deployed configurations match their intended state. Each finding maps to the ZTA tenet and specific control it affects. Citadel's action queue prioritizes implementation tasks by posture impact: which changes advance the most tenets, close the most control gaps, and move the organization furthest along the maturity model per unit of effort.

Zero Trust maturity is measured across five pillars defined by CISA's Zero Trust Maturity Model: Identity, Devices, Networks, Applications and Workloads, and Data. Each pillar has four maturity levels: Traditional (manual configurations, static policies, limited visibility), Initial (some automation, initial integration of identity and device signals, basic visibility), Advanced (automated provisioning, dynamic policies incorporating multiple signals, centralized visibility with analytics), and Optimal (fully automated, continuous verification, real-time policy adaptation, comprehensive analytics with machine learning). Each pillar progresses independently, meaning an organization may be at Advanced maturity in Identity while remaining at Initial maturity in Data. The maturity model provides a structured framework for prioritizing investment: advancing a pillar from Traditional to Initial typically delivers more security improvement per dollar than advancing from Advanced to Optimal. The model also identifies cross-pillar dependencies: Network maturity beyond Initial requires Identity maturity at Initial or above, because microsegmentation enforcement depends on identity-based policy decisions.

OMB M-22-09 maps specific capabilities to the CISA maturity pillars with defined targets for federal agencies. The Identity pillar requires agency-wide MFA with phishing-resistant authenticators, centralized identity management, and integration with authorization decisions. The Devices pillar requires a complete inventory of all devices authorized for government use, with endpoint detection and response deployed across the fleet. The Networks pillar requires DNS traffic encryption, HTTP traffic encryption for all internal communications, and network segmentation. The Applications and Workloads pillar requires application testing, secure development practices, and accessibility via the internet with appropriate ZTA enforcement. The Data pillar requires data categorization, data protection strategies aligned with the categorization, and automated monitoring for unauthorized data access. These requirements translate into specific control implementations that organizations must demonstrate through evidence, not assertions. Federal agencies must report progress through annual FISMA metrics. Defense contractors and organizations seeking federal authorization must demonstrate Zero Trust maturity appropriate to the sensitivity of the data they handle.

Rampart computes your Zero Trust maturity score across all five CISA pillars from live assessment data. Each pillar is scored against the four maturity levels based on the controls you have implemented, the evidence that supports them, and the freshness of that evidence. A radar visualization displays your current maturity level for each pillar alongside your target level, making gaps immediately visible. Rampart decomposes each pillar score into its component controls, so you can trace exactly which controls contribute to your current maturity level and which missing controls prevent advancement to the next level. Artificer analyzes your maturity profile and recommends the highest-impact actions for advancing each pillar. Artificer identifies cross-pillar dependencies: if your Network pillar advancement requires Identity pillar capabilities you have not yet implemented, Artificer sequences the remediation plan accordingly. The maturity score updates continuously as Sentinel collects new evidence, controls are implemented or degraded, and infrastructure changes affect your posture. Your Zero Trust maturity is not a point-in-time assessment prepared for a reporting deadline. It is a living measurement that reflects your current architectural state.

Zero Trust Architecture tenets map directly to NIST 800-53 control families, and those control families are the foundation of nearly every compliance framework in the federal and commercial ecosystem. The Access Control (AC) family implements tenets related to per-session access, dynamic policy, and continuous authorization. The Identification and Authentication (IA) family implements identity verification and dynamic authentication tenets. The System and Communications Protection (SC) family implements encrypted communication, microsegmentation, and data protection tenets. The Configuration Management (CM) family implements device integrity monitoring tenets. The System and Information Integrity (SI) family implements continuous monitoring and improvement tenets. The Audit and Accountability (AU) family implements the data collection tenet. Because CMMC Level 2 derives from NIST 800-171, which derives from the 800-53 Moderate baseline, every control you implement for Zero Trust simultaneously advances your CMMC posture. FedRAMP baselines select from the same 800-53 catalog. SOC 2 Trust Service Criteria cross-walk to 800-53 control families. ISO 27001 Annex A controls map through published NIST cross-references.

The relationship between Zero Trust and CISA's Zero Trust Maturity Model is direct and authoritative. CISA developed the maturity model specifically to help organizations measure their progress against the ZTA concepts defined in NIST 800-207 and the requirements established by OMB M-22-09. FedRAMP authorization increasingly incorporates Zero Trust requirements for cloud service providers, particularly those operating in moderate and high baselines. CMMC Level 2 and Level 3 environments handling CUI on defense networks face Zero Trust requirements that flow through DoD authorization conditions and the Defense Information Systems Agency (DISA) Security Technical Implementation Guides. Organizations pursuing multiple frameworks simultaneously benefit from the structural overlap: work done to satisfy ZTA requirements in the Identity pillar directly satisfies IA-family controls across every framework that includes them. Work done to implement microsegmentation for the Network pillar directly satisfies SC-7 across every framework that requires boundary protection. The investment in Zero Trust is not parallel to compliance investment. It is the same investment, measured through different lenses.

Rampart maintains the cross-reference engine that resolves these relationships through the NIST 800-53 derivation chain. As you implement Zero Trust controls, Rampart computes your readiness percentage for every framework in the catalog that shares the same underlying 800-53 controls. The computation is not an estimate. It resolves each individual control relationship through the derivation chain and accounts for framework-specific parameter differences. FedRAMP may require the same SC-7 control as your Zero Trust implementation but with specific FedRAMP parameter requirements for boundary protection mechanisms. CMMC may require the same IA-2 control but with NIST 800-171 parameter specifications for multi-factor authentication. Rampart tracks these parameter-level differences and scores compliance at the parameter level, not just the control level. When you activate a new framework assessment, it arrives pre-populated from your existing Zero Trust work. The marginal effort to add each subsequent framework decreases because the control overlap compounds through the derivation chain. One security posture. One Zero Trust Architecture. Every framework advanced simultaneously.