Inductive Automation Ignition SCADA Security Guide: Gateway, Roles and Tokens

Ignition gateways are web servers that sit between operators, engineers and the process, and many of their security controls ship open by default. An empty permissions field means public access, the Gateway Network trusts its peers through zones you define, and API keys in Ignition 8.3 reach the whole HTTP API. This guide walks through how authentication, roles, security levels, security zones, service security, API keys, secrets and audit profiles actually work in Ignition 8.1 and 8.3, and turns them into a hardening baseline. It is written for OT engineers, SCADA administrators and the security teams that review their gateways. For the wider OT programme see the OT Security Guide, which this page does not repeat.

Key takeaways

• Empty means public. The Gateway Config, Status and Home Page permission fields, plus Designer and Create Project permissions under the Identity Provider strategy, grant unrestricted access when left empty, so set every one explicitly.
• Two authentication strategies, two control models. The Classic strategy uses user sources and roles; the Identity Provider strategy uses OpenID Connect, SAML or Ignition's internal IdP with security levels, and that is where MFA and single sign-on come from.
• Security zones control places, not people. Zones group gateways, hosts and IP ranges, and Service Security policies on each zone decide what remote gateways can read, write, acknowledge or store.
• API keys in 8.3 are powerful machine credentials. They are Basic Tokens sent in the X-Ignition-API-Token header, shown once and hashed, with no expiry described in the documentation, so you must rotate and inventory them yourself.
• Auditing is off until you turn it on. You must create an audit profile, assign it as the Gateway Audit Profile, enable auditing per project, and switch on pruning deliberately, then forward the records to your SOC.

How identity and access work in Ignition

Ignition separates who a user is (authentication) from what they may do (roles or security levels) and where a connection comes from (security zones). The two authentication strategies behave differently and the choice drives most later decisions.

• System Identity Provider: chosen in Config, Security, General. It controls access to the gateway web configuration and to the Designer when the Designer Authentication Strategy is Identity Provider. An option forces re-authentication at the IdP, which effectively disables single sign-on for those sessions.
• Classic user source behaviour: the Schedule Restricted property limits logins to a user's assigned schedule, useful for shift-based operator accounts. The Failover Source (None by default) can be Hard, used only when the primary is unreachable, or Soft, used when credentials fail. Soft failover means a password rejected by Active Directory can still succeed against a local store, which is rarely what an auditor expects.
• Federating to the enterprise: pointing the System Identity Provider at your corporate OIDC or SAML IdP gives you MFA, joiner-mover-leaver automation and central session revocation. Keep a tested break-glass path, because the IdP becomes a dependency for engineering access. See the OT and ICS Identity and Access Guide for where an OT identity boundary should sit.
• Ignition as IdP: Ignition can act as an identity provider for isolated systems that cannot reach the enterprise IdP, which is common below the industrial DMZ.

Admin roles and privileged access

Ignition has no single built-in "administrator" switch. Privilege is the sum of the permission fields in Gateway General Security Settings, project security in the Designer, per-tag security and the user management options. Map each to a named role or security level and keep the population small.

• All or at least one: each permission field lets you require all listed security levels or any one of them. Requiring an "Administrator" level plus an "MFA" level, both mapped from IdP claims, is a simple way to enforce MFA for configuration access.
• Separate engineering from operating: operators use Perspective or Vision; engineers use the Designer; gateway administrators change the gateway. Do not let one shared account cover all three. Shared "admin" logins are the most common finding on integrator-built gateways, and they defeat the audit log.
• Privileged access path: reach the gateway configuration through a jump host or remote access broker in the industrial DMZ rather than from the corporate network. See the OT Remote Access Guide.

Integrations, API tokens and service accounts

Ignition is an integration hub: it talks to PLCs, databases, other gateways, MQTT brokers, historians and enterprise systems. Each link is a non-human identity with a credential that needs an owner.

API keys (Ignition 8.3)

• What they are: created under Platform, Security, API Keys as a Basic Token, the only type available. The key is sent in the X-Ignition-API-Token header and is required for routes such as /data/api/v1/resources, /data/api/v1/sync and /data/api/v1/modes and for the routes in the gateway's /openapi documentation.
• Scope: the documentation cautions that keys grant full access to the gateway's HTTP API routes. Every key carries the Authenticated security level, which cannot be removed; add further levels only where they are needed.
• Lifecycle: the gateway hashes the key and shows it only once. No expiry is described, so set a rotation interval in your own process, store the value in a vault, and use Disable (temporary) or Delete (immediate, irreversible revocation) when a consumer is retired.
• Transport: "Require secure connections" is on by default for API keys; keep it on so tokens never cross the network in clear text.

Secrets and stored credentials

• Embedded versus referenced: database, device and profile passwords can be embedded (encrypted with the gateway's keys, but decrypted at runtime and visible to privileged users) or referenced from a Secret Provider in 8.3.
• Secret Provider types: Internal (gateway-managed encrypted files referenced by name), Remote (another gateway's provider over the Gateway Network, added in 8.3.3, denied by default until the zone's Secret Provider Access allows it) and File (cleartext or ciphertext files on disk, added in 8.3.5). There is no native HashiCorp Vault connector; the documentation describes mounting external secrets to disk, for example in Kubernetes, and reading them with the File provider.
• Database and directory accounts: the SQL account behind a Database user source or audit profile, and the bind account behind an Active Directory user source, should be dedicated, least-privilege and listed in your service account inventory. See the Service Account Security Guide and the API Key Management Guide.

Gateway Network trust

• Transport and port: gateway-to-gateway traffic uses port 8060 by default. Require SSL defaults to true for incoming connections; Require Two Way Auth adds mutual certificate trust.
• Connection Policy: ApprovedOnly is the default (new connections cannot exchange data until approved); Unrestricted accepts any incoming gateway; SpecifiedList allows named gateways only. Allow Incoming Connections defaults to true; untick it on gateways that should only dial out.
• Service Security policies: per zone you can Deny a service outright or set alarm journal, audit log and history provider access (Inherited, No Access, Query Only, Query and Storage), alarm acknowledge and shelving, notification pipelines, and tag access (ReadWriteEdit, ReadWrite, ReadOnly, None, Inherited). Writes from remote gateways run as the Impersonation Role Name unless Trust Remote Security Levels is ticked.

Logging and detection

Ignition's audit system records actions such as tag writes and user source authentication into an audit profile. Three profile types exist: Database (external SQL, default table AUDIT_EVENTS, Auto Create available), Internal (on the gateway, viewable only from the Status page) and Remote (forwarded to another gateway, with Use Store and Forward enabled by default).

1. Create a Database profile so records leave the gateway and can be queried by your SIEM connector.
2. Assign the Gateway Audit Profile in Config, Security, General for gateway-scoped events.
3. Enable Auditing per project in the Designer under Project, Properties, General and choose the profile.
4. Set retention on purpose: Retention defaults to 90 days, but on Database profiles Pruning Enabled defaults to false, so nothing is pruned until you enable it. Size the database or ship records out before pruning.
5. Use the API key audit trail: mutative API calls (POST, PUT, DELETE) are logged with user, IP address and key; GET requests are not, so watch read volume at the network layer.

Pair gateway logs with passive monitoring of the conduits around the gateway. See the OT Network Security Monitoring Guide.

Hardening baseline

Inductive Automation publishes an Ignition Security Hardening Guide on its trust portal; use it as the vendor baseline and the settings below as the identity and network core. Roll changes out in this order:

1. Inventory: list every gateway, version (8.1 or 8.3), module, user source, IdP, API key, database connection and Gateway Network peer. Record the owner of each credential.
2. Encrypt transport: install a trusted certificate, enable HTTPS (commonly on 8043) and turn on Force Secure Redirect, which is disabled by default. Use the Excluded Cipher Suites list to remove weak suites. Enable Use Proxy Forwarded Headers only behind a trusted reverse proxy.
3. Close public access: fill every permission field, set User Inactivity Timeout, leave Allow User Admin false, and remove default or shared accounts.
4. Federate: move gateway and Designer access to the Identity Provider strategy backed by an MFA-capable IdP; set a non-zero auth token Time-To-Live.
5. Zone the network: define security zones by IP, host name and gateway name, use the Require Secure Connection and Direct Connection Required qualifiers, and give the Default zone the least access. Keep Connection Policy at ApprovedOnly.
6. Constrain services: set conservative defaults (Query Only or No Access) for history providers and audit logs, ReadOnly or None for tag providers, and never leave the default access profiles as Inherited.
7. Move secrets: in 8.3, replace embedded passwords with referenced secrets and review who can read the decrypted values.
8. Turn on audit and test: confirm events arrive in the SIEM, then run a tabletop for a stolen engineer credential.

Testing and rollback: make each change on a staging or redundant backup gateway first, take a gateway backup before you change security settings, and change one control at a time during a maintenance window. Security zones are referenced by name inside projects, so renaming a zone silently breaks those references; rename only with a project search first. Keep a local administrator path (Ignition's internal IdP or an internal user source) sealed for break-glass in case the IdP or certificate change fails, and restore from the backup if operators lose access.

Small site versus multi-site estates

• Single plant, one gateway: an Active Directory-Internal Hybrid user source with Hard failover and strict permission fields is a reasonable start; add an IdP when MFA becomes a requirement.
• Hub-and-spoke or enterprise estates: standardise on the Identity Provider strategy, a zone and Service Security template per site class, a central Database audit profile, and Remote secret providers only where the zone explicitly permits them. Treat the central gateway as a high-value conduit in your zones and conduits design.

Common misconfigurations

• Empty permission fields: Gateway Config or Designer permissions left empty after commissioning, so anyone who can reach the web port can change the gateway.
• Gateway exposed to the internet: the HTTP or HTTPS port published directly for convenience. Internet Accessible Device (T0883) is a standing initial access route in ICS; publish only through a remote access broker.
• Unrestricted Gateway Network: Connection Policy switched to Unrestricted during commissioning and never reverted, combined with a Default zone that allows ReadWrite tags.
• Soft failover to a local store: Failover Mode set to Soft, so a disabled directory account can still log in with a stale local password.
• Immortal sessions and keys: User Inactivity Timeout or auth token TTL at zero, and 8.3 API keys created by integrators with no owner or rotation.
• Audit profile never assigned, or pruning never enabled: either no records exist when an incident happens, or the database fills and stops accepting them.
• Unpatched runtime: the trust portal publishes advisories, including Java runtime advisories and upgrade recommendations; feed them into the ICS Advisory Triage and OT Vulnerability Management Guide process.

Framework mapping

In IEC 62443 terms the gateway is usually a component in a supervisory zone, and Gateway Network links are conduits; see the IEC 62443 Guide.

Practitioner checklist

• Every gateway, version, module and Gateway Network peer is inventoried with an owner.
• Gateway Config, Status, Home, Designer and Create Project permissions are set; none is empty.
• Gateway and Designer access use an MFA-capable IdP, with a sealed break-glass account tested quarterly.
• HTTPS is enforced with Force Secure Redirect, weak cipher suites excluded, and no gateway port is reachable from the internet.
• Connection Policy is ApprovedOnly, Require SSL is on, and each zone has an explicit Service Security policy with no Inherited defaults.
• Every 8.3 API key has an owner, minimal security levels, a vault entry and a rotation date.
• Embedded passwords are migrated to referenced secrets where 8.3 allows it, and service accounts are least privilege.
• Gateway and project auditing write to a Database profile, pruning is deliberate, and records reach the SIEM.
• Advisories from the vendor trust portal are triaged against your installed versions.

Standards and references

• Inductive Automation: Gateway General Security Settings (Ignition 8.1)
• Inductive Automation: Service Security (Ignition 8.1)
• Inductive Automation: Security Zones (Ignition 8.1)
• Inductive Automation: API Keys (Ignition 8.3)
• Inductive Automation: Secrets Management (Ignition 8.3)
• Inductive Automation: Audit Log and Profiles (Ignition 8.1)
• Inductive Automation: Trust Portal and Ignition Security Hardening Guide
• MITRE ATT&CK: Internet Accessible Device

Related NHI Mgmt Group resources: OT Security Guide · OT and ICS Identity and Access Guide · OPC UA Security Guide · OT Remote Access Guide · Secrets Management Guide