Project Security

Every TIA project can carry its own users, user groups and roles, decide what each role is allowed to do, and set the password rules those users have to follow. Studio shows all of it in one place, so you can check who may open a project and what they may do without switching to TIA Portal.

Open a project with Connect, then look in the project tree: under the project there is a Security settings folder with two entries, Settings and Users and roles. Double-click either one to open it. The folder appears for TIA Portal V17 and later; on an older version the project has no security area to show.

You can change the project's users, its roles and their rights, and its password rules right here in Studio and write them back to the project. A project that is not protected yet can be given its first administrator and its protection from Studio as well, see Protecting a project from Studio below.

Some values are shown with a small lock. Those are values TIA Portal does not hand out to another program, or values it works out for you. Hover the lock and Studio tells you in plain words why, and where you can change it instead.

Users and roles

Users and roles opens as its own tab with three pages: Users, User groups and Roles.

The Users page lists every account the project knows, one per row:

• whether the account is active
• the user name
• whether it is a user of this project or an account from your central user management
• the password, which is never readable, here or anywhere else
• the authentication method
• whether a runtime session times out, and after how many minutes
• the domain the account comes from, when it comes from the central user management
• the alias and the comment

The anonymous user, if the project has one, is marked as such in the list.

Select a row and the lower half of the page shows three tabs for that account:

• Assigned user groups, the groups the account belongs to
• Assigned roles, the full role list with a tick against the roles this account holds
• Assigned rights, everything those roles add up to, engineering rights and per-device rights together

Changing users

Above the list a small toolbar lets you Add User, set the password of the selected user, and Delete User. Editing a field in a row, ticking a role for an account, adding a user or staging a deletion does not touch the project straight away. Each change is collected in a Pending changes strip at the top of the tab, where you can see what is waiting, remove a single change, or Discard them all. Press Apply to write everything to the project in one step. Studio asks you to confirm first and tells you how many changes it will make, then reports how many went through.

Add User opens a small dialog for the name, an optional comment, the password typed twice, and whether the account starts active. As you type the password, Studio checks it against the project's own password rules and tells you at once if it is too short or missing a kind of character, so an account is never created with a password the project would reject.

Setting a password is always a direct action you take in Studio, never staged and never done for you. Pick the user, type the new password twice, and Studio applies it after the same live check.

If the connection to TIA Portal drops while changes are waiting, Studio keeps the pending list so nothing is lost, and you can apply it once the connection is back.

User groups

The User groups page lists the groups the project knows: the group name, its description, whether it is active, and the domain it comes from. Select a group and the lower half shows the roles that group carries.

The page is a read-only view. Groups come from your central user management, and their membership, their description and the roles they carry are administered there, so Studio shows them and marks them as not changeable here. A project without central user management carries no groups, and the page says so rather than leaving you with an empty table.

Roles and rights

The Roles page lists every role: its name, a description, the runtime session timeout and the comment.

Two kinds of role appear side by side. Roles that TIA Portal defines itself cannot be renamed or deleted, and their function rights are fixed. Roles created in the project can be changed, and Studio marks the difference on every row.

Select a role and the lower half shows three tabs:

• Engineering rights, what the role may do in the project itself, such as opening it for writing or changing the PLC program
• Runtime rights, picked per device, so you see exactly what the role may do on that panel or controller. A device without user management says so instead of showing an empty list.
• User-specific runtime rights, the catalogue of rights defined in this project

Changing roles and rights

A role created in the project can be edited here; a role TIA Portal defines itself stays read-only. A small toolbar above the list lets you Add Role and Delete Role. Rename a custom role, or give it a comment or a session timeout, by typing in its row, and set what it may do by ticking rights: on the Engineering rights tab for the project itself, and on the Runtime rights tab, one device at a time, for a panel or a controller. The User-specific runtime rights tab has its own Add Runtime Right and Delete Runtime Right buttons for the project's own catalogue of rights.

None of this touches the project at once. Each change joins the same Pending changes strip as the users, and Apply writes them all in one step after a confirmation. Deleting a role or a runtime right first tells you how many users, groups or roles still hold it, so you see what the deletion takes with it before you confirm.

If the project is not protected yet, TIA Portal does not report engineering rights at all, and it shows a shorter role list in its own editor. Studio says so on the page rather than leaving you to read an empty list as "this role has no rights".

Password policies

The Settings tab opens with four pages: Project protection, described further down, and three pages that hold the password rules of the project.

Password settings for Runtime and Engineering are the rules for the project's own users:

• the minimum length of a password
• how many digits it must contain
• how many special characters it must contain
• whether it must mix upper and lower case
• whether passwords expire, after how many days, and how many days ahead the warning starts
• how many previous passwords may not be used again

Password settings for S7-1200/1500 PLCs carry the single switch TIA Portal offers for that PLC family: whether the password policy applies.

Password settings for legacy PLCs carry the switch plus the minimum length, the digits, the special characters and the mixed-case rule for older controllers.

Change any of these values and a Save button writes them back to the project. Studio checks a value against the range TIA Portal allows before it saves, so a number that is too high or too low is refused with a plain message rather than written and rejected later.

The three pages need TIA Portal V18 or later. On V17 the pages are still listed and each one says which version it needs, so you are never left wondering whether a page failed to load.

Project protection

The Project protection page tells you whether the project is protected, names the accounts that hold the administrator role, and says how many users of its own the project carries.

A protected project asks for a user name and a password every time it is opened, in Studio as well as in TIA Portal. How that prompt works is described under Project Management.

Two things are worth knowing before you protect a project:

• Protection cannot be removed once it is on. Not in Studio, and not in TIA Portal. The only way back is a copy of the project made before protection was switched on.
• Protecting a project creates its first administrator account, and everyone who opens the project afterwards needs an account.

Protecting a project from Studio

When a project is not yet protected, the Project protection page shows a Protect Project button. It takes two steps.

First you confirm that you understand what protection does: it cannot be removed afterwards, it creates an administrator account and signs that account in, and it re-secures the password of every project user that already exists.

Then you fill in a short form: the administrator user name, the password twice, and the name of the project typed once, so a protect can never happen by accident. Choose Protect Project Now, and the project is protected and the new administrator is signed in. From then on the project asks for a user name and a password every time it is opened. If the new administrator cannot be signed in right away, the message says so and asks you to close the project and open it again with those credentials before you change anything else.

Because protection cannot be undone, make a copy of the project first if you want a way back.

Doing this from the assistant

The assistant reads the whole security area of the open project. Ask it in plain words, for example:

• "Who may manage users and roles in this project?"
• "Which roles can download to the PLC?"
• "Show me the password rules of this project."
• "What rights does the account Operator3 end up with?"

It answers with a short summary first and goes into a list only when you ask for one, so a project with dozens of roles and rights does not flood the chat. For a single user or a single role it gives you the full picture.

On request it also changes the security area for you. It can add a project user, rename one, switch one on or off, remove one, and change which roles a user holds; it can create, rename and delete a role you made in the project and set its rights; it can turn the anonymous user on or off; and it can adjust the password rules, all from the chat. For example, "Deactivate the account Operator3", "Give the Operators role the download right" or "Set the minimum password length to twelve".

Before it writes anything, the assistant shows you what the change adds and what it takes away and asks you to confirm. A change that removes access, deleting a user or taking a role away, is always previewed first, so nothing is taken away in one unseen step. It works from the security picture it last read, and if the project changed in the meantime it reads it again before writing.

Some things stay yours to do in Studio. The assistant does not set a user's password and does not protect a project; it points you to those instead of doing them.

Reading the two pages is part of your TIA Portal connection and needs no extra licence. Changing users, roles, rights and password rules, whether from the pages or by asking the assistant, and protecting a project need a Pro plan or higher.