Most on-premise video is not air-gapped. On-premise video runs in the customer's data centre and still reaches the internet for certificates, package updates, licence checks, time and telemetry. An air gap removes all of that, and the question that decides a procurement is not whether the video works — it does — but whether everything the video quietly depends on can be rebuilt inside the fence.
This post walks that list. Air-gapped video conferencing fails first at the browser, then at the clock, then at the update path, and almost never at the media. Everything below applies equally to offline video conferencing for one isolated enclave and to a whole estate run that way.
What air-gapped video conferencing actually means
Air-gapped video conferencing is described loosely in most tenders, so start with a definition that procurement can hold you to. NIST's glossary records the CNSSI 4009 definition of an air gap as "an interface between two systems at which (a) they are not connected physically and (b) any logical connection is not automated (i.e., data is transferred through the interface only manually, under human control)."
Two things follow from that sentence. The first is that no software on the isolated side may assume a route out, however narrow — not a proxy, not "just DNS", not an outbound-only allowance. The second is that the gap is a human process, not a technology: every patch, certificate, licence file and exported recording crosses it because a person carried it across, and that person is now part of your threat model.
There is a sanctioned middle ground. NIST's guide to operational technology security recommends "unidirectional gateways" alongside DMZ architectures to keep traffic from passing directly between corporate and OT networks (NIST SP 800-82r3), and asks architects to consider "where physical separation may be required as opposed to logical separation." A one-way path out — logs and recordings leaving, nothing entering — is a common compromise. It is not an air gap, and it should not be sold as one.
The call itself barely changes
The media path is the part teams expect to be hard in offline video conferencing, and it is the part that already works. Real-time media has no inherent need for the public internet; it needs a route between endpoints and a server in the middle.
Connectivity establishment gets simpler, not harder. RFC 8445 defines a host candidate as "a candidate obtained by binding to a specific port from an IP address on the host," while server-reflexive candidates come from a STUN server and relayed candidates from a TURN server. Inside one routed network with no NAT between clients and the media server, host candidates are enough — the STUN and TURN infrastructure that dominates public deployments has far less to do. Keep TURN where clients sit behind internal firewalls or on segmented VLANs; drop the assumption that you need a public relay address.
Encryption is unaffected, and this is the first place an air gap surprises people pleasantly. RFC 8827 requires that "all media channels MUST be secured via SRTP," and media encryption does not depend on a public certificate authority: RFC 8122 exists precisely because for many hosts "self-signed certificates are usually the only option," and lets endpoints publish "a secure hash of their certificate, known as the 'certificate fingerprint', within the session description," so that "end hosts can trust even self-signed certificates" when the signalling is integrity-protected. The media plane is fine offline. The signalling plane is where the certificate problem lands.
The browser breaks before the media does
A browser will not open a camera on a page it does not consider secure. `getUserMedia()` "is only available in secure contexts," and if the document is not loaded securely "the `navigator.mediaDevices` property is `undefined`, making access to `getUserMedia()` impossible" (MDN, MediaDevices.getUserMedia). On an isolated network there is no public CA that will issue for your internal hostnames, and no ACME challenge that can be validated. So you run your own certificate authority — and inherit its whole lifecycle:
- Root distribution. The internal root must be installed and trusted on every browser, desktop, mobile device and kiosk that will ever join a call. Devices that arrive later, or get reimaged, arrive broken.
- Revocation that resolves. RFC 5280 defines the CRL distribution points extension, which "identifies how CRL information is obtained" via URIs such as HTTP or LDAP. Those URIs must point inside the air gap. A certificate whose CRL lives on the internet fails closed, slowly and confusingly.
- Expiry as a scheduled outage. With no automated renewal, certificate expiry is a date in a calendar. Short-lived certificates are good security practice and bad air-gap practice unless the renewal runs entirely inside.
- Hostnames and DNS. Internal DNS has to resolve the names on the certificates, and clients must not be configured with resolvers they cannot reach.
None of this is exotic, and all of it is work that the deployment plan usually assigns to nobody. It is also the most common reason an air-gapped pilot stalls in week one with cameras that will not turn on.
Time has no upstream
Air-gapped video conferencing has no upstream clock: an isolated network cannot reach a public time source, and time is not a cosmetic detail when the deployment exists to record things. In NTP, "primary servers are assigned stratum one" and a primary server is "synchronized to a reference clock directly traceable to UTC (e.g., GPS, Galileo, etc.)" (RFC 5905). That is the substitute: a local stratum-1 appliance with its own GNSS receiver, serving the isolated network. The US government distributes UTC "via the GPS signal in space with a time transfer accuracy relative to UTC(USNO) of ≤30 nanoseconds, 95% of the time" (GPS.gov), which is orders of magnitude better than any recording needs.
The failure mode without it is quiet. Servers free-run, drift apart by seconds and then minutes, and every recording carries a timestamp that cannot be reconciled with anything outside the room — which is exactly the problem that timestamps, retention and export that hold up later are meant to avoid. If a GNSS antenna cannot be installed, the honest fallback is a disciplined local reference plus a written, signed record of its offset against a trusted clock, taken on a schedule.
Air-gapped video conferencing re-homes everything that phones home
The rest of the work is an inventory exercise. Every dependency that normally reaches out has to be replaced with something inside, or removed.
What normally reaches the internet | What it does | What replaces it inside |
|---|---|---|
Certificate issuance | Public CA issues and renews TLS certificates | Internal CA, root distributed to every device, CRL hosted internally |
Time synchronisation | Public NTP pool | Local stratum-1 server with a GNSS reference clock |
OS and package updates | Distribution mirrors, container registries | Internal mirror and registry, loaded by hand on a schedule |
Licence activation | Vendor licence server check-in | Offline licence file, issued per term and re-issued by hand |
Telemetry and crash reporting | Vendor endpoints | Disabled, or written to local storage and exported deliberately |
TURN relay candidates | Public relay addresses for NAT traversal | Internal TURN only where segmentation requires it; host candidates otherwise |
Model and feature updates | Downloaded AI models, remote inference | Models shipped with the release; anything remote is simply unavailable |
Two entries on that list are worth dwelling on. Updates become a change-control event with a physical step, so the realistic patch cadence is monthly or quarterly, not continuous — and the media that carries them is, by the CNSSI definition above, the only automated-free path across the gap and therefore the main thing an attacker would target. And licensing is a commercial question, not a technical one: a vendor that only sells per-minute, metered access cannot serve a network that can never report usage.
What you still owe, gap or no gap
Isolation is a security control. It is not a compliance answer, and it does not reduce what a recording has to prove. Hashes, access logs, immutable storage and a defensible export path are all still required, for the same reasons set out in why a record button is not a chain of custody. If anything, the air gap makes export the sharp edge: the copy that leaves for an auditor, a regulator or a court crosses the boundary by hand, and that transfer needs the same hash-and-log discipline as everything before it.
Storage arithmetic does not change either — retention still multiplies by bitrate and camera count, and there is no elastic tier to fall back on when the array fills. The cost of running it yourself is the right baseline, plus hardware you cannot scale on demand and a support model that cannot reach in.
Where the air gap actually helps, and where it does not
It helps with one specific class of problem: foreign-jurisdiction disclosure, vendor access and unaudited outbound data. A system with no route out cannot be compelled through its provider's remote access, because there is none — which is the sharpest version of the argument in where your media legally has to live.
It does not help with the insider, the contractor with a USB stick, or the badly configured internal firewall that quietly bridges two segments. And it costs you the things connectivity pays for: rapid patching, vendor diagnostics, remote support and anything that depends on a service you do not run. Most organisations that ask for an air gap need it for one enclave, not for the whole estate — and the right answer is usually a small isolated deployment beside a conventional one, not the whole platform pushed offline.
Build, buy, or deploy
Building on open source is the default assumption for air-gapped work, and it is viable — the component list you would run does not change offline, though every one of those components now needs an internal update path. The trade is engineering time, forever.
Buying SaaS is simply out. A metered, hosted service cannot run on a network that cannot reach it.
Samvyo supports fully air-gapped deployment, with the media path, TURN and recording running on your hardware inside the boundary, based on SFU architecture and resilient by design. Two conditions are worth knowing before you scope it: it is available under a licensing agreement rather than the pay-per-use plan, because usage cannot be metered across an air gap; and a fully offline deployment is set up under a specific commercial and legal agreement rather than a standard contract. Where it does not fit: if your requirement is really "keep data in-country" rather than "no route out," a conventional on-premise or regional deployment is cheaper and easier to operate — a conventional on-premise video deployment is cheaper to operate and easier to support.
The Bottom Line
Air-gapped video conferencing is rarely blocked by the video itself. Media works offline; encryption works offline; connectivity gets simpler. What breaks is the supporting cast — certificates the browser insists on, a clock with no upstream, updates with no mirror, licences with no check-in — and each of those has a known substitute that somebody has to own.
Scope air-gapped video conferencing by inventorying every outbound dependency before you scope the media servers. The list is longer than the video, and it is where the project actually lives.
What's Next
For which component sees cleartext media in any deployment, read where the media flows and what you can prove. For the wider choice this sits at the end of, see on-prem, managed cloud or SaaS and your data story.
Frequently Asked Questions
What is air-gapped video conferencing?
It is video conferencing running on a network with no connection to the internet at all — no proxy, no outbound-only route. NIST records the CNSSI definition of an air gap as an interface where two systems are not physically connected and any logical connection is manual, under human control. In practice it means the media servers, signalling, TURN, recording, storage, certificate authority and time source all live inside the isolated network.
Does WebRTC work without an internet connection?
Yes. WebRTC needs a route between endpoints, not a route to the internet. On a single routed network, ICE host candidates are usually enough, and STUN and TURN matter only where internal segmentation or firewalls sit between clients and the media server.
Why does the camera not work on our internal video site?
Almost always the secure-context rule. Browsers expose getUserMedia only in secure contexts; on a page that is not loaded securely, navigator.mediaDevices is undefined. On an isolated network you need an internal certificate authority, certificates for your internal hostnames, and that root trusted on every device.
How do you keep time in sync on an air-gapped network?
With a local stratum-1 time server driven by a GNSS receiver. RFC 5905 defines a primary server as one synchronised to a reference clock directly traceable to UTC. Without it, servers free-run and recording timestamps stop being defensible.
Is an air gap the same as data residency?
No. Residency is about where data is stored; an air gap is about whether anything can reach it. An air gap answers a disclosure and remote-access risk that a region setting does not, and it is a much heavier operating burden. Most teams asking for one actually need in-country storage with no vendor access.
Can Samvyo run fully air-gapped?
Yes — technically Samvyo supports a fully air-gapped setup, with media, TURN and recording running on customer-controlled hardware and resiliency built in. It is offered under a licensing agreement rather than the pay-per-use plan, since usage cannot be metered offline, and a fully offline deployment is arranged under a specific commercial and legal agreement.
