Federated Retrieval-Augmented Generation for Cybersecurity in Resource-Constrained IoT and Edge Environments: A Deployment-Oriented Scoping Review

Abstract

Cybersecurity operations in IoT and edge environments require fast, evidence-grounded decisions under strict resource and trust constraints. While large language models can support triage and incident analysis, their parametric knowledge may be outdated and prone to hallucination. Retrieval-augmented generation (RAG) improves grounding by conditioning responses on retrieved evidence, but also introduces new risks such as knowledge-base poisoning, indirect prompt injection, and embedding leakage. Federated learning enables collaborative adaptation without centralizing sensitive data, motivating federated RAG (FedRAG) architectures for distributed cybersecurity deployments. This study presents a deployment-oriented scoping review of FedRAG for cybersecurity. The review follows PRISMA-ScR reporting guidance and synthesizes 82 studies published between 2020 and 2026, identified through keyword search and citation snowballing over OpenAlex, arXiv, and Crossref. We develop a taxonomy that clarifies the components of federated systems, deployment locations, trust boundaries, and protected assets. We further map the combined RAG+FL attack surface, summarize practical defenses and system patterns, and distill actionable guidance for secure, privacy-preserving, and efficient FedRAG deployment in real-world IoT and edge scenarios. Our synthesis highlights recurring trade-offs among robustness, privacy, latency, communication overhead, and maintainability, and identifies open research priorities in benchmark design, governance mechanisms, and cross-silo evaluation protocols for practical deployment.

1. Introduction

Cybersecurity is a knowledge-intensive domain: analysts must interpret logs, correlate heterogeneous signals, map observations to tactics and techniques, and make time-critical decisions with incomplete evidence. Large language models (LLMs) can assist in summarization, triage, and question answering, but their parametric knowledge can be outdated, and their outputs can hallucinate, a failure mode that is unacceptable for security operations. Retrieval-Augmented Generation (RAG) mitigates these limitations by retrieving supporting documents at inference time and conditioning generation on retrieved context [1]. As summarized in recent RAG surveys [2], this “retrieve-then-generate” paradigm has rapidly become a widely adopted architectural pattern for building LLM applications that require grounding, attribution, and fast knowledge refresh.

However, RAG also introduces new security and privacy risks that matter for security-critical deployments. Attackers can poison the knowledge base (KB) to corrupt answers [3], craft indirect prompt injections (IPIs) that exploit retrieved text [4,5], or implant backdoors into retrievers and generators [6,7]. Even when raw documents are never shared, embeddings and retrieval metadata can leak sensitive information through embedding inversion [8,9] and through routing/search patterns in distributed settings.

1.1. Motivating Deployment Scenario and Design Tensions

To ground the discussion, we use a running scenario that is representative of modern cybersecurity deployments in resource-constrained Internet of Things (IoT) and edge environments.

1.1.1. Scenario: Multi-Site IoT Fleet with a Central SOC

As illustrated in Figure 1, consider an enterprise (or a managed security service provider) that monitors IoT devices deployed across multiple sites (factories, offices, retail stores, or critical-infrastructure substations). Each site has an edge gateway that aggregates device telemetry (logs, alerts, flows) and stores local knowledge artifacts (tickets, incident notes, playbooks). A central security operations center (SOC) coordinates incident response and maintains curated global knowledge (approved policies, enterprise-wide threat intelligence, and vetted vulnerability references). The organization aims to deploy a RAG-based assistant to support analysts and operators in pivotal tasks, such as diagnosing device anomalies, mapping indicators to attack techniques, and recommending containment actions tailored to local constraints. In this workflow, the most valuable evidence is distributed and sensitive: raw telemetry and internal incident knowledge cannot be freely centralized, and cross-site or cross-organization sharing is governed by strict trust boundaries.

Figure 1. Motivating deployment scenario for cybersecurity IoT/edge FedRAG.

1.1.2. Key Design Tensions

This scenario highlights four recurring trade-offs that frame FedRAG as an architectural necessity rather than an optional enhancement:

• Freshness vs. governance: cybersecurity knowledge updates rapidly, but ingesting new content without provenance controls increases poisoning risk.
• Locality vs. completeness: edge-local evidence reduces leakage and latency, but purely local KBs can miss cross-site patterns.
• Confidentiality vs. collaboration: collaboration improves coverage and personalization, yet sharing documents, embeddings, or updates can leak sensitive incident information.
• Efficiency vs. security overhead: privacy-preserving retrieval (Trusted Execution Environments (TEEs), Homomorphic Encryption (HE), and Private Information Retrieval (PIR)) and privacy controls add latency and compute cost that matter on gateways and devices.

These tensions recur throughout the survey and provide a deployment lens for the taxonomy (Section 4) and mitigation guidance (Section 6).

1.2. Why FedRAG for IoT/Edge Cybersecurity?

A central barrier to adopting RAG in cybersecurity is that key evidence is distributed and sensitive. Operational telemetry (e.g., IoT device logs and alerts), internal incident reports, proprietary playbooks, and organization-specific threat intelligence are usually spread across sites or organizations. Regulatory constraints, contractual obligations, and Intellectual Property (IP) considerations often preclude centralizing raw data and, in some cases, sharing full document collections. At the same time, edge/IoT environments introduce severe resource constraints and enlarge the attack surface, making cloud-only RAG architectures difficult to deploy safely [10,11]. Before FedRAG, federated learning (FL) had already been explored for intrusion detection systems (IDS) and distributed security analytics in edge settings [12].

FL enables collaborative model adaptation without exchanging raw data by aggregating model updates [13,14]. Recent work integrates FL and RAG into FedRAG systems, which federate one or more components of the RAG pipeline, such as retriever tuning [15], distributed retrieval (federated search and routing) [16,17,18], secure/federated vector similarity search [19,20,21], or cross-silo confidential orchestration [22]. Beyond “classic” cross-silo settings, emerging systems highlight privacy-preserving RAG workflows [23] and federated parametric/in-context co-adaptation [24]. For cybersecurity IoT/edge deployments, these designs must simultaneously address (i) adversarial threat models, (ii) strict confidentiality boundaries, and (iii) resource and connectivity constraints.

1.3. Scope and Contributions

This survey complements broad systematic mappings of FedRAG [25] by focusing on the intersection of FedRAG, IoT/Edge and cybersecurity. Emphasizing practical challenges and deployment realism, we contribute:

• A deployment-oriented taxonomy organizing FedRAG by federated component(s), architecture (centralized/federated/decentralized), deployment locus (device/edge/on-prem/cloud), trust boundary, and protected assets (Section 4).
• A layered taxonomy presentation: an analytical comparison table and grouped comparison views by deployment and application context, with an appendix tagged inventory of reviewed works.
• A security and privacy synthesis unifying RAG-specific threats (poisoning, indirect prompt injection, retriever backdoors, data extraction, embedding inversion) with federated adversaries (malicious clients, poisoning, update leakage, routing leakage), culminating in an edge-feasible mitigation checklist (Section 6).
• An evaluation map and checklist covering benchmarks and metrics for retrieval quality, generation groundedness, security robustness, privacy leakage, and edge efficiency (Section 5).
• Three deployment blueprints (Section 8) that translate the literature into practically deployable system designs for SOC and IoT/edge scenarios.

1.4. Paper Organization

Section 2 describes the survey methodology and scope. Section 3 reviews RAG, FL, federated search, secure retrieval, and edge constraints. Section 4 surveys FedRAG architectures, representative systems, and cybersecurity applications. Section 5 discusses evaluation protocols. Section 6 details challenges and mitigations. Section 7, Section 8 and Section 9 cover related work, deployment discussion, future directions, and conclusions.

2. Survey Methodology and Scope

We conduct this work as a deployment-oriented scoping review. We adopt a transparent protocol for (i) identifying relevant literature, (ii) screening and categorizing studies, and (iii) synthesizing deployment patterns, threat models, and open gaps for cybersecurity IoT/edge FedRAG. We report the study identification and selection process in accordance with the PRISMA Extension for Scoping Reviews (PRISMA-ScR) [26] and provide a completed PRISMA 2020 flow diagram [27] (Figure 2). The completed PRISMA-ScR checklist is provided in the Supplementary Materials. A predefined review protocol (Appendix A) was used and documented. This review was not prospectively registered.

Figure 2. PRISMA 2020 flow diagram for identification, screening, eligibility assessment, and inclusion of studies in this scoping review.

2.1. Research Questions

We organize the survey around four research questions (RQs):

• RQ1 (What is federated?): Which parts of the RAG pipeline (retriever, generator, index/KB, routing, orchestration) are federated, and what trust boundaries are assumed?
• RQ2 (Edge realism): Which IoT/edge constraints dominate design choices, and how are they addressed in systems and evaluations?
• RQ3 (Threats and defenses): What risks emerge from the combined RAG+FL attack surface, and which defenses are practical under edge constraints?
• RQ4 (Evaluation): What benchmarks, metrics, and protocols are used to evaluate FedRAG, and how should they be adapted for cybersecurity IoT/edge deployments?

2.2. Information Sources and Search Strategy

We used a hybrid identification strategy combining keyword search with forward and backward citation snowballing. Primary sources were OpenAlex, arXiv, and Crossref. Searches were conducted in February 2026 and were restricted to English-language journal articles, conference proceedings, preprints, and technical reports published between 2020 and 2026.

Keyword queries were organized into thematic clusters covering FedRAG, privacy-preserving/confidential RAG, secure/private vector search and private ANNS, RAG security threats (prompt injection, poisoning, backdoors, extraction), edge/on-device/IoT RAG, federated LLM adaptation (e.g., federated fine-tuning/LoRA), embedding inversion and Vec2Text, and cybersecurity RAG applications. Representative queries and protocol settings are provided in Appendix A.

After keyword retrieval, we performed three rounds of forward and backward citation snowballing starting from a predefined seed set of conceptually central works in RAG, federated learning, edge computing, and RAG security. We also used predefined alternative methods (e.g., DOI/arXiv ID/title resolution) to ensure coverage of seminal works and benchmarks that keyword queries may not capture.

Because this is a deployment-oriented scoping review, coverage was defined conceptually rather than by disciplinary labels alone. In practice, adjacent areas relevant to reviewer concerns can be understood through FedRAG-relevant functional clusters: distributed information retrieval through federated search, routing, and source-selection studies; secure computation for vector search through private ANNS, secure/encrypted vector search, and TEE/HE/PIR-assisted retrieval studies; and edge information retrieval through edge/on-device RAG, serving, caching, and indexing work. We further reduced omission risk through seed-based forward/backward snowballing and predefined other-method identification of conceptually central works in these adjacent areas. We therefore do not claim exhaustive coverage of DIR, secure computation, or edge IR as standalone areas of literature; rather, we aimed to cover those parts of these areas that materially affect FedRAG deployment, privacy, threat modeling, or evaluation conclusions.

2.3. Eligibility Criteria

We included English-language journal articles, conference proceedings, preprints, and technical reports published between 2020 and 2026 that provide substantive technical evidence relevant to the cybersecurity deployment of FedRAG in IoT/edge settings. Specifically, we included works that satisfy at least one of the following:

• FedRAG architectures and federation primitives: federated retriever/generator tuning, federated indexing, and federated search/routing [15,16,17,18,24,28].
• Privacy-preserving retrieval for RAG: TEEs, cryptographic similarity search, federated/private vector search, and private ANNS building blocks [19,20,21,22,29,30,31,32,33,34].
• Privacy-preserving RAG workflows: local privacy shields, differential privacy (DP) KB release, and end-to-end privacy-preserving RAG pipelines [23,35,36,37,38].
• Edge/on-device and serving optimizations: system designs and optimizations relevant to IoT deployments (indexing, caching, incremental updates, scheduling) [39,40,41,42,43,44,45,46,47].
• Cybersecurity RAG applications and RAG security analyses/benchmarks: security assistants and adversarial evaluations relevant to SOC and IoT/edge [3,48,49,50,51,52,53,54,55,56,57,58].

Operationally, we treated a work as in-scope FedRAG evidence if it satisfied at least one of three conditions: (i) it federated a RAG-relevant component or coordination function (retriever, generator, index/KB, routing, or orchestration); (ii) it instantiated the secure retrieval/search mechanism that becomes a first-class bottleneck in cross-silo RAG; or (iii) it provided deployment evidence (benchmark, application, or security evaluation) that materially constrains FedRAG design choices. By contrast, generic background works on IR, LLMs, or FL were cited for exposition but were not counted in the PRISMA-ScR corpus unless they changed the deployment, privacy, or threat-model conclusions of the survey.

For clarity, we distinguish three roles in the review. We refer to a study as a FedRAG architecture/pattern when federation changes at least one operational RAG component or coordination function in the deployed workflow. We refer to supporting building blocks when a paper does not itself instantiate end-to-end FedRAG, but contributes a retrieval, privacy, or coordination primitive that becomes a binding constraint in FedRAG deployment (e.g., private vector search, secure aggregation, or routed source selection). We refer to contextual evidence when applications, benchmarks, or security analyses do not federate the full workflow, yet materially determine the threat model, evaluation protocol, or operational requirements used in this survey. This distinction is used consistently below: the patterns in Section 4 describe FedRAG design choices, whereas supporting building blocks and contextual evidence are included to explain feasibility, risk, or evaluation constraints rather than to relabel every adjacent system as FedRAG.

We excluded purely centralized RAG studies without a security/privacy/edge/federation angle, and purely FL security works that do not interact with retrieval or KB governance. During full-text assessment, we excluded reports with no substantial RAG/retrieval focus, insufficient deployment-oriented technical detail, or non-primary study types for this scoping review. Foundational background references retained for exposition were not counted as included studies in the PRISMA-ScR corpus. A summary of inclusion and exclusion criteria is detailed in Appendix A.

2.4. Screening Procedure and Selection Flow

Study selection followed PRISMA-ScR and is documented in the PRISMA 2020 flow diagram (Figure 2). Records from keyword search and citation snowballing were de-duplicated using DOI, arXiv ID, OpenAlex ID, and normalized titles, then screened by title/abstract and full text. Overall, 10,330 records were identified, 2519 duplicates were removed, 7811 records were screened, 139 full-text reports were assessed (including predefined other-method records), and 82 studies were included. Full-text exclusions (n = 57) were due to no substantial RAG/retrieval focus (n = 53), insufficient deployment-oriented technical detail (n = 3), or non-primary technical study type (n = 1). The PRISMA-ScR flow diagram reports the core study-selection corpus used for evidence synthesis. Additional background references were cited where needed to contextualize foundational concepts.

2.5. Quality Assessment and Evidence Interpretation

Because the field is rapidly evolving and includes many preprints, we did not compute a single “quality score”. Instead, we used a structured quality assessment checklist (detailed in Appendix A) to interpret the strength and transferability of evidence when synthesizing design patterns and open gaps.

2.6. Data Extraction, Coding, and Synthesis

For each included work, we extracted: (i) deployment setting (cross-silo vs. cross-device; device/edge/cloud split), (ii) federated components (retriever, generator, index, routing or orchestration), (iii) threat model(s) and protected assets (updates, queries, embeddings, context, KB), (iv) defense mechanisms (secure aggregation, DP, HE/PIR, TEEs, access control, sanitization, provenance), and (v) evaluation tasks/metrics (retrieval, groundedness, Attack Success Rate (ASR), privacy leakage, latency, bandwidth). The coding procedure was hybrid. We initialized a deductive coding frame from the research questions and from recurring deployment axes (federated component, deployment locus, trust boundary, protected asset, defense family, and evaluation dimension). We then refined subcategories inductively while reading full texts, especially for architectural patterns, privacy mechanisms, and operational constraints. This iterative process produced the taxonomy of Section 4: the top-level axes were fixed early, while pattern definitions, tag combinations, and deployment groupings were stabilized only after repeated comparison across included works. We mapped studies into the taxonomy of Section 4, and distilled threats/mitigations in Section 6. The Appendix tag dictionary (Appendix B) serves as the operative coding legend used to apply these tags consistently. In other words, the top-level axes were author-defined for analytical consistency, whereas lower-level pattern labels and tag combinations were evidence-refined during full-text comparison. Because this is a scoping review rather than an inter-rater reliability study, we report the coding logic and tag legend explicitly rather than a formal agreement coefficient; reproducibility therefore rests on the transparency of the coding rules and examples provided in the taxonomy tables and appendix.

2.7. Scope Limitations and Threats to Validity

Our scope is intentionally deployment-oriented and cybersecurity-centric, which introduces two limitations. First, some general-purpose RAG systems work (e.g., advanced retrievers/rerankers) is only included when it changes the security, privacy, or edge feasibility story. Second, FedRAG is a fast-moving area with many preprints; results and naming conventions can change quickly. We mitigate this by (i) emphasizing design patterns and threat surfaces that are stable across implementations, and (ii) making our taxonomy explicit so future work can be integrated consistently. A further interpretive boundary concerns the combined RAG+FL attack surface synthesized later in the paper. Some risks are supported by direct end-to-end FedRAG systems or benchmarks, whereas others are synthesis-based inferences drawn by combining empirical RAG attack studies with empirical FL poisoning/leakage studies under shared trust-boundary assumptions. We therefore treat the combined threat map as a deployment-oriented synthesis rather than as a claim that every combined threat has already been validated on a single unified production-grade FedRAG stack.

3. Background

3.1. Retrieval-Augmented Generation

RAG systems augment an LLM with a retriever and an external knowledge base (KB). Given a query q, a retriever returns top-k evidence passages ${\left\{d_i\right\}}_{i=1}^k$, and the generator produces an answer conditioned on retrieved context [1]. Dense retrieval commonly uses a bi-encoder: $e_q=f_{\theta }\left(q\right)$, $e_d=f_{\theta }\left(d\right)$, with similarity $\mathrm{sim}(e_q,e_d)$ (e.g., dot product), enabling approximate nearest neighbor (ANN) search over a vector database [59].

3.1.1. Pipeline Components That Matter for Security and Deployment

Operational RAG pipelines typically include (i) ingestion and KB governance (source vetting, provenance, access control), (ii) chunking and embedding, (iii) indexing and ANN search, (iv) optional reranking, (v) context assembly (quotas, filtering, sanitization), and (vi) generation and post-processing (citations, refusal, policy checks). These stages define the main assets (documents, embeddings, queries, retrieved context, and model parameters) and the main attack surface (poisoning at ingestion, retrieval manipulation, and injection/exfiltration at generation).

3.1.2. Security and Privacy Implications of Embeddings

In modern RAG deployments, embeddings are often treated as “safe” derived data. However, embeddings can leak substantial information about the underlying text via generative embedding inversion attacks [9] and via practical reconstruction methods such as Vec2Text [8]. Recoverability depends on embedding models and system choices; mitigations can preserve ranking while reducing leakage [60]. These results imply that, in cybersecurity RAG, embeddings and retrieved context must be treated as sensitive assets, especially when shared across silos or processed in third-party infrastructure.

3.2. FL Basics

FL trains models across multiple clients without centralizing raw data. The canonical FedAvg algorithm alternates between local optimization on clients and server-side aggregation of updates [13]. Because model updates can leak information, practical FL deployments often use secure aggregation (SA) [61] and sometimes differential privacy (DP) [62]. Cross-silo FL is common for organizations; cross-device FL is common for IoT and mobile, where partial participation and communication efficiency are central [14].

Threats Inherited from FL

Federation introduces classic threats such as malicious clients and backdoor/poisoning attacks [63], as well as update-based leakage attacks that reconstruct training information from gradients/updates [64]. Secure aggregation mitigates per-client update leakage [61], but can introduce scalability costs; recent protocols such as Turbo-Aggregate aim to reduce secure aggregation overheads [65]. These threats and mitigations become more complex in FedRAG because retrievers and routers directly influence which external text is injected into the generator context.

3.3. Federated Search and Secure Retrieval

Federated search retrieves results from multiple autonomous collections without centralizing content [66]. In RAG, this becomes “retrieve-then-generate” across multiple silos: source selection (routing), ranking fusion, access control, and query privacy become first-order issues. Recent FedRAG designs explore routing [16], evaluation benchmarks for federated search in RAG [17,18], TEEs for confidential RAG [22], homomorphic-encryption-based vector search [19], and TEE-assisted federated vector similarity search [20,21].

Private and Encrypted Vector Search

When the retriever must operate across trust boundaries, secure retrieval primitives become relevant. Private/secure approximate nearest neighbor search (ANNS) protocols and encrypted semantic search systems protect queries and/or databases, e.g., SANNS [29], two-server private ANN with sublinear communication [30], PACMANN [31], single-server private ANNS designs [32], and encrypted semantic search engines such as Compass [33]. RAG-specific systems (e.g., PIR-RAG) further tailor these primitives for end-to-end RAG query privacy [34].

3.4. IoT/Edge Constraints and Security Requirements

Edge computing pushes computation closer to data sources to reduce latency and bandwidth, but it also imposes limits on compute, memory, energy, and network availability [10]. IoT/edge cybersecurity deployments require:

• Confidentiality: protect sensitive telemetry, incident data, and private KB contents;
• Integrity: prevent KB poisoning, index manipulation, and malicious update injection;
• Availability: tolerate intermittency and resist DoS at retrieval/generation;
• Auditability/provenance: trace evidence used in outputs for compliance and incident review.

These operational constraints, together with the above security requirements, jointly shape the design space of FedRAG. In particular, they influence index structure, routing strategy, update mechanisms, and trust management. Table 1 summarizes these constraints and their corresponding design implications.

Table 1. IoT/edge constraints and their implications for FedRAG design.

Constraint	Implication for FedRAG
Limited memory/storage	Small local indexes; aggressive chunking; caching; incremental updates
Limited compute	PEFT for tuning; lightweight retrievers; split execution
Intermittent connectivity	Local-first retrieval; delayed/async rounds; robust fallbacks
Heterogeneity	Personalization; domain adaptation; per-silo log formats
Bandwidth/latency budgets	Routing optimization; compressed updates; efficient secure primitives
Adversarial environment	Provenance; ingestion hygiene; security regression testing

Because “IoT and edge” spans hardware with very different capabilities, we use the operational hardware taxonomy in Table 2 throughout the remainder of the survey. The purpose is not to impose a universal standard, but to make deployment claims explicit about which edge tier they realistically target.

Table 2. Operational hardware tiers used to interpret FedRAG deployment feasibility.

Tier	Typical Role	Usually Feasible	Usually Impractical Without Offload
T0: device/sensor class	Microcontroller-class endpoints, simple sensors, low-power embedded devices	Telemetry collection; lightweight filtering; secure forwarding; policy-constrained local caching of tiny artifacts	Full vector indexing; dense retrieval; local LLM inference; cryptographically heavy private retrieval
T1: smart endpoint class	Phones, rugged handhelds, rich IoT endpoints, compact edge clients	Small local indexes; lightweight retrieval; selective context reduction; constrained on-device RAG	Cross-silo confidential search with strong cryptographic overhead; heavy retriever training; large generators
T2: edge gateway class	Site gateway, branch server, industrial edge box	Local-first KB hosting; moderate retrieval; caching; policy enforcement; participation in federated routing or retriever adaptation	Large-scale confidential retrieval across many silos without careful cost controls
T3: edge/on-prem server class	Factory server, SOC appliance, on-prem cluster	Multi-KB orchestration; routed retrieval; retriever adaptation; audit logging; some TEE-assisted or otherwise secure coordination	None by definition, but cost/latency still constrain TEEs, HE, and PIR at scale

These requirements motivate both architectural choices (Section 4) and security analysis (Section 6).

4. FedRAG for Cybersecurity in IoT/Edge Environments

4.1. System Model, Trust Boundaries, and Threat Actors

We consider FedRAG deployments in which evidence and/or learning signals are distributed across multiple silos (organizations, sites, or tenants) and often originate from resource-constrained IoT and edge environments. A FedRAG system typically includes: (i) one or more knowledge bases (local KBs per silo and optional global KB tiers), (ii) a retriever (and possibly a reranker) that selects evidence, (iii) a generator that produces responses conditioned on retrieved context, and (iv) a coordination layer that handles federation, routing, policy enforcement, and auditing.

4.1.1. Cross-Silo vs. Cross-Device Federation

Most cybersecurity deployments are naturally cross-silo: sites or organizations collaborate while keeping raw documents local. Some IoT scenarios also involve cross-device participation, in which multiple devices contribute updates or telemetry summaries under intermittent connectivity. These settings differ in participation, heterogeneity, and communication constraints [14], and they motivate different FedRAG designs (e.g., gateway-level aggregation vs. device-level personalization).

4.1.2. Trust Boundaries and Protected Assets

We treat the following as primary protected assets: raw documents, embeddings and index structures, queries, retrieved context, and model updates. Importantly, embeddings and retrieved passages can leak sensitive incident information (Section 3.1) [8,9], and federated updates can leak information about local corpora [64]. Therefore, “keeping documents local” is insufficient for strong confidentiality in multi-silo deployments.

4.1.3. Threat Actors

We consider three broad attacker classes that frequently co-exist in cybersecurity settings: (i) content adversaries who can inject or tamper with KB content (poisoning, retrieval hijack) [3,67]; (ii) interaction adversaries who exploit the RAG interface (indirect prompt injection, KB extraction) [4,68,69]; and (iii) federated adversaries who participate in federation to poison or backdoor models and/or infer private information from updates [63,64]. This survey emphasizes deployments in which these threats overlap and must be mitigated jointly.

4.1.4. The Coordination Layer as Both Control Point and Bottleneck

Routers, aggregators, and orchestration services are often introduced to select silos, aggregate updates, enforce policy, and record audit trails. These components improve scalability and governance, but they also create additional attack surface and operational bottlenecks. A compromised router can leak which silo is likely to contain relevant evidence; a fragile aggregator can delay update propagation or become a single point of failure; and an orchestration layer with weak policy separation can expose context across trust tiers. For this reason, we treat the coordination layer not as “glue code” but as a first-class FedRAG component whose confidentiality, integrity, availability, and auditability must be specified explicitly [16,20,22].

These attacker classes represent distinct but overlapping dimensions of cybersecurity threats within federated retrieval-augmented generation (FedRAG) systems. A comprehensive deployment-oriented taxonomy is presented in Table 3, highlighting critical aspects of architecture, trust boundaries, protected assets, and applicable defense mechanisms. This survey emphasizes deployments in which these threats overlap and must be mitigated jointly, guided by the structured categorization provided in the taxonomy.

Table 3. Deployment-oriented taxonomy for FedRAG in IoT/edge cybersecurity.

Axis	Keywords
Architecture	Centralized; Cross-silo FedRAG; Peer-to-peer; Edge–cloud; Multi-KB
Fed. component(s)	Retriever; Generator; Index/KB; Vector search; Routing
Deployment	On-device; Edge gateway; On-prem; Cloud; Split execution
Trust boundary	Single-org; Multi-org; Distrusted parties; Tiered KBs
Protected assets	Documents; Updates; Embeddings; Queries; Context; Metadata
Threat model	Leakage; Inference; Inversion; Poisoning; Prompt injection; Access bypass
Defenses	Secure agg.; DP; HE/PIR; TEEs; Access control; Sanitization
Engineering	Trade-offs; Scalability; Heterogeneity; Comm. cost; Intermittency

4.1.5. Analytical Classification and Grouped Views of Reviewed Works (2020–2026)

We organize the evidence base at two levels. Table 4 classifies studies by study class, deployment condition, and dominant guarantee, while Table 5 and Table 6 present grouped views by deployment context and by cybersecurity application context. These tables emphasize deployment fit, guarantee type, dominant limitation, and best-fit use. Detailed latency/bandwidth cost signals are discussed later in Section 5, where representative numerical reference points are summarized. We additionally summarize a conservative evidence maturity dimension at the study-class level, because maturity is reported inconsistently in the literature and would otherwise be overstated if assigned as a hard operational label to every entry. Table A5 in the appendix lists the individual works using the same compact tag set. A complete dictionary of the compact tags (covering deployment architecture, federated components, study/source types, threats, and defenses) is provided in Appendix B.

Table 4. Analytical classification of the reviewed FedRAG evidence base.

Study Class	What Is Federated or Protected	Typical Trust Boundary/ Deployment Fit	Primary Guarantee or Concern	When This Class Is Most Appropriate	Typical Evidence Maturity
Local-first and edge-optimized RAG	Local KB, index, retrieval, caching, and split execution	Single organization; strong locality; T1–T3 hardware tiers	Latency, memory, intermittency, and bounded exposure	When most queries can be answered from local telemetry/playbooks and cross-site escalation should be exceptional	Mostly prototype systems and controlled system evaluations; operational evidence remains limited
Federated retriever adaptation and personalization	Retriever parameters, adapters, embeddings, or routing-related updates	Cross-silo settings with related tasks but heterogeneous vocabularies or formats	Transfer vs. leakage; personalization vs. consistency	When raw documents cannot be shared, but learning a better retriever across silos materially improves coverage	Mostly research prototypes; benchmark and operational evidence remain scarce
Federated routing and source selection	Query routing, source selection, fusion, and retrieval exposure control	Multi-silo search where broadcast is too costly or too revealing	Coverage vs. metadata leakage; coordination reliability	When many silos exist and query minimization is required for bandwidth, confidentiality, or policy reasons	Mix of prototype systems and benchmark evidence; little documented operational use
Confidential cross-organization RAG	Retrieval and sometimes generation executed across protected trust boundaries	Multi-organization collaboration with mutually distrusted parties	Context confidentiality and policy enforcement	When the KB is high-value and the central question is whether any cross-silo retrieval can be performed safely at all	Mostly prototype or primitive-level evaluations; operational evidence is sparse
Private or federated vector search protocols	Top-k search protocol, query privacy, vector-database privacy, access-filtered search	Cross-silo or outsourced retrieval where the search primitive itself is the bottleneck	Query/DB secrecy vs. communication and latency overhead	When documents may stay local, but embeddings, access patterns, or vector search transcripts remain too sensitive to expose	Primitive evaluations and prototype systems dominate; benchmark-style evidence is more common than deployment reports
Privacy-preserving RAG workflows	Queries, retrieved context, embeddings, or KB release itself	Single- or multi-org deployments with strict privacy controls on evidence movement	Selective disclosure, local privacy, and sanitized sharing	When the main design goal is to bound what leaves a device/site, even before introducing heavy confidential retrieval	Early prototypes and controlled evaluations; operational evidence remains limited
Cybersecurity applications and benchmarks	End-to-end tasks, operational assumptions, and evaluation artifacts	SOC, DFIR, CTI, vulnerability analysis, and IoT security workflows	Task realism, auditability, and deployment maturity	When selecting evaluation criteria, operational assumptions, and concrete workflow requirements for a FedRAG deployment	Mix of benchmarks and prototypes, plus a small amount of workflow-oriented deployment evidence (e.g., Wazuh Copilot; CyRAG/ GraphCyRAG), but little sustained production evidence

Table 5. Grouped comparison of the reviewed literature by deployment context. Each row summarizes a study cluster rather than individual articles.

Deployment Group	Representative Studies	Typical Deployment/ Trust Boundary	Guarantee Type	Dominant Cost/Limitation	Best-Fit Cybersecurity Use
Local-first/ edge-optimized operation	EdgeRAG; MobileRAG; Chain-of-Rank; CoEdge-RAG; DIRC-RAG; DGRAG; RAGCache; CacheBlend; EraRAG [39,40,41,42,43,44,45,46,47]	Single organization; edge gateway or split edge–cloud execution; strong locality; T1–T3 hardware tiers	Systems efficiency and bounded exposure	Memory pressure, cache governance, intermittent links, and limited global visibility	Site-local triage, IoT operator assistance, and low-latency incident support
Cross-silo retriever adaptation/ personalization	FedE4RAG; pFedRAG; FedMosaic; HyFedRAG [15,24,28,70]	Related organizations or sites with heterogeneous corpora, formats, or vocabularies; raw documents stay local	Collaborative optimization and partial privacy	Update leakage, coordination overhead, personalization drift, and limited operational evidence	Multi-site enterprise SOCs where local playbooks differ but retrieval quality must improve jointly
Selective cross-silo routing/source selection	RAGRoute; FeB4RAG; MKP-QA [16,17,18]	Multi-silo search where broadcasting every query is too costly or too revealing	Exposure minimization and routing control	Metadata leakage, missed recall under strict routing, and coordination reliability	Cross-site threat-intelligence lookup and tenant-aware evidence selection
Confidential cross-organization retrieval	C-FedRAG; FRAG; FedVS/FedVSE; PIR-RAG; Compass [19,20,21,22,33,34]	Multi-organization or outsourced retrieval across mutually distrusted parties; high-value shared KBs	Confidential retrieval via TEE, HE, PIR, or private ANNS	Latency and communication overhead, stronger infrastructure assumptions, and complex trust setup	Regulated intelligence sharing, selective high-value KB access, and cross-organization investigation
Controlled-disclosure/ privacy-preserving workflows	LPRAG; VAGUE-Gate; DP-SynRAG; ppRAG; SD-RAG [23,35,36,37,71]	Single- or multi-site deployments that must bound what queries, context, or KB releases can leave a site	Local privacy, sanitization, selective disclosure, and DP-style release control	Utility loss, sanitization error, and limited end-to-end deployment evidence	Endpoints or sites with strict evidence-release policies and strong privacy constraints

Table 6. Grouped comparison of the reviewed literature by cybersecurity application context.

Application Context	Representative Studies	Typical Evidence Environment	Main Deployment Value	Main Limitation/Maturity
SOC triage and response copilots	Wazuh RAG copilot; CyRAG/ GraphCyRAG; MoRSE [49,55,56]	Alerts, SIEM events, playbooks, tickets, and analyst notes	Analyst assistance with retrieval-grounded explanations and workflow integration	Workflow-oriented evidence exists, but sustained production validation across large SOCs remains scarce
DFIR and incident reconstruction	GenDFIR; ProveRAG [50,52]	Logs, reports, timelines, and multi-source case evidence	Evidence-backed reconstruction, provenance, and cross-source correlation	Cross-team confidentiality and chain-of-custody issues are rarely evaluated in federated settings
Vulnerability analysis and remediation	Vul-RAG; ProveRAG [50,51]	CVEs, advisories, code/security knowledge bases, and remediation guidance	Grounded vulnerability interpretation and patch or mitigation support	Frequent updates, freshness, and poisoning resistance remain open operational issues
CTI enrichment, ATT&CK mapping, and threat attribution	TechniqueRAG; AURA [53,72]	Threat reports, ATT&CK-aligned knowledge, and enrichment corpora	Shared reasoning over evolving threat knowledge and more consistent analyst outputs	Schema alignment, trust in shared intelligence, and cross-silo governance remain under-specified
IoT/edge security assistance	ChatIoT; EdgeRAG; MobileRAG [39,40,48]	Device telemetry, local manuals, operational playbooks, and intermittent connectivity	Local-first assistance under bandwidth, compute, and privacy constraints	Direct operational cyber evidence is still limited; much of the support comes from enabling systems rather than long-lived deployments
Malware analysis and explainable security reasoning	TraceRAG [54]	Sensitive malware traces, behavior reports, and explanatory evidence chains	Auditability and evidence-backed reasoning for high-stakes analysis	Secure handling of sensitive samples and cross-boundary retrieval remains only lightly evaluated

We interpret maturity conservatively. We reserve “operational evidence” for works that report real workflow constraints, practitioner-facing deployment context, or sustained operational reporting; research systems, even when implemented, remain prototypes without such evidence, and datasets/toolkits/evaluation artifacts are treated as benchmark evidence rather than deployment proof. Under this interpretation, systems such as CHATIoT, EdgeRAG, MobileRAG, C-FedRAG, and FRAG remain prototype evidence because they are evaluated as research implementations under controlled settings. By contrast, deployment-facing systems such as the Wazuh Security Event Response Copilot and the PNNL CyRAG/GraphCyRAG report provide workflow-oriented evidence for analyst use, but they still fall short of broad, sustained production validation across large operational SOC or IoT environments. On this basis, the current corpus is dominated by prototypes and benchmarks, while documented operational cybersecurity deployments remain scarce.

Several regularities emerge from Table 4, Table 5 and Table 6. First, the strongest distinction is not merely “federated” versus “non-federated”, but what is being federated: updates (Pattern P2), routing decisions (Pattern P3), confidential execution across organizational boundaries (Pattern P4), the vector-search protocol itself (Pattern P5), or privacy controls around the full workflow (Pattern P6). Second, the grouped deployment view shows that the dominant design question changes with the trust boundary. Single-organization edge deployments are primarily constrained by locality, cache safety, and hardware fit, whereas multi-organization deployments are dominated by coordination, confidentiality, and policy enforcement. Third, the grouped application view shows that cybersecurity use is concentrated in SOC, DFIR, vulnerability-analysis, CTI, and IoT-assistance workflows, while documented long-lived operational evidence remains sparse. Overall, the literature suggests a practical ordering of choices: start with local-first or routed designs when exposure can be minimized operationally; move to federated adaptation when heterogeneity hurts retrieval quality; and reserve confidential retrieval or private vector search mechanisms for settings where the trust boundary itself makes simpler designs unacceptable.

4.2. Architectural Patterns

We summarize common architectural patterns in Table 7 and illustrate them in Figure 3, highlighting their alignment with IoT/edge cybersecurity requirements. These patterns are not all mutually exclusive. In particular, Patterns P4–P6 operate at different analytical layers: P4 is an architecture-level answer to low inter-organizational trust, P5 isolates the retrieval protocol as the bottleneck to secure cross-silo search, and P6 adds workflow-level privacy controls that can be composed with either of the former two patterns.

Table 7. Summary of architectural patterns (P1–P7) and their deployment implications for cybersecurity IoT/edge FedRAG.

Pattern	Analytical Layer/Core Idea (What Changes vs. Centralized RAG)	Typical Deployment Split	Typical Feasible Tier(s)	Representative Exemplars
P1	Architecture layer: local-first retrieval with controlled escalation; generation may remain centralized	Retrieve at edge gateway/on-prem; generate on-prem/cloud	T1–T3 (T0 as data source only)	EdgeRAG, MobileRAG [39,40]
P2	Adaptation layer: federated retriever tuning to share improvements without sharing raw text	Local corpora; federated updates via a coordinator (SA/DP optional)	Typically T2–T3; lightweight adapters may extend to capable T1 clients	FedE4RAG, pFedRAG [15,28]
P3	Coordination layer: federated search with routing/source selection to minimize cross-silo exposure	Router/coordinator selects silos; retrieval stays local to providers	T1 for routing logic; T2–T3 for provider-side retrieval	RAGRoute; FeB4RAG; MKP-QA [16,17,18]
P4	Architecture/trust layer: confidential cross-organization RAG when providers are mutually distrusted	TEEs/HE execute retrieval (and sometimes generation) across boundaries	Mostly T3; sometimes T2 with offload or strong infrastructure support	C-FedRAG; FRAG [19,22]
P5	Retrieval-protocol layer: federated/private vector similarity search as a first-class component	Global top-k computed under access filters without centralizing vectors	Mostly T3; selective T2+ offload only	FedVS/FedVSE; PIR-RAG [20,21,34]
P6	Workflow/privacy-control layer: privacy-preserving RAG around queries, context, embeddings, or KB release	Local privacy shields or DP KB release; optional confidential retrieval	T1–T3, with minimal filtering and release controls extendable to constrained endpoints	LPRAG; VAGUE-Gate; DP-SynRAG; ppRAG [23,35,36,37]
P7	Hybrid execution layer: personalization and edge–cloud co-adaptation across heterogeneous silos	Tiered adapters and split execution; co-adaptation under constraints	T1–T3 with coordination concentrated at T2–T3	HyFedRAG; FedMosaic [24,70]

Figure 3. Visual summary of recurrent analytical patterns (P1–P7) in FedRAG for IoT/edge cybersecurity. The patterns are shown side-by-side for readability, but they are not all at the same abstraction level: P1–P3 and P7 summarize architecture or adaptation choices, whereas P4–P6 capture composable trust-, retrieval-protocol-, and workflow-level privacy/security patterns.

These tier labels are grounded in the representative implementations reviewed here rather than in an abstract capability ranking. MobileRAG evaluates a fully on-device pipeline on a Galaxy S24-class smartphone, supporting T1 feasibility for lightweight local retrieval and prompt reduction [40]. EdgeRAG is evaluated on a Jetson Orin Nano with 8 GiB DRAM and a 15 W power limit, supporting T2 feasibility for memory-aware edge retrieval [39]. RAGRoute reports sub-millisecond router inference and explicitly notes that the router is lightweight enough for low-resource devices, but its provider-side retrieval experiments are still run on server-class infrastructure, so we treat routed search itself as lighter-weight than the retrieval backends it coordinates [16]. By contrast, C-FedRAG, FRAG, FedVS, FedVSE, and PIR-RAG rely on TEEs, HE, PIR, or multi-server cloud deployments, so we conservatively interpret them as T3-oriented or offloaded T2 deployments rather than native T1 techniques [19,20,21,22,34].

4.2.1. Pattern P1: Local-First Retrieval, Central Generation

An edge gateway maintains a local KB/index; IoT devices query locally. Only if local evidence is insufficient, the gateway escalates to cross-silo retrieval or a central KB. Generation runs on a secure on-prem server or a controlled cloud. This pattern reduces data exfiltration, supports offline operation, and fits edge indexing optimizations [39,40]. For security, local-first retrieval also limits the blast radius of prompt injections and poisoned external feeds, at the cost of potentially reduced global context.

4.2.2. Pattern P2: Federated Retriever Adaptation

Sites collaboratively fine-tune a dense retriever (or PEFT adapters) over local corpora using FL. FedE4RAG illustrates privacy-preserving federated embedding learning via distillation and encrypted parameter exchange [15]. For cybersecurity, this pattern supports adaptation to site-specific log formats, device vocabularies, and local threat narratives. A key design choice is whether the retriever is shared globally (with higher transfer) or personalized per site (with higher privacy and local accuracy).

4.2.3. Pattern P3: Federated Search with Routing and Source Selection

Rather than broadcasting queries to all silos, routing selects a small set of relevant sources. RAGRoute proposes lightweight query-time routing to reduce redundant traffic while maintaining retrieval quality [16]. FeB4RAG and MKP-QA provide complementary benchmarks to compare federated search strategies, source selection, and fusion policies in multi-provider settings [17,18]. Routing is especially valuable for bandwidth-limited IoT/edge deployments and can reduce query exposure, but it introduces a new trust point (the router) and a new leakage channel (routing decisions as metadata). From a coordination perspective, Pattern P3 is only as reliable as its router and source-selection policy: mis-routing, stale provider metadata, or fail-open fallback logic can simultaneously harm recall, increase unnecessary cross-silo exposure, and create analyst-visible delays.

4.2.4. Pattern P4: Confidential Cross-Org RAG

When silos do not trust each other, confidentiality becomes dominant. Pattern P4 should be read as an end-to-end architectural stance: the question is how retrieval and, in some systems, generation are executed across a low-trust boundary without exposing sensitive context. C-FedRAG uses TEEs to execute retrieval and generation in enclaves, protecting context confidentiality [22]. FRAG explores HE-based encrypted vector similarity search for secure collaborative retrieval [19]. Such approaches are relevant to cross-organizational threat intelligence sharing, but must be engineered to support latency, remote attestation, and side-channel robustness. In coordination terms, Pattern P4 concentrates trust into a secure orchestration path: enclave lifecycle management, attestation, key handling, and failover behavior become part of the security boundary rather than mere implementation details.

4.2.5. Pattern P5: Federated/Private Vector Similarity Search as a First-Class Component

Many FedRAG designs implicitly assume that cross-silo retrieval can be implemented safely once documents remain local. In practice, the retrieval protocol itself often becomes the security bottleneck. Pattern P5 is therefore narrower than P4: it isolates top-k search, access filters, and similarity computation as the object being secured, whether or not the rest of the RAG pipeline is confidential. Recent work studies federated vector similarity search in which each provider keeps its vectors locally while jointly computing top-k results under access filters, using TEEs as a coordination point (FedVS) [20]. Related systems target privacy-preserving and efficient vector search with secure coordination (FedVSE) [21]. These approaches connect FedRAG to a growing body of private ANNS and encrypted semantic search work [29,30,31,32,33], which provides building blocks when the query, the database, or both must remain confidential. For cybersecurity consortia, federated/private vector search supports “need-to-know” sharing: only the minimum necessary context is revealed for the current query, subject to policy. Its coordination bottleneck is narrower than in P4 but no less important: the secure top-k selection, access-filter enforcement, and result fusion logic must remain correct under partial trust, since mistakes at this layer can either leak forbidden candidates or suppress relevant evidence.

4.2.6. Pattern P6: Privacy-Preserving RAG Workflows (Local Shields, DP KB Release, and End-to-End Designs)

Beyond protecting model updates, FedRAG must protect queries, retrieved context, and embeddings. Pattern P6 is best understood as a workflow-level overlay: it governs what may leave a device or silo and in what transformed form, and can therefore compose with P4 or P5 rather than compete with them. Locally private RAG variants (e.g., LPRAG [35]) aim to reduce sensitive leakage from queries or contexts via perturbation/redaction, and plug-and-play shields (e.g., VAGUE-Gate [36]) seek to enforce local privacy without modifying the base retriever/LLM. A complementary line of work focuses on releasing a usable RAG KB under DP, e.g., by synthesizing a private surrogate corpus (DP-SynRAG) [37]. Finally, end-to-end privacy-preserving RAG frameworks (ppRAG) [23] propose integrated designs that combine access control, privacy controls, and secure retrieval. Adjacent multimodal IoT evidence shows that similar workflow-level protections can also combine segmentation-based sanitization, LoRA/Ghost Clipping adaptation, and curated retrieval in privacy-aware vision-language assistants [73]. For IoT/edge cybersecurity, these workflows are relevant when privacy constraints prevent raw incident data from leaving devices or sites, yet operational value requires cross-silo knowledge sharing.

4.2.7. Pattern P7: Personalization and Hybrid Edge–Cloud Execution

Beyond federating retrieval or routing, cybersecurity deployments often require personalization because silos differ in logging formats, device fleets, policies, and threat exposure. Personalization can be implemented at multiple layers: (i) retriever/embedding personalization (e.g., depth-adaptive embedding tuning in pFedRAG [28]) and (ii) generator and in-context co-adaptation (e.g., FedMosaic [24]). In parallel, hybrid FedRAG (HyFedRAG) highlights split execution and heterogeneity [70], which is analogous to IoT settings where some evidence is local (device logs) and some is remote (threat feeds).

This pattern highlights a few critical open questions for secure deployment: when should we federate retrievers, when should we federate generators or prompts, and how do we prevent federated personalization from amplifying privacy leakage or backdoors?

4.3. Edge-Optimized RAG as a Building Block

IoT/edge deployments fundamentally change the performance envelope of RAG: indexing, retrieval latency, and context assembly must operate under strict memory/compute limits and intermittent connectivity. EdgeRAG proposes online indexing and memory-aware embedding caching to keep edge RAG feasible under tight memory constraints [39]. MobileRAG proposes an on-device pipeline with efficient vector search and content reduction to reduce memory and energy costs [40]. Related constrained multimodal QA work on robots shows that budget-aware routing can selectively trigger retrieval augmentation and question decomposition only when the expected utility justifies the extra compute, which is directly relevant to edge FedRAG policies for selective inference under tight memory and energy budgets [74]. These methods can be integrated into FedRAG to reduce per-client resource usage and enable local-first retrieval.

4.3.1. Serving and Caching for Low-Latency RAG

Caching is a practical knob for edge feasibility: it reduces the cost of repeated retrieval, amortizes embedding/ANN overheads, and can lower network usage when remote retrieval is expensive. RAGCache studies knowledge caching for RAG inference [41], while CacheBlend explores cached-knowledge fusion to accelerate RAG serving [42]. In FedRAG, caching interacts with privacy and governance: cached artifacts (retrieved chunks, embeddings, KV-cache content) may contain sensitive incident data and thus require the same access control and retention policies as the underlying KB.

4.3.2. Edge-Friendly Retrieval Pipelines and Hardware Acceleration

Beyond caching, edge deployments often require simplified retrieval pipelines and/or hardware-aware designs. Chain-of-Rank explores edge-friendly design choices for domain-specific RAG [43], and DIRC-RAG investigates hardware acceleration for edge RAG pipelines using in-memory computation [44]. From a FedRAG perspective, these works emphasize that “what to federate” is constrained by hardware: it may be feasible to federate retriever adapters or routing policies while keeping heavyweight generation centralized.

4.3.3. Freshness and Incremental KB Updates

Cybersecurity knowledge evolves rapidly (new Common Vulnerabilities and Exposures [CVEs], new indicators, new playbooks), so KB update costs and staleness become first-class concerns. EraRAG studies incremental RAG for growing corpora [45], and dynamic-knowledge benchmarks such as MIRAGE/MIRAGE-Bench highlight that grounding quality can degrade under KB drift and retrieval noise [75,76]. For FedRAG, a key open systems question is how to coordinate federated indexing and update propagation without leaking sensitive deltas or enabling poisoning.

4.3.4. Collaborative Edge Scheduling and Distributed RAG Execution

In multi-gateway deployments, collaborative scheduling and distributed execution can reduce latency and smooth resource utilization. CoEdge-RAG studies hierarchical scheduling for retrieval-augmented LLMs in collaborative edge computing [46], and DGRAG explores distributed graph-based RAG in edge–cloud systems [47]. These systems provide building blocks for FedRAG deployments where some routing, retrieval, or aggregation must happen across multiple edge nodes.

In summary, achieving feasibility in edge environments requires a multi-layered approach rather than a single optimization. Key components include: (i) local-first retrieval strategies to minimize latency and exposure; (ii) caching and incremental update mechanisms; (iii) the use of lightweight retrievers with split execution models; and (iv) strict governance of cached artifacts to prevent performance optimizations from introducing new leakage channels.

4.4. Cybersecurity RAG Applications Motivating FedRAG

Cybersecurity RAG applications motivate FedRAG because the underlying evidence is (i) highly distributed (across sites, tenants, and organizations), (ii) confidential (logs, incident tickets, internal playbooks), and (iii) fast-changing (threat intelligence and vulnerabilities). While many application papers are not “federated” per se, they expose recurring deployment requirements: provenance, least-privilege retrieval, and robustness to adversarial content.

Representative Application Families

Current cybersecurity RAG systems span several task families: (1) IoT/edge security assistants that ground responses in heterogeneous threat intelligence and device telemetry [48]; (2) cybersecurity QA and analyst support with specialized retrieval/routing [49,55]; (3) vulnerability analysis and detection grounded in verifiable sources (e.g., CVE/National Vulnerability Database [NVD]/Common Weakness Enumeration [CWE]) with explicit provenance [50,51]; (4) Digital Forensics and Incident Response (DFIR) and incident summarization that reconstruct timelines from multi-source evidence [52]; (5) Cyber Threat Intelligence (CTI) and ATT&CK-aligned reasoning for technique annotation and threat attribution [53,72]; and (6) malware analysis where explainability and evidence traceability are central [54]. Government and lab reports (e.g., CyRAG/GraphCyRAG) highlight operational constraints and evaluation considerations for cyber defense pipelines [56]. We summarize these representative applications and their implications for FedRAG in Table 8. More generally, graph-based multi-hop RAG systems such as StepChain GraphRAG show how explicit evidence-chain construction over retrieved knowledge graphs can support traceable reasoning for complex analyst-style questions, even when the target workflow is not cybersecurity-specific [77].

Table 8. Representative cybersecurity RAG applications that motivate FedRAG design requirements.

System	Task Focus	Evidence and FedRAG Motivation
ChatIoT [48]	IoT security assistant	Heterogeneous CTI + device context; motivates local-first retrieval and confidential cross-site escalation
MoRSE [49]	Cyber QA	Multiple expert retrievers; motivates routing and controlled evidence exposure
ProveRAG [50]	Vulnerability analysis	Provenance-driven retrieval from trusted sources; motivates auditability and signed ingestion
Vul-RAG [51]	Vulnerability detection	Knowledge-level retrieval for code/security knowledge; motivates continual KB updates and evaluation under drift
GenDFIR [52]	DFIR timeline	Multi-source incident evidence; motivates privacy-preserving retrieval across teams/tenants
TechniqueRAG [72]	CTI annotation	ATT&CK-aligned retrieval; motivates consistent shared schemas and access control
AURA [53]	Threat attribution	Multi-agent reasoning grounded in knowledge; motivates governance and robustness under adversarial intelligence
TraceRAG [54]	Malware analysis	Explainable evidence-backed analysis; motivates provenance and secure retrieval for sensitive samples
Wazuh RAG copilot [55]	SOC operations	Tool-integrated triage and response with attack/response simulation; workflow-oriented deployment evidence for analyst support
CyRAG/GraphCyRAG [56]	Cyber defense report	Government-lab, workflow-oriented RAG report for analyst decision support; motivates evaluation realism and secure deployment practices

These applications underscore that FedRAG design is not only about federating model updates; it is equally about KB governance (what enters the KB and with what provenance), trust boundaries (which silos can see which queries/evidence), and robustness (how the system behaves under poisoned or instruction-bearing content).

4.5. Representative Systems, Toolkits, and Benchmarks

While the architectural patterns and application contexts above identify the main design clusters, the specific systems implementing these concepts span several domains. From federated retriever adaptation (e.g., FedE4RAG [15], pFedRAG [28]) and confidential cross-silo retrieval (e.g., C-FedRAG [22], FRAG [19]) to edge-optimized caching and serving algorithms (e.g., RAGCache [41], EdgeRAG [39]), the landscape is diverse. Table 4 and Table 5 and Table 6 summarize these systems from study-class, deployment, and application perspectives, and Table A5 provides the appendix tagged inventory. Concrete cybersecurity applications motivating these system designs are summarized earlier in Table 8.

5. Evaluation Protocols and Benchmarks

Evaluating FedRAG for cybersecurity requires more than accuracy in answers. A deployment-ready evaluation should jointly measure: (i) retrieval quality and evidence coverage, (ii) grounded generation and citation faithfulness, (iii) security robustness under adversarial content and malicious participants, (iv) privacy leakage across trust boundaries, and (v) efficiency under edge constraints.

5.1. Component-Level Evaluation: Retrieval, Routing, and Generation

5.1.1. Retrieval Quality

Standard information-retrieval metrics (Recall@k, nDCG, MRR) remain relevant. BEIR provides a broad retrieval benchmark suite [78] and is commonly used to sanity-check retrievers before domain specialization. In cybersecurity deployments, retrieval evaluation should be repeated under access control and federated routing constraints, because the reachable evidence set may change per silo.

5.1.2. Routing and Federated Search

When evidence is distributed, evaluation must include source selection, result fusion, and policy filters. FeB4RAG and MKP-QA provide benchmarks for multi-provider/FedRAG settings [17,18], and can be adapted to SOC scenarios by treating sites/tenants as providers and enforcing per-provider access rules.

5.1.3. Generation Groundedness

Automated metrics for faithfulness and groundedness are increasingly used in RAG. RAGAS provides a practical evaluation toolkit for RAG pipelines [79]. However, automated scoring should be complemented with targeted failure analysis, because cybersecurity outputs often require precise caveats and operationally safe recommendations.

5.2. End-to-End and Task-Based Evaluation for Cybersecurity

For SOC/IoT security assistants, end-to-end evaluation should align with operational tasks: incident summarization, triage, alert explanation, vulnerability analysis, threat-hunting queries, and playbook retrieval. Application-oriented systems (e.g., ChatIoT, ProveRAG, GenDFIR) highlight that task success depends on multi-source evidence and provenance [48,50,52]. Where possible, evaluation should report both effectiveness (task accuracy, analyst acceptance) and efficiency (time-to-answer, latency, and resource cost).

5.3. Security Robustness Evaluation

5.3.1. Knowledge Poisoning and Manipulation

RAG-specific poisoning attacks show that a small amount of malicious content can redirect retrieval and corrupt outputs [3,67,80,81]. More recent work studies practical and black-box poisoning regimes [82,83,84]. BadRAG analyzes vulnerability patterns in RAG pipelines and can be used as a diagnostic lens for robustness gaps [85].

5.3.2. Indirect Prompt Injection (IPI)

IPI is a realistic threat when retrieved documents include instruction-like content [4,5]. Benchmarks such as SafeRAG and OpenRAG-Soc provide evaluation setups for RAG security regression testing [57,58], while Retrieval-barrier IPI expands realism by considering attacks in the wild [86].

5.3.3. Backdoors and Extraction

Retriever or generator backdoors can steer retrieval and/or leak private KB content [6,7,87]. For FedRAG, robustness evaluation should also consider malicious clients and model-update attacks (Section 6), because poisoned updates can silently degrade retriever behavior and amplify downstream RAG risks.

5.4. Privacy and Confidentiality Evaluation

5.4.1. Embedding and Context Leakage

Embedding inversion and reconstruction results imply that embeddings and retrieved context are sensitive [8,9,60]. Privacy evaluation should include adversarial reconstruction tests (when feasible) and should report what artifacts are exposed across trust boundaries (queries, embeddings, retrieved chunks, citations).

5.4.2. Privacy-Preserving RAG and Secure Retrieval

End-to-end privacy-preserving RAG workflows (ppRAG, LPRAG, VAGUE-Gate) propose privacy controls for queries and context [23,35,36], while secure retrieval systems (C-FedRAG, FRAG, FedVS, PIR-RAG) protect context and/or queries during cross-silo retrieval [19,20,21,22,34]. Evaluation should report the privacy–utility–latency trade-off induced by each mechanism.

5.5. Dynamic Knowledge, Freshness, and Continual Updates

Cybersecurity KBs change continuously. Evaluations that assume a static KB can overestimate real-world performance. Incremental RAG systems such as EraRAG study update-efficient retrieval under growing corpora [45], while MIRAGE and MIRAGE-Bench highlight performance degradation under dynamic knowledge and retrieval drift [75,76]. For FedRAG, the freshness evaluation should also assess how quickly updates propagate across silos, and whether update mechanisms introduce new poisoning or leakage channels. We use propagation delay to denote the elapsed time between admitting an update at one authorized silo and making that update query-visible to other authorized silos. A complementary metric is the staleness window: the maximum age of evidence that can still be surfaced at answer time under the current synchronization policy.

5.6. Edge Efficiency and Cost

Edge deployments require reporting compute, memory, bandwidth, and latency. EdgeRAG and MobileRAG provide baselines for local indexing and on-device constraints [39,40]. Serving/caching work (RAGCache, CacheBlend) shows that latency can be reduced via cached artifacts [41,42], while collaborative edge systems (CoEdge-RAG, DGRAG) emphasize scheduling and distributed execution costs [46,47]. In addition to averages, edge evaluations should report tail latency and worst-case memory usage, because SOC workflows often operate under strict SLAs.

5.7. Checklist for Deployment-Oriented Evaluation

Table 9 provides a checklist that researchers and practitioners can use to assess whether a FedRAG evaluation is close to deployment realism. The checklist combines two kinds of guidance. Some rows (e.g., retrieval quality, groundedness, latency, and baseline robustness) recur directly in the surveyed systems and benchmarks. Others (e.g., routing leakage, propagation delay across silos, or policy-aware evidence reachability) are synthesis-driven deployment recommendations that became necessary when comparing studies across trust boundaries and hardware tiers. We therefore distinguish whether an item is already a common reporting practice or whether it remains underreported but necessary for practical deployment.

Table 9. Evaluation checklist for cybersecurity IoT/edge FedRAG.

Aspect	What to Report/Check	Status in the Surveyed Literature
Retrieval quality	Recall@k/nDCG/MRR; per-silo reachable evidence; effect of access control and routing	Commonly reported, but often without policy-constrained reachability
Grounded generation	Faithfulness/groundedness metrics (e.g., RAGAS); citation correctness; abstention and uncertainty handling	Commonly reported in modern RAG evaluation
Federated setting	Cross-silo vs. cross-device; client participation; heterogeneity (per-silo performance distribution)	Partly reported; often normalized only at a high level
Security robustness	Poisoning (targeted/black-box), IPI, backdoors; ASR + cost; defense overhead; regression testing suites	Increasingly reported, but coverage is uneven across threat classes
Privacy leakage	Exposure of queries/context/embeddings; embedding inversion tests; DP parameters if applicable	Partly reported; often limited to one leakage channel
Confidential retrieval	TEE/HE/PIR/PrivANNS assumptions; latency and bandwidth overhead; failure modes under partial trust	Frequently underreported beyond headline latency
Freshness/dynamics	KB update frequency; incremental indexing cost; evaluation under drift; propagation delay; staleness window; rollback/invalidation policy	Underreported but deployment-critical
Edge efficiency	Memory/compute/energy, bandwidth, tail latency; caching effectiveness; incremental energy cost of secure retrieval, local filtering, and federated updates	Partly reported; tail metrics, battery impact, and security-induced energy overhead are often omitted
Reproducibility	Code/configs; dataset/KB availability; clear baselines and ablations	Common expectation, unevenly achieved in practice

5.7.1. Quantitative Reference Points

The checklist above specifies what should be measured; however, deployment decisions often hinge on how large the trade-offs are (e.g., “is privacy worth the latency/bandwidth hit?” or “do we need caching to meet SOC latency SLOs?”). To make these trade-offs more concrete, Table 10 summarizes representative numerical metrics reported in recent FedRAG-related systems. We define these metrics as follows to ensure clarity: Retrieval Quality (e.g., Recall, nDCG) and Task Quality (e.g., F1, Accuracy) measure the relevance of evidence and the correctness of the final output, respectively. Latency represents the end-to-end wall-clock time per query, while Time-To-First-Token (TTFT) isolates the initial delay before generation starts. Throughput reflects the system’s processing capacity (e.g., queries per second). Communication Cost quantifies the bandwidth usage for cross-silo retrieval or updates. Memory denotes the runtime footprint of indices and models on edge devices. Finally, Robustness measures resilience to attacks, typically reported as Attack Success Rate (ASR). Because these results come from different datasets, workloads, hardware tiers, and threat models, they are best interpreted as order-of-magnitude reference points rather than direct apples-to-apples comparisons. We therefore group them first by dominant workflow task/setting (local/edge serving, federated routing/adaptation, confidential retrieval, and attack evaluation), and then expose the usual hardware tier and dominant mechanism explicitly in separate columns. In this sense, the table is organized jointly along task/setting, hardware tier, and dominant privacy/security or systems mechanism, rather than by chronology alone. Table 10 should not be read as a single ranking table. The grouping is intended to reduce category error, not to normalize away all experimental differences: even within a group, the entries may rely on different hardware, corpora, access policies, and security assumptions. Accordingly, the table should be read as a set of benchmarking envelopes for design discussion, not as evidence that one system universally outperforms another.

Table 10. Representative numerical reference points grouped by dominant workflow task/setting (N/A = not explicitly reported). Typical hardware tier(s) and dominant mechanism are included to make hardware and privacy/security assumptions explicit. Values remain non-comparable across different datasets, hardware, and workloads.

Work	Tier(s)	Dominant Mechanism	Retrieval Quality	Task Quality	Latency	TTFT	Throughput	Communication Cost	Memory	Robustness
Edge/local execution and serving
EdgeRAG [39]	T2–T3	Local-first indexing/cache locality	Recall and generation quality within 5% of Flat baseline	Similar generation quality to Flat index	Retrieval latency improved by 1.22× on average and 3.69× on memory-limited datasets	1.8× faster on average; 3.82× on larger datasets	N/A	N/A	About +7% cache overhead	N/A
MobileRAG [40]	T1	On-device locality/context reduction	Recall@10 ≈ 0.93 (SIFT)	Maintains competitive QA accuracy while reducing input context	Retrieval/search latency improved by 1.72–8.89×	1.18–1.41× lower	Prompt-eval speed 35–90 tokens/s (model-dependent)	N/A	10.7–54.5% lower memory usage; 24.4–40.2% lower power	N/A
CoEdge-RAG [46]	T2–T3	Collaborative scheduling/routed execution	N/A	QA quality gains of 4.23–91.39% over baselines	E2E latency under skew can rise by 47.21–93.68% with naive routing; oracle routing cuts 25.33–33.55%	N/A	N/A	N/A	N/A	N/A
RAGCache [41]	T2–T3	Serving cache/speculative overlap	N/A	Quality preserved while reducing serving overhead	Non-overlapping retrieval time reduced by 1.5–4.3× (with speculative pipelining)	Up to 4× lower	Up to 2.1× higher	N/A	N/A	N/A
CacheBlend [42]	T2–T3	Cache reuse/HKVD fusion	N/A	Quality drop within 0.02 (F1/Rouge-L) vs. full recompute	E2E delay up to 2–5× lower (vs. MapReduce-style RAG baselines)	2.2–3.3× lower	2.8–5× higher	N/A	Negligible extra memory overhead (HKVD)	N/A
SubGCache [88]	T2–T3	Graph cache reuse	N/A	Accuracy gains up to +7 points in some settings, typically with stable quality	Response time reduced by up to 5.76×	Up to 6.68× lower	N/A	N/A	N/A	N/A
Proximity [89]	T2–T3	Similar-query/result caching	k-recall remains high (e.g., 99.4% at $\tau =1.0$)	Maintains benchmark accuracy while reusing similar-query results	Retrieval latency reduced by up to 59% (MMLU) and 75% (MedRAG); cache lookup around 4.8 $\mu$s	N/A	N/A	Vector-database calls reduced by 77.2% (skewed MedRAG workload)	N/A	N/A
Federated routing and adaptation
RAGRoute [16]	T2–T3	Routed retrieval/exposure minimization	Recall reaches 95.3–99.0% (MIRAGE) and about 90% (MMLU)	End-to-end QA accuracy remains close to all-source RAG (e.g., 72.24% vs. 72.22%)	Routing inference overhead is low (0.3 ms GPU/0.8 ms CPU)	N/A	N/A	Cross-silo queries reduced by up to 77.5%; communication volume reduced by up to 76.2%	N/A	N/A
FedMosaic [24]	T2–T3	PEFT co-adaptation	N/A	Average accuracy improved by 10.9% over strong baselines	N/A	N/A	N/A	Communication cost reduced by 91.4%	Adapter storage footprint reduced by 78.8–86.3%	N/A
Confidential or private retrieval
PIR-RAG [34]	T3; T2+ offload	PIR	NDCG@10=0.799, Precision@10=0.710 (Graph-PIR baseline: 0.901/0.850)	N/A	Retrieval query time around 13–24 s (16.84 s at 5k-doc setting)	N/A	N/A	Uplink 2.4–24 KB; downlink 47.6–474 MB	N/A	N/A
Attack studies
HijackRAG [67]	N/A	Poisoning; retrieval manipulation	Malicious retrieval F1 often near 1.00	N/A	N/A	N/A	N/A	N/A	N/A	ASR up to 97% (black-box), with high transferability across retrievers
BadRAG [85]	N/A	Backdoor; poisoned retrieval	Triggered adversarial retrieval success up to 98.2% with only 10 poisoned passages	Under attack, downstream QA quality can drop sharply (e.g., GPT-4 accuracy 92.6%→19.1%)	N/A	N/A	N/A	N/A	N/A	Retrieval backdoor success up to 98.2%; GPT-4 reject ratio 0.01%→74.6%; negative-response ratio up to 72%
Rag-and-Roll [5]	N/A	Indirect prompt injection	N/A	N/A	N/A	N/A	N/A	N/A	N/A	Indirect prompt attacks typically around 40% success, rising to about 60% under a relaxed criterion

5.7.2. Implications for Evaluation Design

The literature numbers above suggest several practical takeaways for cybersecurity IoT/edge FedRAG:

• TTFT and throughput matter as much as retrieval time. Multiple caching/KV-reuse lines of work report 2.2–6.68× TTFT improvements [41,42,88], so evaluation should report TTFT and throughput (ideally with tail metrics such as P95), not only Recall@k or average retrieval latency.
• Edge feasibility is multi-objective. On-device systems show meaningful speedups, with MobileRAG reporting double-digit memory/power reductions and EdgeRAG showing latency gains while keeping extra memory overhead low (about +7%) [39,40]; evaluations should therefore include memory footprint, power/energy (or at least a fixed power cap), and accuracy/recall side-by-side.
• The energy cost of security should be separated from base serving cost. In cybersecurity IoT/edge deployments, on-device retrieval already consumes memory and power, and additional security/privacy controls can add further overhead through secure retrieval, repeated local filtering, and federated updates. The current literature provides only limited direct reporting of this incremental cost, so future evaluations should distinguish base retrieval/generation energy from the extra energy induced by security mechanisms, especially on T1–T2 hardware.
• Bandwidth dominates under strong privacy. PIR-style designs can require tens of seconds and tens-to-hundreds of MB downlink per query [34], turning query reduction into a first-class objective. Techniques such as federated routing (e.g., ≈77.5% fewer cross-silo queries [16]) and retrieval caching (e.g., 77.2% fewer database calls [89]) become essential to meet edge bandwidth budgets.
• Workflow fit should be evaluated explicitly. For reactive workflows such as alert triage, analyst-in-the-loop troubleshooting, and time-critical containment support, the current evidence favors local-first or routed retrieval paths: MobileRAG and EdgeRAG show that T1–T3 local retrieval can reduce latency, memory, and power pressure [39,40], while RAGRoute adds only sub-millisecond routing overhead and substantially lowers cross-silo query and communication volume [16]. By contrast, PIR-RAG reports retrieval-phase times around 16.84 s at the 5k-document setting and 47.6–474 MB downlink per query [34], which is difficult to reconcile with reactive SOC loops and is better matched to delayed, high-confidentiality workflows such as cross-organization intelligence enrichment, retrospective investigation, or selective escalation. TEE-oriented systems such as C-FedRAG, FedVS, and FedVSE are more promising than PIR/HE for selective high-value escalation on T3 infrastructure because they concentrate secure coordination in enclaves rather than repeatedly fetching large plaintext clusters, but the current literature still reports limited analyst-facing, per-query SLA evidence beyond prototype evaluations [20,21,22]. HE-oriented FRAG and PIR-style retrieval remain the hardest to justify for default reactive loops because their reported evaluations rely on server-class assumptions and emphasize confidentiality/throughput trade-offs more than analyst-facing response deadlines [19,34].
• Freshness should be reported as a timed systems property. In cybersecurity settings, it is not enough to say that a KB is “dynamic”; evaluations should measure propagation delay, staleness window, and any rollback or cache-invalidation lag after policy or threat-intelligence updates.
• Robustness should be quantified with attacker cost and defense overhead. Recent attacks can exceed 90% ASR [67,85]; beyond ASR, evaluations should also report behavioral-shift indicators (e.g., reject ratio and sentiment shift), poison budget (e.g., number of poisoned passages), and any defense-induced latency/accuracy regressions.

6. Challenges and Mitigations

FedRAG inherits threats from both RAG and federated/distributed learning, and the combination creates new failure modes. This section synthesizes the main threat surfaces and maps them to edge-feasible mitigations. Where end-to-end FedRAG evidence is sparse, we explicitly treat the combined threat surface as a synthesis across adjacent RAG and FL results under compatible deployment assumptions.

6.1. RAG-Layer Threats

6.1.1. Knowledge Poisoning and Retrieval Manipulation

RAG pipelines can be attacked by injecting malicious or misleading documents into the KB, causing retrieval to surface attacker-chosen evidence and steering generation. Targeted poisoning attacks and retrieval hijacking have been demonstrated in multiple settings [3,67,80,81]. Practical and black-box poisoning regimes further reduce the attacker’s requirements [82,83,84]. For cybersecurity deployments, poisoning is particularly dangerous because (i) threat intelligence feeds can be adversarial or noisy, and (ii) incorrect guidance can lead to operational harm. In practice, the first line of defense should be operational rather than purely statistical: signed ingestion, provenance tracking, source allowlists, staged publication into trusted KB tiers, and rollbackable caches. Anomaly detection on incoming documents can be useful as a secondary screen, but it should not be treated as the primary control because legitimate threat intelligence is often novel and outlying by design.

6.1.2. Indirect Prompt Injection (IPI) via Retrieved Content

IPI occurs when retrieved documents contain instructions that the model follows, overriding developer intent [4,5]. Realistic benchmarks show that IPI can occur in web-derived corpora and social content [58,86]. Operational guidance (e.g., OWASP) treats prompt injection as a top risk for LLM applications [90]. For SOC assistants, IPI is plausible whenever retrieved tickets, wiki pages, or external advisories contain instruction-like sequences or adversarially crafted payloads.

6.1.3. Backdoors and Supply-Chain Compromise

Backdoored retrievers can redirect retrieval toward malicious evidence [6], and backdoors can be used to exfiltrate private KB information [7]. TrojanRAG highlights that retrieval augmentation itself can become a “driver” that triggers backdoor behaviors [87]. In FedRAG, the supply-chain risk extends to federated updates: compromised clients can inject backdoor signals into retriever or generator adaptation.

6.1.4. KB Extraction and Confidentiality Attacks

Even when access controls exist, attackers may attempt to extract KB contents through repeated queries and feedback. Pirates of the RAG demonstrates adaptive attacks to leak KB information from RAG applications [68], and RAG-Thief studies feedback-guided extraction of KB content [69]. These attacks are particularly relevant in multi-tenant SOC tools where query interfaces are exposed to many users. They also interact with edge caching: cached context or retrieved chunks can serve as unintended extraction channels if not properly governed.

6.1.5. Embedding Leakage and Privacy Pitfalls

Embedding inversion attacks show that embeddings can leak underlying text [8,9], with mitigations that reduce recoverability [60]. The Good and The Bad provides a broader privacy analysis of RAG systems and highlights leakage vectors beyond direct document exposure [38]. In cybersecurity, embeddings derived from incident reports, logs, and alerts can contain sensitive identifiers, so “embedding sharing” must be treated as data sharing.

6.2. Federated and Distributed Threats

6.2.1. Malicious Clients and Federated Poisoning/Backdoors

FL is vulnerable to malicious participants that attempt to poison global models or implant backdoors [63]. In FedRAG, retriever poisoning is particularly harmful because it indirectly alters which external text reaches the generator. Robust aggregation, update auditing, and controlled participation can help, but they must be evaluated under non-IID and partial participation, which are common in IoT deployments [14].

6.2.2. Update Leakage and Gradient Inversion

Even without raw data sharing, updates can leak information about local corpora. Gradient leakage attacks and their variants (e.g., iDLG) demonstrate that private information can be reconstructed from gradients [64]. Secure aggregation reduces per-client visibility [61], while DP limits memorization but requires careful privacy accounting [62]. Because retrievers are trained on sensitive text (e.g., tickets and incident narratives), leakage evaluation is important even when the generator remains frozen.

6.2.3. Routing, Access-Pattern, and Cross-Silo Metadata Leakage

Federated search introduces leakage channels through routing decisions, access patterns, and returned metadata (e.g., which provider responded, number of hits, latency profiles). Routing systems such as RAGRoute reduce cross-silo queries [16], but evaluation should consider whether routing decisions themselves leak sensitive information about local corpora or incident states.

6.3. Mitigation Strategies and Deployment Guidance

Mitigations must be practical under edge constraints and across organizational trust boundaries. We organize mitigations into governance controls, model-level defenses, and secure retrieval primitives. Table 11 summarizes the major threat categories and representative deployment-oriented mitigation strategies.

Table 11. Threats and representative mitigations for cybersecurity IoT/edge FedRAG.

Threat	Representative Works	Mitigation Ideas (Deployment-Oriented)
KB poisoning/retrieval hijack	[3,67,82,83,84]	Signed ingestion + provenance; allowlists and staged publication for sources; red-team poisoned corpora; rollbackable trusted KB tiers; anomaly detection only as a secondary screen
Indirect prompt injection (IPI)	[4,5,58,86,90]	Context sanitization and instruction filtering; constrained tool use; retrieval-time policy filters; selective disclosure and “safe context” gating [71]
Backdoors/supply chain	[6,7,87]	Model provenance and reproducible builds; scanning for trigger tokens; retriever fine-tuning on trusted corpora; robust FL training and update auditing
KB extraction (exfiltration)	[68,69]	Query rate limits; response watermarking and monitoring; least-privilege retrieval; canary documents; restrict feedback channels; govern caches and logs
Embedding/context leakage	[8,9,38,60]	Treat embeddings as sensitive; minimize cross-boundary exposure; apply privacy shields (LPRAG/VAGUE-Gate) [35,36]; consider DP synthetic KB release [37]
Update leakage	[61,62,64]	Secure aggregation; DP for retriever adapters; minimize update frequency; evaluate privacy leakage empirically; scalable secure aggregation protocols [65]
Coordination-layer compromise or bottleneck	[16,20,22]	Separate routing, aggregation, and policy roles; audit routing decisions; define fail-closed behavior for coordinator outages; measure policy-check and propagation delays
Confidential retrieval across silos	[19,20,21,22,34]	TEEs for context confidentiality; HE/PIR/PrivANNS for query/DB privacy; strict access control and audit logs; report overhead and failure modes

A Practical Ordering of Defenses

For many deployments, the most cost-effective path is: (1) strong KB governance (source vetting + provenance), (2) access control and routing to minimize exposure, (3) systematic security regression testing (SafeRAG/OpenRAG-Soc) [57,58], and (4) confidential retrieval primitives (TEE/HE/PIR) when trust boundaries require them. Privacy-preserving workflows (ppRAG, LPRAG, VAGUE-Gate) become critical when sensitive incident evidence must cross organizational boundaries [23,35,36].

6.4. Open Gaps Specific to Cybersecurity IoT/Edge FedRAG

To make the problem-solution mapping explicit, Table 12 summarizes the main unresolved issues, what can already be done with today’s design patterns, and the residual gaps that remain important for cybersecurity deployments.

Table 12. Problem-solution-gap map for cybersecurity IoT/edge FedRAG.

Operational Issue	Why It Matters in Cybersecurity IoT/Edge	What Can Already Be Done	Residual Gap
Unified threat composition	Real deployments may combine poisoned KBs, malicious clients, prompt injection, and metadata leakage in the same workflow	Separate controls exist for ingestion, routing, FL robustness, and confidential retrieval	Few evaluations combine these attacker classes within one end-to-end FedRAG protocol
Cache safety and update governance	Caches and incremental updates are essential for latency, but stale or poisoned artifacts can spread across silos	Govern cache retention, signed ingestion, staged publication, and policy-aware invalidation	Safe cache invalidation and delta propagation remain under-evaluated, especially under partial trust
Propagation delay and desynchronization	In cyber defense, delayed dissemination of new indicators or mitigations can directly affect response quality	Measure update frequency, incremental indexing cost, and routed retrieval under drift	Propagation delay and staleness window are rarely reported as first-class metrics across silos
Coordination-layer reliability	Routers, aggregators, and orchestrators can improve efficiency but also create bottlenecks and leakage channels	Separate coordination roles, audit routing decisions, and define fail-closed policies	Few systems quantify how coordination failures affect availability, policy correctness, or cross-silo leakage
Benchmark realism and auditability	SOC/IoT deployments require access control, provenance, and human-auditable outputs, not only answer accuracy	Adapt existing RAG/FedRAG benchmarks and integrate provenance-driven workflows	Cybersecurity-specific multi-silo benchmarks with realistic policy tiers and update streams remain limited

7. Related Work

This survey intersects multiple sections of the literature: (i) retrieval-augmented generation (RAG), (ii) FL and federated systems, (iii) privacy-preserving and confidential retrieval, (iv) RAG security (poisoning, injection, backdoors, extraction), and (v) cybersecurity-specific LLM/RAG applications. Because our goal is deployment guidance under real trust boundaries, we position related work after the main taxonomy and threat synthesis so that comparisons can be made along concrete deployment axes (e.g., whether a service is federated, which boundaries are crossed, and which assets are protected).

7.1. Comparison with Existing Surveys and Frameworks

Table 13 highlights representative surveys/frameworks most adjacent to our scope and clarifies what is unique about this work.

Table 13. Representative related surveys/frameworks and how this survey differs.

Work	Primary Focus	Key Difference vs. This Survey
RAG survey/systematization [2]	General RAG architectures, retrievers/generators, and evaluation practices	Does not center trust boundaries, federated deployment, or cybersecurity threat models; we map security/privacy risks to concrete deployment patterns
FedRAG mapping study [25]	Broad mapping of FedRAG literature	Less emphasis on IoT/edge constraints and RAG security threats; we provide deployment-oriented tags, mitigation checklists, and blueprints for security deployments
FL for cloud/edge security review [91]	FL for security analytics in cloud/edge environments	Focuses on FL for security tasks; does not model retrieval-based evidence injection, KB governance, or prompt-injection/extraction threats introduced by RAG
Federated LLM fine-tuning survey [92]	FL and PEFT methods for adapting LLMs	Focuses on federating generator adaptation; we emphasize the retrieval/KB layer (routing, private retrieval, KB safety) as the main bottleneck in cyber FedRAG
Securing RAG framework [93]	Systematizes risks/mitigations for RAG applications	Does not address federation-specific leakage and malicious-silo threats; we connect RAG security to federated updates, routing leakage, and edge constraints

7.2. General RAG Surveys and Evaluation Toolkits

General RAG surveys summarize retriever/generator designs and the broader RAG evaluation landscape [2]. Complementary toolkits and benchmarks (e.g., RAGAS, MIRAGE) help enable groundedness evaluation in practice and highlight sensitivity to retrieval noise and drift [75,76,79]. Our survey differs in that we treat trust boundaries, confidentiality, and adversarial risk as first-class constraints and focus on what changes when retrieval crosses organizational boundaries and when evidence is attacker-influenced.

7.3. FedRAG and Federated Adaptation of Components

The FedRAG mapping study provides a broad view of the emerging FedRAG space [25]. In addition, a growing body of work studies federated adaptation of LLMs and PEFT modules, which is relevant when the generator (or prompt policies) is federated rather than kept fixed [92]. We extend these perspectives by making federation component-specific: retriever federation (Pattern P2), routing/search federation (Pattern P3), confidential cross-boundary execution and secure retrieval protocols (Patterns P4–P5), and privacy-preserving workflow federation (Pattern P6). This enables a more actionable comparison for practitioners: two “FedRAG” systems may share a name but have fundamentally different threat surfaces depending on whether they federate updates, retrieval, or confidential execution.

7.4. FL for Cybersecurity and Edge Deployments

FL has been widely explored for security analytics such as intrusion detection, often motivated by privacy and data-locality requirements [12,91]. These works provide important background on non-IID behavior, communication constraints, and classic FL threats [14]. However, they typically assume that the learned model consumes local features and do not account for retrieval-based evidence injection or KB governance. Once RAG is introduced, integrity and interface threats (poisoning, injection, extraction) become first-order, and the interaction between FL threats (malicious clients, update leakage) and RAG threats must be evaluated jointly (Section 6).

7.5. Privacy-Preserving Retrieval and Confidential RAG

A substantial portion of the literature studies private similarity search and private ANNS as primitives for protecting queries and/or vector databases [29,30,31,32]. Encrypted semantic search engines such as Compass further push accuracy and practicality of encrypted retrieval [33]. RAG-specific systems integrate these primitives into end-to-end pipelines, including confidential cross-silo RAG (C-FedRAG, FRAG) and query-private retrieval for RAG (PIR-RAG) [19,22,34]. We unify this work under a deployment view: in many cross-silo cyber settings, secure retrieval is the main bottleneck because embeddings, access patterns, and retrieved context are themselves sensitive assets.

7.6. RAG Security: Attacks, Defenses, and Benchmarking

RAG introduces new adversarial levers—poisoning and retrieval manipulation [3,67,84], indirect prompt injection [4,5], backdoors and supply-chain compromise [6,87], and KB extraction [68,69]. Recent benchmarks and frameworks aim to systematize these risks and enable regression testing [57,58,93]. We contribute by connecting these threats and defenses to federated deployment constraints (routing leakage, malicious silos, update leakage) and to edge engineering realities (caching, intermittency, limited compute), which are often under-specified in security-only RAG work.

7.7. Cybersecurity RAG Applications and Operational Constraints

Finally, domain-specific RAG systems for cybersecurity highlight operational constraints that motivate FedRAG in practice: on-prem deployment, strict auditability, least-privilege retrieval, and continual KB updates [48,50,52,55]. Even when these systems are not federated, they motivate the system requirements that FedRAG must satisfy in real SOC workflows. Accordingly, we treat application papers as evidence for deployment needs and integrate them into our taxonomy and evaluation checklist rather than presenting them as a separate “application-only” thread.

8. Discussion: Practical Deployment Blueprints

This section translates the taxonomy and threat analysis into three deployment blueprints. Each blueprint is a composable design that practitioners can adapt to their trust boundary and edge constraints.

8.1. Blueprint A: Local-First Retrieval with Controlled Escalation

When to use: a single organization with multiple sites/edge gateways; strict data locality; intermittent connectivity.

Design: deploy a local KB/index at each gateway (Pattern P1) and answer most queries locally. Escalate to a central/on-prem generator only when local evidence is insufficient.

Security controls: signed ingestion and provenance (to mitigate poisoning), local access control, and IPI sanitization at the context assembly stage.

8.2. Blueprint B: Federated Retriever Personalization with Routed Retrieval

When to use: multiple silos with similar tasks but different vocabularies/log formats; need personalization without sharing raw data.

Design: federate retriever adapters/embeddings (Pattern P2) and optionally add federated routing policies (Pattern P3) so queries are sent only to relevant silos. Personalization systems such as pFedRAG illustrate tiered embedding tuning [28].

Security controls: secure aggregation for update confidentiality [61]; DP on retriever adapters when leakage risk is high [62]; robust aggregation and update auditing to resist poisoning/backdoors [63].

Engineering note: PEFT-based FL methods (e.g., Low-Rank Adaptation (LoRA)-based personalization) can reduce communication, but must be evaluated for leakage and backdoor amplification [94,95,96,97].

8.3. Blueprint C: Confidential Cross-Silo Retrieval with Policy Enforcement

When to use: multi-organization collaboration; mutually distrusted knowledge providers; high-value KBs (threat intel, incident reports).

Design: use secure retrieval primitives (TEEs, HE, PIR/PrivANNS) for cross-silo search (Patterns P4–P5), while keeping sensitive context confidential. Systems such as C-FedRAG, FRAG, FedVS/FedVSE, and PIR-RAG exemplify different trust/overhead points [19,20,21,22,34].

Operational fit: in current evidence, confidential retrieval is best treated as a selective escalation path rather than the default path for every analyst query. It is most defensible for delayed, high-value workflows such as cross-organization threat-intelligence enrichment, retrospective investigation, or policy/compliance lookups, where confidentiality dominates and multi-second overhead may be acceptable. TEE-based coordination appears more plausible than HE/PIR for these selective escalations because it can keep secure computation concentrated within an enclave-backed orchestrator, whereas PIR-style cluster fetching and HE-based encrypted similarity search still carry heavier latency/communication assumptions in the reported evaluations [19,22,34]. Even so, it is harder to justify any of these mechanisms for reactive triage or containment loops unless the deployment measures local end-to-end overhead and shows that the chosen mechanism satisfies the required analyst-facing SLA, especially below T3 or without offload [16,20,21,39,40].

Security controls: strict access control and audit logs; query budget/rate limits to mitigate extraction; selective disclosure and sanitization to mitigate IPI [71].

8.4. Blueprint Comparison and Selection Criteria

Table 14 summarizes the main trade-offs. Based on this, the following design guidance is provided. If most queries can be answered from local telemetry and playbooks, start with Blueprint A and add routed escalation. If performance depends on learning better retrievers across heterogeneous sites, evolve toward Blueprint B. If the deployment crosses organizational trust boundaries or the KB is a high-value asset, Blueprint C becomes necessary, but it should usually be reserved for selective escalation or slower intelligence-oriented workflows unless local measurements show that its overhead fits the required analyst-facing SLA (Table 9).

Table 14. Deployment checklist and blueprint comparison for cybersecurity IoT/edge FedRAG.

Stage/Blueprint	What Must Be Specified	Practical Checks (What to Do/Report)
Architecture Selection and Blueprints
Blueprint A (local-first)	Best for single org/strong locality. Risks: local poisoning, IPI.	Signed ingestion, context sanitization, and freshness policies.
Blueprint B (fed. personalization)	Best for heterogeneous silos. Risks: update leakage, routing leakage.	Secure aggregation, DP, robust routing with access control.
Blueprint C (confidential retrieval)	Best for cross-org. Risks: high overhead, complex trust boundaries.	TEEs/HE/PIR setups, strict policy enforcement, selective disclosure.
General Implementation Checklist
Scope and threat model	Use case(s), trust boundary (single org vs. multi-org), target hardware tier(s), protected assets, attacker model	State what crosses boundaries (queries, embeddings, context, updates); specify whether the design targets T0/T1/T2/T3 resources; include combined attacker cases (poisoned KB + malicious client + IPI)
KB governance	Data sources, ingestion pipeline, provenance, access control tiers, update process	Signed ingestion + allowlists; canary documents; red-team poisoned corpora; define retention policy for cached context and logs
Privacy and confidentiality	Leakage surfaces and protection mechanisms (SA/DP/LDP/TEE/HE/PIR/ PrivANNS)	Treat embeddings/context as sensitive; report privacy budgets (if DP/LDP); measure overhead of confidential retrieval primitives
Security hardening	Prompt-injection controls, poisoning/backdoor defenses, extraction controls	Context sanitization and policy filters; robust aggregation and update auditing; query budgets/rate limits; regression testing with SafeRAG/OpenRAG-Soc-style suites
Evaluation and monitoring	Metrics across retrieval/generation/ security/privacy/edge efficiency	Follow Table 9; report per-silo performance; include dynamic-knowledge tests, propagation delay, and staleness window; monitor drift and security failures post-deployment
Edge engineering	Memory/compute/latency/bandwidth constraints; caching/freshness strategy	Report tail latency and worst-case memory; govern caches; evaluate incremental update cost, propagation lag, and cache invalidation under policy
Operationalization	Auditability, incident response integration, reproducibility, compliance constraints	Log retrieval provenance, routing decisions, and policy filters; define who can query what; provide configs and baselines for reproducibility

8.5. Deployment Checklist and Common Pitfalls

To translate the literature into an actionable implementation plan, Table 14 summarizes a deployment checklist aligned with the blueprints and the evaluation/threat tables (Table 9 and Table 11).

Common Pitfalls

Across the surveyed literature, we repeatedly observe pitfalls that can derail real deployments: (i) treating embeddings or cached context as “non-sensitive” artifacts; (ii) assuming RAG automatically improves safety or robustness [98]; (iii) evaluating only answer accuracy while ignoring routing leakage, injection, extraction, or update leakage; and (iv) ignoring dynamic-knowledge drift and cache safety in edge settings. The blueprints and checklists in this survey are designed to make these pitfalls explicit.

9. Future Directions

FedRAG for cybersecurity IoT/edge is still emerging. We highlight directions that are both research-relevant and deployment-relevant.

9.1. Benchmarking Under Realistic Trust Boundaries

Current benchmarks cover federated search and IPI to some extent [17,18,58], but cybersecurity needs: multi-silo datasets with access control, red-teamed KBs, and realistic update streams (new CVEs, new alerts). Dynamic-knowledge evaluation (e.g., MIRAGE) should be combined with multi-silo routing and policy constraints [75]. In particular, future benchmarks should report propagation delay and staleness window, rather than treating cross-silo freshness as a qualitative property.

9.2. Governance-First FedRAG: Provenance, Policy, and Audit

Security deployments require traceability and policy enforcement. Future systems should integrate provenance and signed ingestion (as in ProveRAG-style workflows [50]) with confidential retrieval and federated update pipelines. Audit trails should cover not only cited documents but also routing decisions and retrieval filters.

9.3. Cache Safety, Freshness, and Secure Update Propagation

Edge feasibility depends on caching and incremental updates [41,42,45], yet cache safety is under-explored. Open questions include: safe cache invalidation under access control, privacy-preserving propagation of KB deltas across silos, poisoning detection for update streams, and how to minimize the time-to-visibility of authorized updates without increasing leakage.

9.4. Robust and Private Personalization

Personalization is essential in heterogeneous IoT/edge security environments. A key direction is to combine PEFT-based federated personalization (LoRA adapters) with strong privacy and robustness guarantees [94,95,96,97]. This includes understanding how personalization interacts with backdoors and with embedding leakage.

9.5. Energy Cost of Security

For resource-constrained IoT and edge deployments, energy should be treated as a primary systems constraint rather than as a secondary optimization metric. Future work should therefore report not only the base energy cost of retrieval and generation, but also the incremental energy cost induced by security/privacy controls such as secure retrieval, local privacy filtering, and federated update participation. This distinction is especially important on T1–T2 hardware, where a mechanism may satisfy privacy requirements yet still be impractical if its security overhead materially reduces battery life, duty cycle, or thermal headroom.

9.6. Human-in-the-Loop Evaluation and SOC Integration

Ultimately, cybersecurity assistants must help analysts make correct decisions faster. Future work should evaluate FedRAG in realistic SOC workflows (case triage, alert clustering, ticket writing) with human feedback, while maintaining strict confidentiality and auditability.

10. Conclusions

FedRAG is a promising path to bring retrieval-grounded LLM assistance into cybersecurity settings where evidence is distributed, sensitive, and fast-changing. However, FedRAG is not “RAG + FL”: federation changes the threat model (malicious silos, routing leakage, update leakage), and RAG changes the failure modes of learned components (poisoning, injection, extraction).

This survey organized the space with a deployment-oriented taxonomy, an analytical comparison table (Table 4), grouped main-text views by deployment and application context (Table 5 and Table 6), and an appendix tagged work inventory (Table A5), distilled architectural patterns and blueprints for IoT/edge cybersecurity, and unified RAG and federated threats into a mitigation checklist (Table 11). We also highlighted evaluation practices and gaps, including the need for dynamic-knowledge benchmarks, realistic access control, and end-to-end SOC task evaluations (Table 9).

Because end-to-end FedRAG deployments are still limited, some conclusions about the combined attack surface should be read as synthesis across adjacent RAG and FL evidence rather than as universal empirical proof on a single stack. Even with that boundary in view, we expect the most impactful near-term progress to come from governance-first FedRAG: provenance and policy enforcement at ingestion and retrieval, coupled with security regression testing and privacy-preserving retrieval primitives when trust boundaries require them.