The Post-Quantum
Enterprise VPN

1. The Access Problem

1.1 Implicit trust is the legacy default

Traditional VPNs were designed to extend the corporate network to a remote user. Once connected, the user typically gains broad reachability into internal systems, governed — if at all — by network segmentation that is difficult to maintain and easy to misconfigure. Zero-trust network access (ZTNA) products improved the model but frequently re-introduced the same weaknesses at the edges: brokered tunnels with implicit east-west reach, policy enforced inconsistently across platforms, and identity decisions that are not cryptographically bound to the device actually carrying the session.

1.2 Classical cryptography is now a dated assumption

Nearly every VPN and ZTNA product in production today protects sessions with classical-only key establishment. Under the "harvest now, decrypt later" model, an adversary with access to fibre taps, cloud transit, or compromised intermediate equipment captures encrypted traffic today and decrypts it once a cryptographically-relevant quantum computer arrives — with public industry roadmaps placing that window in the early-to-mid 2030s. For banking, healthcare, legal, defence, and regulated professional-services communications, whose confidentiality horizon runs 7–30+ years, every classical-only session established now is a future disclosure.

1.3 Two predictable procurement failures

• Failure A — harvested exposure. Every session on a classical-only access platform contributes to an adversary's long-term harvest.
• Failure B — forced retrofit. Every classical-only access platform deployed now will need a disruptive cryptographic retrofit on a hard regulatory deadline (CNSA 2.0 mandate windows of 2027–2031), during a period when every other regulated organisation is attempting the same migration.

AegisWire is designed so a customer can adopt a modern zero-trust access posture and resolve both failures in a single procurement.

2. Design Goals

The AegisWire VPN platform is built to five binding goals:

1. Zero-trust, default-deny access. No connectivity without an explicit, verified authorisation tied to tenant, user, and device. The absence of a denial is never permission.
2. Post-quantum by default, everywhere. Every session, every customer, every deployment shares one cryptographic posture. No negotiation to a weaker suite, no classical-only lane for lower tiers.
3. Policy integrity end to end. Access policy is authored once in the management platform, cryptographically signed, and verified at every gateway before enforcement — eliminating drift, tampering, and silent override.
4. Observability without surveillance. Operators get the telemetry they need to run the service; they never get the ability to read customer traffic. Privacy-preserving monitoring is the production default, not an add-on.
5. One posture, any boundary. The same access model, policy enforcement, and cryptographic posture runs in managed SaaS, dedicated, self-hosted/sovereign, and hardware-appliance modes. Customers choose the operational boundary, not the security level.

3. How AegisWire Works

The platform is organised into three layers that together deliver governed, post-quantum access.

3.1 The client

A native client runs on macOS, Windows, Linux, iOS, and Android, with one uniform security posture — mobile and Linux clients are not weaker builds. It enforces an operating-system-level kill switch, performs secure in-tunnel DNS resolution, applies full- or split-tunnel routing by administrative intent rather than user preference, and roams seamlessly across wired, Wi-Fi, and cellular networks without interrupting the session. The client consumes signed policy and signed trust-chain artefacts and verifies them on receipt.

3.2 The gateway network

A global network of regional gateway pools is the cryptographic and policy-enforcement layer. Every session terminates at a gateway that verifies the client's cryptographic presence against the signed trust chain, evaluates the published policy for that tenant, user, and device, enforces default-deny, applies privacy-preserving monitoring without content inspection, and participates in DDoS-resistant connection setup that requires proof of origin before committing resources. Pools support controlled draining, capacity-aware scaling, and deterministic failover, with connection-affinity routing that keeps established sessions stable during membership changes.

3.3 The management platform

The management platform is the customer's authoritative control surface: it authors and publishes signed policy, manages identity and certificate lifecycles, runs the enterprise admin console, and issues the audit-evidence bundle. Policy is signed end to end and verified before enforcement; certificate issuance, rotation, and revocation are integrated platform operations with revocation propagating through the trust chain; and each tenant operates with isolated resources and separate key material, so cross-tenant separation is structural rather than policy-gated.

4. Access and Policy Model

The access model is where AegisWire differs most from a commodity tunnel. Each control below is enforced, not advisory.

4.1 Device enrolment and identity binding

Onboarding binds device identity to the user and to policy relationships. Connectivity requires verified enrolment, not merely valid user credentials — a stolen password without an enrolled, trusted device does not yield access. Credential refresh and revocation are managed platform operations; revocation propagates through the trust chain, not just the directory.

4.2 Full- and split-tunnel by administrative intent

Routing is decided by policy, not by the user. Administrators define which traffic is carried in-tunnel and which is permitted to egress locally, with split-DNS and per-application matching evaluated consistently across platforms. The user cannot quietly route sensitive traffic around the policy.

4.3 Secure DNS and per-application policy

DNS resolves inside the tunnel under policy, with split-DNS rules evaluated before generic split-tunnel rules; when strict DNS policy cannot be satisfied, the client blocks rather than leaks. Per-application rules bind routing and DNS behaviour to the same application matchers, so policy follows the application, not just the destination address.

4.4 Always-on kill switch and seamless roaming

The kill switch is enforced at the operating-system level: if the tunnel is not healthy, traffic does not leak to the open network. Sessions survive network changes — Wi-Fi to cellular, office to field — without dropping or requiring reconnection, so enforcement is continuous even on the move.

4.5 Default-deny enforcement

At every gateway, connectivity is granted only by an explicit, signed authorisation matching the connecting tenant, user, and device. There is no implicit east-west reach, no "connected therefore trusted" state, and no path by which a gateway can enforce a policy that was never authored in the management platform.

5. Governance, Privacy, and Evidence

A regulated buyer evaluates an access platform on how it is governed and what it can prove, not only on what it can do.

5.1 Privacy-preserving monitoring

Operational visibility — gateway health, session counts, policy-enforcement outcomes — is available without content inspection, payload logging, or cross-tenant aggregation. The platform is designed so that an operator cannot, even with full administrative access, read a customer's traffic. Privacy is the production default, not a configurable option a customer must remember to enable.

5.2 Audit and policy provenance

Policy publication is recorded as an auditable, tamper-evident trail: who authored a policy, when it was signed, and which gateways verified and applied it. Because gateways verify signatures before enforcement, the audit record reflects what was actually enforced — not merely what was intended.

5.3 The evidence bundle

AegisWire ships a standard evaluation bundle, available under NDA, designed to pass an internal security-review committee in week one of engagement:

• Software Bill of Materials (SBOM) — per release, in CycloneDX or SPDX format.
• Reproducible-build attestations — release artefacts rebuildable byte-for-byte from source.
• Signed release manifests — every binary, container image, and client release signed.
• Architecture and threat-model documentation — adversary model, mitigations, and residual risk.
• Incident-response runbook — escalation paths, named roles, notification SLAs, forensic preservation.
• DPA, sub-processor list, and SLA — UK IDTA and EU SCCs attached; service-credit-backed availability terms.
• Vulnerability-disclosure policy — published, with a safe-harbour commitment and a security@aegiswire.com contact.

6. Deployment Models

AegisWire delivers the same access model, policy enforcement, and cryptographic posture across four deployment models. Customers choose on residency, isolation, and operational-control requirements — never on security capability.

6.1 Managed SaaS

AegisWire operates the management platform and gateway network. The customer retains full policy authorship, administrative control, and certificate ownership. Fastest path to production for customers whose compliance regime permits vendor-operated infrastructure.

6.2 Dedicated single-tenant

A dedicated, isolated management-platform instance and dedicated gateway infrastructure, with custom update schedules and tenant-specific operational controls. The standard option for regulated customers needing stronger isolation than a shared fleet without operating the platform themselves.

6.3 Self-hosted / sovereign

The customer operates AegisWire inside their own cloud account, data centre, or sovereign enclave, controlling infrastructure, update cadence, network boundaries, and residency, with AegisWire providing software, trust anchors, signed releases, and support. For strict sovereignty, classification, or air-gap requirements.

6.4 Hardware appliance

A rack-mount appliance for customer-controlled edge enforcement, running the same trust model, policy enforcement, and cryptographic posture as the cloud deployment. For branch, field, and enclave use cases that need a local enforcement point.

All four models share the same evidence bundle, SLA structure, DPA, and sub-processor list — adjusted only for who operates each boundary.

07Security and Compliance Posture

AegisWire ships one cryptographic standard for access — every customer, every session, every packet — aligned to the US NSA's CNSA 2.0 mandate, UK NCSC post-quantum migration guidance, and the NIST post-quantum standards that underpin both. The posture is built into the engineering, not retrofitted at procurement, and is uniform across every deployment model.

Third-party attestations (SOC 2 Type II, ISO 27001, FIPS 140-3 CMVP, sector schemes) are commissioned alongside the commercial engagement that scopes them; the architecture and evidence bundle are pre-built to carry them. If a specific attestation is a contract condition, raise it in the commercial conversation and the audit is scoped with the engagement. The companion Post-Quantum Secure Transport whitepaper covers the cryptographic and supply-chain posture in more depth.

8. Engagement Model

AegisWire engagements are engineering-led. The first conversation is a working session between your architects and ours, not a capabilities deck. A typical engagement runs in five steps:

1. Discovery call — 30 to 45 minutes on your environment, identity provider, compliance posture, and constraints.
2. Architecture briefing — a deep technical session against your reference architecture, under NDA.
3. Proof of concept — time-boxed, in your environment, with your identity provider and policy set, against jointly-agreed acceptance criteria. No charge for a scoped POC on the path to a commercial engagement.
4. Commercial — MSA, DPA, SOW, and SLA; invoice-based annual terms; customer-paper MSAs accepted for larger accounts.
5. Delivery — named Solutions Engineer, named Customer Success contact, named incident hotline, and a documented escalation path.

Purchase orders, NET 30 / 60 / 90, multi-year locks, and AWS / Azure marketplace transactions are supported. Source-code escrow and dedicated-instance options are available where the customer's compliance model requires them.

AegisWire is operated by ITLOX LTD, registered in England & Wales. All content © 2026 ITLOX LTD. This whitepaper is released for evaluation under NDA — please do not distribute outside the evaluating organisation.