Notifications
Clear all
Topic starter
08/06/2026 3:59 pm
TL;DR: Air-gapped and heavily firewalled environments force authentication flows to operate without the external communication most identity systems assume, making SAML, OIDC, token exchange, and webhook delivery far harder to support, according to WorkOS. The real issue is not connectivity alone but the mismatch between modern authentication patterns and isolated operating models.
NHIMG editorial — based on content published by WorkOS: Air-gapping and authentication: How WorkOS supports secure and isolated environments
Questions worth separating out
Q: How should security teams govern authentication in air-gapped environments?
A: They should map every identity dependency to a specific network path, then decide whether that path is allowed, replaced, or internalised.
Q: Why do air-gapped deployments create identity governance risk?
A: They create risk because authentication systems usually assume external communication for token exchange, metadata access, and event delivery.
Q: What breaks when authentication services are reused across connected and isolated environments?
A: Shared credentials, callback URLs, and webhook paths can blur the boundary between environments and create cross-tenant or cross-deployment trust exposure.
Practitioner guidance
- Inventory every external identity dependency Map redirects, token exchanges, metadata fetches, webhooks, and callback endpoints before moving a workload into a restricted network.
- Separate credentials by deployment boundary Use unique per-customer or per-environment credentials, and prevent shared keys or shared callback configurations from spanning connected and isolated deployments.
- Treat network allowlisting as identity governance Define the smallest acceptable set of ports, protocols, DNS targets, and IP ranges, then validate those paths during access review and change control.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for adapting authentication flows to heavily firewalled or on-prem deployments
- Specific network and environment configurations that limit cross-boundary exposure
- Best-practice patterns for webhook handling, local buffering, and off-network update delivery
- Implementation notes for customers that need both connected and isolated deployment models
👉 Read WorkOS's guide to air-gapped authentication in isolated deployments →
Air-gapped authentication: what identity teams need to plan for?
Explore further
08/06/2026 5:20 pm
Air-gapped authentication is really a boundary-management problem, not a product problem. The article shows that isolated environments break the network assumptions embedded in modern authentication flows, especially where redirects, token exchange, and callbacks are expected. That means IAM teams need to treat isolation as a design constraint that affects trust propagation, not as a deployment wrinkle. The practitioner conclusion is that identity architecture must be planned around the boundary itself.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to 2024 ESG Report: Managing Non-Human Identities.
- The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured.
A question worth separating out:
Q: Which frameworks should teams use for restricted identity environments?
A: NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture are both relevant because they emphasise governance, continuous verification, and bounded trust paths. Teams should use them to map identity flows to network controls, then verify that isolated deployments still satisfy the intended control objectives.
👉 Read our full editorial: Air-gapped authentication exposes the identity gap in isolated deployments
