Why Does Ignition EAM Get Access Denied Editing Edge Tags?

Where does the EAM tag push stop?

Start with the request path. The EAM controller gateway builds the tag or UDT payload and sends it over the gateway network to the Edge agent gateway. On arrival, the Edge gateway assigns the connection to a security zone. It then checks the Service Security policy for that zone against the target tag provider. The write lands in the provider only if that policy allows edits.

The error below means the packet reached the Edge gateway and was rejected by the final gate:

Ignition-edge1-poc-ot-uk: Failed: Attempt 1: Access Denied. Remote tag editing is not allowed for tag provider 'edge' in the calculated zone.

The Edge gateway identified the controller, computed a zone, looked up the edge provider's tag access level for that zone, and found either Read Only or Read/Write. Pushing tag definitions or UDTs is a configuration edit. It is not a value write, so it needs Read/Write/Edit. A stock install with no user security configured does not change this outcome. Service Security is a gateway-to-gateway control and is separate from user or role authentication.

Check: confirm the error names the agent gateway and the edge provider. If it does, the transport works and the fix is in Service Security.

Is the gateway network link actually up?

Check layer one first, even when the error points at security. A connection that flaps or sits unapproved produces intermittent results. Those results can hide whether a policy change took effect.

1. On the EAM controller, open the gateway network status and confirm the outgoing connection to the Edge agent shows as running.
2. On the Edge gateway, confirm the incoming connection from the controller is approved and running.
3. Confirm the gateway names on both sides are unique. Duplicate names break zone matching and agent identification.
4. If the link uses SSL, confirm both gateways have accepted each other's certificates.

Check: the controller lists the agent as connected and healthy in the EAM agent status. A simple read-only task, such as retrieving agent status, completes without error.

Which security zone does the Edge gateway calculate for the controller?

The Edge gateway compares each incoming gateway network connection against the Security Zones list. Zones can match on gateway name, IP address, or host name. They are evaluated in the order listed, and the first match wins. A connection that matches no zone falls into the Default zone. That zone assignment is the "calculated zone" in the error text.

This matters for the fix. If you raise tag access on the wrong zone, the error does not change.

1. On the Edge gateway, open Config > Security > Security Zones.
2. Read each zone's identification criteria, in order. Look for the controller's gateway name, its IP address, or its host name.
3. If no zone matches the controller, the connection is in the Default zone.
4. Watch for NAT, proxies, or multiple NICs on the controller. The source IP that the Edge gateway sees may differ from the controller's configured address.

Check: write down the single zone that the controller connection resolves to before you touch any policy.

How do I grant Read/Write/Edit on the edge provider?

Service Security holds a policy for each zone. Inside each policy, tag access is set per tag provider. There are three levels:

EAM tag and UDT deployment needs the bottom row.

1. On the Edge gateway, not the controller, open Config > Security > Service Security.
2. Edit the policy for the zone identified in the previous section.
3. Under the tag access settings, find the edge provider. If the zone uses a single default access level for all providers, set that level or add an explicit entry for edge.
4. Set access to Read/Write/Edit and save.

Check: reopen the policy and confirm that edge shows Read/Write/Edit under the correct zone. This change applies to new requests and needs no gateway restart.

How do I avoid opening edit rights to every gateway?

The quick fix is to raise the Default zone to Read/Write/Edit. That works, but it gives tag-edit rights to any gateway that connects and matches no other zone. On a network with several agents, plus any peer or rogue gateway that can reach the port, that is too broad for a production Edge node.

1. On the Edge gateway, create a dedicated security zone for the EAM controller. Identify it by gateway name, IP, or host name.
2. Move that zone above any broader zone in the priority list so it matches first.
3. In Service Security, give only this zone Read/Write/Edit on edge. Leave Default at Read Only, or at whatever your site standard requires.
4. Repeat this on every Edge agent that receives EAM tag deployments. The setting is local to each agent.

Check: from a gateway that belongs in the Default zone, if one is available, a tag-edit attempt is still denied. The controller's own attempt succeeds.

How do I verify the UDT push end to end?

1. Re-run the EAM task that sends the UDT to the agent. Previous failed attempts will not retry against the new policy on their own.
2. Confirm the task result reports success for the agent, with no Attempt failure line.
3. On the Edge gateway, open the Tag Browser for the edge provider. Confirm the UDT definition sits under Data Types and any instances appear where expected.
4. Open one instance and confirm its parameters and member tags match the controller-side definition.
5. Confirm member tags show good quality, which proves the pushed definition resolved against the Edge device connections.

FAQ