The aerospace and defense sector operates under a set of security and compliance constraints that most organizations never face. You're not just protecting data. You're protecting controlled unclassified information, managing international traffic in arms regulations, and satisfying auditors from federal agencies. Your network security decisions directly impact your ability to bid on contracts, maintain certifications, and access classified programs.
Zero Trust Network Access (ZTNA) is often presented as a universal solution for remote work and distributed teams. But off-the-shelf cloud-proxied ZTNA creates a serious problem for defense contractors: it introduces third-party cloud providers into your ITAR compliance boundary. When your network traffic transits Zscaler's cloud or Cloudflare's network, you've just made those companies part of your security perimeter. For ITAR-controlled data, that's not just a technical decision. It's a compliance liability.
Bowtie Security was built to solve this specific problem. Sovereign, direct-routed ZTNA keeps your traffic on infrastructure you control, your data never transits a third-party cloud, and your compliance story stays clean.
Why Aerospace and Defense Requires Different Security Architecture
The regulatory environment for defense and aerospace organizations is built on a simple premise: the government owns access to your network. Three regulations define the boundaries of what you can and cannot do with network security architecture.
ITAR (International Traffic in Arms Regulations) restricts the dissemination of defense articles and technical data to U.S. citizens and approved foreign persons. ITAR data includes designs, specifications, and manufacturing processes for weapons systems, aircraft, engines, and related components. When ITAR data transits a network, that network is subject to ITAR requirements. If your network traffic passes through a foreign-owned cloud infrastructure, you've just created an ITAR violation risk. The State Department's Directorate of Defense Trade Controls doesn't provide waivers for cloud providers.
CMMC 2.0 (Cybersecurity Maturity Model Certification) is the Department of Defense's mandatory certification requirement for contractors and subcontractors. CMMC Level 1 requires basic security practices. CMMC Level 2 requires implementation of 171 specific security controls aligned to NIST SP 800-171. Level 3 and above require additional controls for classified information handling. Most prime contractors require subcontractors to achieve Level 2 certification before contract award. The network architecture you choose must support CMMC control verification, particularly AC-3 (access control) and SC-7 (boundary protection).
FedRAMP (Federal Risk and Authorization Management Program) applies when you're providing cloud services to federal customers or hosting federal data in cloud environments. FedRAMP-authorized cloud providers operate under specific security baselines. But FedRAMP authorization doesn't eliminate ITAR requirements. A FedRAMP-authorized cloud provider can still violate ITAR if your traffic includes ITAR-controlled technical data.
CUI (Controlled Unclassified Information) is handled under NIST SP 800-171 and DFARS 252.204-7012. CUI data must be protected according to its marking level. Your network segregation, access controls, and encryption requirements scale with the sensitivity of the data you handle. An aerospace company managing both unclassified commercial designs and ITAR-controlled military components needs network architecture that supports compartmentalization.
These regulations aren't optional compliance checkboxes. They determine who you can hire, what infrastructure you can use, and which customers will do business with you.
Why Cloud-Proxied ZTNA Creates Compliance Risk
Commercial ZTNA solutions like Zscaler and Cloudflare offer significant advantages: they're easy to deploy, they scale automatically, and they work well for organizations that need remote access without managing appliances. But they introduce a fundamental architectural problem for defense contractors.
When you use cloud-proxied ZTNA, your network traffic is decrypted, inspected, and re-encrypted at a third-party data center. Zscaler operates data centers globally, including in foreign countries. Cloudflare operates a distributed network across multiple jurisdictions. This is fine for commercial organizations. It's not fine when your traffic includes ITAR data.
Here's the specific compliance problem: ITAR considers any system that touches ITAR data part of your ITAR compliance boundary. When your network traffic passes through a third-party cloud, that cloud provider is part of your boundary. The State Department expects you to maintain effective control over ITAR data at all times. Control means you have direct ownership, direct access, and direct visibility into where that data goes and who can access it.
Using a cloud-proxied ZTNA provider means your ITAR control is now shared. The cloud provider has access to your unencrypted traffic. The cloud provider's infrastructure, compliance practices, and personnel policies are now part of your ITAR boundary. This creates audit problems. When the Defense Counterintelligence and Security Agency (DCSA) audits your CMMC compliance, or when you're preparing for a Customer Facility Security Review (CFSR), you'll need to justify why using a foreign-associated cloud provider for ITAR data traffic is appropriate. The answer is: you can't.
The compliance exposure is real. Defense contractors have been cited for ITAR violations for less intrusive decisions. In 2021, a prominent aerospace company was found to have transmitted ITAR-controlled technical data through unsecured email. The penalty was millions in fines and contract suspension. Using cloud-proxied ZTNA for ITAR data isn't as obviously wrong as email, but the compliance boundary issue is similar.
Additionally, if your cloud ZTNA provider is breached or subpoenaed, ITAR data may be exposed. You don't control the incident response or the disclosure process. Your compliance story becomes dependent on another company's security practices and legal obligations.
Sovereign ZTNA: Keeping Data on Your Infrastructure
Sovereign ZTNA means your network traffic stays on infrastructure you control. There's no third-party cloud intermediary. Traffic is encrypted end-to-end, and decryption happens on your network. You maintain complete visibility and control.
Bowtie's architecture accomplishes this through direct-routed network access. Instead of proxying traffic through a cloud service, Bowtie establishes direct encrypted tunnels from users to your network infrastructure. The Bowtie controller is the only cloud component. It handles policy decisions and authentication. The actual data path is direct and encrypted. Your data never leaves your infrastructure.
This design solves the ITAR compliance problem immediately. Your ITAR boundary is your network. Your control is not shared with a third party. Auditors can verify that ITAR data doesn't transit foreign infrastructure. Your CMMC 2.0 controls remain under your ownership.
The direct-routed approach also provides concrete security advantages. You have complete visibility into access patterns. You can implement compartmentalized access controls that separate different classified programs or customer contracts. You're not dependent on a cloud provider's incident response or disclosure practices. If there's a breach, you control the investigation and notification process.
There are operational tradeoffs. You're managing appliances instead of relying on managed cloud services. You need to maintain uptime and redundancy. But for organizations handling ITAR or high-sensitivity CUI, this tradeoff is straightforward. Control and compliance are more important than operational convenience.
Specific Use Cases in Defense and Aerospace
Secure Access Across Multiple Classified Programs. A large prime contractor manages contracts with the Air Force, Navy, and Army. Each program has separate classification levels, separate data compartments, and separate compliance requirements. The contractor needs to provide remote access to employees who work on multiple programs, but data from Program A must be compartmentalized from Program B.
Cloud-proxied ZTNA can't effectively implement program-level compartmentalization. The cloud provider's network sees all traffic. A misconfiguration or breach could expose data across programs. Sovereign ZTNA allows the contractor to build separate network segments for each program, with access controls tied to specific individuals' security clearances and program assignments. A network engineer can work on Program A, be promoted to Program B, and have their access updated within hours. Program data never transits shared infrastructure.
Contractor Workforce Management. Defense primes frequently work with specialized subcontractors. An aerospace company building a missile guidance system works with a company that specializes in inertial sensors. The sensor company's employees need access to the prime's network to view design specifications and integration requirements. But they shouldn't have access to the overall system architecture or combat effectiveness data.
With cloud-proxied ZTNA, you're trusting the cloud provider's network to compartmentalize that access. If the cloud provider is misconfigured, or if the subcontractor's network is compromised, data could be exposed. With sovereign ZTNA, the sensor company's employees connect directly to a specific segment of the prime's network. Access is controlled by the prime's policy, not by a cloud provider's capabilities. If the subcontractor's network is compromised, the damage is limited to the specific segment they have access to.
Multi-Site Manufacturing Access. A large defense contractor operates manufacturing facilities in three states. Engineers in corporate headquarters need remote access to production floor monitoring systems, quality control data, and supply chain integration systems. Some employees need access to multiple facilities. Some need access to only one.
Cloud-proxied ZTNA aggregates all traffic through a central cloud proxy. This creates latency for engineers accessing local production systems. It creates a bottleneck for large data transfers of design or quality control records. Sovereign ZTNA can route local traffic locally. An engineer at Facility A accessing a production monitoring system at Facility A connects directly to Facility A's network. Traffic doesn't transit a cloud provider. Latency is minimal. Data transfer rates are not constrained by cloud proxy throughput.
Air-Gapped and Partially-Connected Environments. Some classified defense programs operate in air-gapped or low-bandwidth networks. An air-gapped network has no connection to the internet. A partially-connected network has limited external connectivity, usually through a single monitored gateway. Deploying cloud-proxied ZTNA in these environments is difficult or impossible. Sovereign ZTNA can be deployed with a local controller and minimal internet dependency. Users connect through local network infrastructure. The system works even in extreme connectivity scenarios.
CMMC 2.0 Control Mapping and ZTNA
CMMC 2.0 defines specific security controls that ZTNA helps satisfy. Understanding this mapping is essential for contractors planning their network architecture.
AC-2: Account Management. CMMC requires that system accounts be created, enabled, disabled, and removed based on role and responsibility. ZTNA policy ties access decisions to identity and role. A user's access profile is their identity plus their assigned program or facility. When a user is assigned to a new program, their ZTNA policy is updated. When a user leaves the company, their access is revoked within hours.
AC-3: Access Control. This is the core control. CMMC requires that access to information and information systems is restricted to authorized users, processes, and devices acting on behalf of authorized users. ZTNA enforces access at the network layer. A user without proper authorization cannot even establish a network connection to a resource. This satisfies AC-3 more directly than traditional firewall rules, which operate at the port and protocol level and assume network-layer authentication is already handled.
AC-4: Information Flow Control. CMMC requires that information flows within systems and between systems are controlled based on the types of information and the requirements associated with information and information system partitions. ZTNA implements flow control by connecting users to specific network segments. A contractor employee in the commercial division doesn't have a network path to the classified division. Even if their credentials are compromised, the network path doesn't exist.
SC-7: Boundary Protection. This control requires monitoring and control of communications at external boundaries of systems. ZTNA provides granular boundary protection. External users (contractors, remote employees) don't have direct access to internal networks. All external connections are authenticated and policy-controlled. The network boundary is enforced at the identity and device level, not just at the port level.
SI-4: Information System Monitoring. CMMC requires monitoring of systems for unusual or suspicious activity. ZTNA provides detailed logging of all access attempts: who connected, what they accessed, when, and from what device. This data is essential for CMMC audits and incident investigations.
Implementing CMMC 2.0 requires integration of multiple security technologies: identity and access management, network segmentation, device management, vulnerability management, and incident response. ZTNA is the enforcement point for identity-based access control and boundary protection. It doesn't eliminate the need for the other technologies, but it aligns your access architecture to the CMMC control framework.
Deployment Considerations for Defense Organizations
Deploying sovereign ZTNA in a defense contractor environment requires specific attention to operational and compliance requirements.
High Availability and Failover. Defense contractors can't tolerate extended network outages. Critical applications must be accessible even if a primary data center fails. Sovereign ZTNA architecture should include geographic redundancy with automatic failover. This requires additional infrastructure compared to cloud-proxied ZTNA, but it's necessary for mission-critical applications.
Encryption and Key Management. All traffic must be encrypted end-to-end. The encryption keys must be managed internally, not held by a cloud provider. Key rotation must be auditable. CMMC 2.0 and NIST SP 800-171 specify encryption requirements for data in transit and at rest. Your ZTNA system must support these requirements natively.
Device Trust and Posture Checking. CMMC 2.0 requires that access decisions account for device health: is the device patched, is antivirus current, is the operating system configured securely. ZTNA policy can enforce device posture requirements. A contractor employee trying to connect from a personal laptop with outdated patches is blocked, even if their identity credentials are valid. This requires integration between your ZTNA system and your mobile device management or endpoint detection platform.
Audit and Compliance Logging. Defense auditors will demand logs. Who accessed what. When. From where. On what device. All logs must be retained for a specific duration (usually three years). Logs must be tamper-protected. Your ZTNA system must be designed with audit logging as a core requirement, not an afterthought.
Integration with Existing DFARS and CMMC Compliance Infrastructure. Most contractors already have security monitoring, vulnerability management, and incident response processes in place. Your ZTNA deployment should integrate with these existing systems, not replace them. The ZTNA logs should feed into your security information and event management (SIEM) system. The device trust data should come from your existing mobile device management platform. Integration reduces operational complexity and ensures consistency across your security posture.
Contractor and Subcontractor Access. Managing access for external contractors is a persistent challenge. A contractor employee needs temporary access to specific resources while their background investigation is pending. Another contractor is assigned to multiple programs and needs tiered access. ZTNA policy must support temporary access with automatic expiration, multi-program access with compartmentalization, and contractors from foreign companies with appropriately limited access. This requires flexible policy configuration and regular access reviews.
The Compliance Reality Check
Ultimately, the choice between cloud-proxied ZTNA and sovereign ZTNA is a compliance choice, not a technology choice. Cloud-proxied solutions are mature, well-supported, and operationally convenient. But they create compliance complications for organizations handling ITAR or high-sensitivity CUI. When you're subject to State Department regulations and Defense Department audits, convenience is the wrong optimization target.
Sovereign ZTNA means your network architecture aligns with your regulatory requirements. Your compliance boundary is your network. Your control is not shared. Your auditors see a clear, defensible architecture. That alignment is what defense contractors need.
