Configuring Authenticated S7-1500 S7 Read/Write from Windows Apps

Overview

When a TIA Portal V20 project is downloaded to an S7-1500 CPU with the default access-protection settings, third-party Windows applications that previously read and wrote Data Blocks over the legacy S7 transport (PUT/GET, ISO-on-TCP/RFC 1006) suddenly stop working. The HMI keeps operating normally because the HMI uses a project-bound secure S7 channel that TIA Portal V20 negotiates with the CPU. The third-party Windows application has no project credential set and falls back to legacy PUT/GET, which the CPU now refuses.

This reference explains the S7-1500 security model introduced in TIA Portal V20 and FW 3.1.x, the precise mechanism by which PUT/GET is rejected, and the supported paths to restore authenticated read/write from a Windows host. It is written for engineers maintaining a redundant S7-1500 system composed of a 6ES7 517-3HP00-0AB0 (S7-1517-3 PN/DP) and a 6ES7 518-4JP00-0AB0 (S7-1518-4 PN/DP), both on FW 3.1.4, programmed in TIA Portal V20. The same access-protection model also applies to the S7-1500R/H redundant systems; the only redundancy-specific delta is the floating system IP that the OPC UA server binds to.

Affected Hardware, Firmware, and Tooling

The catalog numbers cited are the standard S7-1500 CPUs. The redundant S7-1500R catalog family (suffix R) and the S7-1500H catalog family (suffix H) carry a different MLFB; for example, 6ES7 515-...R... is an S7-1500R. The same access-protection rules apply, but the OPC UA endpoint binds to the R/H system IP rather than a physical CPU IP, which is what the Windows client must target.

Why PUT/GET Stops Working After Access-Level Changes

Under Properties → Protection & Security → Access level the CPU exposes a four-level access list. TIA Portal V20 changes the default for newly created or migrated devices to a configuration that disables PUT/GET. The list is reproduced in the table below with the actual on-wire effect.

The “Permit access with PUT/GET communication from remote partners” checkbox at the bottom of the same page is the single bit that gates the legacy transport. The Siemens Knowledge Base entry ID 109925755 documents the toggle and explicitly notes that PUT/GET has no integrity protection, no encryption, and no authentication. The CPU logs every PUT/GET request that lands on TCP/102 in the diagnostic buffer, and on a CPU set to level 2/3/4 the connection is closed at the S7-connection establishment phase — the client sees a TCP RST or, more commonly, a timeout if its socket layer retries.

Symptoms seen in third-party libraries:

• libnodave: res_negative with no specific error code, or daveConnectionError on the very first connectPLC call.
• Snap7: Cli_Connect() returns S7ClientError with errTCPConnectionTimeout (0x0000 0001) because the CPU closes the socket during the S7-communication-setup (ISO 802.3 / CR/CC negotiation).
• Prodave: error class 0x80, error code 0xD0 (area length error after authentication) or 0xA1 (function not allowed in current protection level).
• OPC UA client (UA Expert, .NET Standard): succeeds because OPC UA is a separate subsystem that runs on TCP/4840 and is configured independently of the S7 access level.

Secure S7 Communication Architecture

The secure S7 channel documented in the SIMATIC S7-1200/S7-1500 Communication Function Manuals (see the Secure vs. legacy communication reference) has the following properties on FW 3.1.4:

• Transport: ISO-on-TCP/102 carrying a TLS 1.2/1.3 session. The session is keyed to a CPU-generated or imported X.509 certificate.
• Project binding: the partner (PG, HMI, panel) is identified by the TIA Portal project ID and the CPU serial. Both sides validate the binding before any S7 PDU is exchanged. A non-project partner cannot complete the handshake even if it presents a valid certificate.
• Role-based access: the project maps every HMI tag to a DB area and a privilege. A WinCC Runtime generated from the same project inherits the mapping. A third-party app that has not been enrolled in the project does not have a mapping at all.
• No legacy fallback: once a CPU is project-bound as secure, the same port (TCP 102) refuses legacy PUT/GET from any source, including partners that the CPU has never seen.

The architecture of a typical deployment is shown below.

Configuring TIA Portal V20 for Authenticated Access

1. Open the CPU protection settings. In the project tree, expand the CPU (e.g., PLC_1 [CPU 1517-3 PN/DP]) and open Properties → Protection & Security → Access level. Select Read/write access (HMI) if you want HMI write operations to remain permitted.
2. Set a password for the access level. Under Password for access level 2 (read/write access) enter a strong password. Without a password, the level is bypassed and the CPU accepts any PG/HMI on TCP/102.
3. Choose the S7 connection mechanisms. Three toggles appear below the access list:
   • Permit access with PUT/GET communication from remote partners — leave disabled for production. Enable only for diagnostics.
   • Permit access with secure communication — keep enabled. This is the default in TIA V20.
   • Activate the OPC UA server — enable if the Windows application will use OPC UA (recommended).
4. Define users and roles (TIA V20). TIA Portal V20 introduces a per-user authorization model under Properties → Protection & Security → User management. Add a service user for the Windows application:

User name:        scada_bridge
Role:             HMI operator (write)
Authentication:   Password + certificate
Certificate:      Imported from PKCS#12 generated in the CPU certificate manager
Session timeout:  60 min

5. Compile and download. Right-click the CPU → Compile → Hardware and Software (rebuild all). Then Download to device with the CPU in STOP if the certificate set changed. Confirm that the HMI is still functional and that a third-party PUT/GET test now returns a connection error.

Windows-Side Options for Authenticated Read/Write

Option A — OPC UA (recommended)

The S7-1500 OPC UA server is the only path that the CPU supports for authenticated, encrypted, integrity-checked read/write from a third-party Windows host. FW 3.1.4 exposes the following capabilities.

A Windows application can use the OPC Foundation .NET Standard library (UA .NET Standard), the Eclipse Milo Java stack, or any commercial SDK. The minimal C# snippet below opens a signed/encrypted session, authenticates with the user created in TIA, and reads a tag out of an exposed DB.

using Opc.Ua;
using Opc.Ua.Client;
using Opc.Ua.Configuration;

var app = new ApplicationConfiguration {
    ApplicationName = "WinSrv",
    ApplicationType = ApplicationType.Client,
    SecurityConfiguration = new SecurityConfiguration {
        ApplicationCertificate = new CertificateIdentifier(
            storeType: CertificateStoreType.X509Store,
            storePath: "CurrentUser\\My",
            subjectName: "WinSrv")
    },
    TransportConfiguration = new TransportConfiguration()
};
await app.LoadApplicationConfigurationAsync();

var endpoint = new ConfiguredEndpoint(
    null,
    new EndpointUrl("opc.tcp://192.168.0.10:4840"),
    EndpointConfiguration.Create(app));

var session = await Session.Create(
    app, endpoint, false,
    sessionName: "WinSrv",
    sessionTimeout: 60_000,
    userIdentity: new UserIdentity("scada_bridge", "P@ssw0rd!"),
    preferredLocales: new[] { "en" });

// Read a DB variable exposed under the OPC UA address space
var nodeId = new NodeId("ns=3;s=\"MyDB\".\"Setpoint\"");
var value  = (float)await session.ReadValueAsync(nodeId);
Console.WriteLine($"Setpoint = {value}");

The OPC UA server must be enabled under Properties → OPC UA → Server on the CPU. The user scada_bridge must be granted the OPC UA role that allows read/write to the relevant DB node.

Option B — Enable PUT/GET and accept the risk

1. In TIA Portal, open Properties → Protection & Security → Access level.
2. Tick Permit access with PUT/GET communication from remote partners.
3. Compile and download.

PUT/GET is now accepted from libnodave, Snap7, Prodave, or any ISO-on-TCP/RFC 1006 client. Drawbacks:

• No authentication: any host on the engineering network can read/write.
• No encryption: payload and tag names travel clear-text.
• No integrity check: a packet can be tampered with or replayed.
• No audit trail on the CPU beyond the diagnostic buffer.

Acceptable only on an isolated engineering network, a test rig, or for non-production diagnostics. In a redundant production cell, this is a regulatory finding waiting to happen.

Option C — SIMATIC SDK with project binding

The SIMATIC Automation Tool SDK and SIMATIC S7-PLCSIM Advanced expose a managed API to project-bound secure S7 channels, but they require the SDK to be installed on the Windows host and a TIA Portal project (or PLCSIM instance) to be present. They are not a generic path for an application that does not own the TIA project.

Siemens does not currently publish a public S7-secure API for third-party Windows or Linux applications outside of the SIMATIC product line. Library projects such as libnodave, Snap7, and openS7 remain locked to the legacy transport.

Configuring the OPC UA Server on the S7-1500

1. Properties → OPC UA → Server → General: enable the server, set the server port (default 4840), and the discovery URL.
2. Security: enable at least one signed-and-encrypted security policy. Disable the None policy in production.
3. Authentication settings: enable UserName/Password identity. Add the user scada_bridge (created in TIA under User management) and assign the OPC UA role.
4. Address space: under Symbols, expose the DBs that the Windows application needs. Each DB becomes a node under the OPC UA address space. Select Optimized block access for DBs that were created with optimized access; non-optimized DBs are exposed as raw byte views and lose the symbol names.
5. Subscription settings: keep the default 1000 ms publishing interval; raise the keep-alive count to 30 to survive short network glitches.
6. Compile and download.
7. From the Windows host, run the OPC Foundation UA Expert client. The endpoint must expose the security policy you enabled; if only None is visible, the CPU certificate is not yet trusted by the client. Export the CPU certificate from CPU → Properties → Protection & Security → Certificate manager and import it into the client’s TrustedPeers store.

Redundancy Considerations

The catalog numbers supplied (6ES7 517-3HP00-0AB0, 6ES7 518-4JP00-0AB0) are standard S7-1500 CPUs. If the project uses them in a software-redundancy scheme (one active, one standby, application-level switchover) the OPC UA server runs on the active CPU; the standby refuses connections until promotion. WinCC V8.0 supports software-redundancy monitoring via a cyclic script that reads the partner state — see the WinCC V8.0 configuration and communication reference for the full pattern.

// WinCC V8.0 C script — software redundancy check
#include "apdefap.h"
int gscAction( void ) {
    // Master status is exposed by the CPU under DB999 byte 0
    DWORD dwState = GetTagByteState("MasterState");
    if (dwState == 1) {
        // partner is master — direct traffic to partner IP
        SetTagChar("OPC_Endpoint", "opc.tcp://192.168.0.11:4840");
    } else {
        SetTagChar("OPC_Endpoint", "opc.tcp://192.168.0.10:4840");
    }
    return 0;
}

For a true S7-1500R/H system the OPC UA server is hosted by the R/H system and is reachable on the system IP, not on the primary or backup physical IP. The system IP floats between the two physical CPUs at the moment of switchover. The Windows OPC UA client should connect to the system IP and re-create the session after a disconnect; UA .NET Standard’s Session automatically re-creates the channel when the keep-alive exceeds the configured count.

Migration Checklist from TIA V17 to V20

Every project that is opened in TIA Portal V20 for the first time is silently migrated. The migration normalises the access-protection settings to the V20 defaults. A V17 project that “just worked” in V17 may stop working the moment it is downloaded from V20. The mandatory post-migration checks are:

1. CPU → Properties → Protection & Security → Access level: confirm the level is what you intend (do not accept the new default blindly).
2. Permit access with PUT/GET communication from remote partners: re-evaluate. If a third-party Windows app exists, the choice is between enabling this bit or moving that app to OPC UA.
3. User management: in V17, users lived on the CPU under Web server → User administration. In V20, users are under Protection & Security → User management. The old Web-server users are not imported automatically.
4. OPC UA → Server → Symbols: re-export the DBs. V20 can change the symbol hash on every migration, which causes OPC UA clients to lose their node IDs.
5. Compile → Hardware and Software (rebuild all): never download without a full rebuild after a V20 migration.

Reading CPU Diagnostic Buffer Entries for Security Events

Every failed authentication, every refused PUT/GET, and every OPC UA session rejection is logged in the CPU diagnostic buffer. The events to look for are:

Open the buffer in TIA Portal: Online → Online & Diagnostics → Diagnostic buffer. The events are timestamped to the CPU real-time clock; if the clock is unsynchronised, sort the events by event ID rather than by time.

Troubleshooting Matrix

Verification Procedure

1. HMI regression. Open the HMI Runtime and confirm that the HMI reads the same values that the Windows app reads. If the HMI fails, the project binding is broken — re-download the project to the panel.
2. CPU diagnostic buffer. Open TIA Portal → Online → Online & Diagnostics → Diagnostic buffer. Confirm no 0x013C…0x013E entries from your own clients.
3. OPC UA smoke test. From a second Windows host, run UA Expert. Browse the address space and confirm the DB nodes are present. Subscribe to one tag, write a value, and confirm the change reflects in the CPU and in the HMI.
4. Legacy PUT/GET test (only if option B was chosen). From a libnodave-based tool, run db_read(1, 0, 4). If the read returns 4 bytes, PUT/GET is enabled. If it returns an error, the toggle was not downloaded.
5. Redundancy failover (S7-1500R/H only). Force a switchover via TIA → Online → Force failover. The OPC UA client should reconnect within 5–10 seconds to the system IP and resume the subscription.
6. Wire trace. Run Wireshark on the Windows host and confirm that the OPC UA session is signed and encrypted (filter: opc.tcp). Any TLS alert is a configuration mismatch, not a transport failure.

Field-Proven Caveats

• The default behavior of TIA Portal V20 changes the access level silently on every project migration from V17 or earlier. A project that “just worked” in V17 may stop working the moment it is opened in V20 and downloaded. Always re-check the access level after a migration.
• The OPC UA server on the S7-1500 cannot exceed 1000 concurrent monitored items per session in FW 3.1.4. For larger SCADA applications, shard the workload across multiple sessions.
• Some third-party OPC UA clients (older versions) only support SecurityPolicy None. The CPU exposes None only if the user explicitly enabled it. For production, disable None and use Basic256Sha256 or Aes256Sha256RsaPss.
• The CPU certificate generated by TIA V20 uses a 2048-bit RSA key by default. Some legacy clients reject RSA > 1024. Either import a smaller cert or upgrade the client.
• The OPC UA Methods interface is the only way to invoke secure writes that are atomic; simple “write to tag” operations on a tag mapped to a DB are equivalent to direct variable writes and bypass any application-level check.
• The Siemens OPC UA server does not expose recipe data, data logs, or trace buffers by default. Those must be modeled in the project under Additional OPC UA symbols if needed.
• PUT/GET cannot be enabled on a CPU that is currently bound to a TIA Portal project as “secure only”. Re-downloading the project with the new toggle requires an explicit Compile → Hardware and Software (rebuild all) followed by a Download to device; a partial download keeps the old protection profile.
• On a software-redundancy pair, the standby CPU is reachable on its own IP but the OPC UA server only accepts requests on the active CPU. A libnodave-based tool that fails over to the standby will get a TCP RST; an OPC UA client that targets the active IP will see a BadServerNotConnected on the standby and must reconnect to the new active IP.