Streamlining CNSA 2.0 alignment with Ground Orbit Networks
Encrypted traffic can still be useful to an adversary who never breaks the tunnel today. Collect the ciphertext now. Store it. Wait until a cryptographically relevant quantum computer can recover the session keys that classical public-key algorithms used to protect it. That pattern is harvest now, decrypt later (often shortened to HNDL).
If your remote site, branch, or field location has data that must stay confidential for years, past the next circuit refresh, the path design has to answer that threat. Algorithm choice is only half the design. Who holds the keys that can turn ciphertext back into plaintext matters just as much.
Ground Orbit Networks operates a managed path from first mile through last mile into headquarters and cloud. For customers who need National Security Systems–oriented cryptography direction, Ground Orbit offers a CNSA-aligned connect-in option built around a hard rule: Ground Orbit must not hold keys that can decrypt customer payload. Payload decrypt capability stays with the customer (customer KMS, bring-your-own-key, or an external HSM). Ground Orbit operates the black path: ciphertext in transit. Payload decrypt stays with the customer.
That option is distinct from Ground Orbit’s default managed-path design, where Ground Orbit provisions and operates a post-quantum VPN on the first hop for path protection. The CNSA-aligned connect-in option adds a customer-held payload layer so Ground Orbit never holds the keys that turn your traffic into plaintext. Do not read path protection and payload custody as the same control.
The problem: classical crypto and patient collection
What HNDL actually is
On an untrusted underlay (commercial cellular, LEO satellite, metro Ethernet, or the public internet), an adversary who can observe or archive traffic does not need to break encryption in real time. They need enough recorded ciphertext and enough time for future cryptanalysis to matter.
Classical key-establishment algorithms that dominate today’s VPNs (RSA and elliptic-curve Diffie–Hellman families) are the part that fails first against a large-scale quantum computer. Symmetric algorithms at CNSA-class strengths (for example AES-256) remain the durable layer once keys are established correctly. The urgent change is how those keys are established and who can ever recover them.
HNDL is its own threat class beside an active compromise of a router. Persistence on network devices and bulk collection of ciphertext stack. A path that is always up can still be the wrong path if today’s key exchange is worth archiving.
What CNSA 2.0 covers
CNSA 2.0 is the NSA’s Commercial National Security Algorithm Suite 2.0: the quantum-resistant algorithm set and transition direction for National Security Systems (NSS). Public NSA materials name algorithms such as AES-256, SHA-384 / SHA-512, ML-KEM-1024 for key establishment, and ML-DSA-87 for signatures, with staged timelines for when NSS must support, prefer, and then exclusively use those algorithms. New NSS acquisitions are expected to support CNSA 2.0 algorithms on the Agency’s published schedule (commonly cited from January 1, 2027 for new acquisitions, with category-by-category exclusive-use dates into the early 2030s).
CNSA 2.0 is a cryptography and procurement roadmap for NSS. Ground Orbit sells managed connectivity aligned to that direction; CNSA itself is the Agency’s algorithm suite and transition schedule. Citing it does not make a commercial managed path “CNSA certified.” Ground Orbit does not claim CSfC approval, NIAP validation, or CNSA product certification in this post. What we claim is design direction: help customers align site-to-cloud connectivity with that algorithm and key-custody intent.
What breaks in a legacy managed-path model
Legacy WAN design often stops at “put a VPN on the circuit.” That can leave you with:
- Classical-only key exchange on the outer path, so archived sessions remain a long-term gift to a patient collector.
- Provider-held decrypt keys for the payload, so the operator of the managed path can read what the customer meant only the customer to read.
- One long-lived tunnel with no plan to rotate algorithms when standards move (no crypto agility).
- Marketing language that says “quantum-safe” without naming who holds decrypt, which algorithms apply on which segment, or what evidence you get at cutover.
For mission and government-adjacent environments, those gaps are the difference between a brochure and an architecture you can defend in review.
Solution overview: black path + customer-held payload keys
Ground Orbit’s answer for this option is deliberate and narrow.
Default rule for the CNSA-aligned connect-in option: encrypt customer payload with keys the customer holds before traffic enters Ground Orbit’s operated path. Plaintext stays on the customer red side only. Ground Orbit receives ciphertext and carries it across first mile, managed core in colo points of presence, and last mile / private cloud attach.
Path protection on the underlay, including post-quantum path crypto on Ground Orbit’s default managed path, hardens carrier exposure. It is a separate control from payload custody. When the customer-held payload layer is required, underlay path crypto leaves payload plaintext with the customer. Path crypto hardens the underlay; the customer-held payload layer remains the custody control for this option.
Architecture at a glance
| Concern | Legacy complexity | What Ground Orbit streamlines |
|---|---|---|
| HNDL exposure | Classical key exchange on long-lived tunnels worth archiving; provider can decrypt the only layer | Customer-held payload crypto (algorithms per engagement against the CNSA 2.0 floor) so archived classical sessions stay opaque to anyone who held only the path. Path post-quantum crypto is separate underlay hardening; customer-held payload crypto is the HNDL answer for this option |
| CNSA 2.0 direction | Slides that say “aligned” without a key-custody story | Algorithm floor from public CNSA 2.0 guidance, plus a connect-in model that keeps payload decrypt out of Ground Orbit custody |
| Who can read the payload | Managed VPN where the provider holds the keys | Customer KMS / BYOK / external HSM for payload decrypt; Ground Orbit operates the black path |
| Procurement and ops | Separate crypto project + separate WAN project | One managed connect-in service: you attach with payload already encrypted; Ground Orbit runs the black underlay and day-two path operations |
This post is about CNSA 2.0 alignment and HNDL protection on the managed path. A separate Ground Orbit article covers zero-knowledge-style architecture for encryption keys in more depth. Do not treat this piece as that full key-architecture brief.
Walkthrough: how you join without handing Ground Orbit plaintext
This is a managed service. You bring requirements and custody. Ground Orbit supplies the black-path attach and operates the path.
Step 1: Name what must stay confidential for years
Before design lock, write down:
- Which flows leaving each site still matter in five or ten years (SCADA, mission telemetry, identity, CUI, or other long-lived confidentiality classes).
- Whether those flows fall under NSS cryptography direction for your program, or under a commercial risk posture that still wants the same HNDL defenses.
- Who must hold decrypt keys: your KMS, your HSM, or a bring-your-own-key arrangement Ground Orbit never exports.
- Destinations that must stay on the same managed path: headquarters, partner network, on-prem data center, over AWS Direct Connect as the primary cloud path.
Hand that inventory to Ground Orbit in the site and mission review. Do not start with a brochure claim of “quantum-safe” and reverse-engineer custody later.
Step 2: Put payload encryption on the customer red side
Legacy designs often let the managed-path operator terminate the only encryption layer. For this option, invert that:
- Encrypt on your red side (your LAN, your approved crypto edge, your HSM/KMS boundary) so plaintext exists only there. Use algorithms agreed for the engagement against the CNSA 2.0 floor.
- Hand Ground Orbit ciphertext only. Dual-router CPE and the managed black path never see payload plaintext.
- Prefer patterns where your inner customer crypto stays intact end to end (including dual-encrypt / Type-1-style gear you already run before the CPE, or encrypting independently into your cloud VPC). Do not make Ground Orbit the sole terminator of the payload security association.
- Confirm in writing: Ground Orbit ops has no export of customer payload decrypt keys.
If a design would let Ground Orbit decrypt customer payload with Ground Orbit–owned keys, it is the wrong profile for this option.
Step 3: Attach into the managed black path
Once payload custody is set:
- Connect your site LAN into Ground Orbit–provided routers (dual CPE by default).
- Ground Orbit attaches first-mile transports (5G, LEO satellite, or private circuit), often bonded when the site cannot live through a single-carrier outage.
- Traffic crosses the managed core in colo points of presence and reaches headquarters or AWS on private WAN / AWS Direct Connect.
- Underlay path protection (including post-quantum path crypto where the managed path uses it) hardens carrier exposure. Treat it as black-on-black path protection beside your customer-held payload layer. Keep both in place.
Validate reachability with Ground Orbit. Cut over only after custody and path checks pass.
Step 4: Keep crypto agility on the operating checklist
CNSA 2.0 transition dates move by equipment category. Your path should not depend on a single frozen classical tunnel.
- Prefer designs that can change key-establishment algorithms without redesigning every site.
- Prefer short-lived sessions and clear rotation practice over one archive-worthy tunnel.
- At review, ask which algorithms apply on which segment, who holds decrypt, and what evidence you receive at cutover. Require that evidence in writing.
Considerations
Security
- Multi-tenant isolation keeps customers in separate Layer 2 / Layer 3 contexts on the managed path. Single-tenant is available when your security requirements need it.
- State the trust boundary in every design review: customer red → customer-held encrypt → Ground Orbit black path → authorized destination.
- Do not confuse path monitoring with payload inspection. Ground Orbit operates the path; on this option, payload decrypt stays with the customer.
Cost and procurement
You buy one managed connect-in service and one bill for the path Ground Orbit operates. Customer KMS, HSM, or Type-1-style products you already run stay on your side of the custody line. Commercial terms live in the signed service agreement. Uptime percentages and certification logos belong only in that agreement when they have been earned.
Operations
Ground Orbit owns day-two operations of the black path: transports, bonding, middle mile, cloud attach, and service desk under the service agreement. You own applications, site LAN, and payload key custody. Incident response on the path leaves customer decrypt keys with the customer.
Conclusion / next steps
HNDL makes “encrypt the circuit and move on” incomplete. Classical public-key algorithms that protect most tunnels today are exactly what a future cryptographically relevant quantum computer is expected to break. CNSA 2.0 names the algorithm direction for National Security Systems. Alignment for a managed commercial path also requires a custody answer: who can decrypt.
Ground Orbit Networks helps by operating a managed black path while keeping payload decrypt keys customer-held, so we can carry your traffic without holding the keys that turn it into plaintext. That is how we help you align site-to-cloud connectivity with CNSA 2.0 direction and harden against harvest-now-decrypt-later collection, without claiming a certification we have not earned and without decrypting for you.
Contact us to discuss your use case: brianlauer@groundorbitnetworks.com · groundorbitnetworks.com