Manage security settings in Designer.

ReferenceModules Security → UI | Engine


Designer Audit Posture

The Designer Workspace produces three kinds of activity records, each with a different purpose. Knowing which one to look at — and which one a regulator will accept as evidence — matters for compliance.

Record

Purpose

Regulatory weight

Recent Changes / Version Control (Designer → Track Changes)

Engineering-activity audit. Records who edited which object and when, with UserName + UserComputer + timestamp.

Engineering activity log. The right place for "who changed the configuration" questions.

MCP Category tag on objects

AI-authoring contract. Objects created by AI carry an MCP Category and can be overwritten by subsequent AI edits. Objects without the tag are owned by the user and AI writes silently skip them.

Authority record (which objects AI may modify), not an audit trail.

MCPSessionLog.txt in the solution's MCP debug folder

A trace file the Designer writes during AI sessions. Useful for troubleshooting an unexpected AI behavior — what tool was called, what arguments, what failed. Rotated per session into a Logs/ subfolder.

Debug aid only — NOT an audit trail. Customers requiring regulatory audit evidence must use Recent Changes / Version Control (engineering-time) or the runtime Alarm Historian via the AuditTrail toggles in Alarms Global Settings Reference (runtime control actions, including MCP Custom Tool execution).

Designer authentication: Designer uses Windows Authentication. There is no plan to add OIDC, SAML, or any external IdP for Designer login. Operator-side IdP work (10.1.6) targets the Runtime HTML5 client, not Designer.

Compliance scope: FDA 21 CFR Part 11, NERC CIP-007, and IEC 62443 SR 6.1 regulate runtime control actions, not configuration-time engineering edits. The Designer Workspace is out of scope for those regimes; the runtime is in scope. See the relevant compliance how-to pages for the runtime audit-coverage matrix.


In this section...