Design remote sites to keep working when the central assumptions fail.

1. Classify each edge site by service consequence

Do not apply the same architecture to every remote site. Record the consequence of site loss and the service that site actually supports.

• Critical service: loss materially affects public safety, mission operations, revenue, production, regulated service, or a large user population.
• Important service: loss degrades operations but alternate processes exist for a limited period.
• Best-effort service: site can remain unavailable without unacceptable consequences while normal support restores it.

For each site, define maximum tolerable outage, required local data/state, communications dependency, power autonomy, on-site staffing, field-response time, and the decision authority for degraded operation.

2. Decide what the site can do without the center

Edge systems should have an explicit disconnected-mode design. The answer may be "nothing," but that should be a conscious risk decision rather than an accident discovered during an outage.

• Can the site authenticate users or workloads when the central identity service is unreachable?
• Which policies/configuration must be cached locally, and how long can cached policy remain valid?
• Can critical transactions queue locally and reconcile safely later?
• What data must remain available locally for safe operation?
• What functions should stop rather than operate on stale data?
• Can local staff execute a safe shutdown or minimum-service mode without remote administrators?

Document conflict handling and reconciliation before an outage. "Store and forward" is incomplete unless the team knows how duplicate, reordered, or conflicting transactions will be resolved.

3. Build real communications diversity

CISA's National Emergency Communications Plan emphasizes resilient, secure, and interoperable communications for response and recovery.^{CISA National Emergency Communications Plan} For edge sites, diversity should be evaluated at the physical and provider-dependency level, not just by counting circuits.

• Document provider, local loop, conduit/path, last-mile technology, power dependency, and termination point.
• Check whether two providers share the same building entrance, pole line, aggregation facility, or upstream network.
• Use alternate technologies where consequence justifies it: terrestrial + cellular, terrestrial + satellite, or other physically distinct paths.
• Define which traffic is allowed on degraded links and which services are rate-limited or suspended.
• Keep an emergency communications path that does not depend entirely on the production network being recovered.

For communications infrastructure, CISA's enhanced visibility and hardening guidance recommends secure administration, stronger visibility, and network-device hardening against sophisticated actors.^{CISA — Enhanced Visibility and Hardening Guidance}

4. Size power autonomy around the actual recovery path

CISA's Resilient Power Best Practices recommends defining resilience requirements, assessing gaps, maintaining backup systems, testing them, and planning telecommunications together with power continuity.^{CISA Resilient Power Best Practices}

• normal and critical load;
• UPS or battery runtime under measured load;
• generator/alternate-source startup and transfer behavior where present;
• fuel or energy replenishment assumptions;
• cooling and environmental-control dependency;
• remote telemetry that remains available during utility loss;
• safe shutdown sequence if autonomy is exhausted.

A runtime number is only useful if it is measured periodically under representative load and compared with the time required to restore power, start alternate generation, shed nonessential load, or dispatch field support.

5. Make remote administration recoverable and constrained

Remote management is an edge site's lifeline and a high-value attack path. Separate management access from normal user/workload traffic wherever practical.

• Use named privileged identities and strong authentication.
• Restrict management interfaces to approved paths.
• Maintain an out-of-band or alternate recovery method for critical sites.
• Back up device configuration and recovery material independently of the site.
• Monitor privileged access, configuration changes, failed administration attempts, and loss of critical telemetry.
• Document emergency access procedures and review use afterward.

6. Design telemetry for intermittent connectivity

Remote sites may lose the path used to export monitoring data. A central dashboard that simply turns gray does not tell the operator whether the site is down, isolated, or still functioning locally.

• Separate site-health signals from link-health signals.
• Buffer important telemetry locally when connectivity is intermittent.
• Monitor telemetry queue/backlog so evidence loss is visible.
• Use local health checks for functions that must continue during isolation.
• Record power, environment, network path, workload health, storage, and synchronization/backlog indicators appropriate to the site.

The OpenTelemetry Collector can receive, process, and export telemetry independently of application backends, which can be useful for gateway or site-level collection.^{OpenTelemetry Collector}

7. Treat field service and spares as part of the architecture

Edge availability is often limited by logistics rather than failover code. Maintain a site support record with travel/dispatch time, access restrictions, local contacts, critical spares, replacement lead times, remote-hands arrangements, recovery tools/credentials, and end-of-support dates.

Standardization can materially reduce recovery time. A small number of approved edge patterns, known spare kits, and documented replacement procedures are easier to sustain than dozens of one-off site designs.

8. Test graceful degradation and restoration

• central control plane unavailable but local service still needed;
• primary carrier lost with alternate path constrained;
• utility power lost and backup autonomy shorter than repair time;
• remote administration unavailable and local staff must recover;
• site operates disconnected and later reconnects with queued transactions;
• hardware fails but replacement is delayed;
• telemetry export fails while the site continues operating.

Measure whether the minimum service actually remained available, whether staff knew when to degrade or stop, how long recovery took, and whether data/state reconciled correctly afterward.

30-day edge resilience reset

1. Week 1: classify sites, document minimum service, and map power/communications/identity/data dependencies.
2. Week 2: verify actual carrier diversity, measured power autonomy, remote-admin recovery, and field-service assumptions.
3. Week 3: test one disconnected-mode scenario and one power/communications failure scenario.
4. Week 4: remediate hidden common dependencies, stale spares/configuration, and unclear degraded-mode decisions.

Use Infrastructure Resilience for enterprise-wide dependency and recovery governance and Cloud Observability for telemetry/SLO design.

Primary sources

• NIST SP 800-160 Vol. 2 Rev. 1
• CISA — Resilient Power Best Practices
• CISA — National Emergency Communications Plan
• CISA — Communications Systems Dependencies
• CISA — Enhanced Visibility and Hardening Guidance
• OpenTelemetry — Collector