Resolving WinCC User Authorization Conflicts Between Process Screens and Group Displays

When an operator lacking custom authorization on a process graphic can unexpectedly operate technological objects via the Measuring Point Browser or group displays, the conflict is caused by dual authorization evaluations in SIMATIC PCS 7. While custom authorization (such as Authorization Level 10 'ESD Tag') was assigned to the graphic screen button, the operator's user account in WinCC User Administrator still retains standard system permissions for Level 6 ('Higher Process Controlling'). When an object faceplate is invoked via system browsers or group displays, standard APL faceplate scripts evaluate standard Level 5 or Level 6 permissions, bypassing local graphic restrictions. To resolve this, remove Level 6 from the operator profile and map the custom authorization attribute directly into the technological block's OCM properties.

PCS 7 Dual Authorization Model: Graphic Objects vs Faceplates

In SIMATIC PCS 7 WinCC, access security is governed by User Administrator using 16 standard authorization levels (e.g., Level 5: Process Controlling, Level 6: Higher Process Controlling) and user-defined levels (Levels 10 to 16). However, security enforcement operates across two distinct layers:

Graphic Object Level: In Graphics Designer, an engineer can assign an authorization requirement (e.g., Authorization Level 10) to the 'Operator Authorization' property of a specific static button or custom symbol.
Technological Faceplate Level: When a faceplate opens (such as @PG_OpDi01.pdl or @PG_MotL.pdl), the internal scripts evaluate authorization levels bound to the technological block parameters and the logged-in user token. By default, standard APL faceplates check standard system authorization levels (Level 5 or Level 6).

This separation creates security vulnerabilities if an engineer restricts a command button on a process graphic while neglecting the underlying faceplate permissions.

Root Cause of Authorization Bypass via Group Displays and Browsers

The scenario where an unauthorized operator can click 'Set' via group displays or the Measuring Point Browser arises from the following conflict:

On the custom overview picture, the 'Set' button was manually configured with Authorization Level 10 in Graphics Designer. Because the operator lacks Level 10, clicking the button on the graphic is blocked.
However, in WinCC User Administrator, the operator's role has Level 6 (Higher Process Controlling) enabled.
When the operator opens the Measuring Point Browser, searches tags, or clicks an alarm group display, the system opens the official technological faceplate directly via the system window manager.
The standard faceplate C/VBS scripts do not evaluate the custom graphic property; they query whether the user possesses Level 6. Because Level 6 is active on the account, the faceplate unlocks the 'Set' command.

WinCC Standard Authorization Levels and Hierarchy Matrix

The following table details standard and custom WinCC authorization levels in PCS 7:

Level NumberDefault DesignationEvaluated ByOperational ScopeLevel 1User AdministrationWinCC ExplorerManage accounts and passwordsLevel 4MonitoringStandard ScreensView process graphics, trends, and alarmsLevel 5Process ControllingStandard FaceplatesRoutine start/stop, manual setpoint changesLevel 6Higher Process ControllingStandard FaceplatesInterlock overrides, tuning parameters, safety resetLevel 10Custom (e.g., ESD Tag)Custom Graphics / BlocksDedicated high-risk process interventionsLevel 11Extended Process ControllingAPL Advanced ViewsMaintenance simulation and bypass operations

Step-by-Step Procedure to Enforce Unified Security Permissions

To eliminate authorization loopholes and enforce consistent ESD restrictions across all screens and faceplates:

Audit Operator Roles in WinCC User Administrator:
- In WinCC Explorer, open User Administrator.
- Select the Operator user group or user profile.
- Deselect Level 6 (Higher Process Controlling) for all operators who should not possess ESD override authority.
- Ensure only authorized safety supervisors possess Level 10 (ESD Tag) and Level 6.
Map Custom Authorization to Block Instance Properties in CFC:
- Rather than hardcoding authorization solely on graphic buttons, configure authorization at the block level.
- In CFC, open the Technological Block properties (e.g., OpDi01 or ESD interlock block).
- Under the OCM / Attributes tab, map the command authorization parameter (e.g., Op_Level or OS_Perm) to Authorization Level 10.
Update APL Faceplate Authorization Mapping (If Required):
- In the faceplate internal tag configurations, ensure the block's operation scripts evaluate the specific authorization level configured on the technological instance.
Recompile OS and Test All Entry Points:
- Execute a Changes-Only OS Compile in SIMATIC Manager.
- Download changes to the OS Server and Clients.

Verification

Verify comprehensive authorization enforcement:
1. Log into WinCC Runtime with the standard Operator account.
2. Open the process screen containing the ESD control; verify that the 'Set' action is disabled and greyed out.
3. Open the Measuring Point Browser, search for the ESD tag, and open its faceplate from the browser list.
4. Confirm that the 'Set' command button inside the faceplate is now strictly greyed out and non-operable.
5. Log in with an authorized Supervisor account (possessing Level 10); confirm that the 'Set' action unlocks on both the process graphic and the faceplate.

Limitations and Operational Precautions

Hardcoded Graphic Buttons: Avoid placing raw, unlinked control buttons on process graphics that write directly to PLC tags; always route commands through standardized technological faceplates to maintain consistent audit logging.
Area-Specific Authorizations: WinCC User Administrator allows assigning authorizations per Plant Hierarchy Area. Ensure that permissions are audited across all areas, not merely the global profile.
SIMATIC Logon Integration: In plants utilizing SIMATIC Logon with Windows Active Directory groups, authorization levels must be synchronized between Windows domain groups and WinCC user roles.

Engineer FAQ

Why did setting authorization on a graphic button fail to protect the tag?

Because graphic object properties protect only that specific button. Any other access path—such as block icons, group displays, measuring point browsers, or faceplates—bypasses the graphic button.

Can I restrict faceplate commands without modifying the APL library?

Yes. Technological blocks provide authorization parameters (such as Op_Level or Feature bits) in CFC that dictate what authorization level is required by the faceplate.

What happens if an unauthorized user attempts to write to a tag via scripting?

If the user executes a script without checking PASSCheckLevel(), the write may succeed unless the WinCC Tag itself is protected by an authorization attribute in Tag Management.

How do I protect WinCC tags directly in Tag Management?

In WinCC Tag Management, open Tag Properties, and under 'Authorization', select the required authorization level (e.g., Level 10). WinCC will reject any write attempts from users lacking that level.