By Brett Stone
In the information technology field, we are all intimately familiar with Active Directory and the role it plays in our environment. It’s the workhorse for authentication, access controls, group policies, and administrative controls. Since it handles all these tasks so reliably on the enterprise side, it’s tempting to think you can just extend its domain to the operational technology (OT) environment or at the very least leverage the same architectural and administrative practices.
The reality is, while the technology may have a lot of crossover, business and operational environments have differing business objectives that should be considered.
OT technology and systems run the machines, applications, and processes that keep the plant running. Availability and predictability matter just as much as security. A failed login on a business network is an inconvenience, downtime on the shop floor could be a disaster. How you design identity in OT isn’t just a technical decision, it’s a risk management decision that directly affects operations.
The conversation shouldn’t simply be “Should Enterprise and OT share the same directory?” A better question would be: “What domain architecture actually best aligns with the organization’s operating model while appropriately mitigating risk?”
Same Technology, Different Priorities
From a technical angle, both Enterprise and OT domains use the same basic tools: domain controllers, group policies, security groups, service accounts, and centralized authentication. But the way they’re managed, and the reasons behind those choices, couldn’t be more different.
Business environments are designed around agility and accessibility. Changes are more frequent, outages do not usually affect business as a whole, and recovery time has acceptable tolerance. OT networks are designed around stability and control. Changes are painstakingly planned, outages are expensive in both time and money, and recovery speed is critical. Policies that make office workers more productive often introduce unacceptable risk for plant operations.
An additional layer of complexity in decision making is that organizations do not all operate the same way. Some are highly centralized with regional or even global services. Others have individual sites, each having local autonomy. Others are segmented by business unit, geographical boundary, or both. There is not one size that fits all or even a couple of best practice architectures to choose from for larger organizations. The approach to properly architecting an organizations OT domain(s) must account for risk and operational agility while appropriately accounting for level of centralization and site autonomy the business needs.
OT domain architecture is rarely a clear-cut decision. The right approach depends on how your organization is structured, how much risk you’re willing to accept, and how much operational control your sites need. Those answers look different for every business. OT network design has big implications down the road and can be time consuming (and expensive) to rearchitect later on. There’s not just one right answer in how you separate OT from the Enterprise network, and you want to make the right decisions for the business.
Identity Architecture Is Not One Way Or The Other
To simplify the concepts and to allow for some comparative analysis, let’s break it down into four conceptual tiers. These aren’t strict templates, just different ways of thinking about the tradeoffs:
Tier 1: Fully Shared Enterprise Identity: Fully Shared Enterprise Domain. Everything is centralized. The OT environment is just an extension of the business domain. The same directory serves both. This means the lowest effort and full alignment with Enterprise’s way of working, but OT shares the same fate as Enterprise. If Enterprise has a problem with an accidental policy roll-out or a compromise, operations may feel it too.
Tier 2: Separate OT Identity with Limited Enterprise Trust: The entire OT environment has its own directory with carefully controlled links to Enterprise, regardless of how many sites or regions exist. Usually, there’s a one-way trust: business users can get into OT resources if needed, but OT credentials and admin rights don’t spill back. The benefit? You get risk separation but with some ability to use central services. The cost is more infrastructure and the need for careful design and monitoring.
Tier 3: Central OT Services with Site-Level Separation: Each site operates as its own Active Directory domain, all joined under a single AD forest with the central OT domain as the forest root. This means that sites can be managed by services in the forest, while still maintaining autonomy to use site-specific management for GPOs, patching, DNS, etc.. Management becomes more complex, as you now have both forest admins as well as local domain admins. Separation of duties becomes a discussion that needs to be had.
Tier 4: Site-Autonomous OT: Every site runs its own show with an isolated domain setup. Trusts? Practically none. If connections between sites are needed, they’re handled through special tools or manual processes. The upside is tight local control and resilience. The challenge? High operating overhead, and management becomes difficult administratively and technically.
As stated previously these tiers are meant as guidelines to assist in decision making. A specific tier may be exactly what you are looking for, or a combination of tiers (hybrid) would better answer your needs. However you decide, serious thought needs to be given to trust models, site autonomy, and centralization. Decisions should be made based on these two questions. How much risk are we willing to accept, and how will we manage these risks?
Trust Models Matter
The fundamental difference in the tiers is all about trust – what gets shared, which way, and on what terms.
Two-way trusts: Both sides recognize each other’s users. If an Enterprise account gets breached, the attacker can target OT. Admin privileges can cross the line, depending on setup. This doubles the risk area. A compromise or misconfiguration in one domain can directly affect the other.
One-way trusts: Usually setup as OT to Enterprise. Business users can get into OT if needed, but OT admins can’t swing over to Enterprise. Permissions flow one way, reducing some risk. An Enterprise administrator does not automatically gain administrative reach into the OT domain. The direction of trust controls the direction of access.
No trust: Full separation. No automatic access, no accidental exposure. If you need to manage users between domains, you do it through jump servers or explicit provisioning. This maximizes containment at the cost of convenience.
Understanding why a trust exists is more important than how it is implemented. You don’t just pick a model for security reasons. You choose based on where you need to share identity and where containment is non-negotiable.
Why Separation Makes Sense
These tiers aren’t just about security; they reflect fundamentally different approaches to running Enterprise and OT.
As stated before, Enterprise is generally optimized for agility. OT is generally optimized for continuity. Those are both valid goals, but they are not the same goal. You can’t optimize for both using one architecture.
This tension is most visible at Tier 1. When OT lives inside a fully shared enterprise domain, it inherits the operating assumptions of the business network. That might mean aggressive Group Policy enforcement, broad administrative models, faster patch cycles, or service dependencies that make sense for office productivity but introduce unacceptable risk in a plant environment. OT systems do not get to opt out of enterprise changes, they absorb them.
Moving toward Tier 2 gives OT teams room to manage identity on operational terms. A separate OT domain means policies can be scoped to plant requirements, service accounts can be governed around maintenance windows and vendor constraints, and administrative access can be defined by operational role rather than inherited from the enterprise. Change in the business network no longer automatically becomes change in the operational environment.
At Tier 3 and Tier 4, that separation extends further. Sites or facilities gain the ability to contain incidents locally, operate independently during enterprise outages, and shape governance to their specific risk profile without waiting on central Enterprise timelines or inheriting enterprise assumptions that do not apply to their environment.
In other words, moving up the tiers is not just a cybersecurity decision. It is often a business continuity decision. The further OT identity is separated from the enterprise, the more control operational teams have over their own environment and the less exposure they carry from systems and processes that were never designed with plant operations in mind. That principle becomes especially important when the most process-critical systems in a facility are involved.
Some Things Must Remain Separate
The tiers described above address how organizations structure identity between Enterprise and OT at a broad level. But within OT itself, there is a further reality that no tier model fully eliminates: some systems will always require their own domain, regardless of how the surrounding architecture is designed. These are islands, environments where the case for isolation is so strong that integration with even a well-designed OT domain introduces unacceptable risk.
Distributed Control Systems (DCS): Vendors like Honeywell or Emerson often provide their own preconfigured Active Directory, tightly scoped for that system. They’re not built for broad OT integration, and trying to force them in can break important safeguards. Only connect a DCS domain to a broader OT forest if you have a clear operational need, and vendor support to do so.
Safety Instrumented Systems (SIS): These are often even stricter. These systems protect lives and critical infrastructure. mostly, if not completely isolated from the OT network, and tying their identity to the broader OT or enterprise setup could lead to serious consequences due to an incident in those domains. When safety system integrity is at stake, shared domain infrastructure is not a convenience tradeoff, it could be a liability.
Vendor-managed and OEM-specific platforms: Some industrial applications including turbine control systems, compressor packages, laboratory automation platforms, and advanced process control suites come locked down by the vendor, sometimes with local accounts or vendor-managed domains. In some cases, the vendor-managed domain may follow a traditional managed service provider (MSP) model where they provide offsite, centralized authentication and authorization for their equipment under scope. Any consideration of setting up trust between the MSP centralized domain and the facility should be carefully assessed.
What these systems share is not just technical complexity, it is consequence. A misconfiguration, a compromised credential, or an unplanned policy change in a shared identity environment can propagate into systems where the downstream impact is not just a disrupted business workflow. It could mean a failed safety function, a process excursion, or a regulatory violation. The islands exist because the cost of getting it wrong in those environments is categorically different from the cost of getting it wrong elsewhere.
This distinction should always drive decision, and it points to an important truth: the right architecture is never determined by what is easiest to implement. It is determined by an honest assessment of risk, operating requirements, and the resources available to maintain whatever is built.
How Organizations Should Decide
Rather than starting with architecture diagrams, organizations should start with questions:
- How much autonomy do sites or business units need?
- Which environments must remain operational if a cyber incident takes place?
- Where is risk acceptable and where is it not?
- What are our capabilities for administering and managing on a day-to-day basis?
The answers will guide you, maybe toward one clear tier, or a hybrid model. What matters is you end up with a model that aligns with your risk mitigation strategies, business needs, and your ability to operate and maintain it.
Designing identity architecture for OT isn’t a project you do once and walk away from. It’s an ongoing commitment to understanding how you manage risk, how your organization operates, and what the cost of getting it wrong looks like in your environment. Decisions do not matter if they weren’t deliberate and thought out. The organizations that get this right are the ones that asked questions first, built something sustainable, and stayed disciplined enough to maintain it.
