Hardening an engineering station running TIA Portal

The engineering station is the point from which plant software is designed, modified and downloaded to controllers. A workstation running TIA Portal handles PLC projects, HMI configurations, network parameters, credentials and process know-how. Yet on many plants, the engineering station is treated like any office PC: open browser, email configured, local administrator account, no software restrictions, no structured backup.

The result is a wide attack surface with elevated privileges and direct access to the production process. Any compromise of the engineering station can potentially affect the entire plant: PLC code modification, HMI configuration tampering, intellectual property exfiltration, lateral movement across the OT network.

Hardening these workstations does not require special products. It requires discipline, consistent choices and the willingness to treat the engineering station for what it is: a critical plant asset, not a general-purpose desktop.

Who this article is for

Anyone who manages or maintains TIA Portal engineering workstations in production environments. System integrators, automation engineers, plant technicians, OT security officers. Most of the guidance also applies to environments with other Siemens tools (STEP 7, WinCC) and, with adjustments, to engineering workstations from other vendors.

Operating system hardening

TIA Portal runs on Windows. That means the first line of hardening is the operating system itself. The starting point is reducing the machine's attack surface by removing everything that is not needed for the engineering tool to function.

Unnecessary Windows services and features

An engineering station does not need Bluetooth, Xbox Game Bar, OneDrive, Cortana, Windows Media Player or most of the services enabled by default on a standard Windows 10 or 11 installation. Disabling unnecessary services reduces attack vectors and improves overall stability.

In practice, the approach is to start from the list of active services and evaluate each one. Some services are clearly useless on an engineering workstation; others need to be checked against TIA Portal and communication driver dependencies. Siemens publishes compatibility lists with supported Windows versions and software prerequisites: starting from those is the safest way to avoid issues.

A method that works well is to install Windows from a clean image, apply cumulative patches, install TIA Portal with only the components strictly needed, and then disable whatever remains unused. Doing the opposite — starting from a PC already in use and trying to "clean it up" — is less reliable and almost always leaves residues behind.

Operating system security settings

• Windows Firewall: keep it enabled and configure explicit rules for the ports used by TIA Portal and PLC communication (typically TCP 102 for S7 communication, plus diagnostic and download ports). All other inbound traffic should be blocked by default.
• Remote Desktop: disable RDP unless strictly necessary. If needed, limit it to specific users and enable Network Level Authentication.
• Autorun and autoplay: disable completely. USB drives are one of the most common attack vectors in industrial environments.
• PowerShell: consider Constrained Language Mode or, where feasible, restrict execution of unsigned scripts via policy.
• Event log sizing: increase the size of Security and System logs. On many default Windows installations, logs rotate too quickly to be useful for post-incident analysis.

If the workstation is domain-joined, many of these settings can be pushed via Group Policy. If it is standalone — as is often the case in smaller plants or with portable workstations — they need to be applied locally and documented.

User management

On too many engineering stations, everyone works under the same account, which happens to be a local administrator. This makes it impossible to distinguish who did what and grants maximum privileges to anyone who sits down at the machine.

Named accounts and least privilege

Each person accessing the engineering station should have a named account. The local administrator account should be protected with a strong password, stored securely and used only for OS maintenance tasks. Day-to-day work — opening TIA Portal, reviewing projects, running diagnostics — does not require administrator privileges.

TIA Portal itself has a project-level user access management system (User Management Component, UMC) that allows assigning differentiated roles and permissions. Enabling this feature lets you separate those who can only read a project from those who can modify it and download it to the PLC. It is not a perfect mechanism and it adds complexity to daily operations, but on plants where multiple people work or where external contractors are involved, it is a practical measure to reduce the risk of unauthorised changes.

Service accounts and shared accounts

If service accounts exist for automated communication (for example, towards a version control system or an OPC server), they should be documented, with strictly limited permissions and managed password rotation. Generic shared accounts ("automation", "engineering", "admin") should be phased out progressively. As long as they exist, any log event associated with that user is useless for accountability purposes.

TIA Portal project protection

A TIA Portal project contains PLC software, HMI configuration, hardware parametrisation, networks, diagnostics and in many cases the company's process know-how. Protecting the project means protecting both intellectual property and the ability to restore the plant.

Block-level know-how protection

TIA Portal allows setting know-how protection on blocks (OBs, FBs, FCs, DBs) to prevent reading and modification without the correct password. This protection is not military-grade encryption — it is a containment measure that discourages casual access and limits source code visibility to unauthorised users. It should be used selectively: protecting everything makes legitimate maintenance difficult; protecting critical blocks (process cycles, recipes, safety-related logic) is a reasonable compromise.

Project-level protection

At project level, TIA Portal offers the option to associate a password for opening the project file. This prevents anyone without credentials from opening it. Here too, the password needs controlled management: if everyone knows it, the protection is void; if only one person knows it and that person is unavailable, there is an operational problem.

Project password management should be documented and shared securely — a dedicated password manager or a protected offline archive is preferable to emails, sticky notes or Excel files on the desktop.

Application whitelisting

Application whitelisting is one of the most effective measures for an engineering station, even though it is among the most demanding to maintain. The principle is simple: only explicitly authorised software can run on the machine. Everything else is blocked.

Windows provides native tools for this: AppLocker in Enterprise and Education editions, and Windows Defender Application Control (WDAC) on Windows 10 and 11. AppLocker allows defining rules based on publisher, path or file hash. WDAC offers more granular control but is also more complex to configure.

In practice, implementing whitelisting on an engineering station requires significant upfront work: all legitimate executables must be identified (TIA Portal, communication runtimes, drivers, Siemens auxiliary tools, any third-party utilities) and rules must be created to authorise them without disrupting normal operation.

The real risk is blocking something that is needed. This is why it makes sense to start in audit mode (logging only, no blocking), verify over an adequate period, and then switch to enforcement mode. TIA Portal updates and HSP/SSP packages require a review of the rules, since new executables and DLLs are added or replaced.

The benefit is tangible: a ransomware binary, a lateral movement tool or an unauthorised executable brought in on a USB drive will be blocked before it even starts. On a machine whose sole purpose is to run TIA Portal and communicate with PLCs, whitelisting makes full sense.

Patch and update management

Updating an engineering station is not the same as updating a corporate laptop. Every OS patch, every TIA Portal update and every communication driver change can have side effects on tool behaviour, PLC firmware compatibility or online communication stability.

Windows updates

Siemens regularly publishes information on the compatibility of Microsoft patches with its products. Before applying a Windows cumulative update on a production engineering station, it is good practice to check the compatibility notes and, where possible, test on a non-critical machine first.

Leaving Windows Update in fully automatic mode on an engineering station is risky: an unexpected reboot during commissioning or an incompatibility with a TIA Portal component can cause serious operational problems. It is better to configure updates in controlled mode — automatic download, manual installation — or manage them through WSUS or similar tools with explicit approval.

TIA Portal updates

TIA Portal has its own update cycle: major versions (V17, V18, V19, V20), updates and hotfixes. Upgrading the major version should not be taken lightly. Each TIA Portal version supports specific firmware versions of CPUs, modules and HMI devices. Upgrading TIA Portal without verifying compatibility with the hardware installed in the field can prevent downloads or communication with devices.

Siemens hotfixes are less invasive and generally address specific bugs or vulnerabilities. These should also be applied with awareness, but the risk of incompatibility is lower.

A reasonable practical rule: keep security components updated (antivirus, critical OS patches, TIA Portal security hotfixes) on a short cycle; schedule major TIA Portal version upgrades during maintenance windows, with a full backup and the ability to roll back.

PLC access protection

The engineering station is the link between the engineer and the controller. If the workstation is compromised, the PLC is at risk too. But protection is not only about the engineering station: PLCs themselves offer protection mechanisms that need to be configured.

Siemens CPU access levels

S7-1200 and S7-1500 CPUs support configurable protection levels set from within TIA Portal. These levels restrict which operations can be performed remotely: reading, writing, HMI access, full download. Setting an appropriate access level prevents anyone from connecting to the PLC and modifying the program without authentication.

Newer-generation S7-1500 CPUs also support access control based on individual passwords for different operations (read, write, full access). This allows differentiating between those who can only monitor and those who can download changes.

Secure communication

S7-1500 CPUs with recent firmware support TLS communication for the engineering channel. Enabling secure communication protects the traffic between the engineering station and the PLC from interception and tampering. It requires certificate management, which adds operational complexity, but on exposed plants or incompletely segregated networks it is a relevant measure.

It is worth noting that not all CPUs support all security features in the same way: it depends on the hardware version and firmware. Before relying on a specific feature, compatibility should be verified against current Siemens documentation.

Engineering station backup

The engineering station must be included in the plant backup strategy. Saving TIA Portal projects alone is not enough: the backup must enable rebuilding a working workstation within a reasonable timeframe.

What to back up

• TIA Portal projects: exported or archived (.zap), with a record of the TIA Portal version used
• Licences: document which TIA Portal, STEP 7, WinCC and Safety licences are installed and how they are activated (Automation License Manager)
• Operating system configuration: disk image or at least detailed documentation of the configuration (services, policies, firewall, user accounts, installed software)
• Drivers and hardware support packages (HSP/SSP): the specific versions installed, because the latest version is not always the correct one for the plant
• Certificates and keys: if TLS or VPN connections are used from the engineering station
• Auxiliary tools: PRONETA, Automation Tool, any configured third-party utilities

Where and how to store backups

Backups should be stored separately from the engineering station itself. A NAS on the same unprotected network as the engineering station is not a backup — it is a copy exposed to the same risk. An offline medium, a volume on a segregated network, or a backup on dedicated infrastructure is preferable.

Frequency depends on how often changes are made. After every significant change to the project or to the machine configuration, an updated backup should be the rule. At least once, it should be verified that a functional workstation can be restored from the backup: installing TIA Portal, reimporting projects, reactivating licences, re-establishing PLC communication.

If restoration has never been tested, the backup is an assumption, not a guarantee.

Network management and segregation

The engineering station needs to communicate with PLCs, possibly with SCADA or historian servers and with version control or backup systems. It does not need to browse the internet, access email or reach the office network.

In an ideal scenario, the engineering station is connected to the OT network via a dedicated interface with no direct connection to the IT network or the internet. In practice this is not always achievable — updates, Siemens package downloads, communication with ticketing or version control systems may require connectivity. In these cases, the compromise is a controlled connection, mediated by a firewall with restrictive rules and monitored.

The use of dual network cards — one facing the OT network, one facing the IT network — without an intermediate firewall is a configuration that is often seen but creates a direct bridge between the two worlds. The engineering station effectively becomes an uncontrolled router. If this configuration exists, it should be documented, assessed and ideally replaced with a more segmented architecture.

Antivirus and endpoint protection

Siemens maintains a list of antivirus products that have been tested for compatibility with TIA Portal and other platform products. Using an untested antivirus can cause performance issues, block legitimate executables or interfere with PLC communication.

The exclusions recommended by Siemens for TIA Portal installation paths and project files should be configured. Without exclusions, real-time scanning can noticeably slow down project opening and compilation.

Antivirus alone is not sufficient: on an engineering station it is a complement to whitelisting and OS hardening, not a substitute. On air-gapped machines or those with very limited connectivity, signature updates need specific planning — via manual updates or an internal distribution server.

Physical port control

USB ports are a classic attack vector in industrial environments. Drives with infected firmware, dedicated attack devices, simple unauthorised copying of projects — the risk is real and well documented.

Options range from completely disabling unnecessary USB ports (via BIOS/UEFI or system policy) to using device control solutions that only allow authorised devices. The choice depends on the operational context: if the engineering station is fixed inside a control cabinet and never needs USB, disabling is the simplest option. If USB drives are needed to transfer projects or updates, a controlled process is required — for example, a dedicated scanning station before use.

Physical network ports also deserve attention: a portable engineering station connected to an uncontrolled network (hotel, customer network, hotspot) and then brought back onto the OT network can carry threats.

Logging and visibility

An engineering station without logging is a black box. In the event of an incident, it becomes impossible to reconstruct who did what, when and from where.

At a minimum, operating system logs (Security, System, Application) must be active, with adequate sizing and ideally forwarded to a centralised collector. Logins, failed attempts, software installations, policy changes and remote access events should be retained.

If the infrastructure allows it, TIA Portal application logs (download activity, online modifications, project access) also help reconstruct events. The depth of logging depends on organisational maturity and available tools, but starting at least with Windows logs is a step accessible to anyone.

Common mistakes and realistic trade-offs

Perfect hardening on paper is useless if it does not hold up in daily practice. Some recurring mistakes worth highlighting:

• Hardening done once and never updated: every TIA Portal update, every configuration change or every new package installed can invalidate whitelisting rules, antivirus exclusions or firewall policies. Hardening is an ongoing process, not a one-off activity.
• Rules too restrictive that get bypassed: if whitelisting blocks a tool needed during commissioning, the field technician will find a way to disable it. A sustainable and respected configuration is better than an ideal configuration that is systematically circumvented.
• Project backups but not machine backups: having the .zap project file is not enough if rebuilding the engineering station takes three days, licences need reactivation and packages need reinstalling. The backup must cover everything needed to become operational again.
• No separation between development and production environments: using the same workstation to develop, test and download to production without any verification process increases the risk of errors and uncontrolled changes.
• Single shared administrator account: if everyone uses the same account with maximum privileges, every traceability and project protection measure becomes ineffective.

Plant reality imposes trade-offs. But trade-offs should be made consciously, documented and periodically reassessed — not accepted by default through inertia.

A reasonable priority sequence

Not everything can be done in a single day. For those starting from an unprotected engineering station, an intervention sequence that balances impact and effort might look like this:

Our perspective

The engineering station is probably the most underestimated asset in OT security. It has direct access to PLCs, holds the plant's know-how, is used by multiple people (often with maximum privileges) and is the first point of contact between engineering work and the production process. Treating it like any other PC is a risk that many organisations carry without realising it.

Hardening does not require extraordinary budgets. It requires decisions, consistency and maintenance over time. All the measures described here are implementable with tools already available, provided the time is invested to configure, test and sustain them.

Official resources and useful guides

• Siemens Industrial Security
• Siemens ProductCERT — Security Advisories
• Siemens — Operational Guidelines for Industrial Security (PDF)
• NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security
• CISA — Industrial Control Systems
• ISA/IEC 62443 — Industrial Automation and Control Systems Security