Securing the AVEVA PI System in Modern Enterprise Environments

Meta description: Practical PI System security guidance for enterprise OT/IT: identity, AD/Kerberos, service accounts, gMSA, hardening, firewalls, audit and mistakes.

Why PI System security is different in 2025

The PI System sits between operations and enterprise IT: it must be reliable, low-latency and always-on, while meeting corporate security and compliance controls. Secure PI is not a single setting but a set of design decisions across identity, network segmentation, least privilege, patching, monitoring and change control.

This guide provides an evergreen model and practical steps PI administrators and OT/IT architects can take to reduce risk without disrupting data flows or operational support.

Scope note: this focuses on Windows-based PI Data Archive and AF/Analytics with common client integrations. Always validate changes in a representative test environment before production rollout.

PI security model — layered controls

PI security is best considered in layers:

• Identity & authentication: Windows/AD, Kerberos, service credentials
• Authorisation: PI Identities, mappings, trusts, permissions
• Transport & network: ports, firewalls, segmentation, encryption where available
• Host & service hardening: OS hardening, service accounts, patching
• Monitoring & audit: logs, events, configuration baselines, change control

A frequent failure is hardening one layer while leaving others permissive (for example, strict firewalls but broad PI Identities). Aim for balanced controls aligned to operational reality.

Authentication and authorisation

Authentication: prefer Windows integrated security

Windows integrated authentication is preferred because it centralises credential lifecycle, enables Kerberos in domain contexts and reduces shared secrets. If Windows integrated authentication isn’t possible (for example, workgroup/DMZ scenarios), apply compensating controls: tightly constrained service accounts, explicit trusts, restricted network paths and heightened monitoring.

Authorisation: PI permissions are PI objects, not just AD groups

PI access is governed by PI/AF security objects:

• PI Identities: role-like objects for permissions
• Mappings: Windows users/groups → PI Identities
• PI Trusts: allow connections based on source attributes (IP/hostname/app) — powerful but risky if broad
• Explicit permissions: Data Archive and AF permissions at database, element and point levels

Design principle: map groups to identities (not individuals) and align identities to job functions (eg “PI Vision Readers”, “AF Model Editors”) with least privilege.

Active Directory, Kerberos and service accounts

Active Directory: use roles for manageability

• Create dedicated AD security groups for PI roles (readers, writers, admins, AF designers, support)
• Avoid deep nesting; it complicates troubleshooting across domains
• Treat shared OT accounts as exceptions requiring compensating controls (use named accounts with MFA for humans; service accounts for services only)

If spanning domains/forests, clarify early whether trusts are one-way or two-way, whether Kerberos delegation is permitted, and which domain holds service accounts — these decisions affect PI Vision, AF clients and authentication flows.

Kerberos: reduce NTLM fallback

Kerberos prevents credential relay and reduces NTLM reliance. Symptoms of Kerberos issues include repeated credential prompts, inconsistent access between machines, and alias vs hostname failures.

Operational checks:

• Manage DNS and SPNs deliberately; ensure SPNs match service identities when using aliases or load balancers
• Standardise name usage (FQDN, short name, alias) and document it
• Ensure time synchronisation across domain members
• Monitor for silent NTLM fallback; remediate before NTLM is disabled

Also see Service accounts, Kerberos, and gMSA in PI System environments (practical SPN patterns, common pitfalls, verification steps).

Service accounts: treat them as infrastructure

Service accounts are central to PI deployments. Best practice:

• Use one service identity per function or server role, not one account for everything
• Deny interactive logon for non-human accounts
• Apply appropriate password policies (see gMSA below)
• Document which services run as which accounts and their permissions

Avoid using Domain Admins temporarily and forgetting to remove elevated rights, sharing an account across unrelated servers, or granting local admin as a workaround instead of resolving DCOM or permission needs.

gMSA and modern identity choices

Group Managed Service Accounts (gMSA) automate password management and rotate credentials via AD. gMSA is useful where you have multiple servers for similar services, strict rotation requirements, or limited appetite for manual password windows.

Considerations before adopting gMSA:

• Confirm AD domain functional level, KDS root key setup and AD support
• Verify application compatibility for each PI component — some expect traditional user accounts
• Plan SPN registration for gMSA and naming for aliases/load-balanced endpoints
• Assign required rights (log on as a service, local/PI permissions) — gMSA is not automatically least privilege

Pragmatic rollout:

1. Pilot on non-critical web or utility services with easy rollback
2. Define ownership between PI and AD teams for gMSA creation and SPN management
3. Use the pilot to document a request template, test steps and monitoring signals

Network security and firewalls

Segment by function

Typical traffic types: data ingestion (interfaces → Data Archive), user access (clients/PI Vision → AF/Data Archive), administration (RDP/WinRM), and replication/HA. Adopt zones such as:

• OT source networks (PLCs/DCS historians)
• Interface/connectors zone
• PI core services zone (Data Archive, AF)
• User access zone (VDI, engineering workstations, PI Vision)
• Enterprise services (AD/DNS/PKI, monitoring, backup)

Enforce communication only where required with documented firewall rules mapped to applications and server roles.

Firewall rules: manage them as code or baselines

• Maintain a port and flow matrix (source, destination, port, protocol, purpose, owner)
• Use allow-lists rather than broad internal rules
• Avoid undated temporary rules; record expiry and ticket references
• Capture exceptions in runbooks so on-call staff don’t bypass controls during incidents

Remote access: reduce blast radius

• Use jump hosts/bastions for admin access
• Restrict RDP to admin subnets and consider privileged access workstations for PI admins
• Keep interactive access rare and fully auditable

Hardening checklists

Hardening must be repeatable. Think in three layers: Windows, PI services, and operational process.

Windows and platform baseline

• Run supported Windows with current security updates (aligned to OT change windows)
• Restrict local admin group membership and disable legacy protocols where feasible
• Apply audit policies and endpoint protection with tested exclusions
• Disable unused roles/features and remove unnecessary IIS modules
• Ensure reliable backups and tested restores; treat ransomware resilience as a control

PI Data Archive and AF hardening

• Review PI Identities and permissions: remove broad write access, separate readers/writers/admins, and tightly control who creates points and security settings
• Minimise PI Trusts; if used, scope by exact IP/hostname ranges, tie to specific applications and review regularly
• Run PI services under dedicated least-privilege accounts or gMSA where appropriate
• Limit AF and Data Archive admins to a small group with named accounts
• Protect configuration stores and backups with access controls and encryption at rest where required

Web and client layer hardening (PI Vision / IIS)

• Keep IIS patched and follow corporate hardening baselines
• Use Windows integrated authentication; avoid storing credentials in config files
• Restrict publishing and administrative rights for web content
• Place the web tier in an appropriate network zone and avoid exposing core PI services to broad networks

Operational hardening

• Establish a security configuration baseline and scheduled access reviews (quarterly is common)
• Apply change control to trusts, mappings, firewall rules, service account changes and admin membership
• Include PI-specific steps in incident response runbooks (logs to collect, how to isolate interfaces, minimum telemetry to keep)

Compliance and audit considerations

PI is usually a component within a broader compliance scope (internal standards, NIS2-style obligations, ISO 27001). You will typically need to demonstrate:

Access governance

• Named human accounts, least privilege and timely removal of access
• Evidence of periodic reviews: AD group exports, PI Identity mappings, admin lists
• Separation of duties where applicable (for example, model designers vs approvers)

Change traceability

• Document changes to PI security objects, AF database permissions, point security and firewall rules with ticket references

Logging and monitoring

• Centralise Windows event logs to a SIEM or log platform where possible
• Monitor for repeated auth failures, privilege changes, unexpected service restarts, new/modified scheduled tasks and service account changes

Data handling and retention

• Classify business-critical or regulated PI data
• Protect backups from modification, test restores and retain per policy
• Document security controls for cross-zone replication and data egress

Common mistakes and fixes

1. “Everyone is a PI Admin”
   Symptom: too many privileged PI Identities or local admins. Fix: tiered roles (read-only, operator, engineer, admin), AD groups mapped to PI Identities, controlled break‑glass.

2. Over-reliance on PI Trusts
   Symptom: broad trusts with wide IP ranges. Fix: prefer Windows integrated auth; tightly scope and review trusts.

3. Shared service accounts
   Symptom: one account used for Data Archive, AF, IIS and interfaces. Fix: split accounts by role and consider gMSA.

4. Kerberos/SPN problems masked by NTLM
   Symptom: auth problems “fixed” by enabling legacy settings. Fix: standardise naming, fix SPNs and work to reduce NTLM.

5. Accreting firewall rules
   Symptom: wide rules added during incidents and never removed. Fix: flow matrix, exception expiry and quarterly reviews.

6. Hardening without operational testing
   Symptom: disabled protocols break interfaces. Fix: test in a lab, stage changes, monitor end‑to‑end flows.

7. Untested backups
   Symptom: backups exist but restores are untested and reachable from compromised servers. Fix: test restores, isolate backup repositories, document PI restore steps.

Hardening quick-start sequence

For existing estates, follow this order:

1. Inventory and map servers, roles, service accounts, trusts and network flows
2. Reduce privilege: tighten PI Identities, admin groups and point/AF permissions
3. Stabilise identity: fix Kerberos/SPNs and standardise AD group → PI mapping
4. Apply network segmentation and firewall allow‑lists based on the validated flow matrix
5. Uplift service accounts: split accounts and adopt gMSA where appropriate and supported
6. Deploy monitoring and scheduled access recertification

This sequence reduces the risk that security changes cause outages.

When to involve specialists

Bring in specialists for multi-domain identity, complex Kerberos/SPN issues, legacy trusts that cannot be removed quickly, or when compliance evidence is time‑sensitive. Seek practitioners experienced across PI administration, Windows security and OT network constraints who will deliver maintainable runbooks. You can browse PI System integrators and consultants at https://piadmin.com/directory or find specialist PI System integrators at https://piadmin.com/directory/system-integrator.

Where to go next on PIAdmin.com

• Browse PI System integrators and consultants: https://piadmin.com/directory
• Find specialist PI System integrators: https://piadmin.com/directory/system-integrator