The reason weapon systems maintain dedicated circuits is straightforward: classified data requires protected transport, and historically, protected transport meant physically separate networks. SIPRNet for Secret. JWICS for Top Secret/SCI. Dedicated circuits for anything that didn't fit those categories cleanly.
That model worked when networks were physical. It becomes prohibitively expensive when every weapon system maintains its own physical transport alongside the enterprise networks that already exist at the same sites.
The alternative isn't to trust unprotected transport with classified data. The alternative is to encrypt the data so thoroughly that the transport doesn't matter — and then use whatever transport is available, reliable, and cost-effective.
Black core: the transport doesn't see the data
The black core network concept substitutes cryptographic protection for physical separation. Classified (Red) data is encrypted at the source into unclassified (Black) data, routed over a shared transport network, and decrypted at the destination. The transport network — the "black core" — never sees plaintext classified data. It routes encrypted packets without knowing or caring what's inside them.
This means the transport network doesn't need to be classified. It doesn't need to be dedicated. It doesn't need to be a specific network. It needs to be available, reliable, and sufficient bandwidth — and those are requirements that multiple transport options can satisfy:
- DISN backbone — DISA's enterprise transport, already present at most DoW sites
- Commercial terrestrial circuits — leased IP transport that meets bandwidth and reliability requirements
- MILSATCOM — AEHF, WGS, and next-generation protected SATCOM providing global reach to forward and remote sites
- Commercial SATCOM — including low-earth-orbit constellations like Starlink, offering low-latency broadband to locations where terrestrial circuits are unavailable or cost-prohibitive
- Existing site infrastructure — network capacity already installed for other purposes
The weapon system uses whatever transport is available. The security is in the encryption, not the wire.
The Army deployed this model operationally in Afghanistan, carrying multiple classification levels over a single IP transport network. The concept isn't theoretical — it's fielded.
CSfC: commercial encryption for classified data
NSA's Commercial Solutions for Classified (CSfC) program enables the use of layered commercial encryption products to protect classified data — replacing expensive, long-lead-time Type 1 HAIPE encryptors with commercial products that can be deployed in months at a fraction of the cost.
The model requires two independent layers of encryption from different manufacturers — eliminating single-point cryptographic failure. NSA maintains a Components List of evaluated products, and provides Capability Packages for specific use cases: multi-site connectivity, mobile access, campus wireless, and data at rest.
For weapon system networking, CSfC changes the economics:
| Factor | HAIPE (Traditional) | CSfC (Commercial) |
|---|---|---|
| Procurement cost | $30K-$80K per pair | Fraction of HAIPE cost |
| Lead time | Months to years | Weeks to months |
| Refresh cycle | 5-7 years | Standard commercial refresh |
| Vendor options | Limited | Multiple COTS vendors |
| Key management | Dedicated infrastructure | Integrated with commercial PKI |
| Capability | Point-to-point | Flexible topology including SD-WAN |
A weapon system that replaces HAIPE encryptors with CSfC-approved layered encryption at each site reduces the per-site encryption cost, shortens the refresh cycle, and opens the door to flexible transport options that HAIPE's rigid point-to-point model doesn't support.
Software-defined networking: policy replaces plumbing
The traditional weapon system network is configured physically. Routing decisions are made by hardware configuration. Changing a data flow means changing router configs, firewall rules, and encryption device settings at multiple sites — a change management process that takes weeks and requires authorization review.
Software-defined networking replaces this with policy. DISA's Software Defined Enterprise program is bringing this to the DoW enterprise — automating network provisioning so that connectivity is configured through policy rather than physical change.
For weapon systems, SDN provides:
Policy-driven routing. Data flows are defined by policy — which data goes where, at what classification, with what priority. Changing a data flow is a policy update, not a hardware reconfiguration. The network adapts to mission requirements rather than the mission adapting to network constraints.
Dynamic provisioning. A new site, a new sensor, a new processing node connects to the weapon system's network through policy — not through a circuit provisioning effort that takes months. The transport is already there; the policy defines how to use it.
Classification-aware segmentation. Data at different classification levels can travel the same physical transport because the encryption and policy layers enforce separation — not the wires. The network provides logical segmentation without requiring physical separation for each classification level.
Resilient transport. If one path fails, the SDN controller routes traffic over an alternative path automatically — across DISN, commercial terrestrial, MILSATCOM, commercial LEO SATCOM, or any available transport that meets the policy requirements. A weapon system with a remote sensor site that loses its dedicated circuit today goes offline. A weapon system on SDN-managed encrypted transport — with pre-provisioned alternative paths — fails over to commercial terrestrial, MILSATCOM, or commercial LEO SATCOM automatically. The weapon system's availability doesn't depend on the availability of a single dedicated circuit.
Geopolitical routing awareness. Where the transport fabric supports geographic path awareness, policy can route traffic around geographic nodes as geopolitical conditions require — ensuring that data traverses only approved sovereign territories and avoids infrastructure in regions where transit poses an operational or intelligence risk. A dedicated circuit has a fixed path. A policy-aware SDN fabric can reroute dynamically when the geopolitical landscape changes, without manual reconfiguration.
Continuous monitoring. The SDN controller sees the entire network — traffic flows, latency, utilization, anomalies — in real time. Security monitoring is integrated into the network fabric rather than bolted on per-system.
What this means for authorization
A weapon system that moves from dedicated circuits with HAIPE encryptors to encrypted transport over shared infrastructure changes its authorization boundary. The network infrastructure is no longer part of the weapon system's ATO — it's part of the enterprise transport's authorization. The weapon system's authorization scope narrows to the encryption endpoints and the application, which is a simpler, faster assessment.
This is the same authorization benefit described in the IT modernization series for compute: shared infrastructure carries the infrastructure authorization, and the weapon system authorizes at the application level. For networking, the principle is identical — the transport is authorized by whoever operates it, and the weapon system is responsible for the encryption that protects its data on that transport.
The AO's office benefits directly: one fewer dedicated network authorization per system that migrates. The SCA assesses the encryption architecture once, not the network infrastructure at every site.
The model already exists at the application layer
Program offices running applications on enterprise platforms like Platform One are already using this model — they just don't call it SDN. Istio service mesh provides policy-driven traffic management, mTLS encryption, observability, and routing at the container level. SDN provides the same capabilities at the infrastructure level. The concepts are parallel: abstract the application from the physical transport, enforce security through policy rather than physical separation, and manage changes through configuration rather than hardware reconfiguration.
The operational model converges too. If the program office is already using GitOps for application deployments — desired state declared in version control, automated reconciliation, audit trail, peer review, rollback — the same model applies to network configuration. Network-as-code eliminates the manual change management process that makes network updates take weeks. A routing change becomes a reviewed, version-controlled policy update rather than a site visit with a change request.
The testing model extends too. In application DevSecOps, code merges trigger automated tests that validate functionality before deployment. The network equivalent: a proposed configuration change triggers an emulated network test that validates routing, latency, throughput, and service-level minimums against the weapon system's operational requirements — before the change is published to production. Configuration that would degrade availability or violate performance thresholds is caught in the pipeline, not discovered in operations.
This isn't standard practice for DoW network operations today. But the tooling exists, the principles are proven at the application layer, and the program offices already doing DevSecOps for compute are positioned to extend it to networking with minimal conceptual overhead.
The reliability question
Program offices will ask: is shared transport as reliable as my dedicated circuit?
The answer depends on the implementation. A single shared circuit is not more reliable than a single dedicated circuit. But a software-defined network that can route traffic over multiple available paths — DISN backbone, commercial transport, existing site infrastructure — is more resilient than a single dedicated circuit that has no failover.
The dedicated circuit's reliability model is: if this circuit fails, the weapon system loses connectivity until the circuit is restored. The SDN model is: if this path fails, traffic routes over an alternative path automatically. The reliability is in the fabric, not in any single wire.
This is the same argument from the availability post: dedicated isn't inherently more reliable. It's more familiar. The enterprise alternative, properly implemented, provides redundancy that no single dedicated circuit can match.
Robert Burckner is the founder of Millabs Corporation, a Service-Disabled Veteran-Owned Small Business. He has served as ISSM and ISSE for legacy weapon systems at the Air Force Lifecycle Management Center — including work on the DoW TDM circuit elimination initiative — and as Division Chief at the Space Warfighting Analysis Center (USSF/NRO).
If your program is evaluating whether its weapon system's dedicated network infrastructure could migrate to encrypted enterprise transport, contact Millabs. This assessment can be performed independently on behalf of the program office through existing government contract vehicles.