Short answer. S7-1500 password protection is not one password but several, and each protects a different thing. CPU access control decides who can download, who can read and who only gets in through the HMI. The password for confidential PLC configuration data protects private keys and other confidential data. Know-how protection hides a block’s code but does not stop anyone loading it. From TIA Portal V19 with firmware V3.1, access control is built on users and roles (UMAC), and PUT/GET is off by default.
TIA Portal has at least three passwords, each one locks a different door, and mixing them up tends to end the same way: carefully hidden code and a download path open to anyone on the network. Below: what each mechanism protects, what it leaves open, where it is set according to Siemens’ November 2025 manuals, and how to check it works. For the wider picture, see the practical PLC cybersecurity guide for machine programmers.
In particolar modo vedremo:
S7-1500 password protection: four mechanisms, four targets
Keep this table open while you configure. Menu paths come from Siemens’ 11/2025 manuals (TIA Portal up to V21) and, for legacy access control, from the V19 UMAC application example (07/2024), except where the 2014 system manual is named: check those against your own version.
| Mechanism | What it covers | Limit stated in the manual | Where you set it | From which version |
|---|---|---|---|---|
| Access control with users and roles (UMAC) | Who downloads blocks and configuration, who runs test functions, who switches RUN/STOP, who updates firmware | Not documented in the sources used | “Security Settings > Users and roles” in the project tree; CPU properties, “Protection & Security > Access control” | TIA V19, CPU firmware V3.1 |
| Legacy access control via access levels | Four levels: Full access, Read access, HMI access, No access | It does not identify who is connecting: it “did not authenticate the user”. Blocks on the memory card “are not write- or read-protected” (2014 manual) | Option “Use legacy access control via access levels” | The only scheme below FW V3.1; still selectable in V19 |
| Password for confidential PLC configuration data | Private keys and other confidential configuration data; from V21 and FW V4.1, optionally the entire configuration | Without a password, “weak protection of private keys” | “Protection & Security > Protection of the PLC configuration data” | STEP 7 V17 |
| Know-how protection | The code of an individual block | The block can still be copied, deleted, loaded and compared online/offline (2014 manual) | Block properties, “Protection” option under “General” (2014 manual) | Check your version |
| Copy protection | Binds the block to the memory card’s serial number: it only runs with that card | Without know-how protection on top, copy protection can be reset (2014 manual) | Path not documented in the sources used here | Check your version |
Access control: users, roles and three rights
Since TIA Portal V19 and firmware V3.1, the S7-1500 uses User Management & Access Control, or UMAC. Before that there were only password-protected access levels: the CPU knew someone had typed the level’s password, not who. With UMAC you create named users, assign roles, and each role carries rights on the CPU.
There are three access rights, and they are worth reading slowly:
- HMI access: HMI access and diagnostic data only; tags can be read and written from an HMI device.
- Read access: read-only access to the hardware configuration and blocks. It also allows changing the operating state (RUN/STOP) and setting the time of day.
- Full access: everything, including downloading blocks and hardware configuration, test functions, RUN/STOP and firmware updates.
The Read access detail catches people out. A “read-only” user can stop the machine: give Read access to maintenance and you have also given them CPU STOP.
Firmware V3.1 changed the defaults for a new project. According to Siemens’ UMAC application example, the confidential configuration data password and secure-only PG/PC and HMI communication are on from the start; the PUT/GET permission is disabled and greyed out; the legacy access control from V17 and V18 is disabled.
Where to set it
- In the project tree, open “Security Settings > Users and roles” and create the users. Each user has a “Runtime timeout” field: the idle time after which the user is logged out. On the CPU, password is the only authentication method.
- In the CPU properties, “Protection & Security > Access control”, “Enable access control” must be ticked. That is the default.
- Leave “Use legacy access control via access levels” off, except for the HMI case below. In V19 the legacy level is chosen through the rights of the “Anonymous” user; with Anonymous disabled you get “No access (complete protection)”.
The HMI case: the application example says TIA Portal V19 “does not support user-based access control for PLC-HMI communication, only passwords”, and advises avoiding legacy access control if no panel will be connected. Whether that limitation still applies in V20 and V21 is not stated in the sources we read. Check it on your version before you design the panel’s access.
Below firmware V3.1 the four levels apply; the 2014 manual puts them under “Protection” (now “Protection & Security”). The same manual says the CPU logs every correct or incorrect password entry in the diagnostics buffer.
Read access is not read-only: whoever has it can put the CPU into STOP.
What the PUT/GET permission actually does
The option is called “Permit access with PUT/GET communication from remote partner (PLC, HMI, OPC, …)” and sits under “Protection & Security > Connection mechanisms”. The key sentence is in the 2014 manual: CPU-to-CPU communication through the communication blocks “is not restricted by the protection level of the CPU, unless PUT/GET communication is deactivated”. That sentence refers to the legacy protection levels. Our reading: with PUT/GET allowed, the protection level does not stop a remote partner communicating through those blocks.
With firmware V3.1 the box starts unticked and greyed out. When a panel or another PLC won’t talk, the temptation is to tick it and move on. Before you do, write down which partner uses it and why. If nobody can answer, it stays off.
Secure PG/HMI communication
From TIA Portal V17 and S7-1500 firmware V2.9, traffic between the CPU, the engineering station and the panel can run over TLS. The setting is again under “Protection & Security > Connection mechanisms”, check box “Only allow secure PG/PC and HMI communication”. Three things to know before you tick it:
- a CPU set this way “can no longer be reached online” by anything using legacy communication. Confirm your panel supports secure communication first, then tick;
- a project created in TIA older than V17 and loaded onto a V2.9 CPU behaves like a V2.8 CPU: swapping the CPU does not bring TLS with it;
- once the certificate expires, the secure connection from panel or engineering station can no longer be established.
The password for confidential PLC configuration data
It has existed since STEP 7 V17 and protects private keys and other confidential configuration data. Lose it and reset it, and the web server, OPC UA and PG/HMI certificates may have to be created again. You set it in “Protection & Security > Protection of the PLC configuration data”; password strength rules live in “<project name> > Security settings > Settings”, “Password policies” area. From V21 with firmware V4.1 you can extend it to the entire configuration, and then the password is also needed to upload from a memory card into STEP 7.
The problem here is not password strength. It is custody. Four facts from the communication manual:
- using one password for a group of CPUs is allowed, but if one is compromised, all of them are exposed;
- with firmware V4.1, a backup made with “Online > Load backup from online device” can only be restored with the same password used when it was created;
- the “SET_PWD” job writes the password as plain text to a file on the memory card; the manual says to store the card in a safe location;
- a replacement CPU should not arrive with a configuration or a password already set.
Our take: this password is part of the project backup. It belongs in the plant’s shared password manager, next to the TIA project, and at least two named people know it. A long password held by one person is worth less than a decent one stored in the right place, because on restore day that person may not be there. Restoring is covered in the article on PLC and HMI backups for recovering after ransomware.
Know-how and copy protection: the code, not the access
Know-how protection hides a block’s code. Per the 2014 system manual, without the password you can still read the block title, comments, properties and interface, and you can still copy, delete, call, compare online/offline and load the block. The same manual puts it the other way round: configuring an access level does not replace know-how protection. The two add up. They do not substitute for each other.
Copy protection binds blocks to the memory card’s serial number, and the block only runs with that card inserted. The 2014 manual gives the order: copy protection first, then know-how protection on the same block, otherwise copy protection can be reset. The menu path for copy protection is not in the sources we used, so look it up in the documentation for your version.
What about the safety program password?
Different thing. The Siemens manuals used for this article do not cover it, so we do not describe how it works. This article is also not about recovering lost passwords: it is about not ending up needing to.
Example scenario: Line P1
Line P1 is a made-up plant: a palletising line with an S7-1500 CPU at 192.168.10.10, a Comfort HMI panel at 192.168.10.20, two ET 200SP I/O stations at 192.168.10.31 and 192.168.10.32, two switches, a service laptop at 192.168.10.100 and a remote access gateway at 192.168.10.2. In the scenario the project is in TIA Portal V19 and the CPU runs firmware V3.1.
| User (CPU 192.168.10.10) | Right | Why |
|---|---|---|
| Anonymous (anyone connecting without a user, including the panel at 192.168.10.20) | HMI access, via legacy access control | In V19 the panel-to-CPU connection does not support named users, so in the scenario the panel gets HMI access only. This is a scenario choice, not a Siemens procedure: check the panel connection settings in your own project. Our reading: anyone who reaches the CPU without logging in gets the same rights as the panel, so they can read and write tags. |
| maint.p1, shift maintenance technician | Read access | Diagnostics and online/offline compare, no download. Can put the CPU in STOP and change the clock: they know it, and the line procedure says so. |
| prog.p1, programmer on the laptop at 192.168.10.100 | Full access | Downloads of blocks and configuration, test functions, firmware updates. Runtime timeout set, but the source is the web server manual and it doesn’t say whether this applies to a TIA Portal online session: test it on the bench. A laptop left connected with Full access is still the worst case. |
| remote.p1, external technician through the gateway at 192.168.10.2 | Read access | Reads and diagnoses. When and for how long the gateway lets them in is decided outside the CPU: see secure remote access to a PLC and what not to do. |
The rest of the P1 configuration: PUT/GET off, because in the scenario no partner uses it; a confidential configuration data password unique to this CPU and not shared with other lines, kept in the plant password manager and known to the line manager and their deputy. Panel users, the ones the operator logs in with on the Comfort, are a separate list with separate rules.
How we check it
These tests are not from the manual. They are how we confirm a setting is really there. Run them on the bench or during commissioning, never on a line in production.
- From the laptop at 192.168.10.100 with no login, a download to the CPU must be refused. As maint.p1, refused as well. As prog.p1, it must go through.
- Check whether access attempts show up in the diagnostics buffer: the 2014 manual documents this for level passwords, not for UMAC logins.
- With PUT/GET off, a client reading tags over S7 PUT/GET communication must get an error.
- Restore a backup onto a test CPU using the confidential data password taken from the password manager, not from somebody’s memory.
What not to do
- Leave Anonymous on Full access “just for commissioning”. Siemens’ operational guidelines say default passwords must be changed during commissioning, and the same logic applies to access left open for convenience.
- Use the same confidential data password on every CPU in the plant. The manual allows it and also spells out what happens when one leaks.
- Rely on know-how protection to block downloads. It doesn’t.
- Tick PUT/GET to get something talking without knowing who uses it.
- Leave the memory card with the SET_PWD job in the cabinet: it holds the password in plain text.
Limits of this article
- Items marked “2014 manual” come from the S7-1500 system manual of that year: the substance holds, menu names may have changed. The other paths are from the 11/2025 manuals; on V20, or a V21 with different updates, check them on your own installation.
- We do not know whether V20 and V21 support named users for the panel-to-CPU connection. V19 does not.
- The safety program password, firmware updates and secure boot are out of scope.
Sources
- Siemens, User Management & Access Control with TIA Portal V19, application example 109973173, V1.0, 07/2024.
- Siemens, S7-1500, ET 200MP, ET 200SP Communication Function Manual, A5E03735815-AN, 11/2025.
- Siemens, S7-1500 Web server Function Manual, A5E53797648-AB, 11/2025.
- Siemens, S7-1500/ET 200MP System Manual, A5E03461182-AC, 12/2014 edition (dated).
- Siemens, CPU 1518-3 PN Equipment Manual, A5E53640193-AA, 11/2024.
- Siemens, Cybersecurity for Industry – Operational Guidelines, version 2.2.1, April 2024.
Last checked: 29 September 2026
“Semplifica, automatizza, sorridi: il mantra del programmatore zen.”
Dott. Strongoli Alessandro
Programmatore
CEO IO PROGRAMMO srl
