Restrict a single HMI view through the navigation control’s documented authorization settings, then check every other route to that view. Verify whether login requires a second press, and confirm that unauthorized accounts, cancelled logins and logout behavior all match the access requirements.
To restrict access to one HMI screen, assign the required authorization to the navigation control that opens it. Leave unrelated navigation controls unrestricted where the operating requirements allow. Use the runtime’s documented user-management settings rather than building a shared password into a button script. Then check the complete sequence: requesting access, logging in, opening the screen and ending the session. Protecting one button is only sufficient when every other route to that screen is also controlled.
Put authorization on the navigation control
An HMI authorization is a permission assigned through the runtime’s user-management system. A user account receives the permissions appropriate to its role. A protected control checks the current session against its required permission before allowing its action.
For a project with one restricted view, this usually means protecting the button that selects that view. The remaining views do not need the same restriction merely because they belong to the same project.
Keep three settings distinct:
- Authentication: establishes which account is logged in.
- Authorization: determines whether that account may operate the protected control.
- Navigation: selects the destination screen after the control is permitted to act.
A successful login does not necessarily grant the required authorization. An account may be valid but lack permission for the restricted view. Likewise, hiding or dimming a navigation button is not a substitute for enforcing its authorization.
Use the manufacturer’s documentation for the exact control properties, permission assignments and runtime behavior. Their names and available options vary between HMI systems and software versions.
Understand why a second press may be needed
Some runtimes handle a protected navigation button as two separate interactions. The first press requests authentication. After login, another press executes the screen-selection action under the newly authenticated session.
In that arrangement, the expected sequence is:
- With no suitable session active, pressing the button opens the login dialog.
- Successful login establishes a session with the account’s assigned permissions.
- The current screen remains visible because the original navigation action was not queued.
- Pressing the protected button again opens the destination if the session has the required permission.
This is not necessarily a navigation fault. It can be the runtime’s documented separation between login and control operation.
Do not assume every HMI behaves this way. Check whether your runtime resumes the original action, requires another press or provides a documented post-login action. Make the interface instructions match that behavior. If another press is required, a short instruction near the navigation control can prevent repeated login attempts.
Protect every route to the restricted view
Authorization on one button does not prove that the destination is protected. The same screen may be reachable from several places in the project.
Review the project for:
- Other navigation buttons, including shared headers and menus.
- Screen lists, shortcuts and function keys.
- Alarm actions that select a screen.
- Scripts or controller requests that change the active screen.
- Startup behavior and any supported restoration of the previous view.
- Back navigation or history controls, where provided.
Apply the documented authorization mechanism to each applicable route. If the runtime supports a screen-level restriction, establish how it interacts with navigation controls and external screen-change requests. Do not assume that a permission on one object automatically applies elsewhere.
Also distinguish access to the screen from permission to change a value. A restricted maintenance page may contain several actions with different consequences. Where required, protect write controls independently using the documented mechanisms available in the HMI and controller. Reaching a page should not silently grant every operation on it.
Treat automatic opening as a separate design decision
Opening the view immediately after login can reduce an interaction, but it changes the navigation design. Authentication must complete before the application evaluates the required authorization and requests the screen change.
Prefer a documented runtime feature for this sequence when one exists. If the manufacturer documents a script or controller interface for session information and screen selection, establish exactly what each interface provides before using it.
In particular, a signal that says an account is logged in does not necessarily mean that account has the permission required for the destination. A navigation request should depend on the relevant authorization, not merely on a nonempty username or a general login flag.
Automatic navigation also needs a clear destination. Logging in from an unrestricted page should not unexpectedly open a maintenance view unless that is the intended and documented interaction. Pending requests must not remain effective after cancellation, failed authentication or a later change of session.
If the available documentation does not establish those behaviors, retain the explicit second press. Do not invent a controller job number or session interface from a description of a different runtime.
Decide what happens after logout
Protecting entry to a screen does not, by itself, define what happens when the session ends while that screen is visible.
Decide whether the operating requirement calls for returning to an unrestricted view, removing sensitive information, disabling protected actions or a combination of these. Then confirm which behaviors the runtime supports through its documented settings.
Check manual logout, any configured inactivity timeout and a change to an account with fewer permissions. A navigation button that correctly rejects entry may still leave an already-open screen visible after logout unless the project handles that state.
Choose an unrestricted destination that preserves access to necessary operating information. Account for any active data-entry dialog as well. Do not assume that a visible control immediately loses its ability to write merely because a different navigation button is protected.
Verify the sequence during commissioning
Use a controlled commissioning environment and accounts with deliberately different permissions. Start each check from a known session state so an earlier login does not conceal a missing authorization check.
| Starting condition | Action | Result to confirm |
|---|---|---|
| No authenticated session | Select the restricted view | The documented access prompt appears, and the view does not open without authorization |
| Login dialog open | Cancel or enter invalid credentials | Access remains denied and no pending screen change executes |
| Valid account without the required permission | Request the restricted view | Access remains denied despite successful authentication |
| Account with the required permission | Complete the documented navigation sequence | The intended view opens, including a second press if required |
| Restricted view already open | Log out or let the configured timeout expire | Visibility and control permissions follow the approved session-end behavior |
| Unrestricted session | Use an alternate route to the view | The same access requirement is enforced |
| Unrestricted session | Open unrelated permitted views | Those views remain available as intended |
Record the runtime version, relevant permission names, configured entry routes and expected login sequence. If automatic opening is used, include cancellation and session changes in the checks. A successful authorized entry alone does not demonstrate that unauthorized routes are closed.
Keep screen permissions separate from machine safety
HMI screen access control limits access to interface functions. It is not a safety interlock, and it does not replace controller-side permissions, network access controls or a machine’s safety design. Do not rely on a hidden page or protected navigation button to prevent a hazardous machine action.
The distinction between a factory status display and an operator HMI matters here. A passive information display and an interface that changes machine settings have different responsibilities. For the latter, define the permitted actions first, then use documented authorization settings and commissioning checks to make the interface follow those requirements.
Questions
How do you restrict access to just one HMI screen?
Assign the required authorization to the control that opens the restricted screen, using the runtime’s documented user-management settings. Leave unrelated navigation controls unrestricted where appropriate. Also review alternate routes to the same destination, because protecting one button does not automatically protect every way of opening the screen.
Why does a protected HMI navigation button need a second press?
Some runtimes use the first press to request authentication without retaining the original navigation action. After login, another press performs the screen change using the authenticated session. Confirm the documented behavior for your runtime before treating the second press as a fault.
Can the restricted screen open automatically after login?
It may be possible through a documented runtime feature or application interface. The design must check the required authorization, not just whether an account is logged in. Confirm how cancellation, failed login and session changes affect any pending navigation request before implementing automatic opening.
Does logging out automatically close a protected HMI screen?
Not necessarily. A permission on the entry button may only control navigation into the view. Define the required logout behavior separately, then confirm how the runtime handles the visible screen, protected controls, active dialogs and any configured inactivity timeout.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.