Ignition credentials belong in your secrets manager.

Every Ignition gateway I have commissioned held secrets. Database passwords. OPC accounts. Email credentials. API keys buried in gateway scripts. Encrypted or not, they lived inside the gateway, got copied into the next environment, and quietly outlived every rotation policy IT wrote down.

The same plants usually already run HashiCorp Vault, Azure Key Vault, AWS Secrets Manager or Google Secret Manager for everything else. Nobody needed another vault. They needed Ignition to talk to the one they had.

Mustry Secrets registers new provider types on Ignition 8.3’s own Secret Providers page. Named secrets resolve from your manager when something actually needs the value.

What breaks when the password lives in the gateway

Fine for one quiet gateway. Less fine once you have an estate, a compliance review, or a password that actually rotates.

• Rotation means editing every copy. Change the database password in Vault and you still visit every gateway that stored a local paste. Most teams postpone that visit. The old password stays live in a backup.
• Environments drift. Dev, test and production each get their own paste of the same secret. Or worse, the production password rides along in a project export.
• Audits get awkward. NIS2 and IEC 62443 conversations start with “who can read which credential, and when did it last rotate?” A password field on a connection page is a weak answer.
• Restarts become the rotation window. Anything that needs a gateway bounce to pick up a new secret becomes a maintenance event. Plants avoid those. Secrets go stale on purpose.

None of this is exotic. It is what happens when the platform stores secrets and IT stores secrets, and nobody wired the two together.

Native providers, same page

Ignition 8.3 already has Secret Providers. Database connections, OPC and email profiles, and system.secrets scripts can reference a named secret instead of holding the value. Built-in providers cover the internal and file cases. They do not speak Vault, Azure, AWS or Google.

The module adds those types under Platform → Security → Secret Providers. Configure a provider once. Point each connection at a secret name. The gateway resolves outbound when it needs the value. No inbound ports into the plant for the vault. No third-party jars stuffed into the .modl. Plain HTTP against the manager you already run, on the gateway’s own JSON stack.

Providers today:

• HashiCorp Vault. KV v2 and database-engine static roles, with token, AppRole or Kubernetes auth
• Azure Key Vault. Client secret or managed identity
• AWS Secrets Manager. Access key or EC2 instance role
• Google Secret Manager. Service account key or GCE/GKE metadata
• Cached provider. Wraps another provider for hub-and-spoke estates over the Gateway Network

Rotate without scheduling Saturday

Rotate the secret in the manager. The gateway picks it up on the next resolve. Database connections do not fault for a planned bounce. Nobody schedules Saturday night because a password aged out. That is usually the line that ends the meeting.

Caching with last-known-good fallback matters just as much on the floor. If Vault or Azure has a bad afternoon, the plant keeps running on the last good value, and every cached serve lands in the gateway audit trail. The opposite of a sidecar that fails closed and takes the line with it.

Licence behaviour is deliberate. On a lapse there is a 72-hour grace where cached values keep serving with explicit warnings, then reads fail loudly. A plant that thinks it still has credentials and does not is worse than one that knows.

Limits worth knowing

This is not a secrets manager. If you do not have one, pick Vault or your cloud vendor first. The module is the bridge.

It is not a policy engine either. Who may read which path, how often passwords rotate, and which namespaces belong to which plant still live in your manager. Ignition just stops being the place those policies go to die.

Gateway-scope for Ignition 8.3.3+. Edge only loads modules from Inductive’s fixed vendor list, so talk to us before you assume Edge is in scope. Hub-and-spoke over the Gateway Network is the usual pattern when edge sites should not each hold a vault token.

Where it sits

Same idea as MES, SCADA and historians answering different questions: secrets management is not a SCADA feature. It is infrastructure every connection and script depends on. When the password lives in IT’s manager, commissioning a new gateway stops meaning “paste the production password again.”

Mapping the rest of what we built for Ignition 8.3? Start from the modules overview. Secrets is usually the first one that shows up in a security review. €600 per gateway, perpetual, with Basic Care updates available yearly.