Islands of Security in Modern Systems

• Islands of Security are design partitions that isolate system components with locally enforced security guarantees and controlled interconnection policies.
• They are implemented in domains such as hardware capability isolation, network segmentation for IoT, and controlled islanding in power grids, each with tailored mechanisms.
• The approach mitigates risks by confining compromises within isolated regions, though efficient bridging and synchronization remain key challenges.

“Islands of security” denotes a recurring security architecture in which a larger system is partitioned into locally protected regions whose internal integrity and confidentiality are stronger than those of the surrounding environment, and whose interactions are constrained by explicit interfaces or policies. Across recent work, the phrase is used both literally and metaphorically: as hardware- or software-enforced compartments in CHERI, enclaves, and confidential-computing runtimes; as network enclaves for IoT devices and secure routing backbones; as deliberate partitions of electric grids under attack; as a description of DNSSEC trust discontinuities; and as a critique of security properties such as agreement, privacy, and accountability when studied in isolation rather than in combination (Ferraro et al., 7 Jul 2025, Barrera et al., 2017, Brossard et al., 2022, Niu et al., 2021, Rishith et al., 10 Sep 2025, Xu, 20 Feb 2026, Birge-Lee et al., 2022, Steinegger et al., 2021).

1. Conceptual scope and recurring structure

The common structure is local strong guarantees plus limited, policy-mediated communication across boundaries. In CHERI, the boundary is a capability-bounded compartment; in IDIoT, a per-device or per-class network enclave; in Veracruz and SERVAS, an isolate or enclave with attestation and protected memory; in SBAS, a virtual Autonomous System carried over a secure underlay; and in controlled islanding for power systems, a partition of the grid into self-sustained islands resilient to cascading failure or adversarial line-tripping (Ferraro et al., 7 Jul 2025, Barrera et al., 2017, Brossard et al., 2022, Birge-Lee et al., 2022, Niu et al., 2021, Steinegger et al., 2021).

Domain	Meaning of “island”	Representative mechanism
Edge and systems security	Compartment with bounded memory and control reachability	CHERI compartments, enclaves, isolates
IoT and networking	Per-device or per-prefix enclave with strict flow policy	IDIoT, SBAS
Power systems	Deliberate partition into self-sustained subgrids	Controlled islanding
Trust architecture	Locally secure region separated by trust gaps or isolated properties	DNSSEC IoS, distributed-security “five islands”

A notable divergence appears in DNSSEC. There, “Islands of Security” does not describe a desired protection primitive but rather a failure mode: a child zone may publish DNSKEY and RRSIG locally, while the parent omits the corresponding DS record or an intermediate zone lacks DNSSEC, breaking end-to-end validation across the hierarchy (Rishith et al., 10 Sep 2025). In contrast, the distributed-security vision paper uses the metaphor at the level of abstractions: agreement, consistency, privacy, verifiability, and accountability are treated as mature but isolated “islands,” and the research frontier is their fusion into “bridges” and higher-order combinations (Xu, 20 Feb 2026).

This suggests a unifying interpretation: an island of security is not merely an isolated component, but a region in which the enforcement mechanism is sufficiently strong that compromise of adjacent regions does not automatically propagate. The remaining design question is how to connect such regions without dissolving the guarantees that justified the partition in the first place.

2. Hardware-enforced and cryptographically enforced islands

In the CHERI network-stack case study, the threat model assumes a powerful, low-level attacker able to exploit arbitrary memory-safety bugs in C or C++ code, while the hardware capability system enforces two properties: spatial safety and compartmentalization. Each software component is confined to its own permitted region of memory and set of operations; it cannot forge or widen capabilities. The paper explicitly frames this as building “islands of security” within a single address space, without relying on a bulky MMU or separate virtual machines (Ferraro et al., 7 Jul 2025).

The mechanism is capability-based. A CHERI capability pointer is written as

$C = (b, e, p, o),$

where $b$ is the base address, $e$ the exclusive end address, $p$ the permission bits, and $o$ the current offset; the spatial-safety condition is

$b \le o < e.$

At boot time, Intravisor assigns each compartment a distinct Default Data Capability and Program-Counter Capability. In the reported network-stack partition, the three logical compartments are: the application(s) using sockets; the TCP/IP library F-Stack and its user-space networking framework DPDK; and the Ethernet driver’s ring-buffer queues. Any load, store, or jump outside the relevant bounds triggers a CAP_OUT_OF_BOUNDS exception (Ferraro et al., 7 Jul 2025).

The experimental results show that capability isolation can preserve throughput while exposing bottlenecks in the crossing mechanism. In the full-stack replication compartments of Scenario 1, line-rate TCP throughput at approximately $1 \text{ Gb/s}$ was unchanged, with $\Delta_{\mathrm{thru}} \approx 0\%$, and per-write syscall latency rose by approximately $125 \text{ ns}$. When the application was split from F-Stack in Scenario 2, trampoline indirections plus mutex-based synchronization cost approximately $200 \text{ ns}$ in the uncontended case, while under contention writes occasionally stalled up to approximately $b$0, a $b$1 slowdown, even though peak bandwidth remained at the hardware limit (Ferraro et al., 7 Jul 2025). The paper therefore couples an optimistic message—fine-grained compartmentalization with almost zero impact on throughput—with a precise warning: shared synchronization paths can dominate latency.

SERVAS represents a different realization of the same architectural idea. Its “authenticryption shield,” RVAS, makes every DRAM access an authenticated-encryption operation whose tweak encodes protection-domain and execution-context metadata. The 192-bit tweak is

$b$2

and the resulting claim is that each process, segment, enclave, or shared-memory region becomes an “island of security” enforced by cryptography rather than by a patchwork of MMU checks, TLB flushes, key tables, or metadata structures (Steinegger et al., 2021). The paper reports that entering or exiting a SERVAS enclave requires only $b$3 of a simple syscall, instead of $b$4 for Intel SGX, and that the additional RVAS tweak processing adds only $b$5–$b$6 beyond the dominant memory-encryption overhead (Steinegger et al., 2021).

Veracruz generalizes the notion further into heterogeneous confidential computing. An isolate is defined there as a hardware- or software-backed protected execution environment that provides strong confidentiality and integrity for code and data loaded inside it, even when the adversary controls all software outside the isolate, including the OS and hypervisor. Supported technologies include AWS Nitro Enclaves, Arm CCA Realms, and IceCap on seL4 for legacy Armv8-A hardware (Brossard et al., 2022). Its attestation path is normalized through a proxy attestation service: the isolate generates $b$7 and a CSR, embeds $b$8 into native attestation evidence, and receives a proxy-signed X.509 certificate

$b$9

The programming model uses Wasm and WASI, so that the runtime implements an in-memory VFS inside the isolate and principals provision files over TLS (Brossard et al., 2022).

Performance data in Veracruz indicates that strong isolation need not imply extreme cost, but the overhead depends on the layer. On IceCap, compute-bound sysbench incurs $e$0 versus native and $e$1 versus Firecracker; for video object detection on an EC2 Core i7 platform, Wasmtime is approximately $e$2 slower than native, Veracruz-Linux is approximately the same as Wasmtime, and Veracruz-Nitro adds $e$3 over Wasmtime. On an RPi4, Veracruz-IceCap adds $e$4 over Veracruz-Linux (Brossard et al., 2022). The pattern across CHERI, SERVAS, and Veracruz is consistent: the cost of the island is often modest, but the cost of crossing into, provisioning, or synchronizing across islands can dominate.

3. Network-policy islands in IoT and edge systems

IDIoT applies the island metaphor to network behavior rather than to address-space or memory protection. It realizes the “islands of security” vision by treating each class of IoT device as its own tiny, self-contained network enclave, permitting exactly the flows it needs and nothing more. The threat model assumes that any given IoT device may be fully compromised, but not the enforcement point. The attacker’s goals include Mirai-style DDoS, arbitrary data exfiltration, and local-LAN scanning; the defense is to limit strictly what the device may send or receive (Barrera et al., 2017).

Formally, a policy for device $e$5 is described as an explicit whitelist

$e$6

over packet-level events, or concretely as a set of permitted tuples

$e$7

augmented with rate limits and schedule constraints. The paper also gives

$e$8

Compilation targets two enforcement layers: a stateful firewall using iptables and application-layer proxies such as DNS filtering via dnsmasq (Barrera et al., 2017).

The “carving out” of islands is implemented with ordinary network primitives. Each device class is assigned to a dedicated SSID or VLAN; NAT separates the IoT SSID 172.16.1.0/24 from the home LAN 192.168.1.0/24; and hostapd’s ap_isolate=1 blocks layer-2 broadcasts and device-to-device ARP or NetBIOS scans inside the same SSID. The combination of SSID isolation, NAT, and per-SSID firewall rules yields a container-like environment in which the device can speak to cloud services and filtered DNS, but not to arbitrary Internet hosts or to peers on the LAN unless explicitly permitted (Barrera et al., 2017).

The reported implementation overhead is small. On a Pi Zero W acting as a NAT middlebox, the firewall and DNS filtering consume less than $e$9 CPU under typical IoT load, and the latency impact is sub-$p$0 additional round-trip time; the LIFX bulb showed approximately $p$1 extra command latency, described as still imperceptible to users (Barrera et al., 2017). Compatibility is achieved precisely because the island is external to the device: no changes are required to existing IoT firmware, cloud servers, or home gateways.

The CHERI network-stack study addresses a different layer of edge security, but its motivation is closely aligned. It targets embedded systems in critical infrastructures, autonomous drones, and smart industrial systems, and chooses the network stack as the compartmentalization target because it is one of the most critical and targeted components of interconnected systems (Ferraro et al., 7 Jul 2025). The two works therefore instantiate complementary forms of network-centric islanding: IDIoT constrains what a possibly compromised device may say on the network, while CHERI constrains what a compromised protocol component may touch in memory and control flow.

A common misconception is that network-policy islanding and execution isolation are interchangeable. The evidence in these papers suggests otherwise. IDIoT explicitly does not protect firmware integrity or device internals; CHERI does not by itself define the set of permissible cloud endpoints or DNS queries. A plausible implication is that practical edge security often requires both kinds of island simultaneously: one around code and data, another around network behavior.

4. Infrastructure-scale islanding: power grids and secure routing

In electric power systems, controlled islanding is a corrective security action in which the grid operator deliberately opens a set of transmission lines to partition the network into self-sustained islands. Each island must contain coherent generators and be power-balanced so that generation meets load without overloading lines. Under adversarial disturbances, the objective becomes minimizing worst-case post-islanding power-flow disruption while preserving stability (Niu et al., 2021).

The paper formulates the interaction between the operator and adversary as a two-player zero-sum Stackelberg game. The operator chooses a subset of lines $p$2 to open, thereby defining islands $p$3, and sets generator outputs; the adversary compromises up to $p$4 substations and trips lines incident to them. The disruption metric is

$p$5

where $p$6 is the set of disconnected lines (Niu et al., 2021). The adversary’s best response is shown to be a nonnegative, nondecreasing submodular maximization problem under a cardinality constraint, with a $p$7 approximation via the greedy algorithm, while the operator’s best response is an MILP.

Because both players have exponentially many pure strategies, the solution uses a double-oracle algorithm: initialize small sets of operator and adversary strategies, solve the restricted leader-follower game, add the adversary’s best response, add the operator’s best response, and iterate until convergence (Niu et al., 2021). On IEEE 9-, 14-, 30-, 39-, 57-, and 118-bus systems, the game-theoretic operator plan reduced disruption by an average of $p$8 and strictly improved performance in $p$9 of non-catastrophic scenarios, with fewer than $o$0 double-oracle iterations and under one minute runtime even for the 118-bus case (Niu et al., 2021). Here the island is not primarily a confidentiality boundary but a resilience boundary.

Inter-domain routing presents a second infrastructure-scale use of the metaphor. SBAS, the Secure Backbone AS, is a virtual AS that appears as one AS to the BGP-speaking Internet while actually being a federation of Points of Presence interconnected by a secure backbone. Traffic entering an SBAS PoP is carried on the secure underlay to an egress PoP and then delivered over the regular Internet; the paper explicitly describes SBAS as an “island of security” embedded in the global BGP sea (Birge-Lee et al., 2022).

The secure underlay is instantiated with SCION, while legacy interoperability is maintained through BGP. Each PoP performs customer ingress or egress, legacy-BGP ingress or egress, and secure-backbone forwarding via a SCION-IP Gateway. BIRD maintains eBGP sessions to customers and peers, and iBGP sessions to other PoPs. The route authenticity predicate is given as

$o$1

and secure routes are loaded into the highest-priority routing table (Birge-Lee et al., 2022).

Real-world measurements between two PEERING muxes report that the probability of hijack fell from approximately $o$2 without SBAS to approximately $o$3 with SBAS. In Internet-scale simulations, median resilience $o$4 improved from $o$5 without SBAS to $o$6 with six PoPs, and to $o$7 with full Route Origin Validation plus six PoPs (Birge-Lee et al., 2022). The median end-to-end latency overhead was approximately $o$8 over an Internet baseline of approximately $o$9, or roughly $b \le o < e.$0 (Birge-Lee et al., 2022). As with controlled islanding in power grids, the objective is not absolute isolation from the outside world but strategic partitioning that constrains how failure or attack propagates.

5. Trust discontinuities, bridges, and the problem of isolated guarantees

In DNSSEC, an island can be an unwanted artifact. A child zone may be locally signed and verifiable to itself, yet the absence or mismanagement of the parent’s DS record, or the absence of DNSSEC in an intermediate zone, breaks the chain of trust from the resolver’s trust anchor. The paper proposes a decentralized workaround in which the recursive resolver, upon detecting a missing DS, establishes a TLS connection directly to the authoritative nameserver and verifies a certificate whose Subject Alternative Name contains the nameserver’s IP address rather than a DNS name (Rishith et al., 10 Sep 2025).

The resolver logic is described as a 15-step workflow. Standard DNSSEC validation proceeds from root to TLD; if the child DS is missing, the resolver marks a gap, checks whether the authoritative nameserver supports TLS/IP, opens a TLS connection to the nameserver’s IP, verifies that the certificate’s IP matches that address, and then validates the returned DNSKEY and RRSIG for the domain. The paper states qualitative overhead of “three extra RTTs and cryptographic operations” per gap handshake, but does not provide measured latencies, throughput, or scalability data (Rishith et al., 10 Sep 2025). It also does not provide formal proofs, symbolic threat models, or exact cryptographic parameter choices.

The distributed-security vision paper treats “islands” at a higher level of abstraction: agreement, consistency, privacy, verifiability, and accountability are individually mature research areas with canonical protocols and performance bounds, but no single property addresses the full threat landscape (Xu, 20 Feb 2026). Consensus alone orders actions but does not hide them; privacy alone does not provide agreed ordering or consistent state; verifiability alone does not prevent double-spending without agreement; accountability alone may punish misbehavior only after profit has been extracted. The paper’s core claim is that modern systems require bridges between these islands.

Several such bridges are enumerated. Agreement plus consistency yields blockchain-style append-only ledgers. Consistency plus verifiability yields zk-rollups and verifiable databases. Privacy plus verifiability yields collaborative zero-knowledge. Verifiability plus accountability yields economic security through slashing. The paper further notes that with five foundational properties, $b \le o < e.$1 possible property combinations remain largely unexplored (Xu, 20 Feb 2026). In this framing, the problem is no longer merely how to build islands, but how to make their interfaces compositional and synergistic.

Veracruz exemplifies an implementation-level answer to that challenge. It does not merely define an isolate; it standardizes the bridge into it through a proxy-mediated attestation service, a uniform Wasm+WASI execution substrate, and TLS provisioning semantics that hide heterogeneity across AWS Nitro Enclaves, Arm CCA Realms, and IceCap (Brossard et al., 2022). A plausible implication is that the practical success of island-based security often depends less on the purity of the boundary than on the engineering quality of the bridge.

6. Limitations, misconceptions, and open problems

A recurrent misconception is that islands of security are synonymous with complete security. The cited works consistently reject that interpretation. CHERI assumes any compartment may be compromised and aims to reduce the attacker’s blast radius rather than to prevent initial compromise; the Morello study identifies a global mutex around DPDK ring buffers as a bottleneck under many cores or flows, and explicitly proposes lock-free queues, per-flow demultiplexing, or CHERI-sealed message channels as future work (Ferraro et al., 7 Jul 2025). Veracruz places denial of service and several side channels out of scope, including timing and page-fault channels, and acknowledges enclave-specific side channels such as cache and branch-target injection (Brossard et al., 2022). SERVAS similarly incurs dominant overhead from authenticated memory encryption and integrity trees rather than from enclave entry alone (Steinegger et al., 2021).

A second misconception is that isolation can be achieved once and for all at a single layer. IDIoT leaves device identification and spoofing as an open problem, notes that peer-to-peer discovery protocols such as multicast-based smart-home discovery complicate AP isolation, and states that WAN-enabled IoT devices with built-in LTE or LoRaWAN cannot be corralled by the home gateway at all (Barrera et al., 2017). SBAS reduces hijack risk but does so through federation, governance, and incentives, not by replacing the Internet with a uniformly secure substrate (Birge-Lee et al., 2022). The DNSSEC TLS/IP proposal repairs a specific chain-of-trust gap, but the paper itself stops short of formal proofs and empirical evaluation (Rishith et al., 10 Sep 2025).

A third misconception is that the island metaphor always indicates a positive design. In DNSSEC it names a trust failure, whereas in distributed security it names an analytic limitation: mature properties studied in isolation can leave security gaps between them (Rishith et al., 10 Sep 2025, Xu, 20 Feb 2026). This difference matters. An island may be a containment boundary to be preserved, a fault domain to be optimized, or a discontinuity to be bridged.

The open problems across the literature are correspondingly varied. IDIoT raises policy distribution at the scale of tens of thousands of device SKUs, including signed policy publication, updates, revocations, and emergency patches (Barrera et al., 2017). The controlled-islanding work identifies extensions from DC power flow to AC dynamics, time-domain stability, partial information, and dynamic re-islanding under cascading events (Niu et al., 2021). The distributed-security paper calls for systematic frameworks for convergence, management of cryptographic overhead, post-quantum replacements for RSA, ECC, and SNARKs, and human-factor work on key management and trust interfaces (Xu, 20 Feb 2026). CHERI and SERVAS point toward finer-grained compartmentalization and secure sharing, while Veracruz addresses legacy hardware through a software-isolate path based on seL4 and IceCap rather than assuming universal hardware confidential computing (Ferraro et al., 7 Jul 2025, Steinegger et al., 2021, Brossard et al., 2022).

Taken together, these works show that “islands of security” is best understood not as a single technique but as a cross-domain design vocabulary. It describes systems that attempt to localize trust, damage, and reasoning; to make compromise non-transitive; and to replace ambient authority with explicit, mechanically enforced boundaries. Where those boundaries are absent, one sees chain-of-trust failures or isolated properties that do not compose. Where they are present but poorly connected, one sees bottlenecks, side channels, governance problems, or policy-scale limits. The enduring research problem is therefore dual: how to construct islands with strong local invariants, and how to engineer the bridges among them without forfeiting those invariants.