Resolving S7-1200 Web Server Login Block After 6 Failed Attempts

Problem Overview

The SIMATIC S7-1200 CPU 1214 DC/DC/DC with integrated web server, programmed in TIA Portal V11 SP2 Update 5 and running firmware V3.02, exhibits a persistent login block under a specific sequence of operations. The symptom is reproducible: an authenticated user opens the user-defined web pages, performs six (6) successful logins, closes the browser between each session without explicitly clicking Logout, and is then refused on the seventh (7th) attempt. From that point, all further login attempts from any browser instance (Internet Explorer or Chrome, HTTP or HTTPS, with Windows Firewall disabled) fail with invalid user name or password. The CPU only releases the lock after a power cycle. STOP/RUN toggling does not clear the internal session table; MRES (memory reset) does clear user program data and is not recommended as a workaround.

Siemens Support in the Netherlands reproduced the issue, confirmed the firmware behavior, escalated the report to Siemens headquarters in Germany, and disclosed two architectural constraints relevant to the root cause:

1. The embedded web server permits a maximum of 30 concurrent active HTTP connections per CPU.
2. Authenticated user sessions are released approximately 30 minutes after the last activity (session idle timeout).

Once the idle timeout expires, login is again possible, but the leak mechanism repeats on the next browser-close cycle. The bug is treated by Siemens as a firmware defect in V3.0.2 and was under investigation at the time of report. The remainder of this reference describes how to characterize the fault, mitigate it in production, and plan an upgrade path.

Affected Hardware, Firmware, and Engineering Software

CPUs from the V2 firmware family (CPU 1214 order number suffix -0XB0 with V2.x firmware) are not affected by this specific session-leak because their web server uses a different session-handling implementation. CPUs with firmware V4.x and later (V4.0, V4.1, V4.2, V4.3, V4.4, V4.5, V4.6) ship with the rewritten web server introduced for the S7-1200 G2 / V4 platform and do not exhibit the same leak pattern under the same test.

Root Cause: Session Table Leak on Browser Close

The S7-1200 firmware V3.0.2 web server maintains an internal session table that maps the cookie siemens_ad_session to a CPU-side session handle, an authenticated user identity, and an idle timer. When a user authenticates successfully, the server allocates a new entry, returns a session cookie with the HttpOnly and Discard attributes set (the latter instructs compliant browsers to drop the cookie on browser exit), and starts the 30-minute idle countdown.

The leak mechanism is the following sequence:

1. User authenticates → server creates session handle S1, returns siemens_ad_session=A1B2C3 cookie.
2. Browser stores the cookie with Discard → cookie is removed when the user closes all browser windows.
3. User closes the browser → the TCP socket terminates; the browser no longer holds S1.
4. Server receives FIN/RST → expected behavior would be to free S1 immediately because the socket is gone.
5. Defect: Server marks S1 as pending close but does not release the table slot for the duration of the idle timeout, because the cookie-based session is tracked independently of the TCP socket.
6. User repeats 1–5 six times → six entries are stranded.
7. Seventh login → new session allocation exhausts the available session slots in the table and is rejected with a generic login invalid response.

The 30-connection counter referenced by Siemens Support is a separate resource pool (TCP listeners / HTTP workers). It is not the same counter as the session table, but both resources scale with the number of stranded sessions because each leaked session also holds an HTTP worker until the socket is reaped. Once the idle timer (approximately 30 minutes) fires for any of the stranded entries, that slot is returned to the free pool and a new login is accepted — which matches the user's observation that the block self-clears after roughly half an hour.

Cookie Mechanics: siemens_ad_session

The session cookie has the following observable properties in the browser cookie store after a successful login:

Modifying the cookie's expiration to a future date (for example using browser developer tools or an extension) does not extend the server-side session. The web server stores the idle timer independently; on the next request, the modified cookie value is rejected because the server still owns the original handle S1 and will not reissue it. This was confirmed by the reporting engineer, who observed that manually rewriting the expiration made the next login impossible rather than extending the existing one.

Diagnosing the Login Block

The diagnosis is straightforward and does not require TIA Portal to be online, only a standard web browser and the PLC's IP address. Use the procedure below to confirm that the fault matches the firmware V3.0.2 session leak and not an unrelated authentication problem.

1. Open http://<plc-ip> in Internet Explorer or Chrome with cookies enabled (default configuration).
2. Click Log in, enter the configured user name and password, confirm successful entry to the user-defined pages.
3. Close the browser entirely (all windows). Do not click Log out.
4. Re-open the browser, navigate to the same URL, repeat login. Repeat steps 2–3 for a total of six (6) successful cycles.
5. On the seventh (7th) attempt, the login frame accepts the credentials but returns an invalid user name or password error. The PLC is now blocked.
6. Wait 30–35 minutes without any browser activity. Attempt login again. Success confirms the session-leak signature rather than a credential or firewall problem.

If login fails within seconds of correct credentials without any prior browser-close history, the cause is not the V3.0.2 leak. Investigate instead:

• Wrong password (→ check the user list in TIA Portal under Web server → User management).
• Access protection enabled for the HMI/PLC (different from web server protection — configured under Properties → Protection → Access level).
• Time-of-day not synchronized (V4.x requires a valid RTC; V3.x is more permissive but TLS handshakes may fail).
• Wrong IP address or HTTPS-only web server selected while connecting over HTTP.

Workarounds and Mitigations

The following mitigations are listed in order of recommended deployment for production systems. Combine them where appropriate.

1. Always use the explicit Logout button

The most reliable mitigation. Adding a logout link to every user-defined web page and training operators to use it eliminates the leak entirely. The server-side DELETE /<session> handler is implemented in firmware V3.0.2 and correctly frees the session slot.

2. Configure browsers to retain cookies across sessions

Setting the cookie persistence to Keep cookies until they expire prevents the Discard attribute from being honored. The session cookie then survives the browser close and is reused on next visit, which prevents repeated session allocation. Trade-off: shared workstations expose the authenticated session to the next user of the same browser profile.

3. Reduce session lifetime to the minimum supported value

The web server session timeout is not user-configurable on V3.0.2. However, if the application can tolerate an aggressive auto-refresh, polling a light endpoint every few minutes keeps the idle timer reset. Once the user closes the browser, the timer is no longer reset, and after 30 minutes the slot is freed.

4. Schedule a daily recycle of the CPU

Acceptable for non-critical installations. STOP/RUN is not sufficient; a full power-down of 10 seconds or more is required to reset the session table. Combine with a UPS to avoid unintended recycling during mains disturbances.

5. Use the S7-1200 as a passive display only

Disable the Write access checkbox for the variables that the custom web pages expose. Operators can then read process values without authenticating, eliminating the session allocation entirely. The login block is impossible to trigger because no sessions are created.

6. Migrate to a V4.x firmware CPU (recommended long-term)

Firmware V4.0 and later reimplemented the session-handling layer and bind session lifetime to TCP socket state. The browser-close-without-logout pattern no longer leaks a session slot. CPUs with order number suffix -0XB0 can be field-upgraded to V4.4 or V4.5 using a SIMATIC Memory Card (SMC) of at least 4 MB and the TIA Portal online firmware update.

Firmware Upgrade Procedure (V3.x to V4.x)

Only perform the upgrade if the application does not rely on V3-only system blocks. The major-version jump requires a reset to factory settings of the CPU; back up the project first.

1. In TIA Portal V13 SP1 (or later), open the project and select the S7-1200 CPU.
2. Right-click Online & diagnostics → Backup → Online backup to file. Store the file on an external drive.
3. Download the new firmware file (for example 6ES7 214-1AE30-0XB0_V04.05.07.fwx) from Siemens Product Support using the order number search.
4. Copy the .fwx file to the root of a SIMATIC Memory Card (SMC) using a card reader. The card must be empty or freshly formatted (FAT16/FAT32).
5. Insert the SMC into the CPU with power off.
6. Power on the CPU. The front LEDs cycle; the firmware update begins automatically and takes 2–5 minutes. The CPU remains in STOP with the MAINT LED flashing during the update.
7. After the update completes, the CPU performs an automatic factory reset. Re-download the project.
8. Verify the new firmware version under Online & diagnostics → Diagnostics → General.

Programmatic Access Considerations

Applications that consume the S7-1200 web server programmatically (for example, a SCADA driver that performs HTTP POST to write variables) must implement the same logout discipline to avoid the V3.0.2 session leak. A typical session-managed HTTP client pattern in Python follows:

import requests

PLC = "http://192.168.0.10"
USER = "operator"
PWD = "secret"

s = requests.Session()
# 1. GET the login page to harvest any CSRF/redirect state
r = s.get(f"{PLC}/", timeout=5)
r.raise_for_status()

# 2. POST credentials to the login endpoint
r = s.post(
    f"{PLC}/FormLogin",
    data={"Login": USER, "Password": PWD},
    allow_redirects=False,
    timeout=5,
)
r.raise_for_status()

# 3. Use the session
r = s.get(f"{PLC}/awp/custom.html", timeout=5)
print(r.text)

# 4. Always log out to free the server-side session slot
s.get(f"{PLC}/FormLogout", timeout=5)
s.close()

The requests.Session() object preserves the siemens_ad_session cookie between requests and reuses the same session handle across the entire client lifetime, which avoids the leak by design. Clients that open a fresh requests.get(...) for every transaction, by contrast, will leak one session per request on V3.0.2 and exhaust the table in 6–30 requests depending on idle timing.

Alternative: use the S7 communication protocol directly

For applications that only need to read/write PLC tags, bypass the web server entirely and use the S7 communication protocol over ISO-on-TCP (port 102) or the newer PUT/GET interface. Libraries such as python-snap7 or libnodave do not consume web server session slots. This is the recommended approach for high-frequency polling because it also avoids the 30-connection web server limit.

Comparison: V3.x vs V4.x Web Server Behavior

Network Topology for Isolated Web Access

Where possible, place the S7-1200 web server on a dedicated VLAN or a separate IP subnet that is reachable only from operator terminals, not from the corporate network. The web server does not implement authentication rate-limiting or brute-force protection in any firmware version, and an exposed web server is vulnerable to credential guessing. A minimal topology is shown below.

Verification Procedure After Mitigation

Whichever mitigation is chosen, run the verification below to confirm that the login block no longer reproduces. The test mirrors the original fault signature.

1. Power-cycle the CPU and clear the browser cache and cookies.
2. Open a single browser window and navigate to the PLC web server.
3. Log in, close the browser. Repeat 10 times (more than the original 6-cycle limit).
4. On the eleventh attempt, the login should succeed.
5. If a session-based mitigation was deployed (cookie retention or session reuse), verify that the server-side session count remains at 1 by checking Online & diagnostics → Diagnostics → Web server in TIA Portal, if the firmware exposes this diagnostic.
6. If a firmware upgrade was deployed (V3.x → V4.x), run the test on V4.x and confirm that closing the browser immediately frees the session by re-logging within five seconds.

Commissioning Checklist

• Document the CPU order number, firmware version, and web server enable state in the project Functional Specification.
• Define the user name and password policy: minimum length, rotation interval, and storage in the plant password vault.
• Configure user-defined web pages with a prominent Logout button on every page, not only the default welcome page.
• Disable the web server if not required; remove the Enable web server checkbox in the device configuration.
• If the web server is required, restrict the source IP range using a managed switch ACL or a router firewall rule.
• For V3.x firmware, document the 30-minute recovery window in the operating procedures so that on-call engineers do not power-cycle unnecessarily.
• Plan a firmware upgrade to V4.x for V3.x installations on a scheduled maintenance window; verify compatibility of all AWP syntax in the project first.