1. Introduction
Design and Manufacturing workflows are increasingly digital. Computer Aided Design (CAD) tools support designers in defining their product and Computer Aided Manufacturing (CAM) tools support process selection and tool path planning. Application Programming Interfaces (APIs) between software and manufacturing machines enable the Digital Thread where Design IP is transferred, transformed and translated into code that can be interpreted by a manufacturing machine to produce the design. Additive Manufacturing (AM) design workflows are some of the most prevalent, advanced and complete digital workflows where designers can wholly design and commit their designs to production entirely in the digital space. CAD models are typically exported as Stereolithography (STL) files and imported into a slicing program to produce G-Code that can be submitted to AM machines (Figure 1) (Reference Kim, Witherell, Lipman and FengKim et al., 2015).
The digitalisation of Design & Manufacture (D&M) workflows has also created the opportunity for increased collaboration with stakeholders across the supply chain with each managing different elements of the D&M workflow. For example, a simulation company could be collaborating to support the verification of a design, and the manufacturing process optimisation could be handled by the manufacturer. While the enhanced collaboration can reduce the knowledge and skills requirement of a single company, the transfer of data across these workflows exposes individual designers and design firms to cyber-attacks that could steal IP, eavesdrop on activities, disrupt activities and hold firm’s hostage (Reference Gupta, Tiwari, Bukkapatnam and KarriGupta et al., 2020; Reference Mahesh, Tiwari, Jin, Kumar, Reddy, Bukkapatanam, Gupta and KarriMahesh et al., 2021; Reference Prinsloo, Sinha and von SolmsPrinsloo et al., 2019).
Centralised open repositories, such as Thingiverse and GrabCAD, have enabled new global communities of makers. However, their ability to manage and control IP on behalf of the users submitted designs is limited (Reference Felton, Schiffmann, Goudswaard, Gopsill, Snider, Real, McClenaghan and HicksFelton et al., 2023). The maintainers of these repositories and anyone downloading the models can freely analyse and copy with limited to no traceability for the original designer. Centralised repositories do exist where individuals may purchase the rights to download and use a model but they also offer little traceability of how the model is used by the individual once it has been downloaded. The intention may have been to use it for a single print but there is often no guards to prevent repeated manufacturing or sharing of the downloaded model due, in part, to the model being delivered in plain-text STL and/or gcode format.
AM digital thread (from Reference Kim, Witherell, Lipman and FengKime et al., 2015)
Figure 1 Long description
A diagram of the digital thread in additive manufacturing workflows. The diagram is divided into eight phases, each representing a stage in the process: Part geometry/conceptual design, Raw/tessellated data, Tessellated 3D model, Build file, Machine data, Fabricated part, Finished part, and Validated part. Each phase contains various types of information and activities. Phase 1 includes geometry information, other attributes information, material information, machine information, and design requirements. Phase 2 involves tessellated data and point cloud data. Phase 3 includes tessellated model and optimized 3D model for general AM. Phase 4 involves sliced 2.5D for general AM and optimally sliced data for specific machines. Phase 5 includes processing data for specific materials and information for AM process. Phase 6 involves information for post-process. Phase 7 includes information for part qualification. The supporting infrastructure includes data generation, activities for AM process, AM machine/material, test method, tessellation, 3D model editing, machine code generator, and post-process.
Exposing Design IP to any third-party requires design firms to trust that the third party is holding, managing and utilising their data appropriately. Data communicated across the internet is often secured through HTTPS where data is encrypted through SSL/TLS between source and destination. However, many internal networks and API’s on 3D printers use HTTP which provides no such guarantees (Reference Do, Martini and ChooDo et al., 2016; Reference McCormack, Chandrasekaran, Liu, Yu, DeVincent Wolf and SekarMcCormack et al., 2020; Reference Moore, Armstrong, McDonald and YampolskiyMoore et al., 2016). This exposes the data to eavesdropping during transfer as it transmitted in plaintext. Once the data has been sent to the manufacturer for the purposes of manufacturing a job, there is little to no visibility for the design rights holder in how that firm is securing and managing the Design IP they have shared. Equally, there is no means of ensuring the data is used only for the number of components that have been requested and whether it is deleted after the fact. Currently, design firms can only say that once their Design IP has been released to a third party that there is a chance that the third party may be retaining their IP and using it for purposes beyond that of the original intent.
In summary, many current D&M workflows provide a broad attack surface for cyber-attacks that are out of the control of the organisations and design teams who own the IP.
-
1. Design teams commonly provide Design IP in plain-text open formats to Third Parties.
-
2. There is little to no traceability of how Design IP has been used once released.
-
3. Design teams have to trust third party IT infrastructures is secure.
-
4. APIs to AM are often HTTP exposing data to man-in-the-middle eavesdropping attacks.
The emergence of Web3.0 technologies, such as Blockchain, decentralised identifiers and verifiable credentials provide a means of created decentralised trusted privacy preserving networks where work can be issued and the lifecycle of IP can be managed and traced (Reference Cao, Xiao, Shi, Wang, Chen, Wang, Ling, Xu, Zhang and LiuCao et al., 2025; Reference Vayadande, Baviskar, Avhad, Bahadkar, Bhalerao and ChimkarVayadande et al., 2024).
While they do not prevent bad actors in a network, they can provide the traceability to determine where a break in trust occurred that can then be pursued if required. The contribution of this paper is in developing and exploring a concept of how Web3.0 technologies could be used to protect Design IP in an AM D&M workflow.
The paper continues with a description some of the key components of a Web3.0 and how Web3.0 is being used in different sectors to secure work (Section 2). It then provides a narrative on the thought exercise that has been conducted to conceptualise the deployment of a trust network for AM machines within a lab setting (Section 3). Section 4 then details how a break in trust is handled by the network to showcase the traceability that is present. The lessons learned and research questions that it has exposed are then discussed (Section 5). The paper then concludes with key findings (Section 6).
2. Web3.0 trust
Web3.0 is viewed as the third revolution in the world-wide-web. Web1.0 was the creation of centralised static content that individuals around the world could access. Web2.0 was the revolution towards information-centric, interactive and social media platforms. Web3.0 goes further to become user-centric and the move aware from centralised trust governed by individual firms/bodies and a move to decentralised private and secure models. This section summaries the some of the key Web3.0 technologies as reported in reviews by Reference Guan, Ding and GuoGuan et al. (2022, Reference Guan, Ding, Guo and Teng2023), Reference Hossain Faruk, Raya, Siam, Cheng, Shahriar, Cuzzocrea and BringasHossain Faruk et al. (2024), and Reference Vayadande, Baviskar, Avhad, Bahadkar, Bhalerao and ChimkarVayadande et al. (2024) to provide the background necessary to reason how these technologies could be used to support the protection of Design IP.
2.1. Technologies
Imagine there exist a set of actors (e.g., firms, individuals, and machines) who wish to communicate with one another. They need the ability to trust that the actors they are communicating with are who they say they are and that the data that are about to share will be used for it intended purpose. These communications need to be private and any work contracted needs to be recorded for provenance. The actors do not want to use a centralised third-party system that could store their private information, have the potential to eavesdrop on conversation and/or be a single point of failure.
Web3.0 offers a de-centralised trust mechanism to achieve these goals where the following technologies are combined:
-
• Trusted Repositories
-
• Private Digital Wallet/Key Management Stores
-
• Decentralised Identifiers
-
• End-to-End Encryption
-
• Verifiable Credentials and Zero-Knowledge Proofs
-
• Smart Contracts
A Trusted Repository provides security, provenance preservation and tamper-proof guarantees to the data that is stored within it. Blockchains are the most prevalent and common implementation of a trusted repository. There decentralised structure and consensus methods ensure no single point of control or governance and the cryptographic dependency between blocks on the chain ensure immutability over the stored content. It ensures that the data stored within the chain has originated from the author who intended to add it to the chain. This is central to the building of trust between actors in a digital environment and is often used to store the Decentralised Identifiers, Verifiable Credentials and Smart Credentials of and pertaining to the actors within a network.
Digital Wallet and Key Value Management Stores store and maintain the privacy of the private keys that actors will use to digitally sign and encrypt data that originates from them. These keys are an actors digital identify and must remain secure and private as access to them can enable others to imitate another actor on the network. A private-public key pair generated by the actors in the network are used to sign and end-to-end encrypt credentials, messages and smart contracts that can then be submitted to trusted repositories for provenance preservation.
Actors expose their identity through Decentralised Identifiers (DIDs) that can contain metadata describing the actor along with their public key that others can use to verify the signatures of digitally signed data. The DID is signed by the actor and then submitted to the trusted repository. Other actors can then access the blockchain to view this data, which gives an indication of who that actor may be. However, it does not provide proof that this actor says who they say they are and this is where the issuing of Verifiable Credential comes into play.
Verifiable Credentials are digitally signed records by one or more actors that encode some information about another actor(s) in the network. For example, an actor “trusts” another actor is who they say they are or they confirm they have a certificate that has been issued by them. Challenge-Response mechanisms are typically employed when actors are in initial discussions to build the trust required to issue such credentials. The credentials can be kept private or made public where other actors can view and use them as a means of checking and assigning trust to other actors in the network.
Actors can use these credentials as a means to broker work and communications. For example, the credentials could be queried to suggest who should receive requests for work and these can be end-to-end encrypted so actors know that the recipient of the message is the only one who can decrypt the contents. The encrypted negotiations can be performed through decentralised peer-to-peer or centralised pub-sub mechanisms. No matter how the message is transmitted, it can only be decoded by the owner of the DID the message was intended for. Negotiations can then lead to the issuing of Smart Contracts that encapsulates that a package of work that has been brokered. Smart contracts are used to digitally represent the terms and conditions and who is able to digitally sign and/or provide evidence that they have been met. The smart contracts are updated by the actors as the work is completed and as the criteria are met subsequent actions can be taken, often automatically, such as the transfer of funds.
Table 1 summarises these key technologies and the roles they play in achieving trust.
Summary of the technologies used to build Web3.0 trust
2.2. Applications
Supply chains are exploring Web3.0 solutions for record keeping across the product’s lifecycle, from raw material sourcing to manufacturing, shipping, and retail in order to produce Digital Product Passports (Reference Huang, Huang, Heide, Huang, Parisi, Tan, Ma and ZhangHuang et al., 2024; Reference Mulani, Nandgaonkar, Mulla, Sonavane, Borate and MaliMulani et al., 2024; Reference Petrik, Dzierzawa and WarthmannPetrik et al., 2025). Web3.0 provides an immutable and transparent ledger that all authorized participants can access, significantly enhancing trust among stakeholders. Example use cases include consumers being able to verify the ethical sourcing of goods, and companies can identifying and addressing counterfeiting or quality control issues. The increased transparency builds consumer confidence and improves overall supply chain efficiency.
Financial services have also been exploring Web3.0 trust technologies (Reference Auer, Haslhofer, Kitzler, Saggese and VictorAuer et al., 2024; Reference Meyer, Welpe and SandnerMeyer et al., 2022). Decentralized finance (DeFi) platforms are creating new avenues for lending, borrowing, trading, and asset management without the need for traditional banks or brokers. Smart contracts, self-executing agreements with the terms directly written into code, automate financial processes, reducing costs and increasing efficiency. Web3.0 has demonstrated enhanced security and transparency for cross-border payments, asset tokenization, and identity verification.
Healthcare are trialling Web3.0 for secure and immutable records of patient medical histories, prescriptions, and treatment plans (Reference Anand, Ahmad and GhoshAnand et al., 2024; Reference Ghosh, Lavanya, Hassija, Chamola and El SaddikGhosh et al., 2024). This allows for better interoperability between healthcare providers, giving authorized personnel access to accurate and up-to-date patient information while maintaining patient privacy. Traceability of pharmaceuticals, preventing counterfeit drugs from entering the supply chain and ensuring drug authenticity is also enhanced.
Decentralized Identifier (DID) based solutions have also been applied to identity management (Reference Nita and MihailescuNita & Mihailescu, 2024; Reference Sehgal, Sharma, Shukla, Singh and SharmaSehgal & Sharma, 2026). The decentralisation of identity is often referred to as “self-sovereign identity” and allows users to selectively disclose aspects of their identity as needed. This enhances privacy and reduces the risk of identity theft. For instance, a user could prove their age without revealing their birthdate, or verify their professional qualifications without sharing their entire resume. This shift towards user-controlled identity may create a more secure, private, and trustworthy experience in physical and digital interactions.
These applications show the potential of Web3.0 and was the justification for it exploring it as an avenue to secure design IP.
3. Buidling a proof-of-concept Web3.0 trust network for an AM D&M lab
The following section reports the progress in developing a Web3.0 trusted network for a set of AM machines in a University Lab setting. This was performed through a series of workshops and brainstorming sessions within our research team as well as building the software stack to realise it. The objectives were to identify the minimum viable trust network that enables individuals to submit jobs to machines in the lab. The team has captured the challenges that need to be considered when deploying the system in reality.
Figure 2 presents a pictorial view of the minimal trust network which features two types of actor – Individuals and Machines – and the five steps to building trust and the ability for Individuals to issue jobs to Machines on the network.
-
1. Generating Identities.
-
2. Issuing Credentials to build trust.
-
3. Permitting a job to be submitted.
-
4. Firmware Verification to trust what the machine will do with the data.
-
5. Issuing of Smart Contracts for agreed work.
-
6. Sending the Job (Design IP).
3.1. Generating identities
Individuals represent the stakeholders who have some interest in the Machines. For example, a student wishing the manufacture one of their designs and a technician who maintains the Machines. They would interface with the network via app with a Command Line Interface, Terminal User Interface and Webapp being explored. The app would enable them to create their own public-private key pairs that they would use within the network. The individuals would need to keep these secure and private using a HSM (e.g., YubiKey). The app would request the keys when an Individual wanted to interact with the network. The creation of the keys would also a create a DID that would be submitted to the trusted repository. This gives them their identity on the network (1).
A minimal trust network consisting five steps to build the trust required to submit a job
The AM machines in the lab require adaption to include a Hardware Unique Key (HUK) and/or make use of their microcontroller’s TrustZone to provides them with immutable private-public keys that the microcontroller can use to sign data it provides to the network. A custom firmware is in development to provide the necessary interactions with network, such as enabling the machine to issue it’s DID to the trusted repository as well as report its API endpoint for receiving E2EE communications. On boot, the machine would attempt to connect to the network and check whether its DID exists in the trusted repository. If not, it would submit to the repository thereby offering ups its identity so others can identify it in the network (1).
3.2. Issuing credentials to build trust
he actors are now identifiable on the network through their DIDs stored in a trusted repository (1). The webapp would then provide a means for actors to query the actors listed in the trusted repository and enable actors to issue verifiable credentials to one another. There are no limits on the type or number of credentials that could be issued. For the minimal viable trust case in issuing jobs to machines and contextual awareness, four credentials were proposed (Table 2).
The majority of credentials issued require signatures from two actors for it to be valid in the network but Name and Status were considered assertion proofs that could be signed by more than one other DID beside the DID owner that it originated from. ‘Challenge-response’ mechanisms to be used between Individuals would be for them to physically meet and talk with one another where they could confirm their DIDs in the presence of one another. The Machine firmware would feature a challenge-response mechanism for individuals wishing to create a ‘Maintains’ credential with a unique code being displayed on the screen of the printer that would need to be copied and sent back to the machine via the API to confirm the actor is in the presence of the machine.
Credentials proposed for minimal viable trust
3.3. Permitting a job to be submitted
Machines would permit jobs submitted by individuals if the following conditions were met:
-
• There exists a PermittedToPrintOn between the Individual and Machine.
-
• The PermittedToPrintOn was issued by an Individual with a Maintains credential issued by the Machine.
End-to-end encryption technologies secure communications between the Individual and Machine using their private-public key pairs to create a shared key for encryption/decryption. The machine would also provide details of where to find them (i.e., API endpoint address) via the network. In a real-world scenario, an Individual might reach out to a few machines in order to broker a deal following agent-based brokering paradigms (see, for example, Reference Gopsill, Goudswaard, Giunta, Snider and HicksGopsill et al., 2023; Reference Neu, Hicks and GopsillNeu et al., 2023). In this minimal case, the Individual would query for the availability of Machine and if available, would submit a job to Machine.
3.4. Firmware verification to trust what the machine will do with the data
The issuing of DIDs and verifiable credentials have built a network of trust that enables Individuals to submit jobs to Machines if the aforementioned credentials are met. The cryptographic keys also provide end-to-end encryption of the data (e.g., Design IP) between actors in the network. However, there remains no guarantees as to what the Machine will do with the data once it has received it. Therefore, a mechanism is required so the Individual can verify what the Machine will do with the data. This was achieved through firmware verification.
Hashes of the firmware binary as released from an opensource repository (e.g., GitHub) could be used in this verification process. An Individual hash the hash with a nonce to create a unique hash that only the individual knows. The individual would then send a request to the machine that would create the hash of the running binary and have that hashed with the nonce provided by the Individual. This would be sent back to the Individual. If the hashes match then the Individual has confirmed the machine is running the firmware as described in the repository. They could then interrogate the online repository to check its integrity. For example, not sending, copying or storing it beyond its required life.
3.5. Issuing smart contracts for agreed work
Having confirmed they are happy that the Machine can receive their Design IP (gcode), the Individual forms a smart contract that is signed by both the Individual and Machine. The smart contract details the DIDs involved, a hash of the gcode file to be sent and flags that detail the receipt, commencement and status of the job.
3.6. Sending the Design IP
With the smart contract issued, the Individual would then encrypt the gcode so that only the machine (i.e., DID) it is intended for can decrypt it. A watermark could embedded within the component thereby making the gcode unique and Non-Destructive Testing (NDT) could be used to reveal in watermark inside to provide end-to-end traceability of the job (Reference Jiang, Wang, Sarsenbayeva, Irlitti, Knibbe, Dingler, Gonçalves and KostakosJiang et al., 2021; Reference Tiwari, Villasenor, Gupta, Reddy, Karri and BukkapatnamTiwari et al., 2021). A key outcome of this network is that the Design IP needs to only be sent once trust has been made. It is also encrypted so only the Machine where the designer is satisfied with the firmware and what it will do with the data.
4. Breaking trust
To investigate the architecture, the team performed a thought study to develop scenarios where threat actors might attempt to issue invalid credentials. The two primary workflow risks in the architecture were deemed:
-
1. an Individual sends Design IP (i.e., gcode) to an unintended Individual.
-
2. an Individual sending malicious code to a Machine that could damage it.
In 1, there is no need to send any Design IP until the point that a smart contract has been made with a Machine. Impersonating a Machine would need one to implement all the endpoints to interact and act as if they were a Machine on the network. They would then need another DID representing an individual to issue a verifiable credential indicating they Maintain the machine and then for that DID to issue a PermittedToPrintOn to the individual with their Design IP. At this point the Individual holding the Design IP would have to accept the impersoatores credential so they would have had to have physically met this Individual who was intending on subverting them, which provides traceability if the trust were to be broken. If they do accept the PermittedToPrintOn and elected to use it to print on a device emulating a Machine then they would need to emulate the nonced firmware hash.
In 2, the case of the Individual sending malicious code to a machine then, as long as they able to convince the owner of the DID whose has a Maintains credential to issue a PermittedToPrintOn credential then they will be unable to send a job to the Machine. And if they did send a malicious job then it could be immediately traced back to the DID and the maintainer would be able to refer back to who it as they should have recorded some details of that Individual during the issuing of the PermittedToPrintOn credential as well as the associated Smart Contract that would detail the consequences of sending a malicious job.
There is also no reason for allMachines to follow the same rules as outlined previously and for these rules to be made public. In a real-world scenario, it is likely that these checks and criteria would remain private to the owners of the Machines and thus make it much more difficult for a Individuals to identify the requirements to send manufacturing information to a Machine.
5. Discussion and reflection on the proof-of-concept
The proposed architecture is the beginning of a research journey into Web3.0 for Design & Manufacturing workflows. The exercise has revealed a fundamental change in how we form trust between actors in a D&M workflow. The architecture is being implemented within our lab where we will uncover the practical challenges using Web3.0 for D&M workflows. The team are also creating the numerical models to be able to test different sets of credentials and how they can aid in further securing and improving the traceability of Design IP.
Table 3 refers back to the threats identified in Section 1 and how they have been mitigated by the application of a Web3.0 trust model. The primary change is there is no longer a reliance on a Third Party. Design IPcan now be directly assigned and sent the Machine it is intended for. All traffic is encrypted by default and can only be decrypted by the intended recipient. Smart contracts provide the traceability of work conducted through the network. Removing the dependence on Third Party/centralised services also eliminated the overhead in storing potential terabytes worth of Design IP.
Reducing the threats to Design IP
Another insight is the development of trust is not through a series of admins managing a centralised third party service but the issuing of credentials between actors and querying these credentials and developing individuals rules that mean work can be done if these credentials exists. This affords much greater flexibility in how users can manage and perceive trust as they can develop their own rules for engagement rather than adhering to a pre-defined centralised set of rules.
The trust network enables the direct submission of work between an actor and a machine on the network. It also enables work to be negotiated directly between these actors. The end-to-end encryption and firmware verification steps ensure that the Design IP is sent securely to the machine, who is the only machine in the world that can decrypt the Design IP, and the firmware on the machine will only use the Design IP for its intended purpose. An actor submitting a job through a centralised AM farm is unable to have this degree of traceability. Once the job is submitted to the farm software, the job issuer is likely to have little oversight on how the Design IP was transferred from the cloud storage to the machine. Was it downloaded in plain-text? Submitted using a USB? Sent via an unencrypted internal LAN connection? These question do not exist in the Web3.0 solution.
The development of the minimal framework also revealed the potential interpretability of verifiable credentials. Credentials to enable individuals to confirm the status or if the DID were added to provide context to the network. If the individuals elected the make these credentials public then they could be used by humans to interpret and assume trust based on their existence. This could also be achieved through semantic reasoning for a machine. While the current workflow requires explicit credentials to be present, the addition of other credentials offers the opportunity for the machine to derive whether there is sufficient evidence to suggest an individual is permitted to use the machine.
6. Conclusion
This paper has contributed a minimal viable framework for securing Design IP between a design rights holders and maintainers of manufacturing machines in a University lab setting. We have demonstrated the design IP can be maintained securely and transmitted directly to where it is required in an encrypted manner reducing the impact of IP leakage. While the trust network does not eliminate the potential of misuse or foul-play by individuals within a network, it can be used to quickly identify where foul-play may have occurred and give evidence enough to follow-up through legal channels. Furthermore, the break in trust can be immediately communicated to others through the revocation of credentials resulting in immediate impact to an individual within the network. The paper outlines a series of research opportunities in the implementation and study for Web3.0 for securing Design IP. Utlising Web3.0 in Design & Manufacture workflows affords a Secure by Design approach to how we share our Design IP.
Acknowledgement
The work has been undertaken as part of a UKRI’s Innovation Launchpad Researcher-in-Residence Booster (EP/W037009/1) and Digital Design Network+ (UKRI394) awards.
Open access
