Active Directory in OT environments - specific threats and a protection model

In every third OT security project we deliver, one of the first findings is that the industrial environment shares the same Active Directory domain as the office. HMI stations, SCADA servers, historians, and MES systems authenticated by the same domain controller where marketing staff log in. This is not a theoretical threat - it is the daily reality for many industrial facilities across Europe.

The problem is not that Active Directory is a poor solution for OT. The problem is that a typical office-oriented AD configuration does not account for the specifics of industrial automation systems - their availability requirements, lifecycle, and update constraints.

Why AD ends up in OT environments

Integrating Active Directory with industrial environments stems from several practical needs:

• Centralized identity management - instead of local accounts on every HMI station, the organization wants a single authentication point
• Regulatory compliance - IEC 62443 requires user identification and authentication (FR 1 - Identification and Authentication Control), which is easier to implement with AD
• Patch management - WSUS and SCCM/MECM require domain membership for update distribution
• Security policies - GPO as a mechanism for enforcing configuration on OT stations

All of these needs are legitimate. The problem lies in the implementation - most commonly through extending the existing corporate domain to the OT network rather than designing a dedicated architecture.

Problem 1: Shared IT/OT domain

When the OT environment is joined to the same domain as IT, any attack on the IT domain automatically provides the attacker a path to the industrial environment. Compromising a Domain Admin account in the office network means full control over HMI stations, SCADA servers, and historization systems.

What we find in audits:

Problem	Frequency	Risk
Single AD domain for IT and OT	~60% of projects	Critical - IT compromise = OT compromise
Domain Admin accounts used to manage OT	~40% of projects	Critical - no privilege separation
No segmentation between DC and OT network	~50% of projects	High - direct DC-OT communication
Shared IT/OT service accounts	~45% of projects	High - lateral movement through service accounts

Recommended approaches:

1. Dedicated OT domain - a separate AD forest for the industrial environment, with a controlled trust relationship to the IT domain. The preferred solution for large organizations.
2. Dedicated OUs with separated delegation - if a separate domain is not feasible, create separate Organizational Units for OT assets with dedicated administrative delegation and separate GPOs.
3. Local DC in the OT zone - a domain controller (or RODC - Read-Only Domain Controller) placed in the OT network segment, so authentication traffic does not need to cross the firewall to the IT network.

Problem 2: SCADA and MES service accounts

SCADA, MES, DCS, and historian systems require AD service accounts for communicating with databases, reporting servers, and other components. These accounts have specific characteristics that make them particularly vulnerable:

• Static passwords - many OT systems do not support Group Managed Service Accounts (gMSA). Service account passwords are set manually and never changed, because changing them requires a control system outage
• Excessive privileges - OT service accounts often have Domain Admin rights “just in case,” because the administrator did not want to risk authorization issues
• SPNs registered on user accounts - which makes them a target for Kerberoasting attacks (described in detail in the article Kerberos attacks - from AS-REP Roasting to Golden Ticket)

How to secure OT service accounts:

• Use gMSA where technically possible (Windows Server 2012+, supported by an increasing number of industrial applications)
• For systems that do not support gMSA - passwords of at least 30 characters, stored in a dedicated vault
• Restrict permissions to the minimum required by vendor documentation
• Add OT service accounts to the “Protected Users” group or mark with the “Account is sensitive and cannot be delegated” flag
• Monitor TGS ticket requests (Kerberoasting) for accounts with SPNs linked to OT systems

Problem 3: Stale computer objects

In OT environments, device lifecycles are significantly longer than in IT. Engineering workstations, SCADA servers, and HMI computers run for years without reinstallation. The result: Active Directory accumulates computer objects that:

• Represent devices decommissioned from operation but never removed from AD
• Have machine account passwords unchanged for years (the default 30-day rotation may be disabled on OT stations)
• Run on unpatched Windows versions (Windows 7, Windows Server 2008 R2)

Why this matters: Stale computer objects can be exploited for Resource-Based Constrained Delegation attacks. Machine accounts with disabled password rotation are easier to compromise through brute force. Devices on older Windows versions do not support modern protection mechanisms (SMB3, AES Kerberos, LDAP Channel Binding).

How to manage:

• Regular audits of computer objects in OT-dedicated OUs
• Disable machine accounts after device decommissioning (do not delete - preserve history)
• Enforce machine account password rotation where possible
• Document devices that cannot rotate passwords, with justification and compensating controls

Problem 4: GPO and OT system availability

Group Policy Objects are a powerful configuration tool, but in OT environments they can cause system availability issues:

• Forced restart after WSUS update installation can shut down an HMI during a production process
• Account lockout policy after a few failed logon attempts can lock out a control station operator
• Application launch restrictions (AppLocker, Software Restriction Policies) can block SCADA software
• Password expiration enforcement can cause loss of access to an HMI station during a shift

Recommendations:

• Dedicated GPOs for OUs containing OT assets
• Disable automatic restarts - updates applied during maintenance windows
• Higher account lockout thresholds (or disable lockout with compensating monitoring)
• Test every GPO change on a test station before deploying to OT production
• Document exceptions from corporate policies with justification and compensating controls

Problem 5: No tiering model that accounts for OT

The classic Microsoft tiering model (Tier 0 / Tier 1 / Tier 2) does not account for industrial environment specifics. In organizations that have implemented tiering for IT, OT assets are often overlooked or incorrectly classified.

Proposed tiering model with OT:

Tier	Assets	Description
Tier 0	Domain controllers, CA, Azure AD Connect	Identity - managing the entire domain
Tier 1-IT	IT application servers, databases	Corporate services
Tier 1-OT	SCADA servers, DCS, historian, MES	Industrial services - separate from IT
Tier 2-IT	Employee workstations	Corporate devices
Tier 2-OT	HMI stations, operator panels	Control devices - separate from IT

Key principles:

• Tier 1-OT administrator accounts cannot log on to Tier 2-IT resources (and vice versa)
• Tier 0 accounts never log on directly to OT resources
• OT resource management is performed from dedicated PAW stations placed in the OT segment
• OT service accounts have no permissions outside Tier 1-OT and Tier 2-OT

For more on network segmentation in the OT context, see our article OT Network Segmentation.

IEC 62443 and identity management

The IEC 62443 standard, which forms the foundation of industrial automation system security, defines identity management requirements under Foundational Requirement 1 (FR 1 - Identification and Authentication Control):

• SR 1.1 - Human user identification and authentication
• SR 1.2 - Software process identification and authentication
• SR 1.5 - Authenticator management
• SR 1.7 - Strength of password-based authentication

Active Directory can be the tool implementing these requirements, but it needs proper configuration that accounts for the OT context. We describe more about the OT security approach in our article OT security - there is no minimum.

Practical implementation plan

Securing AD in an OT environment is a process that must account for operational constraints. Here is a pragmatic sequence of actions:

Phase 1 - Visibility (1-2 months)

• Inventory of OT assets in Active Directory
• Identification of service accounts and their permissions
• Mapping of GPOs applied to OT assets
• Audit of trust relationships between domains (if they exist)

Phase 2 - Separation (2-4 months)

• Creation of dedicated OUs for OT assets
• Implementation of separate GPOs for OT
• Creation of dedicated OT administrative accounts
• Restriction of service account permissions

Phase 3 - Hardening (3-6 months)

• Implementation of a tiering model with OT considerations
• Enforcement of SMB and LDAP signing (with compatibility testing)
• Migration of service accounts to gMSA where possible
• Deployment of AD security event monitoring in the OT context

Phase 4 - Continuous improvement

• Quarterly permission and account reviews
• GPO testing before every change
• Regular penetration tests covering IT-to-OT paths
• Exception documentation updates

Checklist: AD in OT environments

• OT assets in separate OUs (or a separate AD forest)
• Dedicated administrative accounts for OT resources
• OT service accounts with minimum required permissions
• OT GPOs separated from corporate GPOs
• No automatic restarts after updates on OT stations
• Tiering model accounts for IT/OT separation
• OT computer object inventory up to date
• Tier 0 account logons to OT resources monitored (should generate alert)
• Security policy exceptions documented with compensating controls
• Regular testing of IT-to-OT attack paths

Summary

Active Directory in an OT environment is not a problem that can be avoided. Integration of industrial systems with the AD domain has become standard and delivers real operational benefits. The key is consciously managing the risks this integration introduces - privilege separation, dedicated policies, and a tiering model that accounts for OT specifics.

At SEQRED, we combine IT and OT security competencies, which allows us to design AD architecture that accounts for both worlds. From AD security audits in the context of industrial environments, through tiering model design, to implementation support - we help industrial organizations secure their identity infrastructure without compromising production system availability.

---

Sources:

• IEC 62443 - PLC & SCADA Security Step-by-Step Guide
• SCADA Security Design - S5 Technology Group (2025)
• Microsoft - Enterprise Access Model
• Microsoft - Mitigating critical threats to AD DS in 2025
• Redbot Security - ICS/SCADA Security 2025