Configuring Ignition Project Security After Deployment

Ignition project security depends on administrative access control, not an irreversible project lock. Separate operator use from Designer and Gateway administration, give named accounts only the access required for each function, and place the customer in control of authorization. A user with sufficient Gateway configuration authority can change roles, reset credentials, alter project protections, restore a backup, or replace the project. Treat that authority as the security boundary.

Access-control ownership

The term authorized administrator here means a named user permitted by the customer to modify Gateway settings or project resources. The customer should retain the ability to approve, restrict, and remove every administrator, including the system integrator. Contractual ownership, access governance, and technical permissions must agree before commissioning.

Check 1: Review the customer-approved access register. Expect every operator, customer administrator, and integrator account to have a named owner and a defined purpose before configuring permissions.

Operator and administrator separation

Runtime authorization and engineering authorization are different controls. An operator may need to acknowledge alarms or issue process commands, but those duties do not require opening the Designer or changing Gateway configuration. Do not reuse an administrative account for routine operation.

1. Create or select the operator users or groups in the chosen identity provider.
2. Assign only the application permissions required for normal operation.
3. Create a separate administrative user or group for approved engineering work.
4. Remove Designer and Gateway administration privileges from ordinary client accounts.
5. Keep integrator credentials separate from customer administrator credentials so that either party’s access can be changed independently.

Role names and authorization rules depend on the deployed configuration; read the actual identity-provider and Gateway security settings rather than assuming that a role label grants a particular privilege.

Check 2: Sign in as a representative operator. Expect normal application use while Designer launch, project editing, and Gateway configuration changes remain unavailable.

Designer and Gateway restrictions

Designer restrictions reduce unauthorized editing only while Gateway administration remains controlled. A project password, protected-project setting, or role check cannot create an absolute boundary against a user who can administer the Gateway and rewrite the security configuration. Granting that level of access effectively grants control over the system’s authorization policy.

1. Restrict Designer access to the approved administrative group.
2. Restrict Gateway configuration access to a smaller customer-controlled administrative group where practical.
3. Use individual accounts rather than shared credentials so changes can be attributed and one person can be removed without rotating access for everyone.
4. Document how the customer authorizes integrator access for an update and how that access is removed afterward.
5. Test the restrictions with real non-administrative accounts; reviewing configuration alone does not prove enforcement.

Check 3: Attempt an engineering login with an ordinary client account. Expect authentication or authorization to stop access before any project resource can be saved. Repeat with an approved administrator and expect the authorized workflow to succeed.

Project protection and reusable intellectual property

Project inheritance and protected-project mechanisms can organize reusable resources and discourage routine editing, but they do not defeat an administrator who controls the Gateway. Use them as project-governance controls, not as a substitute for administrative security.

Where a deployment must conceal or constrain especially valuable algorithms, expression functions, scripting functions, or custom user-interface components, encapsulate that functionality in a third-party module built with the Ignition SDK. This moves critical implementation out of ordinary project resources and raises the engineering barrier to inspection or modification. It still does not give the integrator ownership of a customer-controlled Gateway or prevent an authorized owner from replacing or removing the module.

Check 4: Open the delivered project using the least-privileged engineering account selected for the test. Expect protected or encapsulated implementation to remain outside that account’s permitted editing path while the application continues to execute its required functions.

Backup and recovery control

A backup is a security-sensitive copy of the deployed system. If an unauthorized person can obtain and restore it into an environment they administer, front-end restrictions on the production system no longer provide the same boundary. Control backup creation, storage, transfer, restore authority, and retention through customer-approved procedures.

1. Assign custody of production backups to the customer or its designated administrator.
2. Limit backup and restore operations to approved administrative accounts.
3. Protect stored backup files with the organization’s access-control and retention system.
4. Record the approved baseline before commissioning and after each accepted update.
5. Test recovery under controlled conditions and confirm that restored identity and project settings match the approved baseline.

Licensing terms for integrator-developed intellectual property belong in the commercial agreement. State whether the customer receives ownership or a perpetual license, what modifications affect warranty or support, who may create derivative work, and how future maintenance access is approved. Technical lockout must not replace an explicit agreement.

Check 5: Review the recovery test record. Expect the restored project, identity configuration, administrative ownership, and access restrictions to match the accepted baseline.

End-to-end commissioning verification

1. Operator check: Sign in with an operator account. Expect normal runtime functions permitted by the application and no engineering access.
2. Unauthorized Designer check: Use a standard client account. Expect project editing to be denied.
3. Authorized maintenance check: Use a customer-approved engineering account. Expect only the intended Designer and configuration functions.
4. Integrator removal check: Disable or remove the integrator account through the customer-controlled process. Expect the integrator login to fail without affecting operators or customer administrators.
5. Change-control check: Apply an approved test change through the maintenance workflow, record it, and remove temporary access. Expect the accepted project revision to run while temporary privileges no longer work.
6. Recovery check: Restore the accepted baseline in the controlled recovery environment. Expect the same runtime behavior and access boundaries observed in the preceding checks.

Frequently asked questions