# How to Lock an Ignition Project After Deployment to a Client?

**URL:** <https://forum.inductiveautomation.com/t/how-to-lock-an-ignition-project-after-deployment-to-a-client/116147>\
**Category:** Ignition\
**Created:** [June 25, 2026, 9:24am UTC](https://forum.inductiveautomation.com/t/how-to-lock-an-ignition-project-after-deployment-to-a-client/116147 "2026-06-25T09:24:05Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Farheen\_Qureshi](https://avatars.discourse-cdn.com/v4/letter/f/7ba0ec/32.png) [@Farheen\_Qureshi](https://forum.inductiveautomation.com/u/Farheen_Qureshi)\
**Post date:** [June 25, 2026, 9:24am UTC](https://forum.inductiveautomation.com/t/how-to-lock-an-ignition-project-after-deployment-to-a-client/116147/1 "2026-06-25T09:24:05Z")

</div>

Hi Team,

> We develop and deploy Ignition projects for our clients. After the project is deployed at the client's site, we would like to prevent unauthorized modifications to the project.
> 
> What is the recommended way to lock or secure an Ignition project so that:
> 
> 1. Operators can use the application normally.
> 2. Client users cannot open the Designer and modify project resources.
> 3. Project source code, scripts, and configurations remain protected.
> 4. Only our team can make future changes and updates.
> 
> Are there any best practices regarding:
> 
> - Designer access restrictions
> - User roles and permissions
> - Gateway security settings
> - Project inheritance/protected projects
> - Backup and restore protection
> - Licensing considerations
> 
> We are looking for the best approach when deploying projects to customer sites.
> 
> Thanks.

---

<div class="post-metadata">

**Author:** ![David\_Stone](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/david_stone/32/79749_2.png) [@David\_Stone](https://forum.inductiveautomation.com/u/David_Stone)\
**Post date:** [June 25, 2026, 10:44am UTC](https://forum.inductiveautomation.com/t/how-to-lock-an-ignition-project-after-deployment-to-a-client/116147/2 "2026-06-25T10:44:58Z")

</div>

The best approach is not to lock the project down, the customer paid for it, the customer needs it and if you lock them out you're disadvantaging them. Get them to pay you for the IP you are developing, grant them a perpetual license to that IP, explain that any warranty is void if they modify it, and let them develop their own solutions on the servers alongside yours. Get them to pay you for support when they need help working with it.

I have many times unlocked servers of all types where customers have paid for the development time and IP and the integrator has tried to lock them out to extract more money or lock themselves in as exclusive. It guaranteed the integrator was on a blacklist permanently from that point onward.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [June 25, 2026, 12:10pm UTC](https://forum.inductiveautomation.com/t/how-to-lock-an-ignition-project-after-deployment-to-a-client/116147/3 "2026-06-25T12:10:58Z")

</div>

You cannot.

For more details, see this topic:

> [@Best practice to prevent to stolen ignition resources](https://forum.inductiveautomation.com/t/best-practice-to-prevent-to-stolen-ignition-resources/44344):
>
> Hi, As system integrator, there are some cases that I like to protect my resources in ignition after delivering project to client. For example creating a library that use resources like python lib and views,… In other SCADA packages I can put password and encrypted the resource. The resource can be used by system but can’t modify by others unless they know password. The protect option in ignition doesn’t work because when other can access to gateway config they can change the role and passwo…

In general, the most protection you can get is to make a 3rd party module with the SDK to encapsulate the most critical functionality as scripting or expression functions or custom UI components.

---

<div class="post-metadata">

**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\
**Post date:** [June 25, 2026, 1:17pm UTC](https://forum.inductiveautomation.com/t/how-to-lock-an-ignition-project-after-deployment-to-a-client/116147/4 "2026-06-25T13:17:35Z")

</div>

> [@Farheen\_Qureshi](#):
>
> After the project is deployed at the client's site, we would like to prevent unauthorized modifications to the project

You SHOULD restrict access to only authorized users. A user account or group (within chosen IdP) should be created for administrative access to the system.

> [@Farheen\_Qureshi](#):
>
> 1. Only our team can make future changes and updates.

This should be at the direction of your customer. They should ultimately have the keys to manage access, including the ability to restrict / remove your access.

---

<div class="post-metadata">

**Author:** ![Farheen\_Qureshi](https://avatars.discourse-cdn.com/v4/letter/f/7ba0ec/32.png) [@Farheen\_Qureshi](https://forum.inductiveautomation.com/u/Farheen_Qureshi)\
**Post date:** [June 26, 2026, 6:33am UTC](https://forum.inductiveautomation.com/t/how-to-lock-an-ignition-project-after-deployment-to-a-client/116147/5 "2026-06-26T06:33:57Z")

</div>

but we wanted to restrict the project edit mode for client

---

<div class="post-metadata">

**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\
**Post date:** [June 26, 2026, 7:22am UTC](https://forum.inductiveautomation.com/t/how-to-lock-an-ignition-project-after-deployment-to-a-client/116147/6 "2026-06-26T07:22:31Z")

</div>

You can restrict their users to disallow access to the designer and web portal config but it's only a façade; a weak barrier to access. Anyone with access to the server Ignition is running on or its file system can easily take a "backup" of the Ignition gateway files and restore it wherever they want to. It really depends the question you're asking and the security you're after whether what you're asking is possible or not.

Here's how to prevent unauthorised access to the Gateway web portal pages and the Designer (taking into account what I said above):

> **[Roles and Permissions​ - Gateway General Security Settings | Ignition User...](https://docs.inductiveautomation.com/docs/8.3/platform/security/gateway-general-security-settings#roles-and-permissions)**
>
> This page determines security permissions for the Gateway and Designer.

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/9/b93bbf6b0fd80a3fd0501e5f6593a5872364a1bb.png)

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/4/6/46986fb6a6155e920778dac285b9d191a7e4b94d.png)
