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 and its password rules right here in Studio and write them back to the project. Editing the roles and what each one is allowed to do, and giving a project its first protection, arrive in a coming release. Until then make those changes in TIA Portal and press Refresh in Studio to see them.

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.

Group membership and the group description are administered in your central user management, so Studio shows them and marks them as not changeable here. Which roles a group carries is on this page.

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

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 holds the password rules of the project, on three pages.

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, and names the accounts that hold the administrator role.

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.

Giving a project its first administrator from Studio arrives in a coming release. Today, switch protection on in TIA Portal.

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.

The assistant will not set a password and will not protect a project. Those stay actions you take in Studio yourself, and the assistant points you to them instead of doing them.

Reading the two pages is part of your TIA Portal connection and needs no extra licence. Changing users and password rules from Studio, and asking the assistant about the security area, needs a Pro licence or higher.