FORTRESS in Multidisciplinary Research

• FORTRESS is a cross-disciplinary research topic defined by adaptive defenses, dynamic boundary management, and stabilization techniques across various fields.
• Its applications span cloud security, LLM safeguard benchmarks, ML feature pruning for temporal stability, and trusted execution in IoT systems.
• The framework reinterprets traditional fortification by emphasizing reactive adaptation and boundary redefinition to address complex, evolving threats.

Searching arXiv for the listed FORTRESS papers and closely related entries. arxiv_search(query="FORTRESS arXiv", max_results=10, sort_by="relevance") FORTRESS is a recurrent title and metaphor in contemporary research, but not a single unified concept. Across arXiv, it denotes several distinct technical artifacts: a cloud-security architecture that explicitly rejects static perimeter defense in favor of adaptive moving-target defenses (Torkura et al., 2019); a benchmark for frontier-LLM safeguard robustness in national security and public safety (Knight et al., 17 Jun 2025); a temporal feature-pruning framework for stabilizing search and recommendation scores (Jagre et al., 14 May 2026); a trusted-execution-environment design for protecting IoT peripheral data paths (Yuhala et al., 2023); a real-time robotic fallback-planning framework for out-of-distribution failures (Ganai et al., 15 May 2025); a structural-defect segmentation architecture for civil infrastructure (Thrainer et al., 16 Jul 2025); a family of FORTRAN solvers for spin-orbit-coupled spinor Bose–Einstein condensates (2002.04365, Banger et al., 2020); and several fortress-derived conceptual models in social diffusion, cyber-governance, graph privacy, internet architecture, heritage mapping, and artificial-life environment generation (Hołowacz et al., 20 Feb 2026, Chen et al., 25 Jun 2026, Li et al., 2024, Carlin et al., 25 Jan 2026, Davies et al., 2024, Earle et al., 2023). The term therefore functions less as a stable technical keyword than as a cross-domain label attached to architectures, datasets, solvers, and theoretical frameworks. A common thread is the use of “fortress” to mark boundaries—security perimeters, cohesive subgraphs, institutional accountability zones, or modular social enclaves—but the operational meaning depends entirely on the paper in question.

1. Fortress as a critique of static perimeter security

One influential use of the term appears in “Don’t Wait to be Breached! Creating Asymmetric Uncertainty of Cloud Applications via Moving Target Defenses,” which treats the conventional “fortress” view of cloud security as inadequate, especially under zero-day conditions (Torkura et al., 2019). The paper’s core claim is that cloud applications inevitably expose not only service endpoints but also “potential or actual vulnerabilities,” so security centered on hardening walls, audits, and compliance becomes “often toothless” when vulnerabilities are unknown. In that setting, the authors propose replacing fortress-style static defense with an active, adaptive “immune system” based on moving-target defense.

The architecture has two layers. At the infrastructure layer, virtual machines are continuously regenerated as “cell regeneration,” using the intended-state/current-state pair $(\rho,\sigma)$ and rolling workflows such as $\sigma=N \mapsto \sigma'=N+1 \mapsto \sigma''=N$. At the application layer, the attack surface is diversified by transforming microservices and container images so that previously successful scripted attacks cannot be replayed straightforwardly (Torkura et al., 2019). The paper reports median one-node regeneration times of 81 s on AWS, 175 s on GCE, 600 s on Azure, and 126 s on OpenStack, and concludes that attacker dwell time can be reduced from months or days to minutes. It also reports that more than 98% of an attack surface can be changed automatically and minimized in its strongest transformed variant (Torkura et al., 2019).

This reconceptualization matters because it inverts the fortress metaphor. Rather than assuming the wall can be made impenetrable, the system assumes compromise is possible and seeks to deny persistence. A plausible implication is that “fortress” here survives primarily as a target of critique: the paper’s contribution is to move from perimeter hardening to time-bounded, replay-resistant post-compromise defense.

2. Fortress as a benchmark for LLM safeguards

In “FORTRESS: Frontier Risk Evaluation for National Security and Public Safety,” FORTRESS denotes a benchmark rather than a defensive architecture (Knight et al., 17 Jun 2025). Its aim is to measure whether frontier LLM safeguards resist adversarial misuse in national-security and public-safety settings while remaining useful on benign dual-use requests. The benchmark contains 500 expert-crafted adversarial prompts, each paired with a benign counterpart and an instance-specific rubric of 4–7 binary questions, spanning three domains—CBRNE, Political Violence & Terrorism, and Criminal & Financial Illicit Activities—and ten total subcategories (Knight et al., 17 Jun 2025).

The evaluation reports two main metrics: Average Risk Score (ARS), reflecting harmful compliance on adversarial prompts, and Over-Refusal Score (ORS), reflecting refusals on benign paired prompts. The paper highlights markedly different trade-offs across models: Claude-3.5-Sonnet has ARS 14.09 and ORS 21.8; Gemini 2.5 Pro has low over-refusal at 1.4 but high potential risk at 66.29; DeepSeek-R1 has ARS 78.05 and ORS 0.06; and o1 is presented as more balanced with ARS 21.69 and ORS 5.2 (Knight et al., 17 Jun 2025).

The benchmark’s significance lies in its paired design. Because every adversarial prompt has a matched benign version, FORTRESS operationalizes a safety–usefulness frontier rather than treating refusal alone as success. This suggests a broader reinterpretation of “fortress” in AI safety: not a hard wall against harmful content, but an evaluative framework for measuring how selectively and robustly the wall functions under adversarial pressure.

3. Fortress as a stabilization framework in search and recommendation

“Fortress: A Case Study in Stabilizing Search Recommendations via Temporal Data Augmentation and Feature Pruning” uses the term for a production-oriented ML framework addressing temporal instability in scores for repeatedly scored entities such as query–app pairs (Jagre et al., 14 May 2026). The paper motivates the problem through multi-stage retrieval and ranking systems, where score fluctuations can induce candidate flip-flops, threshold instability, and degraded downstream reliability.

The method follows four steps: collect historical snapshots, identify unstable samples, isolate instability-inducing features, and retrain on a reduced feature set (Jagre et al., 14 May 2026). Instability is measured by the Coefficient of Variation,

$$\mathrm{CV}(s_{1:T})=\frac{\sigma(s_{1:T})}{\mu(s_{1:T})},$$

computed over temporal predictions for the same entity. Fortress focuses on the top 25% highest-CV samples, computes feature-level CVs on those samples, and applies a greedy pruning-and-retraining loop until it achieves a statistically significant PR-AUC lift on validation (Jagre et al., 14 May 2026).

In the app-marketplace case study, the baseline “All features (SR + engagement)” system achieves PR-AUC 0.9572 and CV 0.5462, while Fortress reaches PR-AUC 0.9595 and CV 0.5274, corresponding to a 0.24% relative PR-AUC improvement and a 3.44% relative CV reduction (Jagre et al., 14 May 2026). The downstream global candidate flip-flop rate falls by 25.8% relative to the single-snapshot approach. Here “Fortress” signifies not a wall against attack but a wrapper-style feature-selection regime that protects temporal consistency by suppressing volatile signals.

4. Fortress as secure I/O isolation in trusted execution environments

In “Fortress: Securing IoT Peripherals with Trusted Execution Environments,” Fortress denotes a TEE-based architecture that moves the trust boundary down to the peripheral I/O path itself (Yuhala et al., 2023). The system is designed for IoT devices that collect sensitive microphone or camera data and seeks to prevent exposure to compromised operating systems, malicious applications, hypervisors, or untrusted cloud services.

The design isolates peripheral MMIO and DMA regions inside the secure world, places only the sensitive fragment of the driver inside the secure kernel, and transfers captured data through a secure path into a trusted user-space component where obfuscation or encryption can be applied (Yuhala et al., 2023). The implementation uses ARM TrustZone, OP-TEE, secure boot assumptions, TZASC-protected secure I/O regions, core_mmu_add_mapping for secure MMIO mapping, and TA/PTA communication through TEE_OpenTASession and TEE_InvokeTACommand.

The evaluation on an NVIDIA Jetson AGX Xavier shows that secure-world MMIO reads have identical performance to Linux kernel MMIO reads, at approximately 26 cycles for 8-, 16-, and 32-bit reads and 24 cycles for corresponding writes (Yuhala et al., 2023). The main measured bottleneck is secure driver–to–TA buffer transfer, which is about $113\times$ more expensive than Linux kernel-to-user copy without cache flushing and about $10K\times$ more expensive with cache flushing (Yuhala et al., 2023). Driver partitioning for the I$^2$S proof of concept leaves 66.82% of the original driver trusted and 33.18% untrusted, yielding a 33.18% TCB decrease relative to moving the full driver into OP-TEE OS (Yuhala et al., 2023). In this usage, Fortress names a hardened enclave boundary around data ingress rather than computation alone.

5. Fortress as real-time semantic fallback planning in robotics

In “Real-Time Out-of-Distribution Failure Prevention via Multi-Modal Reasoning,” FORTRESS stands for “OOD Failure Prevention in Real Time by Reasoning about Fallback Strategies” (Ganai et al., 15 May 2025). It addresses open-world robotic failures where a nominal policy becomes unreliable and the system must rapidly identify semantically safe fallback goals and trajectories.

The architecture splits reasoning into a slow semantic phase and a fast online phase. At low frequency, multi-modal reasoners identify candidate fallback goals from abstract strategies and anticipate likely failure modes. At runtime, when a monitor triggers fallback, the system computes semantic hazard costs

$$\theta_\phi(x):=\Delta_\phi - sim(Embed(nearby(x,l_\phi)), e_\phi),$$

and solves a reach-avoid planning problem minimizing the worst semantic or collision hazard along the trajectory (Ganai et al., 15 May 2025). Candidate goals are grounded with a VLM, local semantic descriptions are extracted with open-vocabulary detectors such as OWL-ViT or YOLOv8, and planning uses RRT with MPC or LQR tracking.

The hardware timing breakdown is central: querying Molmo for goal points takes 5.82 s; querying Gemini 2.0 Flash for failure modes takes 3.68 s; safety reasoning inference at runtime takes 0.011 s; and the reach-avoid planner takes 1.28 s (Ganai et al., 15 May 2025). The system achieves more than 90% planning success in CARLA for rooftop landing and outperforms on-the-fly prompting baselines in both semantic safety classification and planning success (Ganai et al., 15 May 2025). This suggests another shift in fortress semantics: the “wall” is a set of semantically inferred safe fallback states rather than a fixed exclusion boundary.

6. Fortress as an efficient structural-segmentation architecture

FORTRESS is also the title of a computer-vision architecture for structural defect segmentation: “FORTRESS: Function-composition Optimized Real-Time Resilient Structural Segmentation via Kolmogorov-Arnold Enhanced Spatial Attention Networks” (Thrainer et al., 16 Jul 2025). The model targets real-time or near-real-time deployment for civil-infrastructure inspection under tight computational budgets.

The architecture is U-Net-inspired, with five encoder levels, depthwise separable convolutions throughout, adaptive TiKAN insertion, multi-scale spatial and channel attention, and deep supervision (Thrainer et al., 16 Jul 2025). Its efficiency argument rests on replacing standard convolutions with depthwise separable ones, reducing per-layer parameter cost from $9C_{in}C_{out}$ to $9C_{in}+C_{in}C_{out}$, alongside adaptive TiKAN activation only when $C_{in}\ge 16$ and $\sigma=N \mapsto \sigma'=N+1 \mapsto \sigma''=N$0 (Thrainer et al., 16 Jul 2025).

On CSDD, the model has 2.89M parameters and 1.17 GFLOPs, compared with 31.04M and 13.69 GFLOPs for U-Net, corresponding to about 91% reductions in both parameters and computational complexity (Thrainer et al., 16 Jul 2025). It achieves F1-score without background 0.771, mIoU with background 0.677, and mIoU without background 0.643, outperforming baselines such as U-Net, SA-UNet, and U-KAN (Thrainer et al., 16 Jul 2025). A related thesis presents the same architectural family for culvert and sewer inspection under limited annotated data, likewise naming it “Function-composition Optimized Real-Time Resilient Structural Segmentation” and reporting strong robustness under reduced-data settings (Thrainer, 21 Jan 2026). In this context, FORTRESS denotes not security but an efficiency–accuracy operating point engineered for defect segmentation.

7. Fortress as scientific software for spinor Bose–Einstein condensates

Two physics software papers use FORTRESS and FORTRESS II as names for FORTRAN packages solving coupled Gross–Pitaevskii equations for spin-orbit-coupled spinor condensates (2002.04365, Banger et al., 2020). The first treats spin-1 condensates with three coupled fields in quasi-1D, quasi-2D, and 3D geometries; the second generalizes to spin-2 condensates with five coupled fields.

FORTRESS implements a time-splitting Fourier spectral method with imaginary-time propagation for ground states and real-time propagation for dynamics (2002.04365). It supports anisotropic SOC strengths, harmonic traps, OpenMP parallelization, and outputs energies, chemical potentials, densities, and phases. The paper reports OpenMP speedups above 9 for 1D and 2D real-time codes and above 11 for 3D with 28 threads, with the 3D real-time code exceeding 40% efficiency at 28 threads (2002.04365).

FORTRESS II extends the same philosophy to spin-2 systems, again using OpenMP-parallel FORTRAN 90/95 programs and splitting the Hamiltonian into kinetic, spin-orbit, spin-exchange, and diagonal nonlinear terms (Banger et al., 2020). On a 24-core Intel Xeon Platinum 8160 CPU, the package reports speedups above 10 for 1D and above 9 for 2D and 3D at 24 threads (Banger et al., 2020). Here the name is mnemonic rather than metaphorical: “FORTRESS” is primarily a branded solver family.

8. Fortress as modular enclosure in social systems, graph privacy, and governance theory

Several papers use “fortress” as a substantive metaphor for enclosure, modularity, or concentrated accountability.

In “Beyond Individual Influence: The Role of Echo Chambers and Community Seeding in the Multilayer three state q-Voter Model,” “Fortress Worlds” are highly segregated duplex networks generated with mABCD at $\sigma=N \mapsto \sigma'=N+1 \mapsto \sigma''=N$1, meaning 95% of interactions remain within local communities (Hołowacz et al., 20 Feb 2026). Under the multilayer 3-state $\sigma=N \mapsto \sigma'=N+1 \mapsto \sigma''=N$2-voter model with LOCAL AND and $\sigma=N \mapsto \sigma'=N+1 \mapsto \sigma''=N$3, dense-cluster seeding methods such as CIM and k-Shell fail to trigger global cascades, producing the “Fortress Trap”: isolated bunkers of consensus caused by the Overkill Effect (Hołowacz et al., 20 Feb 2026). The paper contrasts this with VoteRank, which disperses seeds and more reliably overcomes modular bottlenecks. Fortress here denotes social insulation.

In “Decentralized Privacy Preservation for Critical Connections in Graphs,” the paper explicitly describes $\sigma=N \mapsto \sigma'=N+1 \mapsto \sigma''=N$4-cohesion as a “fortress-like cohesive subgraph” (Li et al., 2024). A connected subgraph $\sigma=N \mapsto \sigma'=N+1 \mapsto \sigma''=N$5 is a $\sigma=N \mapsto \sigma'=N+1 \mapsto \sigma''=N$6-cohesion if every vertex satisfies

$\sigma=N \mapsto \sigma'=N+1 \mapsto \sigma''=N$7

The minimal $\sigma=N \mapsto \sigma'=N+1 \mapsto \sigma''=N$8-cohesion containing a query vertex, $\sigma=N \mapsto \sigma'=N+1 \mapsto \sigma''=N$9, is treated as the vertex’s fortress and captures its critical connections (Li et al., 2024). Only the count contribution from inside this fortress is perturbed under decentralized differential privacy, while the outside contribution remains unperturbed. The paper proves that the resulting release satisfies $$\mathrm{CV}(s_{1:T})=\frac{\sigma(s_{1:T})}{\mu(s_{1:T})},$$0-DDP under its two-phase framework (Li et al., 2024).

In “Fortress and Gatekeeper: Theorizing Transitive Trust in Third-Party Cybersecurity Risk Governance,” the “Fortress” is the focal organization that receives customer trust and bears customer-facing accountability, even when technical processing is delegated to vendors (Chen et al., 25 Jun 2026). The framework contrasts the fortress with “gatekeepers,” i.e. vendors that hold data, privileges, analytics functions, infrastructure, or user-support roles. The paper’s four propositions tie fortress expansion to vendor integration, adversarial actionability of metadata, assurance decay, and accountability concentration (Chen et al., 25 Jun 2026). The term here names the visible trustee at the center of transitive trust rather than an actual security perimeter.

A related but distinct critique appears in “The Stateless Pattern: Ephemeral Coordination as the Third Pillar of Digital Sovereignty,” where the “Fortress model” means centralized, database-centric, state-custodial architecture (Carlin et al., 25 Jan 2026). The paper opposes this to a “Mist” model of client-side cryptography and self-destructing relays, arguing that privacy should come from the server’s structural blindness rather than defended stored state (Carlin et al., 25 Jan 2026). This use aligns conceptually with the cloud-security critique in (Torkura et al., 2019): fortress equals defended persistence, and the alternative is ephemerality.

9. Fortress in formal methods, artificial life, and heritage mapping

Additional uses are more specialized but still informative.

In “Portus: Linking Alloy with SMT-based Finite Model Finding,” Fortress is the library used as the SMT-based finite model finder behind a new Alloy backend (Dancy et al., 2024). Portus translates Alloy to many-sorted first-order logic with finite scopes and transitive closure, and Fortress then converts the resulting finite model-finding problem into EUF for SMT solving (Dancy et al., 2024). On a corpus of 49 supported expert Alloy models, the optimized Portus/Fortress configuration solves 46 within 5 minutes; Kodkod remains slightly stronger overall, but Fortress substantially outperforms Kodkod on some function-rich cases such as serializableSnapshotIsolation.als, where Portus takes 108.8 s versus Kodkod’s 904.3 s (Dancy et al., 2024). In this setting, Fortress is a reusable solver library.

In “Quality Diversity in the Amorphous Fortress (QD-AF): Evolving for Complexity in 0-Player Games,” “fortress” is inherited from the Amorphous Fortress grid-world simulation framework (Earle et al., 2023). Each evolved individual is a whole fortress: a 15-by-8 grid-world with 15 entity classes represented by finite-state machines. QD-AF uses MAP-Elites with behavior characteristics based on the mean number of surviving entities and total action-node count, and defines quality as

$$\mathrm{CV}(s_{1:T})=\frac{\sigma(s_{1:T})}{\mu(s_{1:T})},$$1

where $$\mathrm{CV}(s_{1:T})=\frac{\sigma(s_{1:T})}{\mu(s_{1:T})},$$2 is the number of explored nodes and edges and $$\mathrm{CV}(s_{1:T})=\frac{\sigma(s_{1:T})}{\mu(s_{1:T})},$$3 is the total encoded nodes and edges (Earle et al., 2023). The work treats fortresses as autonomous 0-player ecosystems rather than walls or defenses.

In “Royal Reveals: LiDAR Mapping of Kronborg Castle, Echoes of Hamlet’s Halls,” the word fortress appears in its historical architectural sense (Davies et al., 2024). The paper presents a 360-degree LiDAR dataset of Kronborg Castle, a Renaissance fortress in Helsingør, Denmark, reconstructed and modernized between 1574 and 1585, with approximate dimensions 145 m by 74 m, a tallest point of 62 m, and a total floor area of 16,000 m² (Davies et al., 2024). The dataset covers nearly the whole castle except three inaccessible rooms and is intended for SLAM, floorplan generation, and heritage analysis (Davies et al., 2024). This is the least metaphorical use of the term: fortress as a scanned built environment.

10. Recurring themes and conceptual divergences

Despite the heterogeneity, several recurrent motifs are visible.

First, fortress often marks a boundary condition. In cloud security, the boundary is the perimeter that the authors reject as a sufficient model (Torkura et al., 2019). In TEE-protected IoT, it is the secure I/O region (Yuhala et al., 2023). In graph privacy, it is the minimal $$\mathrm{CV}(s_{1:T})=\frac{\sigma(s_{1:T})}{\mu(s_{1:T})},$$4-cohesion enclosing critical edges (Li et al., 2024). In cyber-governance theory, it is the visible organizational locus of trust and accountability (Chen et al., 25 Jun 2026). In stateless internet architecture, it is the central database defended by policy and access control (Carlin et al., 25 Jan 2026).

Second, many papers use fortress in opposition to dynamism. The cloud-security paper argues for regenerative infrastructure and diversification over thicker walls (Torkura et al., 2019). The stateless-coordination paper argues for ephemerality over stored state (Carlin et al., 25 Jan 2026). The robotic FORTRESS system caches high-latency semantic reasoning and then replans dynamically around inferred hazards (Ganai et al., 15 May 2025). These works suggest that the most active technical reinterpretations of fortress are anti-fortress in the traditional static sense.

Third, the term often denotes concentrated internal support. That is literal in $$\mathrm{CV}(s_{1:T})=\frac{\sigma(s_{1:T})}{\mu(s_{1:T})},$$5-cohesion (Li et al., 2024), social echo chambers (Hołowacz et al., 20 Feb 2026), and even the heritage-dataset paper, where the fortress is a multilayered enclosed architectural structure (Davies et al., 2024). A plausible implication is that the enduring appeal of the term comes from its intuitive mapping to internally reinforced, externally bounded systems.

11. Ambiguity and disambiguation

Because FORTRESS is used across security, machine learning, robotics, computer vision, condensed-matter physics, formal methods, graph privacy, and digital-governance theory, disambiguation is essential in scholarly citation. A reference to “FORTRESS” without an arXiv identifier or domain qualifier is ambiguous among at least the following classes:

Use of “FORTRESS”	Research object	Key domain
Moving-target cloud defense	Adaptive security architecture	Cloud security
Frontier Risk Evaluation for NSPS	Benchmark/evaluation suite	LLM safety
Temporal feature-pruning framework	Model-stability method	Search/recommendation
TrustZone peripheral isolation	Secure systems architecture	IoT/TEE
OOD fallback planning	Real-time safety framework	Robotics
Structural segmentation network	Vision architecture	Infrastructure inspection

Additional ambiguity arises from near-homonymous extensions such as FORTRESS II for spin-2 condensates (Banger et al., 2020), QD-AF based on Amorphous Fortress (Earle et al., 2023), and “Fortress and Gatekeeper” as a governance framework (Chen et al., 25 Jun 2026).

12. Significance of the term across disciplines

The broader significance of FORTRESS lies not in a single technical lineage but in the way different fields recruit the metaphor. In security research, fortress frequently names either a challenged paradigm or a defended trust boundary (Torkura et al., 2019, Yuhala et al., 2023, Carlin et al., 25 Jan 2026, Chen et al., 25 Jun 2026). In ML systems and robotics, it names frameworks for robustness against instability or out-of-distribution danger (Jagre et al., 14 May 2026, Ganai et al., 15 May 2025). In computer vision, it brands an efficiency-conscious segmentation architecture (Thrainer et al., 16 Jul 2025). In physics and formal methods, it functions as a solver or software identity (2002.04365, Banger et al., 2020, Dancy et al., 2024). In social and graph-theoretic contexts, it becomes a model of modular enclosure or cohesive support (Hołowacz et al., 20 Feb 2026, Li et al., 2024).

This diversity suggests that “FORTRESS” has become a productive but unstable research signifier. It often conveys defense, cohesion, or boundedness, but the technical substance must be recovered from the specific paper. The term’s most consequential contemporary uses are probably those that subvert the static-fortress ideal—by regenerating compromised cloud nodes, eliminating state custody, or dynamically planning around semantic hazards—rather than those that merely reaffirm defended walls (Torkura et al., 2019, Carlin et al., 25 Jan 2026, Ganai et al., 15 May 2025).