Blockchain as a Cybersecurity Enabler in Federated Networks for Resilience and Interoperability

Abstract

In increasingly interconnected tactical environments, cybersecurity, trust, and interoperability must evolve in tandem. Federated Coalition Networks (FCNs) enable multinational cooperation while preserving national sovereignty; however, the secure management of identities, policies, and configurations across coalition domains remains a critical challenge, particularly under adversarial and resource-constrained conditions. This paper proposes a blockchain-enabled management framework aligned with the defense-in-depth paradigm, focusing on management-plane functions such as policy enforcement, public key infrastructure (PKI) management, and auditable governance, rather than time-critical tactical communications. The solution relies on a permissioned blockchain architecture with Byzantine Fault Tolerant consensus, avoiding energy-intensive Proof-of-Work mechanisms and supporting operation under Disconnected, Intermittent, and Low-bandwidth (DIL) conditions. A coalition-level trust-and-governance model is introduced to prevent unilateral control while preserving national autonomy. A realistic use case and a proof-of-concept implementation demonstrate the feasibility of the approach, showing bounded latency, limited energy overhead, and sufficient throughput for FCN management. These results indicate that appropriately tailored blockchain solutions can effectively enhance resilience, trust, and compliance in federated defense networks.

1. Introduction

The digital era and advancing technology are revolutionizing both civilian and military environments [1]. This technological evolution is transforming how sectors operate, particularly in defense, by enabling new levels of efficiency, communication, and control [2,3]. Security remains a top priority in tactical scenarios and military operations [4]. Today, it is understood through two key dimensions: protecting human lives and safeguarding critical systems. As systems become more interconnected and digitalized, the volume of sensitive data increases, heightening exposure to cyber threats, intrusions, and data breaches that can compromise mission and personal safety.

To address these emerging threats, new technologies are being integrated into the military domain [5]. These technologies are vital for responding to modern tactical demands, especially in dynamic and high-risk environments such as battlefields. Their role includes improving security measures, protecting critical infrastructure, and ensuring operational continuity. Among them, software-defined networks stand out for their flexibility and scalability, enabling adaptive communication infrastructures [6,7]. Blockchain also emerges as a key asset: its decentralized, tamper-resistant nature makes it highly suitable for securing sensitive data, ensuring integrity, and supporting transparent operations. Its potential to transform military communications and data management is widely recognized [8,9].

With the growing need for joint operations, interoperability has become a core requirement. It refers to the ability of systems from different nations to function together seamlessly and securely [10]. Within the interoperability paradigm, the Zero Trust model has gained prominence as a security approach specifically suited to federated network environments [11]. Multinational defense coalitions, such as those led by NATO, rely heavily on interoperability to enable secure and coordinated missions. This necessity has given rise to Federated Coalition Networks (FCNs) [12,13], which are communication architectures that promote cooperation among diverse national systems while preserving autonomy and control. FCNs enable forces and organizations to share resources and dynamically adjust to mission demands securely. Their flexible architecture also provides a foundation for integrating emerging technologies like blockchain, further enhancing trust, traceability, and data protection.

Despite progress in FCNs, their management, typically handled through Command and Control (C2) centers, has yet to incorporate blockchain fully. The benefits of such integration, particularly for reinforcing the confidentiality, integrity, and availability of communications, remain underexplored. Blockchain could also support differentiated service levels across coalition members, a crucial requirement in multinational contexts.

This paper addresses this gap by proposing a blockchain-based management framework for FCNs that strengthens network resilience and introduces an additional security layer consistent with the defense-in-depth paradigm. Beyond improving operational security, the framework incorporates a compliance harmonization layer. This layer facilitates enforcement of regulatory and policy requirements across diverse systems, supporting aligned governance within international coalitions.

While blockchain-based Public Key Infrastructure (PKI) mechanisms have been explored in previous work, the contribution of this paper lies beyond introducing PKI on a distributed ledger. The novelty of the proposed approach resides in its application to FCN under realistic defense and tactical constraints, and in its integration of identity management, policy enforcement, governance, and auditability within a single coalition-oriented framework. Unlike existing solutions that focus on isolated cryptographic services, this work positions blockchain as a management and governance backbone operating at the coalition level, explicitly designed for resource-constrained environments and DIL conditions. Furthermore, the framework is aligned with defense-in-depth principles and NATO Federated Mission Networking concepts, and its feasibility is demonstrated through a proof-of-concept with quantitative performance and energy measurements. To the best of the authors’ knowledge, this is one of the first works to combine coalition-level trust governance, blockchain-based management services, and experimentally validated performance analysis in the context of FCN deployments. In this work, the term Federated Mission Networking (FMN) is used to refer to the NATO doctrinal framework, while Federated Coalition Networks (FCNs) denote the technical and architectural systems addressed by the proposed solution.

The rest of the paper is organized as follows: Section 2 reviews the main FCN concepts. Section 3 explores the benefits of blockchain in FCNs. Section 4 presents the application scenario. Section 5 details the functions included in our framework. Section 6 describes the proposed architecture. Section 7 analyzes the results, and Section 8 concludes the work.

2. Federated Networks Overview

Resource federation has become increasingly popular because it results in a federated system with enhanced aggregated capability. Essentially, the overall capacity of the final system surpasses the sum of the capabilities of the individual federated resources. The concept of resource federation has also been applied to network federation, or Federated Networks (FEDNETs) [14]; FEDNETs are ad hoc and temporary networks that federate around a common objective to achieve a goal. Cooperation between networks is achieved through a common framework agreed upon, including a set of rules, services, and policies.

2.1. Afghan Mission Network (AMN)

The first mission-centric application of the FEDNET concept was the Afghan Mission Network (AMN). It resulted from years of collaboration among Troop Contributing Nations (TCNs) who deployed infrastructure, services, and troops during counter-terrorist operations in Afghanistan from 2001 to 2021. During these operations, the TCNs were forced to collaborate in a heterogeneous technical environment, and in 2012, the NATO Military Committee (NATO MC) approved a request to establish a common domain for TCNs to share services and information. This common domain could be achieved only through domain and network federation [15].

AMN was also conceived as an extended C2 system, intended to manage information exchange and serve as a framework for future system definitions. Consequently, the main objectives that future systems should achieve are:

• Information sharing: the mission must create an environment in which TCNs can send and share information between military and civilian organizations.
• Management and governance: the involved stakeholders should use a commonly agreed set of policies, protocols, technologies, and standards as an interoperability framework during deployment.

2.2. Federated Mission Networking (FMN)

The AMN’s evolution led to the FMN initiative, initially called Future Mission Networking and later Federated Mission Networking. This concept aims to enhance interoperability and readiness among the various forces and entities involved in missions [16]. FMN is still an ongoing effort that aims to:

• Improve the strategic advantage by optimizing the deployment requirements for the NATO verification and validation activities.
• Continuous improvement and adaptation to the technical challenges transforming the mission landscape. This way, the NATO forces will stay in the technological avant-garde.

FMN efforts are organized into “spirals,” each targeting specific capabilities and technologies, such as mobile communications, to be implemented by the end of each development phase. The initiative aims to define coordinated processes, organizations, training, technologies, and standards for NATO nations and allies. Each component must enable each spiral’s required services, sub-services, and capabilities to achieve the desired interoperability. Recent advances in the modeling and simulation of FMN are reported in [17], highlighting the operational and strategic benefits of sustaining interoperability among NATO members and coalition partners.

3. Benefits of Blockchain in FCN

FCNs operate in complex environments where traditional centralized management lacks flexibility and security. Blockchain’s decentralized architecture addresses these issues by removing the central authority and reducing single points of failure. Initially developed for cryptocurrencies like Bitcoin, blockchain has become a versatile tool for enhancing security, transparency, and efficiency across various military applications, including FCN. Its decentralized and immutable transaction records position it well for managing FCNs from C2 systems. Readers interested in a broader understanding of blockchain technology may refer to the tutorial in [18].

A blockchain-enabled management framework offers several key advantages for FCNs:

• Enhanced Security: Blockchain provides a tamper-proof ledger for all transactions and interactions within the network. Each transaction is cryptographically secured and linked to the previous one, creating a difficult-to-alter chain of blocks. This ensures data integrity and protects against unauthorized access and tampering.
• Increased Transparency and Trust: Transactions are recorded on a public or permissioned ledger; however, in the context of FCN deployments, a permissioned ledger is generally more appropriate. Access is restricted to authorized participants, ensuring that all actions within the network are visible and verifiable to trusted parties. This controlled transparency fosters trust and collaboration among coalition members while preserving operational security, a particularly critical aspect of defense and military operations.
• Automation with Smart Contracts: Blockchain technology enables the use of smart contracts, which are self-executing agreements with terms written directly into code. Smart contracts can automatically enforce rules, execute transactions, and manage access control based on predefined conditions. This reduces administrative overhead, minimizes human errors, and ensures compliance with established protocols.

Despite its advantages, integrating blockchain into FCNs poses challenges. Scalability, interoperability, and the need for consensus mechanisms tailored to coalition environments must be addressed. Additionally, blockchain’s computational and energy demands require efficient protocols to ensure sustainable operation.

This paper examines the practical application of blockchain in FCNs, highlights its benefits, discusses key challenges, and proposes integration strategies. As the digital landscape evolves, adopting innovative technologies such as blockchain will ensure that federated coalition networks remain robust and resilient.

4. Scenario and Use Case Description

The following scenario is designed to evaluate the capabilities and functionalities of the proposed system. It is important to note that the operational environment (including all actors, locations, and cartographic representations) is strictly fictitious and created solely for research purposes. This scenario involves forces from three allied nations, an undefined adversarial force, and a neutral territory where neutral, adversarial, and allied elements are co-located.

• Tier one, or Coalition Layer: at the top of Figure 1. It includes a supranational entity centralizing coalition C2 operations. This layer represents a Joint Force Command (JFC) for this illustrative example, though the exact hierarchy is simplified and beyond the scope of this study.
  

  Figure 1. Coalition hierarchy.
• Tier two, or National Layer: in the central section of Figure 1. It involves the national C2 systems that will transpose the coalition orders to the national components and forces. Here, the national layer involves three allied actors: nations A, B and C.
• Tier three, or Tactical Layer: at the bottom of Figure 1. It executes the mission orders and includes the national troops and technological assets. Each component of this layer is federated with its own national C2.

The hierarchy operates across different functional levels: the Coalition layer sets high-level commands, the national layer translates them into executable actions, and the tactical layer carries out these commands (e.g., mission orders or asset configurations).

The use case is located in a fictional city. Nation A troops are located in the north, Nation B forces are located in the northeast, and Nation C troops are located in the southeast, as depicted in Figure 2 with the numbers 1, 2, and 3, respectively; all of the allied forces participate in routine tasks to maintain the peace in the city.

Figure 2. Scenario location.

The use case describes an incident that eventually occurs in the southwest, label 4 in Figure 2. The allied forces come to secure the area. As this zone is considered a non-secure area, communications will be carried out via a swarm of drones rather than through the area’s infrastructure to ensure information transmission. During the operations, one of the communication drones malfunctions and crashes in a distant area under enemy control.

The proposed framework highlights areas 1 to 3 for this use case (see Figure 2) as key zones that would benefit from implementing Blockchain in the FMN environment as follows:

• Before the operation, the IT infrastructure must be configured when forces are deployed or a new ally joins. Blockchain can involve all forces and authorized stakeholders to ensure proper device configuration. Before the operation, when forces are deployed, or a new allied force joins the deployment, the IT infrastructure must be configured appropriately. Blockchain could be used to involve all relevant parties and authorized stakeholders, and to ensure the proper configuration of devices.
• During the operation, blockchain can secure communications among the troops developing the mission, including tactical exchanges, order distribution, mission reports, and device log management. During the operation, the forces can use blockchain-enabled technology to ensure communications [19], including tactical communications (i.e., communications between the troops that develop the mission), order distribution, mission-report generation, and device log management.
• After the operation, the system would ensure the access, availability, and integrity of mission reports for their further analysis.

The specific iconography employed in Figure 2 is detailed in Table 1, which summarizes the symbols used and their corresponding operational meanings. This standardized representation ensures clarity, interoperability, and a consistent interpretation of the elements involved in the scenario. The symbology uses the APP-6 standard symbology from [20].

Table 1. APP-6 iconography used.

Symbol	Description
	Command Post—Allied Command Operations
	Multinational (Coalition) Command Post
	Terrestrial Telecommunications Infrastructure
	Patrol Unit
	Emergency Operation
	Communications Drone
	Medical Facilities
	Law Enforcement Facilities
	Accident Involving Hazardous Explosive Materials
	Adversary Jamming

Utilizing a blockchain service framework in a federated deployment enhances security by providing a tamper-proof environment for services such as PKI. It acts as a unifying bus that standardizes interactions across diverse domains, ensuring seamless communication and synchronization through a transparent, immutable ledger. It also increases resilience by eliminating single points of failure.

5. Functions Requirements Description

After detailing the use case, this section outlines the key functions required to support the blockchain-powered management system in FCN, as outlined in the previous scenario. The proposed structure enhances security, transparency, and efficiency using blockchain technology, focusing on seamless communication, coordination, and resource management across all coalition levels, from strategic to tactical units.

The two primary functionalities explored are categorized as Service Functionalities: Policy Enforcement and Network Functionalities: PKI Management. Together, these functions ensure successful mission outcomes in federated network environments by enabling secure operations, efficient resource allocation, and improved interoperability among various coalition entities. We categorize the functionalities into two main types: Service Policy- and Network-based functionalities. These categories are crucial for ensuring secure operations, optimizing resource allocation, and enhancing interoperability in federated networks, thereby supporting successful mission outcomes.

5.1. Service Policy Enforcement Functionalities

Enforcing security policies via blockchain is vital for protecting assets and ensuring operational integrity in multi-national military conflict zones. Blockchain enables a decentralized, transparent, and immutable approach to defining, applying, and auditing policies. It streamlines protocol establishment, deployment on network devices, and compliance verification, providing a secure, distributed platform for efficient policy management.

Figure 3 provides an overview of the functional workflow implemented by the proposed blockchain-based policy enforcement mechanism, distinguishing between two main types of user profiles:

Figure 3. Functional workflow of the blockchain-based policy enforcement mechanism, illustrating role-based access control, policy queries, modification requests, and explicit rejection paths.

• A privileged profile, referred to as the C2 policy administrator. This role is responsible for defining security policies and their corresponding states, and for evaluating and applying policy change requests submitted within the system.
• A user profile, corresponding to coalition personnel. These users operate the assets to which the defined policies and configurations are applied. During normal operation, if deficiencies or potential improvements in policy configurations are identified, users may submit requests for policy changes.

The diagram illustrates how authorized users interact with the management layer via the decentralized application (dApp), how policy requests are validated against role-based permissions, and how state-changing operations are either accepted or explicitly rejected and recorded on-chain. The explicit rejection paths shown in Figure 3 correspond to policy modification requests that violate coalition-level governance constraints, such as national-level changes that conflict with coalition-approved mandates, and are therefore automatically denied by the smart contract logic.

5.1.1. Minimum Necessary Conditions

• Using blockchain enables the implementation of key security management tools, such as configuration management systems, Intrusion Detection Systems (IDS), and access control mechanisms, which are vital for enforcing security in dynamic military environments.
• Blockchain’s immutable record ensures that all policy changes and compliance checks are securely documented and auditable, allowing real-time monitoring and verification of adherence.

5.1.2. Key Assets

• Safeguarding Critical Assets and Data: Security measures are crucial for protecting the integrity and confidentiality of information in conflict zones. Blockchain technology enhances these measures by ensuring compliance with security standards in a decentralized network.
• Flexibility and Scalability: Blockchain enables scalable security measures, essential for managing complex multinational military operations. Its distributed structure enforces policies continuously without a central authority, which is crucial for high-risk missions.
• Ingrained Audit and Conformity: Blockchain’s auditing features ensure continuous monitoring and validation of policy adherence, quickly identifying and resolving discrepancies. This reduces the risk of security breaches and enhances network resilience. Recent work [21] has demonstrated that blockchain transaction data can be automatically classified to support auditability and risk assessment [22], reinforcing the applicability of blockchain as an auditable governance backbone.

Using blockchain to enforce policies in military services during operations enhances security and operational integrity. Its decentralized and transparent nature ensures consistent rule enforcement and rapid detection of unauthorized access or policy breaches.

5.2. Network PKI Management Functionalities

Data integrity in communication is vital in conflict zones involving multiple countries. In this context, communication parameters such as latency are secondary to asset protection in FCNs. Blockchain improves Public Key Infrastructure (PKI) management by decentralizing and securing it, removing reliance on a central authority. Trust is distributed across network nodes, each of which maintains and verifies public keys. This eliminates single points of failure and increases resistance to malicious attacks. Consequently, tactical networks and operations gain enhanced security and resilience.

5.2.1. Minimum Necessary Conditions

• Implementing blockchain-based PKI requires strong encryption and secure key management to guard against cyber threats. Access controls at all network nodes ensure that only authorized entities can manage certificates, maintaining system integrity in critical military environments.
• The PKI system must handle many devices, users, and transactions typical in military deployments. Blockchain’s distributed architecture supports this scalability, enabling the system to process high certificate issuance and validation requests without compromising performance.
• Blockchain’s decentralized structure provides inherent redundancy, ensuring the system remains operational even if certain nodes fail. This resilience is vital in conflict zones, where network reliability may be compromised due to operational disruptions or attacks.
• To meet the demands of military networks, the blockchain-based PKI must perform certificate-related operations such as validation and issuance with minimal latency. High-performance capabilities are crucial for ensuring real-time communication and timely decision-making in tactical situations.

5.2.2. Key Assets

• Distributed Trust: Blockchain removes the need for a central authority by spreading trust across all network nodes. This reduces vulnerabilities and is especially useful in collaborative military operations, where no single nation should control the entire PKI system.
• Immutability and Auditability: Blockchain’s immutable ledger ensures that public keys and certificates cannot be altered once recorded. This creates a secure and auditable history of all PKI transactions, allowing real-time tracking of issuance, renewal, and revocation, which is crucial for maintaining integrity in sensitive military environments.
• Automated Certificate Management: smart contracts automate certificate issuance, renewal, and revocation, reducing manual effort and enhancing efficiency and security. This automation also promptly revokes certificates, minimizing unauthorized access and boosting overall network security.

5.3. System and Operational Requirements in FCN Environments

FCNs operate in highly dynamic, heterogeneous, and adversarial environments, where multiple nations must cooperate while preserving sovereignty over their assets and decision-making processes. Consequently, the proposed blockchain-enabled framework is designed to satisfy a specific set of system and operational requirements derived from realistic FCN deployments.

From a functional perspective, the framework targets management-plane operations, rather than time-critical tactical command dissemination. Its primary functions include policy enforcement, PKI management, asset authorization, configuration traceability, and auditability. Tactical data exchange and urgent mission orders continue to rely on existing communication systems optimized for low latency.

From an operational standpoint, the following requirements are identified:

• Security requirements: The system must guarantee confidentiality, integrity, and availability (CIA) of management-related information across coalition domains. Unauthorized access, insider threats, and compromised assets must be detectable and mitigable through access control, cryptographic mechanisms, and auditable records.
• Federated governance: No single national authority shall unilaterally control the system. Governance must be shared at the coalition level, while allowing each nation to retain control over its internal assets and configurations.
• Performance constraints: Management operations must tolerate moderate latency (on the order of seconds) but must remain predictable and bounded. Read-only queries should not generate blockchain transactions in order to minimize overhead.
• Scalability: The system must support a growing number of assets, users, and coalition participants without requiring centralized reconfiguration.
• Resource efficiency: Tactical and edge devices are assumed to be resource-constrained. Therefore, they must not be required to act as blockchain validator nodes, nor to perform computationally intensive operations.
• Operation under DIL conditions: The system must tolerate Disconnected, Intermittent, and Low-bandwidth (DIL) communications, ensuring that management operations remain consistent once connectivity is restored.

Reconciliation after network partitioning is performed through a versioned state model, where reconnected nodes discard outdated local states and synchronize with the latest coalition-approved policy state recorded on the ledger.

These requirements guide the architectural and technological choices described in the following sections.

5.4. Threat Model and Security Assumptions

FCN environments are exposed to a broad spectrum of cyber and operational threats, ranging from external adversaries to insider misuse and asset compromise. The proposed framework adopts a defense-in-depth approach and is designed under the assumption that parts of the infrastructure may be exposed, disrupted, or temporarily isolated.

The considered threat model includes:

• Unauthorized users: Attempts to access management services or cryptographic material without appropriate authorization.
• Insider threats: Legitimate users attempting to exceed their assigned privileges or manipulate configurations.
• Compromised assets: Tactical devices or communication relays (e.g., drones) that may be captured, lost, or tampered with in hostile environments.
• Communication disruption: Network partitioning caused by jamming, physical damage, or limited connectivity between coalition domains.
• Policy manipulation: Attempts to alter security policies or trust relationships without proper authorization.

To address these threats, the framework incorporates the following security assumptions and mitigations:

• All identity-related operations are enforced via blockchain-based PKI, enabling immediate revocation and auditable lifecycle management of cryptographic keys.
• Access control logic is embedded in smart contracts, ensuring that unauthorized or malformed requests are automatically rejected.
• State-changing operations are immutably recorded, enabling forensic analysis and post-mission accountability.
• Tactical assets are treated as service consumers, not trust anchors; compromise of a single asset does not undermine coalition-wide trust.
• Validator nodes are deployed at controlled domain boundaries, reducing exposure while preserving distributed trust.

This threat model explicitly supports coalition scenarios where trust is partial, dynamic, and continuously reassessed throughout mission execution.

5.5. Governance and Role-Based Policy Control

To ensure secure and auditable governance in a federated coalition environment, the proposed framework enforces strict role separation and explicit authorization checks for all policy-related operations. Governance logic is implemented directly within smart contracts, ensuring that unauthorized actions are systematically rejected and that all state-changing operations are immutably recorded.

Figure 4 illustrates the validation workflow and test scenarios executed on the deployed policy enforcement smart contract. The diagram highlights how different user roles interact with the system and how governance rules are enforced throughout the policy lifecycle. The evaluation process follows these steps:

Figure 4. Governance and role-based policy control workflow. The figure illustrates administrator-driven policy creation and configuration, authorized user queries and change requests, and explicit denial of unauthorized actions enforced through smart contracts.

• The account that deploys the smart contract, acting as the policy administrator, initializes a baseline set of policies, adds additional policies, and configures their operational parameters.
• An unauthorized user attempts to create or configure policies. These operations are explicitly denied by the smart contract, demonstrating the effectiveness of role-based access control.
• An authorized user queries the current state of the policies that apply to the assets under its control, enabling correct and up-to-date configuration enforcement.
• An authorized user submits a request to modify the configuration of a specific policy, without directly applying the change.
• The policy administrator reviews pending modification requests, approves or rejects them, applies the authorized changes, and verifies that the updated policy state is correctly reflected across the system.

This governance model ensures that no single coalition participant can unilaterally modify security policies while preserving operational flexibility. By embedding governance rules into the blockchain layer, the framework provides traceability, accountability, and resilience against both unauthorized access and insider misuse.

In the proof-of-concept implementation, all coalition members are assigned equal voting weight as a neutral baseline; however, the framework supports configurable weighting schemes based on asset contribution or mission responsibility without architectural modifications.

6. Proposed FCN Architecture

6.1. Framework

This proposal is based on the NATO Architecture Framework v4 (NAFv4) guideline [23], ideal for defining architectures in both business and military contexts. We selected the following viewpoints (C1, S1) from NAFv4 for our system to ensure the appropriate level of detail for our proposal:

• C1—Capability Taxonomy: this viewpoint is concerned with identifying the capabilities and their organization, independent of their implementation. In this case, this viewpoint has been used to identify and organize the internal capabilities, meaning only those capabilities related to the proposed Blockchain-based system. Following the hierarchy and structure presented in Figure 1, the capabilities identified can be linked to a certain tier of the federation. The capability related to data analysis and lessons learned is transversal across all mission planning and organization tiers, as shown in Figure 5.
• S1—Service Taxonomy: This viewpoint is concerned with identifying the service specifications and their organization. In our case, the viewpoint shown in Figure 6 has been used to define the services required to enable the particular capability of Infrastructure Management identified in the previous viewpoint C1. As this viewpoint shows, IT infrastructure management includes managing public key infrastructure, network and asset configuration, and other management and enabled services.

Figure 5. C1 viewpoint.

Figure 6. S1 viewpoint, Infrastructure management capability.

The identified services are associated with different phases of the use case exposed in the scenario according to (1) During the deployment of troops, the networks and assets should be appropriately configured; (2) the deployed assets must be assigned to a user-authorized in the system, and their keys enrolled adequately in the PKI, and (3) the troops should receive the mission order ensuring their confidentiality.

6.2. Consensus, Trust, and Governance Model

The proposed framework is based on a permissioned blockchain architecture, explicitly designed to avoid energy-intensive Proof-of-Work mechanisms. Consensus is achieved through Byzantine Fault Tolerant (BFT) and Proof-of-Stake–like mechanisms, instantiated in the proof-of-concept using Avalanche Subnets. The consensus model tolerates Byzantine behavior provided that a majority of the active stake remains honest, following the security assumptions of Avalanche-based protocols. Classical PBFT-style protocols were not selected due to their high communication complexity and limited scalability under intermittent connectivity, whereas Avalanche-based consensus offers probabilistic finality and improved resilience in DIL environments.

Trust is established at the coalition level, rather than at the national level. Each participating nation contributes authorized validator nodes operating under a shared governance framework agreed by the coalition. This model ensures that:

• No single nation can unilaterally control or modify the ledger.
• Trust emerges from collective validation rather than centralized certification.
• National sovereignty over internal assets and configurations is preserved.

Validator nodes are strategically placed at domain boundaries (e.g., coalition or national command-and-control systems), while tactical and edge devices interact with the system through lightweight client operations. This design minimizes computational and energy requirements for deployed assets.

In the presence of network partitioning or DIL conditions, domains may temporarily operate in isolation. Transactions are locally queued and validated once connectivity is reestablished, ensuring eventual consistency without compromising security. This approach aligns with operational realities in contested and degraded environments.

Overall, the consensus and governance model balances decentralization, resilience, and operational practicality, making it suitable for federated defense deployments.

7. FCN Proof-of-Concept Evaluation

To validate the feasibility of the proposed blockchain-enabled framework, we implemented a proof-of-concept (PoC) on the Avalanche Fuji testnet, complemented by private subnets configured via Avalanche-CLI. The PoC focused on the two core functionalities identified in Section 5. Smart contracts were developed in Solidity and tested with three different user roles: administrator, authorized user, and unauthorized user.

7.1. Policy Enforcement

The contract supported five operations: (i) creation and initialization of policy sets, (ii) retrieval of policy status, (iii) request for policy modification, (iv) policy update, and (v) evaluation of requests. The dynamic reconfiguration logic of the proposed system is shown in Figure 7, providing a high-level overview of the main checks implemented by the framework, along with its behavior and responses. The evaluation has been structured into three main categories:

Figure 7. Dynamic policy reconfiguration sequence after approved or rejected modification requests, illustrating resilience, consistency, and synchronization across federated domains.

• Policy creation and configuration: an administrator creates an initial set of policies and configures them. The same actions are also attempted by a non-administrative user to validate the enforcement of access controls.
• Policy verification: an authorized user queries the current state of the policies that must be applied to its assigned assets.
• Change request and application: after verifying policy states, modification requests are submitted for selected policies, which are subsequently evaluated and applied by an administrator.

In this PoC, we obtained:

• Functional validation: 18 authorized modification requests executed successfully, while 6 unauthorized attempts were systematically rejected.
• Results: Average latency for authorized write operations was ≈1.35 s, with all transactions immutably recorded on-chain. Read-only queries (policy retrieval) generated no transactions, thus avoiding additional overhead.
• Security outcome: Access control rules embedded in the smart contract effectively distinguished user privileges, ensuring that only administrators could authorize or deny modifications.

State changes resulting from policy updates are not actively pushed to disconnected tactical nodes. Instead, updates are recorded on the coalition management layer and retrieved by tactical assets upon reconnection, using version identifiers and timestamps to ensure eventual consistency without requiring continuous connectivity.

7.2. PKI Management

The PKI contract implemented functions for publishing, updating, retrieving, revoking, and authorizing public keys.

• Functional validation: 29 transactions were performed across authorized, unauthorized, and administrator roles. All valid operations succeeded, while unauthorized attempts were blocked.
• Results: Transactions required an average execution time of <$1.5$ s, with a gas cost of approximately 0.004 AVAX (native token of the Avalanche network, used to pay transaction fees (‘gas’) in both mainnet and testnet environments) per operation.
• Auditability: Each state-changing action was immutably recorded, ensuring traceability of key lifecycles (issuance, update, revocation).

7.3. Performance Analysis and Resource Overhead Summary

After deploying on Avalanche (Note that full implementation would require developing additional functionalities depending on the country to provide comprehensive services.), the results of the contracts were evaluated. All functions were tested with authorized, unauthorized, and administrator accounts. Figure 8 illustrates how transactions are recorded on the blockchain. The figure highlights several fields in blue, including the function called transaction details and user identifiers, all of which are securely encrypted. In contrast, highlighted in green, authorized users could access the requested information.

Figure 8. Transaction details validation.

The tests demonstrate that the functions implemented through smart contracts operate as intended, confirming the system’s viability. Furthermore, the fundamental security dimensions are ensured, with information encrypted adequately against unauthorized access. Thanks to the nature of blockchain and the validating nodes, the system’s availability and integrity are guaranteed.

Assets executing transactions or contracts do not need to be chain nodes. Node selection should ensure at least one authorized node in each deployment domain (managed by specifically authorized personnel) while other assets remain system-authorized and consume minimal energy. Thus, thanks to Blockchain’s distributed architecture, if communication between domains is interrupted and some nodes are isolated, transactions will still be validated once communication is reestablished.

This design has two main consequences. First, read-only operations (e.g., policy queries, key retrieval) do not generate on-chain transactions, avoiding overhead; only state-changing functions are recorded. Second, validator placement at the domain boundary reduces cross-domain traffic and supports operation under intermittent or bandwidth-constrained links, aligning with the scalable profile of BFT/PoS systems. Specifically, this proposal reduces communication overhead in resource-constrained environments, as the tactical scenarios across FCN are similar to those of other blockchain-based approaches proposed in [24].

To evaluate the feasibility of the proposed framework, a proof-of-concept implementation was deployed on a permissioned Avalanche-based environment. The evaluation focused on the two core management functions: policy enforcement and PKI management.

The obtained results demonstrate that the blockchain layer introduces limited and predictable overhead:

• Transaction throughput: Sustained performance of approximately 110–125 transactions per second, sufficient for FCN management operations.
• Latency: Average execution time of state-changing transactions between 1.3 and 1.5 s.
• Energy consumption: below 0.02 Wh per transaction, compatible with energy-aware deployments.
• Operational optimization: Read-only operations (e.g., policy queries, key retrieval) are executed off-chain and do not generate blockchain transactions, effectively eliminating unnecessary overhead.
• Resilience: One validator per domain ensures distributed trust and operation under constrained links.

These results confirm that the framework is suitable for management-plane use in FCN environments.

7.4. Blockchain, Resilience and Regulations

One of the most relevant enabling capabilities of the proposed solution is regulatory compliance. Compliance with cybersecurity regulations or certification against recognised cybersecurity standards is progressively evolving from a de facto market-driven requirement (e.g., ISA/IEC 62443 certifications in the industrial domain) into a formal legal obligation for organisations providing specific services or manufacturing certain categories of products, such as products with digital elements under the Cyber Resilience Act (CRA) or essential and important entities subject to risk management and governance obligations under the NIS2 Directive [25].

By introducing an additional architectural layer that integrates multiple systems and functions (i.e., public key infrastructure, identity management, and device configuration), the proposed solution not only simplifies their coordinated management but also enhances traceability and auditability. These properties are essential to support compliance assessments, certification processes, and the provision of verifiable evidence during audits.

Although certain regulatory frameworks explicitly exclude products designed exclusively for military use (NIS2 does not apply to the defence sector, and the CRA excludes products intended solely for defence purposes while remaining applicable to dual-use components or systems incorporating civilian technologies) specific cybersecurity requirements nevertheless apply to Defence and National Security environments. These requirements, typically defined by national authorities and defence procurement frameworks and not publicly disclosed, are at least aligned with industry best practices at the highest security levels. Representative examples include Maturity Level 4 of IEC 62443-4-1, Security Level 4 of IEC 62443-3-3 and IEC 62443-4-2, or the Critical Products category as defined by the CRA.

Consequently, the proposed approach provides objective benefits for both military and civilian contexts, including:

• Support for cybersecurity risk management, applicable both to internal product risk analysis through the identification and inventory of assets enrolled in the system (an essential prerequisite for compliance with NIS2 risk management obligations (Art. 21.2) and for demonstrating risk-based design and technical documentation under the CRA) and to supply chain risk management (CRA Annex I, Part I; NIS2 Art. 21.2(d)), by enabling traceability of activities and dependencies across components and providers. In addition, by leveraging the proposed Service Policy Enforcement Functionalities, the framework ensures that the operational state of enrolled assets remains consistent with the assumptions made during risk assessments, by introducing an additional validation layer for policy enforcement and asset state inventory.
• Validation and enforcement of a secure baseline, defined during asset enrollment and maintained throughout asset operation, by leveraging the proposed Service Policy Enforcement and the Network PKI Management Functionalities, in line with CRA essential cybersecurity requirements related to secure configuration and protection against unauthorized modification (Annex I, points 2(b) and 2(d)).
• Provision of auditable and verifiable records of security-relevant events and transactions, supporting incident handling, effectiveness evaluation, accountability, and evidence generation, as required by NIS2 risk management measures (Art. 21.2(b) and 21.2(f)) and CRA essential requirements on monitoring and diagnostic capabilities (Annex I, points 2(b) and 2(d)), by leveraging the proposed Service Policy Enforcement and the Network PKI Management Functionalities.

The benefits derived from the development and deployment of the proposed solution are not limited to the examples discussed above but ultimately depend on the specific set of services and capabilities implemented on top of the proposed architecture.

More importantly, the relevance of the proposed system does not lie in its alignment with a single regulatory framework, but in its ability to support the validation of compliance across multiple regulatory and certification schemes. By providing consistent traceability, auditable evidence, and enforcement of common security principles, such as asset identification, secure configuration, access control, and lifecycle management, the system enables the verification of cross-cutting cybersecurity requirements that are shared across regulations but are often difficult to assess in practice. As a result, the proposed approach facilitates a more efficient, objective, and reusable compliance validation process, reducing fragmentation between regulatory domains while improving assurance levels in both civilian and defence-related contexts.

7.5. Lessons Learned

The evaluation confirmed that blockchain-based policy and PKI management can securely and efficiently be deployed in a federated coalition context. While additional services (e.g., certificate revocation lists, mission report archiving) are needed for full deployment, the PoC demonstrates feasibility and scalability. Our primary focus has been the NATO FMN environment; however, the same mechanisms for policy enforcement, PKI management, and auditability could also align with broader European cybersecurity and resilience regulations. This shows the approach is not limited to a single governance model but adapts to heterogeneous multinational frameworks, reinforcing operational trust and regulatory compliance across coalitions.

8. Conclusions

This work highlights the potential of blockchain as a key enabler for secure, interoperable, policy-compliant FCNs. Beyond enhancing interoperability in multinational operations, the framework strengthens cybersecurity by adding a decentralized, tamper-evident layer aligned with defense-in-depth strategies. It also introduces a compliance mechanism facilitating consistent enforcement of regulatory and operational policies across diverse coalition members. This PoC reinforces both security assurance and governance alignment in tactical environments.