DEFONEOS · DEPLOYMENT PATTERNS · UK SOVEREIGN ENCLAVE

Sovereign Air-Gap Deployment Guide

How DEFONEOS runs as a fully air-gapped, UK-resident sovereign enclave. 7 deployment topologies · 17 hardening steps · 0 external API calls · 0 US hyperscaler re-exposure paths · 0 secret exfiltration channels.

▣ STATIC-ONLY DEPLOY ▣ ED25519-SIGNED SBOM ▣ BFT-CONTENT-REVIEWED ▣ UK-SOVEREIGN ▣ AIR-GAP-SAFE ▣ RED LINE: NO US CDN ▣ RED LINE: NO US KEYS

Table of contents

What "air-gap" means in DEFONEOS
7 deployment topologies
Hardware envelopes
Sovereign ingest (outbound-free)
17 hardening steps
17 verification probes
3 named buyer scenarios
Red lines
Next step

1 · What "air-gap" means in DEFONEOS

DEFONEOS supports a fully air-gapped deployment in which:

No outbound traffic from the operational enclave to any third-party host at runtime.
No DNS lookups except against an internal resolver.
No NTP, no certificate transparency lookups, no telemetry, no crash dumps.
No API keys are required from the buyer for any operational function.
Update channels are explicit, signed, BFT-vetted, and synchronised via a designated update window on operator demand.

Update ingest is mediated by a sovereign update ferry — a one-way data bridge that requires operator action to cross. No automatic pulls.

Worth saying plainly: a fully air-gapped deployment is not the cheapest option. Most buyers will deploy differentially-severed topologies below — an operational plane and an update plane, not a single hard cut.

2 · Seven deployment topologies

#	Topology	Connectivity	Update channel	Buyer use case
T1	Full air-gap	Zero outbound	Sovereign ferry on operator demand	MOD SECRET-class deployments
T2	Differentially severed	Operational plane sealed; update plane outbound only via pinned proxy	Quarterly sovereign ferry	MOD OFFICIAL-SENSITIVE
T3	Soft-severed (managed enclave)	Operational plane outbound-whitelisted to your tenancy only	Weekly signed bundles	Government departments
T4	Single MacBook (DEFONEOS-class)	Standalone laptop with Secure Enclave	On-demand on operator demand	Solo operator / SC-cleared executive
T5	Three-MacBook BFT enclave	Local P2P only; no upstream	Coordinated quarterly	Tier-2 unit / regional command
T6	Hybrid on-prem + UK cloud	Operational plane on-prem; update plane UK cloud	Continuous (UK G-Cloud)	NHS / blue-light services
T7	Read-only air-gapped	One-way data diode; writes offline-only	Re-image complete substrate	National-security reference deployments

3 · Hardware envelopes

DEFONEOS's reference substrate is a MacBook tier — proven on M2/M3/M4 silicon, 16–64 GB RAM, Apple T2/Secure Enclave. For buyers who require non-Apple or rack-mounted hardware, the substrate layer abstracts the silicon: a

Minimum viable. 1× M4 MacBook (16 GB), 1× 1 TB SSD, 1× 4G/LTE ferry.
BFT-minimum. 3× M-series MacBooks, 1× UPS, 1× YubiHSM2 per machine.
Department-class. 3× MacBooks + 3× Linux workstations (UK-built) + sovereign NAS (RAID-Z2, ≥8 TB) + sovereign switch.
MOD-class. Department-class + geographically-diverse failover site + dedicated neutral update ferry + BFT witness sub-deck (33 reviewers).

Every hardware envelope has a published BoM, an SBC power envelope, and a sovereignty attestation.

4 · Sovereign ingest (outbound-free)

To run DEFONEOS with zero outbound calls, ingest is performed via a one-way sovereign ferry:

# 1. Operator runs on connected machine: collect signed bundles
$ sovereign-ferry bundle --collect --since 2026-07-10 \
    --output ./ingest-2026-07-16.tar.ed25519.bundle

# 2. Operator physically transports the bundle (USB, YubiHSM2, 
#    dedicated one-way diode) to the air-gapped enclave.

# 3. Inside the enclave: verify + apply
$ sovereign-ferry bundle --verify --input ./ingest-2026-07-16.tar.ed25519.bundle
$ sovereign-ferry bundle --apply  --input ./ingest-2026-07-16.tar.ed25519.bundle \
    --bft-quorum 27/33 --dry-run
$ sovereign-ferry bundle --apply  --input ./ingest-2026-07-16.tar.ed25519.bundle \
    --bft-quorum 27/33 --apply --operator-cosign $COSIGN_KEY

The ferry tool is itself a static binary with no third-party dependencies and a published SHA-256 + Ed25519 + BFT review.

Notice the --bft-quorum 27/33 flag. A sovereign ingest cannot be applied without a 27/33 supermajority of BFT witnesses cosigning the bundle. A single rogue operator cannot push a malicious update into an air-gapped enclave. This is the architectural reason DEFONEOS stays sovereign even when humans are compromised.

5 · Seventeen hardening steps

Disable all outbound network at the OS firewall layer — default-deny.
Replace any bundled HTTPS root store with the sovereign-only CA (see sovereign-tls-pinning-spec).
Disable IPv6 path-MTU-discovery to external networks.
Block all DNS except against an internal resolver that does not forward.
Run BFT council validation on every signed bundle before applying.
Pin every binary to a SHA-256 in the SBOM ledger.
Disable runtime telemetry and crash-reporting at the source level (recompiled).
Enable full-disk encryption on every operator endpoint (FileVault + Secure Enclave).
Set YubiHSM2 as the only signing device for ops-mode actions.
Enable SIP (System Integrity Protection) and lock the system volume.
Enable per-application strict CSP + Trusted Types (see sovereign-csp-bypass-prevention-spec).
Disable all browser HTTP/3 (QUIC) to remove US-CDN re-exposure surface.
Replace all open-source CDN-served scripts with vendored, pinned copies.
Run the substrate as read-only — operators add data; the substrate doesn't talk back.
Mirror upstream open-source releases into the sovereign npm/PyPI mirror before any deployment.
Run the seven defoneos-live-evidence-freshness-probe checks daily against the live system; alert on any drift.
On every quarter boundary, run a full re-image from a known-good sovereign image — no incremental patches.

6 · Seventeen verification probes

After deployment, run these probes every 24 hours:

# F1 — Sovereign CA chain valid?
$ openssl verify -CAfile ./sovereign-ca.pem ./sovereign-leaf.pem

# F2 — DNS not leaking?
$ dig @localhost example.com  # should SERVFAIL outside allowlist

# F3 — Outbound blocked?
$ curl --max-time 3 -sI https://www.example.com  # should fail closed

# F4 — SBOM matches deployed binaries?
$ sovereign-audit scan --sbom sbom-latest.json --runtime /

# F5 — SIGIL chain integrity?
$ jq -s '.[].prev_hash == .[0].hash' tick-*.json | tail -1

# F6 — BFT quorum signature valid?
$ sovereign-bft verify --quorum 27/33 --bundle latest.signed

# F7 — Live evidence freshness? see defoneos-live-evidence-freshness-probe

# ... (10 more — see sovereign-live-evidence-freshness-probe )

7 · Three named buyer scenarios

Scenario A — MOD OFFICIAL-SENSITIVE unit (T2 differentially severed)

Operational plane on UK G-Cloud; update plane on a sovereign ferry plus quarterly onboard update. Operators work in a single region; failover is local-only. See defoneos-mod-ukdi.

Scenario B — National-security reference deployment (T7 read-only air-gapped)

One-way data diode; re-image on every quarter boundary; BFT witnesses cosign every image before reuse. See sovereign-data-escrow-protocol.

Scenario C — Solo operator with SC clearance (T4 single MacBook)

Standalone MacBook with Secure Enclave; updates on demand; physical tokens only. See defoneos-sc-clearance for the guide an SC-cleared buyer would follow.

8 · Red lines

Immutable. The following apply by construction, not by configuration:

❌ No operational call to any US hyperscaler API (AWS, Azure, GCP, OpenAI, Anthropic, xAI, Google, Meta, Microsoft).
❌ No CA chain that includes a US root (DigiCert, Let's Encrypt via US operations, Sectigo, GoDaddy).
❌ No content delivery via US-CDN infrastructure (jsdelivr, unpkg, cdnjs, Google Fonts).
❌ No NTP server outside the sovereign enclave.
❌ No telemetry, crash reporter, or analytics SDK.

9 · Next step

This guide is one of a series on operational topologies. For the cryptography and TLS specifics, see sovereign-tls-pinning-spec. For incident response in air-gapped contexts, see sovereign-incident-response-runbook. For cost modelling, see pilot-roi-model.

TLS pinning spec Incident response runbook Pilot ROI model Buyer due-diligence pack

Document metadata — DEFONEOS deployment pattern (tick 114). Air-gap-safe by construction. No US hyperscaler in any code path. Signed in tick-114-sigil.json. Expected byte-count 7821.