WinCC Runtime Advanced User Administration: Security, Roles, Permissions & Operator Login: Complete Contents
- 1. Treat HMI Security as a Control Layer
- 2. Define Roles Before Creating Accounts
- 3. Build a Permission Matrix
- 4. Configure Users, Groups/Roles and Authorizations
- 5. Protect Screens, Buttons and Inputs
- 6. Engineer Login, Logout and Session Behavior
- 7. Validate Critical Commands in the PLC
- 8. PLC-Side Command Gating Example
- 9. Add Platform and Network Controls
- 10. Security Commissioning Test
- 11. Common User Administration Problems
Practical WinCC Runtime Advanced Engineering Guide
1. Treat HMI Security as a Control Layer
User administration is one layer of industrial security. It helps ensure that only authorized people can open protected screens or execute sensitive HMI functions, but it does not replace PLC safety logic, network segmentation, operating-system hardening or organizational access control.
2. Define Roles Before Creating Accounts
Start with functions, not individual names. Typical roles are Operator, Supervisor, Maintenance and Engineer/Administrator. Define exactly what each role can view and execute. Avoid giving every user engineering-level rights simply because it is easier during commissioning.
3. Build a Permission Matrix
| Action | Operator | Supervisor | Maintenance | Engineer |
|---|---|---|---|---|
| Start/Stop normal cycle | Yes | Yes | Yes | Yes |
| Edit production setpoints | Limited | Yes | Yes | Yes |
| Reset equipment fault | Limited | Yes | Yes | Yes |
| Recipe overwrite | No | Limited | Limited | Yes |
| Engineering/service screen | No | No | Limited | Yes |
4. Configure Users, Groups/Roles and Authorizations
Create the required user/group structure in the WinCC engineering environment and assign authorizations according to the matrix. Naming and editor details can vary by TIA Portal version, so maintain a project-level security specification rather than relying on one engineer’s memory of the UI.
5. Protect Screens, Buttons and Inputs
Apply authorizations to actions that can change the machine state: recipe editing, maintenance overrides, manual outputs, drive reset, setpoint changes, alarm acknowledgement policy where relevant and access to service screens. Hide or disable controls consistently, but do not use visibility alone as the security boundary.
6. Engineer Login, Logout and Session Behavior
Provide a clear login path and visible indication of the active user/role where the Runtime supports it. Define logout behavior and inactivity handling appropriate to the machine. Shared permanent logins defeat accountability, especially on HMIs used across shifts.
7. Validate Critical Commands in the PLC
HMI authorization should be reinforced by PLC state logic. For example, a maintenance command can be accepted only when the machine is in Maintenance/Manual mode, safety conditions are healthy and the target equipment is in a valid state.
8. PLC-Side Command Gating Example
// HMI permission is not the final control decision
IF HMI_ResetCmd AND MaintenanceMode AND SafetyHealthy THEN
ResetRequest := TRUE;
END_IF;
IF HMI_RecipeApplyCmd AND MachineStopped AND RecipeValid THEN
ApplyRecipeRequest := TRUE;
END_IF;9. Add Platform and Network Controls
Use least-privilege Windows accounts where applicable, protect engineering files/backups, control remote access, segment the automation network and manage removable media and service laptops. Security improves when the HMI, PLC, network and operational procedures reinforce one another.
10. Security Commissioning Test
Test every role against every protected action. Prove that the Operator cannot open engineering/service screens, cannot overwrite protected recipes and cannot execute maintenance commands. Then verify Maintenance and Engineer accounts receive only their intended rights. Test logout/session behavior and recovery after Runtime restart.
11. Common User Administration Problems
| Issue | Cause | Correction |
|---|---|---|
| Everyone uses one account | Convenience during commissioning | Create role-based individual/shared shift policy per plant rules |
| Protected button still changes process | Alternate write path | Audit all HMI scripts/tags and add PLC validation |
| User cannot access required function | Authorization mapping error | Check role/group and object permission |
| Session remains privileged | No logout/inactivity policy | Engineer session handling and operator procedure |
WinCC Runtime Advanced Hands-On Lab
Use a non-production PLC/HMI project, document the test conditions, and verify every HMI behavior against the PLC watch table or diagnostics. The objective is not only to make the screen work, but to prove that the engineer can diagnose a deliberate fault and recover the system methodically.
Frequently Asked Questions
What is WinCC Runtime Advanced user administration?
It is the HMI access-control configuration used to assign users or roles specific authorizations for Runtime screens and actions.
What roles should a machine HMI use?
A practical starting point is Operator, Supervisor, Maintenance and Engineer/Administrator, with permissions defined by job function and plant policy.
Is hiding a button enough to secure an HMI command?
No. Protect the action with HMI authorization and validate critical commands again in PLC state/interlock logic.
Why is least privilege important on an HMI?
It reduces accidental or unauthorized changes by giving each user only the functions required for their role.
Related WinCC Runtime Advanced & Siemens HMI Resources
Need Practical WinCC Runtime Advanced Training?
Build the complete HMI workflow from PLC communication and tags through alarms, trends, recipes and user administration with a practical Siemens automation project.
Discuss Training or Project Support