# Security Zones in Scale-Out Architecture

**URL:** <https://forum.inductiveautomation.com/t/security-zones-in-scale-out-architecture/105009>\
**Category:** Ignition\
**Tags:** perspective\
**Created:** [April 11, 2025, 5:18pm UTC](https://forum.inductiveautomation.com/t/security-zones-in-scale-out-architecture/105009 "2025-04-11T17:18:22Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![brian.mcenulty](https://avatars.discourse-cdn.com/v4/letter/b/b77776/32.png) [@brian.mcenulty](https://forum.inductiveautomation.com/u/brian.mcenulty)\
**Post date:** [April 11, 2025, 5:18pm UTC](https://forum.inductiveautomation.com/t/security-zones-in-scale-out-architecture/105009/1 "2025-04-11T17:18:22Z")

</div>

I'm working with a few gateways in a scale-out architecture. I'm trying to introduce security zones that would allow specific front-end clients (identified by either hostname or IP) to be given read/write access via a security zone. The default security zone is set up and has a "read-only" policy for all tag providers.

I've tried setting this security zone up on the back-end initially and tested by placing my own client in that security zone's config (by both hostname and IP). From the client, I'm unable to be placed into that security zone. The only way I could verify this was to momentarily update my Default security zone's policy to read/write for the tags which told me I was being placed in that default zone. I've also tried setting up the same zone on the front end, although I suspect it should reside on the back-end since the tags in that gateway are what the zone is being associated with.

Is there something I'm missing when setting up security zones in the scale-out architecture? Also, is there any way from a front-end client to identify which zones the client is being placed into on any back-ends?

---

<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:** [April 14, 2025, 3:43am UTC](https://forum.inductiveautomation.com/t/security-zones-in-scale-out-architecture/105009/2 "2025-04-14T03:43:12Z")

</div>

There are lots of contributing factors which might limit one's ability to write to tags.

If Gateway A is hosting tags to a remote provider configured in Gateway B, then Gateway A can be configured to **Trust Remote Security Levels** as issued to a client at login on Gateway B:  
From [Service Security](https://www.docs.inductiveautomation.com/docs/8.1/platform/security/service-security):

> As of 8.1.2, the Trust Remote Security Levels setting allows users to opt into trusting the Security Levels of remote Gateway users when remote Gateways read, write, and subscribe to local tags.

Despite this very-handy-feature, I'm always nervous using the option for security zones access... Consider the impacts of a client logging in to Gateway B and acquiring an IP-based role there, then being granted write capability on Gateway A, without actually matching the conditions required for the zone on Gateway A. Then again, perhaps that is your goal...

While you're looking at Service Security, check how the remote tag provider is configured for tag writes.

Finally, take advantage of [Test a Login](https://www.docs.inductiveautomation.com/docs/8.1/platform/security/identity-provider-authentication-strategy/test-login-and-logout#test-a-login) from your IdP. While session properties within a client can display the roles that a client is issued, the **Test Login** feature _can_ offer a little more insight as to 'why'.

From here, a bit more information might be necessary.