S7-1200 Web Server Login After V4.0 Firmware: Restore Access

Problem Overview

After migrating an S7-1200 CPU from firmware V3.0 to V4.0 (or replacing the hardware with a V4.0 unit), field engineers report that the integrated web server rejects the previously working admin login. Symptoms typically include a browser prompt that returns HTTP 401 Unauthorized, a Siemens-branded Login failed message, or an indefinite re-prompt for credentials. The web pages render only the public status pages (e.g. Introduction, Module Information) that do not require authentication; any page that triggers a user-rights check fails immediately.

This is a documented behavior change in the SIMATIC S7-1200 web server implementation, not a defect. Beginning with firmware V4.0, Siemens removed the implicit, hard-coded admin user and the matching password that the V3.x firmware accepted as the project default. From V4.0 forward, every account that can reach the protected areas of the web server must be explicitly created inside the TIA Portal project and downloaded to the CPU.

Affected CPUs and Firmware Versions

The login failure described here applies to every S7-1200 CPU that has been brought up on firmware V4.0 or later. The most common part numbers encountered in field service are listed below; always confirm the exact MLFB on the CPU nameplate before applying any of the configuration steps that follow.

The web server function itself is firmware-version dependent. The S7-1200 G2 generation expanded the web server feature set considerably (see the SIMATIC S7-1500, S7-1200 G2, ET 200SP, ET 200pro Web server Function Manual), but the V3.0 vs V4.0 authentication gap is shared across the entire S7-1200 family.

Root Cause: V4.0 Security Model Change

The V3.x web server exposed a single, project-defined admin account. If the project contained no User management entries, the PLC still accepted the username admin with the project password, because the firmware automatically generated this implicit user. Beginning with V4.0, the firmware no longer synthesizes any user from the project password. Instead, every login attempt is checked against the explicit user list that the project compiles and downloads.

The reference for this behavior is the S7-1200 Programmable Controller System Manual, chapter Protecting access to the CPU with a password. It states that the web server user list is consulted independently of the CPU's read/write/commissioning password levels. With no entries in that list, the server cannot authorize any user.

V3.0 to V4.0 Migration Path

Engineers often attempt to upgrade V3.0 firmware to V4.0 in place because the V3.0 CPUs share the same mechanical form factor and connector layout as their V4.x replacements. Siemens explicitly forbids this. The official documentation states:

To upgrade a V3.0 CPU to a V4.x CPU, you must replace the CPU hardware. You cannot upgrade a V3.0 CPU to a V4.x CPU by firmware update.

Source: Exchanging a V3.0 CPU for a V4.x CPU in the TIA Portal manual collection.

If the controller in your cabinet was previously a 6ES7215-1AG31-0XB0 (V3.0) and is now a 6ES7215-1AG40-0XB0 (V4.0), the controller was physically replaced. In that case the project on your engineering station may still reference the old part number, the old firmware, or the old user list. The web-server problem is therefore usually discovered the first time a browser is pointed at the new hardware.

If the controller in your cabinet is still a -1AG31- variant and you have only updated the TIA Portal project to V4.0 syntax, the firmware does not actually contain V4.0 web-server logic. Confirm the firmware on the live CPU under Online > Online & diagnostics > General. The Module version field must show 4.0.x (or higher) before V4.0 web-server semantics apply.

Solution: Configure User Accounts in TIA Portal

The remediation is to populate the Web Server user list inside TIA Portal, recompile the project, and download it to the CPU. The procedure below assumes TIA Portal V15.1 or newer. TIA Portal V13 SP1 supports the same fields, but menu paths differ slightly; for V13 SP1 refer to the system manual dated 03/2014, section 11.2 of the S7-1200 system manual.

1. Open the project that targets the V4.0 CPU.
2. In the project tree, right-click the CPU (for example, PLC_1 [CPU 1215C DC/DC/DC]) and select Properties.
3. In the navigation pane, choose Web server.
4. Check Activate web server on this CPU. Note the IP address that the CPU will use; the same address is the URL that the browser must point at.
5. Optionally check Permit access only via HTTPS. If HTTPS is selected, a self-signed certificate is generated; the browser will warn that the certificate is not trusted until you add an exception or import the CPU certificate.
6. In the same dialog, switch to the User management sub-page.
7. Click Add to create a new user. The dialog exposes the following fields:

Repeat step 7 for every account that should exist on the controller. Up to 32 users can be defined per CPU. Each user must have at least one permission granted; an account with no permissions cannot log in.

8. Click OK to close the CPU properties dialog.
9. Select the CPU in the project tree and click Compile > Hardware (rebuild all).
10. Download the rebuilt project to the CPU: right-click the CPU, choose Download to device > Hardware and software (only changes). Use Hardware and software (all) if the CPU type changed from a V3.0 to a V4.0 part number.

Web Server Activation and Permission Model

The web server activation check box is independent of the user-management table. A common mistake is to enable the web server, leave the user list empty, and assume that the CPU will fall back to the V3.0 behavior. It will not; the server starts, serves the un-authenticated Introduction and Module Information pages, and returns 401 on every protected page.

Permission aggregation follows an OR model: a user only needs the appropriate permission bit set to perform an action. There is no concept of role inheritance in the V4.0 firmware. If you need an operator role, create a single user with Read tags + Query diagnostics enabled; if you need a commissioning engineer role, create a separate user with all six permissions enabled. Do not share a single account across these roles in production environments; every shared account defeats the audit trail that Online & diagnostics > Web server log can provide.

The web server also retains the legacy CPU password scheme for protecting the engineering interfaces (PG functions, HMI connections, S7 communication). The two protection systems are independent. A user can have a fully open CPU password for the engineering station and still require a web-server user account to view diagnostic pages from a browser on the plant network.

HTTPS and TLS Certificate Handling

If you select Permit access only via HTTPS, the CPU generates a self-signed certificate during the next restart after the project is downloaded. The certificate is bound to the CPU's IP address and is unique per device. Browsers that reach the CPU will display a Your connection is not private warning until the certificate is either:

• Trusted once via the browser's Advanced > Add exception dialog (Firefox) or the Proceed to ... (unsafe) link (Chrome / Edge).
• Permanently trusted by importing the CPU certificate into the operating system certificate store or into the Java runtime that HMI panels use.

The certificate can be exported directly from the browser session: click the padlock icon in the address bar, view the certificate, and use Details > Export. The exported file can then be distributed via group policy to all engineering laptops that need to reach the CPU.

If you leave the web server in HTTP-only mode, the username and password are transmitted in clear text. This is acceptable on a trusted engineering sub-net behind a firewall, but it is not acceptable on a plant-floor network that shares infrastructure with the office IT system. Enable HTTPS in any installation where the web server is reachable from outside the immediate cabinet.

Login Procedure with New Credentials

After the download completes and the CPU returns to RUN, open a browser and point at the CPU URL:

http://<cpu-ip-address>/          (HTTP only)
https://<cpu-ip-address>/         (HTTPS)

The Introduction page should render without prompting for credentials. Click any link that requires authentication (for example Tag status or Diagnostic buffer) and the browser will display a Siemens-branded login dialog. Enter one of the user names and passwords configured in TIA Portal. If the dialog closes and the requested page renders, the user list has been downloaded correctly.

If the dialog reappears immediately, or the page displays The user name and/or password is incorrect, the user list on the CPU does not contain the account you typed. Cross-check:

• Spelling and case of the user name in TIA Portal vs in the browser prompt.
• Whether the project you downloaded actually targets the CPU you are connected to (right-click the CPU in the project tree, Go online > Online & diagnostics, compare IP and module version).
• Whether a different project (perhaps a backup) was downloaded by mistake.

Verification Steps

Use the following checks to confirm that the web server is fully functional after the user list is loaded:

1. Module version: Online > Online & diagnostics > General > Module version reports 4.0.x or higher.
2. Web server active: Online > Online & diagnostics > Web server shows Web server is activated and lists the bound IP address.
3. User list size: the same page shows the number of users currently stored in the CPU. It must equal the number of entries in TIA Portal.
4. Authentication: log in with the lowest-privilege account first. The Tag status page should render. Log out, log back in with a higher-privilege account, and verify that a write to a tag succeeds.
5. Diagnostics buffer: the Diagnostic buffer page should display recent entries, including the timestamp of the project download.
6. Audit trail: Online > Online & diagnostics > Web server log lists each successful and failed login attempt with the source IP. Use this to confirm that the login that just succeeded is recorded.

V4.1 Web Server Pitfalls (Siemens KB 109476758)

The same class of "cannot access the web server" complaint reappeared with firmware V4.1. Siemens published a dedicated knowledge base entry that documents the configuration steps and lists the additional parameters that V4.1 introduced. The KB entry is the official starting point for any V4.1 investigation:

Why can you not access the web server of the S7-1200 CPU firmware V4.1? (SIOS ID 109476758)

Key points from that KB entry that overlap with the V4.0 scenario:

• The web server must be activated in CPU Properties > General > Web server, not only in the project-wide settings. A CPU that was previously in RUN with V4.0 firmware and was then updated to V4.1 will retain the V4.0 activation state, which is preserved across the V4.1 firmware update.
• V4.1 introduces the Automatic update of the web server pages flag. If the flag is unchecked, browser-side caching can serve a stale page that still references the V4.0 user list. Clearing the browser cache and reloading resolves the symptom but does not fix the root cause; check the box and redownload the project.
• V4.1 enforces a stricter password policy: passwords must contain at least one uppercase letter, one lowercase letter, one digit, and one special character. Accounts created under V4.0 that do not meet the V4.1 policy are silently rejected; the CPU does not warn that the password is the problem, only that the login failed.

Troubleshooting Matrix

Best Practices and Security Notes

• Use a separate account for every role. Operator, maintenance, and auditor should each have a distinct user with the minimum permissions required. Sharing a single admin account defeats the audit log.
• Use HTTPS in production. The CPU self-signed certificate is acceptable for plant-floor use. For multi-CPU installations, distribute a single CA-signed certificate per cabinet rather than per CPU to reduce certificate maintenance overhead.
• Treat the web server user list as configuration data. Include it in the project's source control so that engineering changes to the user list are versioned alongside the program logic.
• Document the user list in the project documentation. Add a Web server accounts table to the project PDF so that on-call engineers know which credentials to use when the cell phone rings at 3 a.m.
• Schedule periodic password rotation. The V4.x web server has no native password-expiry mechanism; rotate passwords by editing the project and redownloading. Use a maintenance window to avoid unintentional logouts of HMI panels that cache the credentials.
• Keep TIA Portal and the CPU firmware aligned. Mixing a V4.0 project with a V4.6 CPU (or vice versa) is supported but introduces subtle behavior changes, particularly in the password policy and the auto-update flag described in KB 109476758. Pin both versions explicitly in the project documentation.