A full password list locks nothing until each screen is told to use it. After a firmware or software update, open every screen's options, switch protection on, set the access level that may open it, transfer the project and test each screen at the panel. No PLC setting is involved.
You updated the firmware on the panel, typed the passwords back into the manager, went to the floor and every screen still opens without a prompt. The passwords were never the problem. On these panels the password manager is a list of credentials; the switch that makes a screen ask for one lives in that screen's own options in the editing software. This page shows why a full password list leaves every menu open, what each symptom points to, why no PLC setting is involved, the per-screen steps that turn protection on, and the 10-attempt test to run at the panel before the shift starts. The other ways a panel misbehaves after an update sit in the shop-floor screen fixes.
Why do HMI passwords not take effect after a firmware update?
The password manager, the setup screen with eight to ten entry slots, stores credentials only; protection is switched on per screen, so a panel can hold a full password list and open every menu freely until each screen's own options carry the enable.
The two stores do different jobs. The manager holds the passwords and the level each one carries. Each screen's options hold the enable and the access rule for that screen. A project can carry a full list and still leave every screen open, because no screen has been told to ask.
Three switches look alike and get confused. The manager list is credentials. The per-screen enable and level is what locks a menu. Project protection is a third thing again: it keeps the project file from being opened in the editor, and enabling HMI project protection while keeping the editable master covers that one.
After an update, treat every per-screen switch as unverified. Whether the update cleared them or they were never set, the fix below is the same, so work screen by screen.
Which symptom points to which missing setting?
Match each behavior to its store: a full list with no prompt anywhere means the per-screen enable is off, prompts on some screens only means the rest were never set, and a screen locked yesterday but open today means yesterday's login is still active.
- No prompt on any screen, list full. The enable is off on every screen you have checked, or the panel runs a project transferred before the passwords went in. Transfer the current project once and test again; a screen that still opens needs its enable set.
- Prompt on some screens only. Protection is doing what it was told: the screens without a prompt have no enable. List them and finish the set.
- Locked yesterday, open this morning. Most panels keep the logged-in level until logout or power-up, so yesterday's session is still open. Log out deliberately and retest before changing any setting.
- The PLC programming software asks for a password online. That is PLC program protection, a separate feature with its own supported setup, and it plays no part in which panel screens open.
Do PLC settings control HMI screen passwords?
No PLC setting takes part: the screen-security check runs in the panel against the project's access levels, so the whole fix happens in the editing software, and the firmware update on the PLC needs no matching change.
The PLC holds the machine logic and never judges which panel screen may open. Changing PLC logic to chase a panel symptom adds risk and fixes nothing here, so leave the ladder alone until a PLC-side fault of its own appears.
When you want the PLC project itself locked so the logic cannot be opened or edited from the programming software, that is a separate job with a documented path: password protecting a PLC project the supported way.
How do you enable password protection on each screen?
Open the project in the editor, open the options of every screen that must ask for a password, switch its protection enable on, set the minimum access level, check the password entries in the manager, save the project and transfer it to the panel as one job.
- List the screens that must ask for a password before you open the editor: recipe screens, drive and parameter screens, communications and network screens. On a small panel that is 2 to 4 screens.
- Open one listed screen's options in the editor and find the protection or security group in it.
- Switch the screen's protection enable on.
- Set the level a password must carry to open the screen: a maintenance level for recipe and drive screens, an engineering level for network settings.
- Repeat steps 2 to 4 for every listed screen. One enable covers one screen.
- Open the password manager and check that each entry carries the level its screens require.
- Save the project and transfer it to the panel with the editor's normal transfer procedure, and let the transfer finish before the panel goes back in service.
Two refinements sit one level down. To fire the prompt the moment someone touches a setpoint object, on top of the screen enable, use entry protection on the object as covered in password protect an HMI setpoint screen at entry. And when the panel serves several roles, map levels to roles first: HMI screen access control for a protected operator view shows the scheme.
Example: how does the fix run on a 12-screen panel?
A packaging-line panel has 12 screens, 3 of them hold settings, so the job is 3 protection enables, 2 password entries at levels 2 and 3, 1 transfer, and 10 test attempts at the panel, about 20 minutes with the editor already open.
The three settings screens are the recipe screen, the drive parameters screen and the network settings screen; the other 9 stay open. The project defines 3 access levels: 1 operator, 2 maintenance, 3 engineering, and the manager gets 2 entries, one per level above operator.
The assignments are: recipe screen, minimum level 2; drive parameters, level 3; network settings, level 3. That is 3 enables, 2 entries, 1 save, 1 transfer.
The test pass tries 3 protected screens × 3 login states = 9 attempts, plus 1 open screen with no login = 10 attempts in all. The expected result: no login refuses all 3, the maintenance password opens 1 and refuses 2, the engineering password opens all 3. Counted: 3 + 2 + 0 = 5 refusals, 9 - 5 = 4 opens, plus the 1 free screen.
If the maintenance password had opened the network settings screen too, that screen's level would still sit at 2; raise it to 3 in its options and transfer again.
How do you check the protection at the panel?
Test on the panel, never in the editor alone: power the panel up fresh, try every protected screen with no login, then with each password, and finish on one open screen, which gives the 10-attempt pass of the example above in about 5 minutes.
- Power-up, no login. Cycle power, then touch a protected screen. A prompt must appear. No prompt means the panel runs a project without the enable: re-transfer, check the transfer completed, and retest.
- Each password against each screen. Log in at level 2 and walk the protected screens, then level 3. Each level must open exactly the screens the map gives it.
- One open screen. A screen with no enable must open with no login; this catches over-protection that hides a screen the shift needs.
- Log out at the end. Leave the panel so the next operator starts with no login, the state the protection assumes.
A protected screen that still opens after a verified transfer has its enable off in the project: back to its options, set it, transfer, run the pass again. If a popup appears on screens you meant to leave open, why a password popup shows on screen change after passwords are deleted covers that case.
How do you keep the protection set after the next update?
Write the protection map into the project before the panel goes back to the floor: one line per screen with its level, so the next firmware or editor update can be checked against the map in one 10-attempt pass instead of a shift of surprises.
Keep three things with the project: the screen-to-level map, the role that holds each level, and the date of the last panel test. Any firmware update on the panel, any editor update, or any rebuilt project calls for the pass again; it either clears the panel or hands you the exact screen to fix.
One safety rule belongs here: never leave a settings screen open to get the line running and plan to fix it later, because a drive parameter changed mid-run can move a machine with people at it. Verify the protection, then release the panel.
Recommendation: after any firmware or software update on the panel or the PLC, run the 10-attempt test before the shift starts; if a protected screen opens without a login, open that screen's options, set the enable and the level, transfer and test again. Touch PLC settings only when the PLC's own documentation or a PLC-side fault points there.
Questions
What can I do if the maintenance password itself is lost?
The list lives in the project file, so open the project in the editor and re-enter the passwords and levels there, then transfer again. There is no panel-side way to read a password back out, and any reset on the panel itself has to follow the manual's documented procedure for that model. Write the new password into the protection map and run the panel test once more.
How many access levels should a small panel have?
Two cover most small panels: one open level for operators and one protected level for maintenance. Add a third only when engineering settings, usually network configuration, must sit above maintenance. Every extra level adds a password to keep track of and one more row to the test pass, so keep the count at two until a real need appears.
Does protection survive a normal project edit?
Yes, as long as the edit starts from the saved project: the enable and the level are stored with each screen, so a normal change and transfer keeps them. A rebuilt project or a fresh template starts with no enable set anywhere, which is exactly the case the protection map and the 10-attempt pass are there to catch.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.