Blockchain-based access management framework for interoperable digital twins in industrial IoT

Introduction: Digital Twins (DT) have appeared as a significant tool in Industrial Internet of Things (IIoT) environments, allowing real-time monitoring, predictive maintenance, and maximizing device performance. However, integrating DTs with IIoT initiates serious security issues, specifically in the device’s authentication and authorization. The state-of-the-art mechanisms are exposed to insider threats, single points of failure, and privacy issues.

Methods: This study proposes a blockchain-based access control framework for cross-domain DTs. The blockchain (BC) integration eliminates reliance on the centralized authentication server. It uses platform verification from the manufacturer to validate IIoT device integrity and mitigate insider threats. Moreover, the authorization mechanism is implemented using smart contract and access control policies stored in BC. The proposed Non-Fungible Tokens enable role and permission delegation.

Results and Discussion: The integration of Hyperledger Fabric BC, platform hash verification, and NFT-based authorization in the proposed architecture enhanced its resilience against cyber-attacks i.e., replay, DoS/DDoS, insider, and spoofing attacks. Moreover, the proposed framework validates its viability with response times (approximately 300ms) for the authentication and authorization phases. Additionally, identity resolution attains 67 % depletion in latency compared to its counterpart.

1 Introduction

Digital twins (DTs) of physical assets have become a powerful tool for augmenting the functionality of environments connected to the industrial Internet of Things (IIoT). IIoT facilitates real-time data gathering, analysis, and control by linking physical assets to digital systems, which boosts productivity, efficiency, and creativity. These advantages are increased when DTs are incorporated into IIoT systems as they offer a virtual image of real assets that can be utilized for predictive maintenance, optimization, and simulation (Soori et al., 2023).

Industry groups such as the National Aeronautics and Space Administration (NASA) paid attention to the DT when it was first presented, and it remains a critical strategic component in many organizations (Singh et al., 2021). Numerous disciplines have investigated DT technologies in great detail, including automation, computing, and system modeling. They are acknowledged as being as important as blockchain (BC) and artificial intelligence (AI) in smart manufacturing systems. The DT was included in Gartner’s list of the top 10 strategic technology trends for 2019 (Gartner, 2019).

DTs can produce accurate and current representations using real-time data of physical assets. These data can be used to identify possible problems, simulate different scenarios, and optimize operations. DTs can also be utilized to display complicated systems, which facilitates operator comprehension and control (Qi et al., 2021). Moreover, DTs are used to simulate the entire lifecycle of physical objects and systems using data and physical models. DTs can enhance resource allocation and track, monitor, and predict the behavior of real entities through real-time, duplex communication between the virtual and real entities (Hemdan et al., 2023; Alshathri et al., 2023).

Organizations can discover new opportunities to enhance operations and commercial growth by integrating the potential of DTs with IIoT. For example, DTs can be used to integrate agricultural data such as soil, crops, cattle, and machinery with meteorology. Farmers can now manage irrigation based on rainfall predictions, reduce the likelihood of crop failure, and anticipate how crops will react to weather dangers. Similarly, a DT can be deployed for a full supply chain, linking a production plant to logistics and distribution networks. Every stakeholder has its own DT. This interoperability will enable real-time data exchange to enhance inventory management, anticipate supply chain constraints, and adjust production timelines based on delivery data. However, integrating DTs and IIoT also leads to new security issues, especially regarding authentication and authorization. To ensure the integrity and security of the DTs, it is essential to implement robust authentication and authorization mechanisms.

The authentication mechanism validates the identity of the IIoT devices attempting to access a system. Similarly, the authorization mechanism assigns permissions to the validated IIoT devices. It guarantees that physical assets or data can only be accessed, modified, or controlled by authorized people or devices (Devi et al., 2023). However, traditional authentication and authorization mechanisms [Chen et al. (2023), Shi et al. (2024), and Son et al. (2022)] have several drawbacks. These mechanisms rely on a central authentication and authorization service. These centralized services are vulnerable to a single point of failure. It can compromise the security and integrity of IIoT devices and data. The current systems delegate a whole role or use a static access list to delegate permission to cross-domain users/devices. Moreover, due to privileged access, insider threats can install malware to compromise the DT model and its operations (Saraswathi, 2025; Chen et al., 2023; Jain et al., 2024). As a result, it can compromise the security of the IIoT device linked to the DT. Moreover, traditional authorization mechanisms can cause privacy risks between DTs, i.e., intellectual property theft and data manipulation, among others. Therefore, a decentralized, secure, and privacy-preserving authentication and authorization mechanism is vital in an IIoT environment.

The proposed framework eliminates the dependence on a single trusted authentication and authorization entity by integrating BC. Moreover, platform verification from the manufacturer is used to improve the identity authentication of IIoT devices. This enhancement enables the authentication mechanism to detect and prevent insider threats from unwanted changes to the DTs. Moreover, DTs are deployed on the BC. Therefore, it ensures that data tampering and forgeries are prevented by obtaining approval from multiple BC nodes before any changes are made. The proposed framework uses non-fungible token (NFT)-based role and permission delegation to authorize cross-domain users. These NFTs can be programmed to assign more granular, auditable permissions on a resource to a cross-domain user/IIoT device.

This research study is divided into the following sections: Section 2 describes the basic concepts and related works. Section 3 contains a detailed discussion of the proposed framework’s components and system operations. Section 4 describes compatible use cases and the security analysis. The proposed framework implementation and experimental results are debated in Section 5. Finally, the conclusion is provided in Section 6.

2 Preliminaries and related works

2.1 Digital twins

In the literature (Barricelli et al., 2019; Botín-Sanabria et al., 2022), DTs are described as physical or virtual devices or computer-designed models that replicate physical objects. The basic architecture of a DT is composed of three core elements: real space, virtual space, and communication links between real and virtual spaces (Mihai et al., 2022). Unlike digital shadows, a DT monitors, regulates, and optimizes its operations by following the lifecycle of its physical replica (Sepasgozar, 2021). It consistently forecasts future failure conditions by allowing the simulation of different configurations (Qian et al., 2022).

2.1.1 Characteristics of digital twins

The DT must possess the following characteristics.

• High-fidelity: The DT needs to be an accurate virtual replica of the system’s geometry, physics, and behavior.

• Real-time data integration: Real-time bidirectional data flow must exist between the physical system and the DT using the Open Platform Communications Unified Architecture, Message Queuing Telemetry Transport, and 5G/6G (Al Zami et al., 2025).

• Security: The DT must protect against cyber threats using access control and encryption mechanisms (Alcaraz and Lopez, 2022).

• Self-updating: The DT should evolve with the changes in the physical system.

• Interoperability: The DT should be compatible with standard platforms such as Product Lifecycle Management (PLM), Supervisory Control and Data Acquisition (SCADA), Enterprise Resource Planning (ERP), and the Internet of Things (IoT).

• Predictive capabilities: The DT should integrate AI/ML for predictive analytics.

• Self-healing: The DT should monitor relevant parameters and heal automatically using self-diagnosing mechanisms (Mihai et al., 2022).

• Adaptive learning: The DT should enhance prediction accuracy through continuous feedback.

2.1.2 Digital twin development platforms

The following are the well-known DT development platforms.

• Siemens offers a platform for DT development. The DT development suite consists of several modules, including Tecnomatix for computer-based manufacturing, MindSphere for IoT connectivity and predictive analytics, and Simcenter for modeling and evaluation (Siemens, 2025).

• AspenTech offers an asset performance management (APM) suite that uses AI, predictive analytics, and process simulation (Abanda et al., 2024). This suite comprises various solutions such as Aspen Mtell for AI-based predictive maintenance, Aspen Plus/HYSYS for process simulation, and Aspen GDOT for real-time process optimization.

• AVEVA developed an industrial DT platform that optimizes plants and assets and provides real-time data, 3D modeling, and AI analytics. It offers various solutions such as AVEVA Unified Engineering for plant modeling, AVEVA E3D for 3D plant modeling, and AVEVA Predictive Analytics for asset health monitoring (Aveva, 2025).

• Microsoft Azure offers a cloud-based development platform for DTs (Nath et al., 2021). It consists of the following core components: Azure Digital Twins (ADTs) for modeling industrial facilities, IoT Hub for connecting sensors, Synapse Analytics for analyzing sensor data, and Azure Maps for 3D visualization.

• Ansys Twin Builder is a DT platform that provides 3D simulation and reduced-order modeling (ROM) of real-time sensor data for predictive analytics and system optimization (Tang et al., 2025).

2.2 Blockchain

BC is a decentralized distributed ledger technology that stores transactions on multiple nodes in a peer-to-peer network. The BC concept was proposed by Nakamoto (2008). Although BC is the backbone of cryptocurrencies such as Bitcoin, it also has extensive applications in supply chains (Yang et al., 2025), healthcare, and e-commerce (Zhang and Lu, 2025).

BC validates and stores a set of transactions in blocks. Each block consists of two parts, namely, the block header and block data. The header contains information regarding the block, such as the previous block hash, proof-of-work (PoW), Merkle root hash, and timestamp, while the block data contains transactions (Conti et al., 2018). BC creates a chain by linking blocks such that each block contains a hash of the previous block (Saba et al., 2023).

2.2.1 BC operational mechanics

A user initiates and broadcasts a transaction to the BC peer-to-peer network. The BC network consists of special nodes called miners (Novo, 2018). Every miner receives a set of transactions from the newly submitted transactions and builds a block. However, only one miner will receive the prize and submit their block to the chain. As a result, the miners attempt to solve the PoW mathematical puzzle (Laurence, 2023). If a miner discovers the PoW first, it can add its block to the ledger. For validation, it publishes the block and PoW to every miner in the network. Each miner verifies the PoW and links the block to its ledger.

2.2.2 Smart contract

The smart contract application runs on BC to implement a predefined procedure to control transactions between entities without a trusted intermediary (Buterin, 2014). The concept of smart contracts was introduced by Szabo (1997). When certain predefined conditions are met, the smart contract runs automatically. Ethereum was the first platform to use smart contracts. Ethereum uses the Solidity language for smart contract development (Hu and Li, 2025). Other platforms such as Hyperledger, Solana, and Tezos have implemented smart contracts. Smart contracts have the following characteristics: they are self-executing, require no intermediary, are transparent to all parties, cannot be altered once deployed, and are deterministic (Hewa et al., 2021).

2.2.3 Blockchain platforms

In Table 1, the well-known BC platforms are compared/summarized using key parameters.

Table 1

Table 1. Comparison of well-known blockchain platforms.

2.3 Related works

DT technology is reshaping industries by enhancing operational efficiency, decreasing costs, and enabling predictive analytics (Liu et al., 2024). DTs are multi-physics, multiscale, integrated, and probabilistic simulations of complex objects that reflect the lifecycles of their physical equivalents (Glaessgen and Stargel, 2012). Several DT system models have been proposed in the literature for different industries. These studies are summarized in Table 2. Tao et al. (2019) proposed a DT model consisting of five main modules, namely, the physical, virtual, connection, data, and service modules. However, the user module is not taken into consideration. A user module is necessary because it ensures real-time monitoring, control, decision support, and collaboration. However, the user module needs to implement a secure and robust authentication and authorization protocol to protect the DT data.

Table 2

Table 2. Contributions and limitations of the related works.

A user-centric privacy-preserving authentication mechanism was proposed for DT systems (Patel et al., 2024). The DT model comprises the user, cloud, edge, and physical spaces. BC-based decentralized identifiers and verifiable credentials were used to ensure security and privacy in cloud-based DTs. Similarly, Aggarwal et al. (2023) proposed a BC-based privacy-preserving authentication mechanism for DTs in aerospace. The mutual authentication mechanism is implemented among the data controller, data user, and cloud server. The BC ensures authorized access to the data by logging every data-transfer transaction. Similarly, a three-factor authentication mechanism is proposed using BC and elliptic curve cryptography (Thakur et al., 2023). The user fingerprint is used as a third factor to enhance the current two-factor authentication process. The DT data are stored on the cloud, while the hashes are stored on the BC. A user is authorized to access the DT data after fingerprint data validation is used as a third factor to enhance the current two-factor authentication. In addition, the user data request logs are stored on the BC.

Moreover, a BC-based authentication framework for vehicular DT systems was proposed by Gautam et al. (2024). The proposed framework implements elliptic curve cryptography (ECC), cryptographic hash algorithms, pseudo IDs, and a consortium BC to secure intra-twin and inter-twin communication. However, it is assumed that the registration and key exchange phases are secure. A legitimate user can compromise these phases and cause the entire system to collapse. Similarly, a lightweight authentication mechanism was proposed by Jain et al. (2024) for the DT in the Internet of Medical Things (IoMT). A DT is created on the cloud to simulate patient data for analysis and remote monitoring. A multi-factor authentication mechanism is proposed to authenticate doctors before accessing the patient sensor data. The patient’s data are stored on BC. All of the above frameworks have proposed two- and three-factor authentication, but they lack platform verification. Therefore, an insider can exploit a compromised device and misuse the system. Platform verification prevents compromised, malicious, and cloned devices from obtaining system resources.

Virtual replicas of vehicles were developed by Chen et al. (2023); these replicas store and execute driving data in real time. Both vehicles and DTs mutually authenticate each other. However, a central entity is proposed that assigns pseudonym identities to vehicles during registration. These central entities are single points of failure. Similarly, Shi et al. (2024) proposed a Traceable Threshold Single Sign-On (TTSSO) authentication protocol for DT platforms. The mechanism generates a master token for a user from various partial tokens issued by identity servers. However, a single tracking server (TS) is used. The user’s privacy could be breached if the TS is compromised. Similarly, a secure mutual authentication protocol is proposed between data users/owners and cloud servers (Son et al., 2022). The BC is used in the post-authentication phase to store log data and hash values, while the cloud server is used for user authentication. In addition, the cloud server stores and processes data received from different smart devices and sensors. All the above frameworks have proposed centralized servers for user authentication and managing pseudonym IDs. If these centralized servers are compromised or fail, the authentication mechanism collapses. Moreover, it could become a bottleneck and cause a delay in user/IIoT device authentication.

Huang et al. (2024) proposed a decentralized identity management framework that incorporates NFTs and BC to mitigate the security, scalability, and reliability deficiencies of conventional centralized identity resolution systems. The NFT concept is used to bind the owner to its asset using BC. However, they have not discussed the transfer of ownership of an asset. Moreover, the identifier hash is used during authentication, which does not include user/IIoT device platform hash verification. In contrast, the proposed framework redirects the cross-domain user/IIoT device to its parent domain for identity and platform hash verification. We use NFTs to authorize a cross-domain user/IIoT device for an asset. A similar NFT-based authentication framework for metaverse environments is proposed in Khan et al. (2025). An NFT is used as the digital identity for the user. NFT metadata, i.e., the identity and rights, are recorded on BC. However, this study is focused on NFT-based user authentication in a single domain. This framework lacks platform hash verification and permission delegation. Moreover, Gross et al. (2025) proposed a decentralized biobanking framework that uses NFTs to manage, monitor, and share a patient’s 3D cellular tumor models used in cancer research. An NFT is used as a digital identity for the stakeholders and bio-asset digital twins. These NFTs are issued by biobank after offline credential verification. However, the user authentication is based on the NFT-based wallet. There is no multifactor authentication; if an attacker gains access to another user’s wallet, he/she obtains full access.

2.4 Our contributions

The following are the main contributions of this study.

• The proposed framework eliminates a single trusted authentication and authorization entity because it can collapse the entire IIoT environment.

• A smart contract developed in Hyperledger Fabric is used to authenticate users/IIoT devices from their parent domain.

• The user/IIoT device authentication is enhanced with verification from the manufacturer to prevent insider threats from accessing the DT.

• NFT-based role and permission delegation is used to authorize cross-domain users/IIoT devices for a DT with the least privileges.

3 Overview of the proposed framework

The proposed framework is a BC-based authentication and authorization system for cross-domain DT access in IIoT. It is a three-layer framework consisting of physical space (layer 1), blockchain (layer 2), and virtual space (layer 3).

• Virtual space: This layer consists of DTs for a variety of domains, such as smart cities, smart households, and smart industries. A DT is a virtual version of a real-world object or system that provides a detailed depiction of its features, behaviors, and interconnections. Moreover, the layer provides a storage facility for data related to DTs, i.e., sensor data and historical data, among others.

• Blockchain layer: This layer uses smart contracts to implement the authentication and authorization mechanisms for cross-domain communication among DTs. Moreover, the access control policies are maintained on the BC. These policies are used to implement access restrictions and data-sharing protocols. The proof-of-authenticity and integrity (PoAI) (Ali et al., 2020) mechanism uses these access policies to authenticate and authorize cross-DT accesses. Furthermore, this layer ensures security and integrity by recording all interactions among DTs using a distributed BC ledger.

• Physical space: The real world is represented by this layer, which is made up of different domains such as smart cities, smart households, and smart industries. Every domain has a unique collection of hardware and equipment. Information gathered in the real world by sensors and other devices is sent to the virtual space for processing and archiving.

3.1 Notations

Table 3 contains all the notations used in this article with descriptions.

Table 3

Table 3. Notations and their descriptions.

3.2 The proposed framework design

The proposed framework, as shown in Figure 1, is composed of six main entities, i.e., IIoT devices, BC network, smart contract, BC agent, DTs, and the trust registration authority (TRA).

Figure 1

Figure 1. High-level framework.

3.2.1 IIoT devices

IIoT devices are real-world entities with sensors, actuators, and networking technologies integrated into them to exchange, gather, and process data. IIoT is based on these devices, which link digital systems and physical resources. IIoT devices can include anything from basic pressure or temperature sensors to intricate machines with powerful processing capabilities. Due to BC scalability issues, IIoT devices do not communicate directly with BC in the proposed framework. They used BC agents to communicate with the BC. We assume that every IIoT device is equipped with a trusted platform module (TPM).

3.2.2 Blockchain network

Every domain is allowed to deploy one node to form a BC network. A smart contract is implemented in the BC network for cross-DT authentication and authorization. The BC stores cross-DT’s access control policies and user/IIoT device registration. Every domain has a local BC for its local user/IIoT device’s access control, while the global BC is used to regulate cross-domain access.

3.2.3 Smart contract

The proposed smart contract implements cross-DT authentication and authorization. The smart contract stores the access control policies.

3.2.4 Blockchain agent

In the proposed framework, the BC agent is a software module that serves as a mediator between IIoT devices and the BC network. It offers an abstract layer that makes interactions safer and more effective. Moreover, it is used to reduce network traffic by combining the data from different IIoT devices and improving data pre-processing locally.

The BC agent accepts requests from IIoT devices, performs pre-processing and data aggregation, and generates BC transactions. Subsequently, it forwards the transaction to the blockchain service module (BSM). Then, the BSM initiates the smart contract in the BC. The detailed steps in the BC agent are shown in Figure 2.

Figure 2

Figure 2. BC agent.

The BC transactions with their descriptions are provided in Table 4.

Table 4

Table 4. BC transactions.

3.2.5 Digital twins

The proposed framework consists of DTs that simulate real-time data to forecast failures, enhance decision-making, and optimize performance. The state transition diagram of the proposed DT is shown in Figure 3. The lifecycle of the DT begins when a new IIoT device is installed and its virtual replica is created. In the initial state, the DT is registered in the system, and a unique ID is assigned. The metadata, such as the device type, location, and expected behavior, are stored in the BC. At the operation state, the DT receives real-time data from the sensors and PLCs. It executes diagnostics, forecasts failures, and notifies the maintenance team. When the IIoT device requires service, the state transition diagram moves into a maintenance state. The digital replica is modified based on the new system configuration. If an IIoT device is replaced, then the old replica data are archived, and a new replica is created.

Figure 3

Figure 3. Digital-twin life cycle.

3.2.6 Trusted registration authority

The trusted registration authority (TRA) could be a certification authority or a manufacturer. Before deployment, the IIoT devices need to be registered with the TRA. The TRA generates long-term certificates (LTCs) for the IIoT device upon successful authentication and platform verification.

3.3 System operations

The proposed framework’s main procedures are provided below.

1. Domain registration.

2. User/IIoT device registration.

3. Cross-domain authentication.

4. Cross-domain permission/role delegation and authorization.

5. Access to DT.

3.3.1 Domain registration

The BC network is a virtual alliance of the issuing certificate authority (ICA) nodes, with each belonging to a different domain. A manager uses a BC agent to register their domain in the BC. Then, the BC agent runs a smart contract with a “T.register” transaction. The “T.register” transaction consists of a domain IP address, a long-term certificate signed by the root certificate authority (RCA), and a platform hash of an ICA node signed by the manufacturer. The ICA is registered in the virtual alliance if the manufacturer verifies its platform hash; otherwise, the registration request is rejected, as shown in Equation 1. After successful registration, the BC sends the smart contract ID to the manager.

$\begin{array}{c}\hfill Domai{n}_{\mathit{reg}}()=\left\{\begin{array}{c}\Vert I{P}_{a}ddress,LT{C}_{\mathit{RCA}}\left\{P{K}_{\mathit{UID}},\right.\hfill \\ P{H}_s,UID,Si{g}_M\left(UID,P{H}_s,\right.\hfill \\ \left.\left.Timestamp\right)\right\}if\hfill \\ \left(P{H}_c==P{H}_s\right)\hfill \\ \Vert Registrationunsuccessful\hfill \\ if\left(P{H}_c==P{H}_s\right)\hfill \end{array}\right\}\end{array}.(1)$

3.3.2 User/IIoT device registration

3.3.2.1 Key generation

The user/IIoT device having a unique device identifier (UID) generates public and private keys, i.e., $PK\text{\_}UI{D}_i,SK\text{\_}UI{D}_i$.

3.3.2.2 Certificate generation request

The IIoT device sends a registration request to the ICA. This request consists of the IIoT device public key, platform hash, UID, and signature of the manufacturer, as provided in Equation 2.

$CGR=\left\{P{K}_{UI{D}_i},P{H}_c,UI{D}_i,Si{g}_M\left(UI{D}_i,P{H}_s,Timestamp\right)\right\}.(2)$

3.3.2.3 Platform attestation from the manufacturer

The manufacturer generates a platform hash of the device’s software and hardware configuration and the UID during the manufacturing process. This UID and hash are used as the digital identification of the authenticity and integrity of the device. The ICA sends a platform attestation request to the manufacturer. The manufacturer returns the IIoT device’s stored platform hash if the signature is legitimate; if not, an error will be returned, as shown in Figure 4.

Figure 4

Figure 4. Platform attestation by manufacturer.

3.3.2.4 Certification generation by the ICA

After successful platform attestation from the manufacturer (PAM), the ICA smart contract calls CG () to compare the platform hash received in the registration request with the platform hash received from the manufacturer. The ICA confirms that the device is authentic and has not been tampered with if the two hashes match. This guarantees the device’s integrity and legitimacy. Subsequently, the ICA creates the IIoT device’s long-term certificate (LTC), as shown in Equation 3.

$\begin{array}{c}\hfill CG()=\left\{\begin{array}{c}\Vert LT{C}_{\mathit{ICA}}\left\{P{K}_{UI{D}_i},P{H}_s,UI{D}_i,\right.\hfill \\ Timestamp,Si{g}_M\left(UI{D}_i,P{H}_s,\right.\hfill \\ \left.\left.Timestamp\right)\right\}if\hfill \\ \left(P{H}_c==P{H}_s\right)\hfill \\ \Vert Registrationunsuccessful\hfill \\ if\left(P{H}_c==P{H}_s\right)\hfill \end{array}\right\}\end{array}.(3)$

The certificate includes information regarding the IIoT device public key, platform hash, and manufacturer certificate, as provided in Equation 4. Using the “T.register” transaction, the BC agent registers the IIoT device on the BC with this certificate.

$\begin{array}{c}\hfill LT{C}_{\mathit{ICA}}\left\{P{K}_{UI{D}_i},P{H}_s,UI{D}_i,Si{g}_M\left(UI{D}_i,\right.\right.\\ \hfill \left.\left.P{H}_s,Timestamp\right)\right\}\end{array}.(4)$

3.3.2.5 Role assignment

The administrator $(UI{D}_j)$ can assign an user/IIoT device $(UI{D}_i)$ to a role $(rol{e}_t)$, as shown in Equation 5.

$\begin{array}{c}\hfill UA=UA\cup \left(UI{D}_i,UI{D}_j,rol{e}_t\right)\end{array},(5)$

where U is a set of all the users/devices in the system, i.e., U = $\{UI{D}_i,UI{D}_j,UI{D}_k,\dots \dots .\}$.

3.3.3 Cross-domain authentication

The user/IIoT device sends an authentication request to the BC agent. The request’s parameters are provided in Equation 6.

$\begin{array}{c}\hfill P{K}_{\mathit{UID}},P{H}_s,UID,LT{C}_{\mathit{ICA}}\left\{P{K}_{\mathit{UID}},P{H}_s,UID,\right.\\ \hfill \left.Si{g}_M\left(UID,P{H}_s,Timestamp\right)\right\}\end{array}.(6)$

The BC agent initiates a “T.access” transaction and forwards it to the smart contract in the BC.

3.3.3.1 Request broadcast and the ICA’s responses

The smart contract redirects the user/IIoT device request to all ICAs for authentication, as shown in Figure 5. Each ICA tries to verify the user/IIoT device’s parameters in the broadcast by running the PoAI. However, only the user/IIoT device’s primary domain ICA can authenticate the user/IIoT device’s UID and retrieve its platform hash. The primary domain ICA uses the platform hash (PH) function provided in Equation 7. It provides an ICA-signed user’s device platform hash after verifying the user/IIoT device’s registration and ICA’s certificate.

$\begin{array}{c}\hfill PH\left(\right)=\left\{\begin{array}{c}\Vert Si{g}_{\mathit{ICA}}\left(P{H}_s,UID,timestamp\right)if\hfill \\ \left(UI{D}_i\in UA\right)AND\left[LT{C}_{\mathit{ICA}}\left\{ \right.\right.\hfill \\ P{K}_{UI{D}_i},P{H}_s,UI{D}_i,Timestamp,\hfill \\ \left.Si{g}_M\left(UI{D}_i,P{H}_s,Timestamp\right)\right\}\hfill \\ \left.==True\right]\hfill \\ \Vert errorunsuccessfuliferror\hfill \end{array}\right\}\end{array}.(7)$

Figure 5

Figure 5. Smart contract broadcast and ICAs’ responses.

3.3.3.2 Smart contract authentication

The smart contract verifies the ICA signature and the user/IIoT device’s platform hash. The smart contract confirms that the device is authentic and has not been tampered with if the two hashes match, as shown in Equation 8.

$\begin{array}{c}\hfill Authen\left(Si{g}_{\mathit{ICA}}\left(P{H}_s,UID,Role,timestamp\right)\right)\\ \hfill =\left\{\begin{array}{c}\Vert authenticatedif\left\{\left(PHr==PHs\right)AND\right.\hfill \\ VerifSig\left(Si{g}_{\mathit{ICA}}\right.\left\{P{H}_s,\right.\hfill \\ \left.\left.UID,Timestamp\right)==True\right\}\hfill \\ \Vert authenticationfailsiferror\hfill \end{array}\right\}\end{array}.(8)$

3.3.4 Cross-domain permission/role delegation and authorization

3.3.4.1 Role/permission delegation

The role/permission delegation is a procedure by which the owner authorizes a user/role to set a role/permission. The delegation policy consists of an owner $s_m$, a delegatee user $s_n$/role $r_p$, and a role $r_p$/permission $p_r$ as input, as shown in Equation 9. Here, permission is defined as a pair of (o, a), where o is an object and a is an action/set of actions. In simple words, permission means action on an object, whereas a role is a collection of permissions.

$\begin{array}{c}\hfill policy=\left\{s_m,r_p/p_r,s_n/p_r\right\}\end{array}.(9)$

We define four types of role/permission delegations: 1) role-to-user (RU) delegation, 2) role-to-role (RR) delegation, 3) permission-to-user (PU) delegation, and 4) permission-to-role (PR) delegation, as shown in Table 5. The delegation function takes the owner $s_m$, delegatee user $s_n$, and role $r_p$ as the input. The owner delegates the role/permission to the user/role by adding it in RU, RR, PU, and PR, respectively. RU, RR, PU, and PR contain all the role-to-user, role-to-role, permission-to-user, and permission-to-role delegations in the systems.

Table 5

Table 5. Four different types of role/permission delegations.

3.3.4.2 Role/permission revocation

Similar to role/permission delegation, we have four different role/permission revocations.

3.3.4.2.1 Role-to-user revocation

In this type of revocation, the revoke () function takes owner $s_m$, delegatee user $s_n$, and role $r_p$ as the input, as shown in Equation 10. The owner revokes the role from the delegatee user by subtracting the role-to-user delegation in RU.

$\begin{array}{c}\hfill Delegate\left(s_m,r_p,s_n\right)=\left\{\overline{RU}=RU-\right.\\ \hfill \left.\left\{s_m{⇝}^{r_q}{s}_n\right\}\right\}\end{array}.(10)$

3.3.4.2.2 Role-to-role revocation

In this type of revocation, the owner revokes the role from the delegatee role by subtracting the role-to-role delegation in RU, as shown in Equation 11.

$\begin{array}{c}\hfill Delegate\left(s_m,r_p,r_n\right)=\left\{\overline{RRA}=RRA-\right.\\ \hfill \left.\left\{s_m{⇝}^{r_p}{r}_n\right\}\right\}\end{array}.(11)$

3.3.4.2.3 Permission-to-user revocation

In this type of revocation, the owner revokes the permission from the delegatee user by subtracting the permission-to-user delegation in PU, as shown in Equation 12.

$\begin{array}{c}\hfill Delegate\left(s_m,r_p,r_n\right)=\left\{\overline{PU}=PU-\right.\\ \hfill \left.\left\{s_m{⇝}^{p_q}{s}_n\right\}\right\}\end{array}.(12)$

3.3.4.2.4 Permission-to-role revocation

In this type of revocation, the owner $s_m$ revokes permission $P_r$ from the role $r_n$ by adding a permission-to-role delegation in the PR, as shown in Equation 13.

$\begin{array}{c}\hfill Delegate\left(s_m,r_p,r_n\right)=\left\{\overline{PR}=PR-\right.\\ \hfill \left.\left\{s_m{⇝}^{p_q}{r}_n\right\}\right\}\end{array}.(13)$

3.3.4.3 Role activation and permission activation

The user/IIoT device activates the role/permission before using it. The user $s_n$ activates the role $r_p$ or permission $p_r$ by adding a role activation (RA) or permission activation (PA) into RA or PA, respectively, as shown in Equation 14.

$\begin{array}{c}\hfill activate\left(s_m,r_p,s_n\right)=\left\{\overline{RA}=RA+\left\{s_n\gg r_p\right\}\right\}\\ \hfill activate\left(s_m,p_r,s_n\right)=\left\{\overline{PA}=PA+\left\{s_n\gg p_r\right\}\right\}\end{array}.(14)$

3.3.4.4 NFT token creation

The proposed framework uses an NFT for permission delegation. Each NFT consists of a token ID, permission role, expiration time, and signature. Unlike current systems, NFT-based permission/role delegation helps assign more granular, auditable permissions on a resource.

Algorithm 1.NFT token creation.

1: Input: T. create ($s_m$, $s_n$, and $r_p$/$p_r$)

2: Output: $\{s_m{⇝}^{p_q}{s}_n\}$ or error

3: if $\{Authen(Si{g}_{\mathit{ICA}}(P{H}_s,UID,Role,timestamp))==true\}$ then

4: Set Token ID

5: Set Time interval (T1, T2), i.e., Start Time (T1) and End Time (T2)

6: if $\left\{\{s_m{⇝}^{r_q}{s}_n\}\right.$ OR $\left.\{s_m{⇝}^{p_r}{s}_n\}\right\}$ then

7:  $Authorized(s_n)=\left\{r_q\right.$ or $\left.p_r\right\}$

8:  if $\left\{\{s_m{⇝}^{p_r}{s}_n\}\right.$ OR $\left.\{s_m{⇝}^{p_r}{r}_n\}\right\}$ then

9:   $Authorized(r_p)=\left\{r_q\right.$ or $\left.p_r\right\}$

10:  end if

11: end if

12: else

13: return error

14: end if

The proposed smart contract consists of four main modules, namely, the authorization module, authentication module, permission delegation module, and NFT module, as shown in Figure 6. The NFT module generates an authorization token when the user/IIoT device is authenticated successfully and a delegation policy exists on the BC, as shown in Algorithm 1. The following are the steps in NFT token creation.

• The user/IIoT device requests an NFT authorization token from the “authorization module.”

• Upon receipt of the request, the “authorization module” sends an authentication query to the “authentication module” to validate the requesting user/IIoT device.

• Upon successful authentication, the “authorization module” asks the “permission delegation module” to verify and obtain the relevant delegated access rights.

• Based on the validated permissions, the “NFT module” generates an NFT-based authorization token that encompasses the authenticated access rights.

Figure 6

Figure 6. NFT authorization token creation.

3.3.4.5 NFT token revocation

NFT token revocation is accomplished through the revocation of permission or role delegation. The $D$ set stores all the roles and permissions delegations. The NFT token revocation is provided in Equation 15.

$\begin{array}{c}\hfill \bar{D}=D-\left\{\left\{s_m{⇝}^{r_q}{s}_n\right\}\cup \left\{s_m{⇝}^{r_q}{r}_n\right\}\cup \left\{s_m{⇝}^{p_r}{s}_n\right\}\cup \left\{s_m{⇝}^{p_r}{r}_n\right\}\right\}\end{array}.(15)$

3.4 Access to the digital twin

A user/IIoT device can access the DT by using a validated NFT token. The smart contract allows the user/IIoT device to activate the delegated permission/roles required for accessing the DT.

Algorithm 2.Allowing access based on the NFT token.

1: Input: $UID,PHs,Role,LT{C}_{\mathit{ICA}}$

2: Output: $Si{g}_{\mathit{ICA}}${ $P{H}_s$, UID, Timestamp} or error

3: if {$Authen(Si{g}_{\mathit{ICA}}(P{H}_s,UID,Role,timestamp))==true$} AND $\{TI{D}_i\in TID\}$ AND $\{t_1\le t_i\le t_2\}$ then

4: $\overline{PA}$ = $PA$ + $\{s_n\gg p_n\}$

5: $\overline{RA}$ = $RA$ + $\{s_n\gg r_n\}$

6: else

7: return error

8: end if

4 Compatible use case and security analysis

In this section, we illustrate the proposed framework using a practical use case, and the security analysis is performed using the Dolev–Yao security model.

4.1 Compatible use case

We assume the case of a manufacturing industry that produces things using a group of industrial robots. The industry depends on the operations of these robots, and downtime can have a significant effect on revenue. Therefore, the industry has acquired predictive maintenance as a service (PdMaas) from a maintenance company. We assume that PdMaas monitors the robot’s performance in real time and forecasts the risks of failure. Similarly, when it detects a risk of failure, it sends a notification with recommended actions to the maintenance team. However, for accurate forecasting, the PdMaas providers need access to the robot’s DT deployed on the BC. Therefore, an authentication and authorization framework is proposed to verify the PdMaas provider’s identity and assign them the least privileges to access the data. The data access mechanism for the PdMaas provider is provided in Figure 7. The data access steps are provided below.

1. A user/IIoT device belonging to the PdMaas provider sends an access request to the BC agent. Then, the agent initiates a “T.access” transaction.

2. The agent submits a “T.access”” transaction to the smart contract for user/IIoT device authentication and authorization.

3. The smart contract redirects the PdMaas domain’s user/IIoT device UID and platform hash to all the ICAs in the BC network for authentication. Every ICA is a representative of a different IIoT domain. Upon receiving the broadcast, every ICA strives to search the platform hash for the requesting user/IIoT device using the PoAI in its local database.

4. The platform hash is only known to the PdMaas provider domain because it has registered the user/IIoT device. The ICA returns the platform hash to the smart contract.

5. The smart contract compares the hash obtained from the PdMaas provider domain with the hash obtained in the user/IIoT device’s request. If both the hashes are identical, then the smart contract fetches access control policies from BC and generates an authorization NFT for the user/IIoT device.

6. The smart contract forwards the NFT to the BC agent.

7. Then, the BC agent forwards the NFT token to the user/IIoT device.

8. The user/IIoT device is allowed to access the DT.

Figure 7

Figure 7. Use case

4.2 Security analysis

The Dolev–Yao model is used to analyze the security of the proposed framework. We define two types of attackers: external attackers and insider attackers. External attackers can intercept, change, replay, and insert messages in the proposed framework. Insider attackers are legitimate users/IIoT devices. The insider threat can submit false transactions, colluding with external attackers. The BC network is divided into trusted components, such as the BC layer, smart contract, and cryptographic hashing function, and untrusted components, such as communication channels and user/IIoT devices. We assume that every IIoT device is equipped with TPM to calculate the platform hash.

4.2.1 Message confidentiality

According to the Dolev–Yao model, an attacker can decrypt a message. However, the proposed framework uses public key cryptography to enable secure communication among BC nodes (ICAs), BC agents, and users/devices.

4.2.2 Message integrity

According to the Dolev–Yao model, an attacker can modify data/transactions in transit and storage. Hence, the proposed framework used the SHA-256 hashing function and BC ledger to protect data/transactions.

4.2.3 Authentication and authorization

In the Dolev–Yao model, the attacker can impersonate any users/devices. Therefore, the proposed framework used multifactor authentication, i.e., identities and platform hash. Moreover, the proposed framework validates the user/IIoT device identity and platform hash from their parent domain, thus eliminating the risk of impersonation. Similarly, the authorization mechanism generates an NFT token after validating the access control policies stored in BC. An NFT token encodes the role or permission of the owner. The smart contract validates the NFT token against the access control policies, thus preventing the risk of impersonation attacks.

4.2.4 Non-repudiation

We assume that the attacker can repudiate his actions. Therefore, in the proposed framework, every transaction is digitally signed using the private key of the sender.

4.2.5 Replay attacks

According to the Dolev–Yao model, attackers can capture the message and replay it later. The proposed framework timestamps every transaction to prevent replay attacks, while the smart contract checks transaction validity.

4.2.6 DoS/DDoS

Suppose an insider attacker installs malware in an IIoT device. Subsequently, the attacker initiates a DoS/DDoS attack on the IIoT devices in the network by exploiting the victim IIoT device. So, the attacker sends a “T.access” transaction to the BC. However, the proposed framework does not allow this transaction because the victim IIoT device’s current platform hash has changed.

5 Implementation details

The proposed framework is implemented in Hyperledger Fabric. Hyperledger is preferred over other platforms because it is an open-source and permissioned BC. Due to its design, it is favorable for a controlled and secure environment, such as IIoT. Moreover, it utilizes a channel design to establish private sub-networks, thus guaranteeing that sensitive data are accessible only to authorized individuals. Unlike public BCs, Hyperledger Fabric does not charge any transaction fees.

5.1 Network setup

Our implementation consists of three ICA nodes representing different manufacturing organizations, three endorsing peers, and one ordering node. These nodes are deployed in a virtual environment using an ESXi server. The BC network configuration is provided in Table 6.

Table 6

Table 6. Network configuration.

5.1.1 Chaincode

We developed two types of chaincodes in Node.js; i.e., the local and global chaincodes. Every manufacturing organization has a local chaincode. The local BC is used to register local users/devices after platform attestation from the manufacturer. The global chaincode implements user/IIoT device authentication, authorization, NFT token creation, and revocation.

5.1.2 Block design

We implement two MongoDB databases for the local and global chaincodes. Every manufacturing organization implements a MongoDB to store user registration. Similarly, the other MongoDB database is used to store access control policies and NFT tokens. User registration information is saved on the local chain, while access control policies and NFT tokens are saved on the global chain. Both chains have their genesis block, and every block has the hash value of the previous block, except for the genesis block. The proposed block designs of the local and global chains are shown in Figures 8, 9, respectively.

Figure 8

Figure 8. Block design for the local chain.

Figure 9

Figure 9. Block design for the global chain.

5.2 Performance evaluation and comparison

In this section, the response time analysis and overhead ratio analysis are discussed.

5.2.1 Response time analysis

The user index, cumulative distribution function (CDF), and success/failure are used to analyze the response time of the proposed framework.

5.2.1.1 Response time vs. user index analysis

The proposed framework response times are calculated for 1,000 user requests. The x-axis represents the user index, whereas the y-axis represents the response time in milliseconds, as shown in Figure 10. Most of the user request’s response time is approximately 300 ms, showing consistent and reliable throughput. However, some distributed spikes in response times are visible, which may occur due to system load or delays in reading from the distributed ledger.

Figure 10

Figure 10. Response time vs. user index analysis.

5.2.1.2 Response time vs. CDF with percentiles

The user/IIoT device access “T.access” contains two main tasks, i.e., user authentication and user authorization. Moreover, user/IIoT device authentication fetches the user’s device platform hash from the parent using the UID and compares the stored and received hashes. The CDF is used to measure the response time of the authentication mechanism for 1,000 users. Mathematically, CDF is expressed as shown in Equation 16.

$\begin{array}{c}\hfill F_X\left(x\right)={\displaystyle \sum _{x_i\le x}}P\left(X=x_i\right)\end{array},(16)$

where p (X = $x_i$) is the probability of X equal to $x_i$. The CDF provides the percentile analysis of the authentication mechanism response time, as shown in Figure 11. The response time ranges from 215 ms to 240 ms. The median response time is approximately equal to 215 ms. Moreover, 90$\%$ user’s requests have a response time of less than 255 ms.

Figure 11

Figure 11. Authentication mechanism response time analysis using CDF.

Similarly, CDF percentile analysis is used to analyze the authorization mechanism’s response time, as shown in Figure 12. The authorization process consists of access control policy validation and NFT creation. The response time ranges from 95 ms to 130 ms. The response time at the 50th percentile is approximately 95 ms. A 95$\%$ user/IIoT device experienced a response time of approximately 120 ms.

Figure 12

Figure 12. Authorization mechanism response time analysis using CDF.

5.2.2 Impact of the blockchain ledger size on the performance

The proposed framework’s main activities, i.e., authentication, policy fetching, and NFT creation, are evaluated with varying numbers of access control policies, i.e., 1, 50, 500, 2,000, 4,000, 6,000, 8,000, and 10,000, while using 1,000 user requests, as shown in Figure 13. The authentication line graph remains constant regardless of the number of access control policies. It shows that the authentication time is not dependent on the number of access control policies. However, the time required for policy retrieval from BC during the authorization process increases as the number of policies increases. A large number of policies results in an increase in the search time for a specific policy. Moreover, NFT creation is negligibly affected by the increasing number of policies.

Figure 13

Figure 13. Impact of the access control policies’ volume on the authentication, policy fetching, and NFT creation performance.

5.2.3 Latency analysis of the core processes

The authentication, policy fetching, and NFT creation processes are evaluated for latency with 1,000 concurrent user requests. The latency distribution shown in Figure 14 shows that the authentication process has a peak at 115 ms, indicating that a large number of requests have a latency equal to 115 ms. This shows an enhancement of nearly 67$\%$ in latency performance over the current framework (Huang et al., 2024), which is approximately 350 ms. It involves the matching of the current and stored hashes. Similarly, the policy fetching process peaks at 25 ms with a narrower spread in latency values. It indicates that most latencies lie between 20 ms and 30 ms. Moreover, the NFT creation process has a peak at 15 ms and the least spread in latency values. In conclusion, the authentication process has the highest latency and greatest variability, whereas the policy fetching process shows medium latency. Conversely, NFT creation processes are faster and more consistent than all other processes.

Figure 14

Figure 14. Latency analysis of the core processes.

5.3 Scalability analysis throughput

We analyze the proposed framework’s scalability using 50, 500, 2,000, 4,000, 6,000, 8,000, and 10,000 concurrent user requests while the total number of access control policies is 2,000 (constant). The proposed framework efficiently scales up to 6,000 user requests; however, there is a slight degradation in performance after 6,000 users, but it remains constant after 8,000 users. The scalability analysis is shown in Figure 15.

Figure 15

Figure 15. Scalability analysis throughput.

5.4 Comparisons among the existing and proposed frameworks

As shown in Table 7, traditional centralized access control mechanisms (Son et al., 2022; Shi et al., 2024; Chen et al., 2023) rely on a single access control entity, which is a single point of failure. Moreover, these centralized mechanisms are susceptible to different attacks, such as spoofing, DoS/DDoS, replay, and insider attacks. The proposed framework eliminates a centralized access control entity by integrating BC. Moreover, BC is resilient to various attack vectors due to public key cryptography and hashing mechanisms.

Table 7

Table 7. Comparisons among the proposed and existing frameworks.

Similarly, the existing decentralized access control mechanisms (Patel et al., 2024; Aggarwal et al., 2023; Gautam et al., 2024; Thakur et al., 2023; Jain et al., 2024) often lack robust platform verification and permission delegation functionalities, as shown in Table 7. The proposed framework implements platform verification from the manufacturer to enhance the authentication process. It ensures that the compromised devices are stopped from joining the BC network. Additionally, permission delegation provides more fine-grained access control. It implements the principle of least privilege by allowing only the minimum set of necessary permissions.

6 Conclusion

The integration of DTs with IIoT systems is one of the foundations of Industry 4.0, offering huge opportunities for improved productivity, advanced analytics, and fast decision-making. However, this integration leads to several security and privacy issues, especially in secure cross-domain collaboration, insider threats, and centralized trust. This study proposed a decentralized framework to resolve these issues by establishing a privacy-preserving and secure access control solution for cross-domain DT communication. By integrating BC technology, the proposed framework eliminates the centralized trust inherent in current mechanisms and embeds tamper-proof data integrity. The proposed framework provides an additional layer of security by including the IIoT device’s platform integrity from the manufacturer. Moreover, the proposed smart contract-based authentication and NFT-based authorization methods ensure fine-grained, auditable, and dynamic permission delegation. The NFT-based authorization method implemented the principle of least privilege. The proposed framework has attained an identity resolution latency of approximately 115 ms for 1,000 concurrent users, in contrast to 350 ms in the current framework, signifying an enhancement of nearly 67$\%$ in latency performance. Moreover, the Hyperledger Fabric implementation is evaluated thoroughly, and it performed well under load and scalability up to 6,000 concurrent users. The security analysis based on the Dolev–Yao security model verified its resilience against various attacks, such as replay, spoofing, and DoS/DDoS attacks.

6.1 Future directions

We will work on formal verification of the proposed framework’s capabilities using the SPIN model checker. We will investigate the applicability of the proposed framework in other IoT ecosystems, such as smart cities and healthcare. Furthermore, we will investigate the integration of threat intelligence with the BC to enable zero-day attack and advanced persistent threat detection, along with automated response through smart contracts.

Data availability statement

Publicly available datasets were analyzed in this study. These data can be found at: https://github.com/gali675/xDTBauth repository.

Author contributions

GA: Conceptualization, Formal Analysis, Methodology, Visualization, Writing – original draft, Writing – review and editing. SS: Visualization, Writing – review and editing. ME: Supervision, Writing – review and editing. NA: Formal Analysis, Writing – review and editing.

Funding

The authors declare that financial support was received for the research and/or publication of this article. This paper was supported by a research grant funded by Prince Sultan University, Kingdom of Saudi Arabia, through grant number SEED-CCIS-2024-168. In addition, the authors would like to acknowledge the support of Prince Sultan University for paying the article processing charges (APCs) of this publication.

Acknowledgments

The authors would like to acknowledge Prince Sultan University for their valuable support.

Conflict of interest

The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.

Generative AI statement

The authors declare that no Generative AI was used in the creation of this manuscript.

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher’s note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

References

Abanda, F., Jian, N., Adukpo, S., Tuhaise, V., and Manjia, M. (2024). Digital twin for product versus project lifecycles’ development in manufacturing and construction industries. J. Intelligent Manuf. 36, 1–31. doi:10.1007/s10845-023-02301-2

CrossRef Full Text | Google Scholar

Aggarwal, P., Narwal, B., Purohit, S., and Mohapatra, A. K. (2023). Bpadta: blockchain-based privacy-preserving authentication scheme for digital twin empowered aerospace industry. Comput. Electr. Eng. 111, 108889. doi:10.1016/j.compeleceng.2023.108889

CrossRef Full Text | Google Scholar

Al Zami, M. B., Shaon, S., Quy, V. K., and Nguyen, D. C. (2025). Digital twin in industries: a comprehensive survey. IEEE Access. doi:10.1109/ACCESS.2025.3551532

CrossRef Full Text | Google Scholar

Alcaraz, C., and Lopez, J. (2022). Digital twin: a comprehensive survey of security threats. IEEE Commun. Surv. and Tutorials 24, 1475–1503. doi:10.1109/comst.2022.3171465

CrossRef Full Text | Google Scholar

Ali, G., Ahmad, N., Cao, Y., Khan, S., Cruickshank, H., Qazi, E. A., et al. (2020). Xdbauth: blockchain based cross domain authentication and authorization framework for internet of things. IEEE Access 8, 58800–58816. doi:10.1109/access.2020.2982542

CrossRef Full Text | Google Scholar

Alshathri, S., Hemdan, E. E.-D., El-Shafai, W., and Sayed, A. (2023). Digital twin-based automated fault diagnosis in industrial iot applications. Comput. Mater. and Continua 75, 183–196. doi:10.32604/cmc.2023.034048

CrossRef Full Text | Google Scholar

Aveva (2025). Aveva. Available online at: https://www.aveva.com/en/solutions/digital-transformation/digital-twin/(Accessed March 15, 2025).

Google Scholar

Barricelli, B. R., Casiraghi, E., and Fogli, D. (2019). A survey on digital twin: definitions, characteristics, applications, and design implications. IEEE Access 7, 167653–167671. doi:10.1109/access.2019.2953499

CrossRef Full Text | Google Scholar

Botín-Sanabria, D. M., Mihaita, A.-S., Peimbert-García, R. E., Ramírez-Moreno, M. A., Ramírez-Mendoza, R. A., and Lozoya-Santos, J. d. J. (2022). Digital twin technology challenges and applications: a comprehensive review. Remote Sens. 14, 1335. doi:10.3390/rs14061335

CrossRef Full Text | Google Scholar

Buterin, V. (2014). A next-generation smart contract and decentralized application platform. White Pap. 3, 2–1. Available online at: https://scholar.google.com/scholar_lookup?title=A+next-generation+smart+contract+and+decentralized+application+platform&author=Buterin,+V.&publication_year=2014&journal=White+Pap.&volume=3&pages=2-1

Google Scholar

Chen, C.-M., Miao, Q., Kumar, S., and Wu, T.-Y. (2023). Privacy-preserving authentication scheme for digital twin-enabled autonomous vehicle environments. Trans. Emerg. Telecommun. Technol. 34, e4751. doi:10.1002/ett.4751

CrossRef Full Text | Google Scholar

Conti, M., Kumar, E. S., Lal, C., and Ruj, S. (2018). A survey on security and privacy issues of bitcoin. IEEE Commun. Surv. and Tutorials 20, 3416–3452. doi:10.1109/comst.2018.2842460

CrossRef Full Text | Google Scholar

Devi, A., Kumar, A., Rathee, G., and Saini, H. (2023). User authentication of industrial internet of things (iiot) through blockchain. Multimedia Tools Appl. 82, 19021–19039. doi:10.1007/s11042-022-14154-7

CrossRef Full Text | Google Scholar

Gartner (2019). Gartner top 10 strategic technology trends for 2019. Available online at: https://www.gartner.com/smarterwithgartner/gartner-top-10-strategic-technology-trends-for-2019 (Accessed February 10, 2025).

Google Scholar

Gautam, D., Thakur, G., Kumar, P., Das, A. K., and Park, Y. (2024). Blockchain assisted intra-twin and inter-twin authentication scheme for vehicular digital twin system. IEEE Trans. Intelligent Transp. Syst. 25, 15002–15015. doi:10.1109/tits.2024.3394438

CrossRef Full Text | Google Scholar

Glaessgen, E., and Stargel, D. (2012). “The digital twin paradigm for future nasa and us air force vehicles,” in 53rd AIAA/ASME/ASCE/AHS/ASC structures, structural dynamics and materials conference 20th AIAA/ASME/AHS adaptive structures conference 14th AIAA, Honolulu, Hawaii, 23 April 2012 - 26 April 2012, 1818.

Google Scholar

Hemdan, E. E.-D., El-Shafai, W., and Sayed, A. (2023). Integrating digital twins with iot-based blockchain: concept, architecture, challenges, and future scope. Wirel. Personal. Commun. 131, 2193–2216. doi:10.1007/s11277-023-10538-6

PubMed Abstract | CrossRef Full Text | Google Scholar

Hewa, T. M., Hu, Y., Liyanage, M., Kanhare, S. S., and Ylianttila, M. (2021). Survey on blockchain-based smart contracts: technical aspects and future research. IEEE Access 9, 87643–87662. doi:10.1109/access.2021.3068178

CrossRef Full Text | Google Scholar

Hu, T., and Li, B. (2025). Dynamic information utilization for securing ethereum smart contracts: a literature review. Inf. Softw. Technol. 182, 107719. doi:10.1016/j.infsof.2025.107719

CrossRef Full Text | Google Scholar

Huang, T., Xie, R., Ren, Y., Yu, F. R., Zou, Z., Han, L., et al. (2024). Dtais: distributed trusted active identity resolution systems for the industrial internet. Digital Commun. Netw. 10, 853–862. doi:10.1016/j.dcan.2023.06.006

CrossRef Full Text | Google Scholar

Jain, A., Garg, M., Gupta, A., Batra, S., and Narwal, B. (2024). Iomt-badt: a blockchain-envisioned secure architecture with a lightweight authentication scheme for the digital twin environment in the internet of medical things. J. Supercomput. 80, 16222–16253. doi:10.1007/s11227-024-06026-8

CrossRef Full Text | Google Scholar

Khan, W. Z., Siddiqa, A., Alanazi, F., and Khan, M. K. (2025). Nft-based digital identity authentication framework for the metaverse environments. IEEE Trans. Consumer Electron. 71, 5699–5707. doi:10.1109/tce.2025.3564849

CrossRef Full Text | Google Scholar

Laurence, T. (2023). Blockchain for dummies. John Wiley and Sons.

Google Scholar

Liu, S., Zheng, P., and Bao, J. (2024). Digital twin-based manufacturing system: a survey based on a novel reference model. J. Intelligent Manuf. 35, 2517–2546. doi:10.1007/s10845-023-02172-7

CrossRef Full Text | Google Scholar

Mihai, S., Yaqoob, M., Hung, D. V., Davis, W., Towakel, P., Raza, M., et al. (2022). Digital twins: a survey on enabling technologies, challenges, trends and future prospects. IEEE Commun. Surv. and Tutorials 24, 2255–2291. doi:10.1109/comst.2022.3208773

CrossRef Full Text | Google Scholar

Nakamoto, S. (2008). Bitcoin: a peer-to-peer electronic cash system.

Google Scholar

Nath, S. V., Van Schalkwyk, P., and Isaacs, D. (2021). Building industrial digital twins: design, develop, and deploy digital twin solutions for real-world industries using azure digital twins. Birmingham, United Kingdom: Packt Publishing Ltd.

Google Scholar

Novo, O. (2018). Blockchain meets iot: an architecture for scalable access management in iot. IEEE Internet Things J. 5, 1184–1195. doi:10.1109/jiot.2018.2812239

CrossRef Full Text | Google Scholar

Patel, C., Pasikhani, A., Gope, P., and Clark, J. (2024). User-empowered secure privacy-preserving authentication scheme for digital twin. Comput. and Secur. 140, 103793. doi:10.1016/j.cose.2024.103793

CrossRef Full Text | Google Scholar

Qi, Q., Tao, F., Hu, T., Anwer, N., Liu, A., Wei, Y., et al. (2021). Enabling technologies and tools for digital twin. J. Manuf. Syst. 58, 3–21. doi:10.1016/j.jmsy.2019.10.001

CrossRef Full Text | Google Scholar

Qian, C., Liu, X., Ripley, C., Qian, M., Liang, F., and Yu, W. (2022). Digital twin—cyber replica of physical things: architecture, applications and future research directions. Future Internet 14, 64. doi:10.3390/fi14020064

CrossRef Full Text | Google Scholar

Saba, T., Rehman, A., Haseeb, K., Bahaj, S. A., and Lloret, J. (2023). Trust-based decentralized blockchain system with machine learning using internet of agriculture things. Comput. Electr. Eng. 108, 108674. doi:10.1016/j.compeleceng.2023.108674

CrossRef Full Text | Google Scholar

Saraswathi, S. (2025). “Smartchain rbac: a lightweight role based access control protocol using private blockchain for smart cities,” in 2025 6th International Conference on Intelligent Communication Technologies and Virtual Mobile Networks (ICICV), Tirunelveli, India, 17-19 June 2025 (IEEE), 1662–1670.

CrossRef Full Text | Google Scholar

Sepasgozar, S. M. (2021). Differentiating digital twin from digital shadow: elucidating a paradigm shift to expedite a smart, sustainable built environment. Buildings 11, 151. doi:10.3390/buildings11040151

CrossRef Full Text | Google Scholar

Shi, Y., Xu, C., Zhang, Z., and Liu, X. (2024). “Ttsso: traceable threshold single-sign-on,” in 2024 9th International Symposium on Computer and Information Processing Technology (ISCIPT), Xi'an, China, 24-26 May 2024 (IEEE), 81–86.

CrossRef Full Text | Google Scholar

Siemens (2025). Siemens. Available online at: https://www.sw.siemens.com/en-US/technology/digital-twin/(Accessed March 15, 2025).

Google Scholar

Singh, M., Fuenmayor, E., Hinchy, E. P., Qiao, Y., Murray, N., and Devine, D. (2021). Digital twin: origin to future. Appl. Syst. Innov. 4, 36. doi:10.3390/asi4020036

CrossRef Full Text | Google Scholar

Son, S., Kwon, D., Lee, J., Yu, S., Jho, N.-S., and Park, Y. (2022). On the design of a privacy-preserving communication scheme for cloud-based digital twin environments using blockchain. IEEE Access 10, 75365–75375. doi:10.1109/access.2022.3191414

CrossRef Full Text | Google Scholar

Soori, M., Arezoo, B., and Dastres, R. (2023). Internet of things for smart factories in industry 4.0, a review. Internet Things Cyber-Physical Syst. 3, 192–204. doi:10.1016/j.iotcps.2023.04.006

CrossRef Full Text | Google Scholar

Szabo, N. (1997). Formalizing and securing relationships on public networks. Chicago, IL United States: University of Illinois Board of Trustees. doi:10.5210/fm.v2i9.548

CrossRef Full Text | Google Scholar

Tang, Z., Zhuang, D., and Zhang, J. (2025). Evaluation framework for domain-specific digital twin platforms. Sci. Rep. 15, 10544. doi:10.1038/s41598-024-82154-8

PubMed Abstract | CrossRef Full Text | Google Scholar

Tao, F., Sui, F., Liu, A., Qi, Q., Zhang, M., Song, B., et al. (2019). Digital twin-driven product design framework. Int. J. Prod. Res. 57, 3935–3953. doi:10.1080/00207543.2018.1443229

CrossRef Full Text | Google Scholar

Thakur, G., Kumar, P., Deepika, Jangirala, S., Das, A. K., and Park, Y. (2023). An effective privacy-preserving blockchain-assisted security protocol for cloud-based digital twin environment. IEEE Access 11, 26877–26892. doi:10.1109/access.2023.3249116

CrossRef Full Text | Google Scholar

Yang, L., Hou, Q., Zhu, X., Lu, Y., and Xu, L. D. (2025). Potential of large language models in blockchain-based supply chain finance. Enterp. Inf. Syst. 19, 2541199. doi:10.1080/17517575.2025.2541199

CrossRef Full Text | Google Scholar

Zhang, H., and Lu, Y. (2025). Web 3.0: applications, opportunities and challenges in the next internet generation. Syst. Res. Behav. Sci. 42, 996–1015. doi:10.1002/sres.3151

CrossRef Full Text | Google Scholar