Security That Lives in the Tool, Not the PLC

This is the argument the rest of the series is evidence for. Its companions are Three Doors into the Same Controller, which maps the protocols an S7 CPU actually answers on; One Tag, Three Checkboxes, Two Answers, on the per-variable access attributes the native channel ignores; and Encrypted, but Not Authenticated, on what TLS is and is not worth on that channel.

You can read this one on its own. Where it refers to a specific bench result, the article that carries the evidence is linked inline.

Before any individual setting, one framing makes the whole series click — and it is also the reason the settings behave so inconsistently.

Siemens never designed S7Comm / S7CommPlus as a public, documented API for outside developers. It is the internal protocol their own products use to talk to their PLCs: SIMATIC HMI panels and WinCC exchanging runtime data, and TIA Portal, which behaves essentially like another HMI/engineering client on the same channel. For years it was also the only out-of-the-box way to exchange data with an S7 device — OPC UA on these CPUs is a comparatively recent addition.

Now put yourself in Siemens' position as those TIA-engineered systems grew more capable. You need finer-grained ways to control what a tag exposes and to whom, and you have a genuine choice about where to enforce it: down in the CPU firmware and the wire protocol, or up in the engineering tool. In the three cases this series measures — the per-tag attributes, know-how protection, the HMI-visibility filter — the enforcement point Siemens chose was TIA. That was a rational call at the time: a feature in the tool needs no firmware change and no new protocol version to support forever, no compatability issues to diagnose, and — crucially — if TIA is the only sanctioned way to engineer these systems, a security measure implemented inside the tool covers every path that exists. From that vantage point, tool-side enforcement isn’t a shortcut; it’s a complete implementation.

The assumption underneath it is that Siemens' own software stays the only client that ever speaks to the PLC.

Unfortunately — from Siemens standpoint — people didn’t want to be locked in to the Siemens tool ecosystem. As details on the protocols are not publicly specified, the only option was to rely on reverse-engineering the native protocol in order to participate at all; we did, building the ToddySoft Connect S7 driver, as have many before us.

Reverse-engineering broke that assumption: anyone can now open the same native channel a SIMATIC HMI panel uses and talk to the controller directly, underneath the tool entirely — where none of the tool-side checks are in the path.

That is what makes these settings tricky, and it is the question this series asks of every one of them:

That single question separates the settings that harden a device from the ones that only tidy up a project. This article takes the clearest case on each side — know-how protection, whose check lives entirely in the tool, and per-DB write protection, which the controller genuinely enforces — and then draws the pattern the two of them sit at either end of.

Verdict — the secret is the password, and it is checked in the tool. The controller does hold and serve the protected block, but in a transformed, unreadable form; turning it back into source happens in TIA Portal, against a password the controller never sees. Know-how protection reaches the device — it just does not put the device in charge of the check.

Know-how protection lets you password-protect a block so it can’t be viewed or edited in TIA Portal without the password. It is genuinely useful for protecting your intellectual property from anyone who gets access to the PLC — a competitor, a system integrator or contractor, or a customer — because the protection travels with the block into the controller: even uploading the program from the device yields a still-protected block. They can run it and download / upload it, but without the password TIA will not open it, so others can’t read or clone the logic.

Two things are worth pulling apart here, because they are enforced in different places. Whether the block can be pulled off the CPU at all is gated by the controller, by protection level: extracting a block’s compiled body needs at least Read access. Below that, at HMI access, the controller serves the block’s structure but withholds the body; at Kein Zugriff the program is hidden altogether. That gate is the controller’s, and it applies to every block, know-how- protected or not. What the pulled block contains — once you are at a level that can pull it at all — is where know-how protection acts. The unprotected block and the protected one do not come across the wire the same way: the protected body is transformed and comes across larger, not smaller: one contiguous region of the block is replaced by a bigger span of different content — roughly 2 kB becoming roughly 4 kB — while the rest is carried verbatim. The block’s name and its OB title are still in the clear — the protection is on the content, not on the metadata.

What know-how protection does not do is reach runtime tag data. I confirmed this on the bench: with know-how protection enabled on DB42, the block still appears in an S7CommPlus browse and its tags still read and write without the password. That establishes one thing precisely — protecting a block does not restrict what an HMI, SCADA or third-party client reads or writes over the native channel — and it establishes nothing about the block’s own contents, which is a separate surface, measured separately above.

I am deliberately not calling the transformed form "encrypted". The captures show the body changed into an opaque form, but the unprotected body is already opaque on the wire too, so I can’t tell a cipher from any other encoding by looking at the bytes. What I can say is that the content is transformed, that only the tool with the password reverses it, and — see the Kerckhoffs argument below — that the routine doing the transform ships inside TIA and so cannot itself be the secret.

One earlier framing has to go, and it is worth saying why. It is tempting to cast this as a mere flag — the controller sends the block in the clear with a bit that says "protected", and TIA politely declines to open it — which would make a man-in-the-middle that clears the bit enough to hand you the source. The measurement does not support that on two independent counts. First, the protected body is not the plaintext block plus a marker, it is different content: one region of the block is replaced by different, larger content while the rest is carried verbatim, and removing the protection reverses that exactly — so the transformation is the protection’s doing, not a compile artefact. Second, and more decisively: protecting the same, unchanged block a second time produces a different opaque region again — the block’s readable name is unchanged, but the protected bytes are freshly generated each time. A flag cannot do that; a bit is either set or not. Bytes that differ on every application of the protection, over identical source, are the fingerprint of a real transformation with a fresh random value each time, not of a marker a tool honours. So "clearing a marker" would reveal source that isn’t there. The general caution from Encrypted, but Not Authenticated still stands — a client-side check is only as trustworthy as the channel that fed it, and this channel is relayable — but it no longer buys an attacker the block’s logic, so I am retiring the "rewrite the flag and the feature evaporates" claim rather than repairing it.

None of which means the flag story was invented from nothing. It is field lore rather than documentation — knowledge passed between people working with these devices — and it may well have been accurate once. Siemens' own tables treat the know-how protection of the classic STEP 7 tools as a different, weaker thing than the TIA-era mechanism measured here: on the older S7-300/400 line it was not even password-based.^[1] And the belief in the field was that it amounted to little more than a bit the tool agreed to honour. If that is what an earlier generation shipped, the flag picture is not wrong so much as out of date — it describes a scheme the modern platform has since replaced with the transformation above. Where along the way the change happened I have not pinned down; these captures speak only for the CPU and engineering tool in front of me, which is TIA-era, and there it is a transformation, not a flag.

So treat know-how protection as source-confidentiality that travels with the block whose strength is the strength of the password, not as runtime data protection on the device. If your threat model is someone on the network reading and writing tag values over the native channel, know-how protection does nothing for you. If it is someone pulling your program off the CPU to read the logic, know-how protection is a real obstacle — an offline one, as the next section spells out.

And it is worth drawing the line against its neighbour, because they look alike and are not. Block upload — pulling the program off the CPU — is enforced by the controller: measured on the bench, a client below Read access is handed a block’s structure but the compiled body is withheld until it legitimates to Read. That is a real device-side gate. Know-how protection is the opposite: the controller hands the protected block to anyone who may upload at all, and the password check happens in TIA. So of the two "the PLC protects your program" stories, one is true of the CPU (block upload, protection levels) and one is true only of the tool (know-how protection). This chapter is about the second.

There is a sharper way to say what "the check lives in the tool" costs you, and it does not depend on the protection being weak. Whatever TIA does to a block when you protect it, it does on your machine, in software you can take apart. The routine that turns a readable block into the opaque form the controller stores — and the one that turns it back — ships inside TIA Portal to every user. By Kerckhoffs’s principle, a scheme whose security rests on that routine staying secret has no security at all: the method is recoverable by anyone willing to decompile the tool, and for Siemens' S7 protocols people have already done exactly this kind of reverse engineering. Treat the algorithm as known, not as knowable — the argument is stronger for not needing anyone to have done it yet.

So the only thing standing between an attacker and the readable block is the password — not any secret about how the protection works. And the password can be tested entirely offline. An attacker who has pulled the protected block off a device — and the block does travel to the device and comes back still protected, as above — holds everything except the password: the opaque block from the PLC and the method from TIA. Recovering the password is then a local computation, run at whatever speed the attacker’s hardware allows, with nothing in the controller able to see the attempts, slow them down, or lock anything out. The device is not in the loop.

Whether that offline attack is practical is the one thing I can’t settle here: it comes down to how much entropy your password carries and how deliberately slow the key-derivation step is, and I have measured neither. A strong password over a hardened key derivation can keep an offline attacker busy for a very long time — which would be a sound design, precisely because it leans on the password rather than on hiding the method. A weak password, or a fast derivation, turns the opaque block into a weekend’s work. The load-bearing point is not "know-how protection is broken"; it is that the protection is an offline one. It buys time in proportion to password strength, and it buys nothing from the device — so it is no substitute for keeping the block from being pulled off the CPU in the first place.

Don’t confuse it with the global Read access level of the protection-level model, which sounds similar but is a different thing. Read access governs whether the engineering tool may upload / download / modify the CPU’s blocks at all; know-how protection governs whether a block’s source can be opened once someone has it. One is about access to block operations, the other about confidentiality of the logic — and neither touches runtime tag data on the native channel.

Verdict — real. Device-enforced: the controller refuses writes to a write-protected DB on the wire, regardless of channel.

Not everything is a disappointment. Write protection on a data block is actually enforced by the controller. Mark a DB write-protected, and write attempts against it are refused on the wire — this is a device-enforced control, not a tool-side convenience.

Both controls live in the DB’s Properties → Attributes page. The Datenbaustein im Gerät schreibgeschützt (Data block write-protected in the device) checkbox is the one this section is about; the same page also carries the Optimierter Bausteinzugriff (Optimized block access) toggle that decides whether a block is optimized or classic — a distinction this series keeps coming back to, because it changes how tags are addressed on the wire without changing any of the access rules.

This is worth calling out precisely because it stands in contrast to the settings around it. When people ask me "is there anything in TIA that reliably makes data read-only," per-DB write protection is the honest "yes."

The third case study is the one that gives this article its title most directly — though only once you look at which consumer the label names. Every variable in a data block carries three checkboxes: Accessible from HMI/OPC UA/Web API, Writable from HMI/OPC UA/Web API, and Visible in HMI Engineering. The findings, in brief:

Two of the three are therefore not tool-side controls, and this article would be wrong to claim them: the CPU enforces them itself, against third-party clients with no Siemens software in the path. That is exactly why they are worth a chapter here rather than a footnote.

But look at where that enforcement lands relative to the label. The label names three consumers. For OPC UA and the Web API, the controller delivers. For the third — HMI — it delivers nothing at runtime, because SIMATIC HMI panels reach the controller over S7CommPlus, and that is precisely the channel none of the three attributes govern. The only HMI-specific effect any of them has is the Visible in HMI Engineering filter, which lives entirely inside the engineering tool.

So the honest reading is narrower than either "these are real" or "these are tool-side": the attributes are genuinely device-enforced, and the word HMI in their label is the tool-side part. An operator who ticks not writable expecting their panels and SCADA to be held to it has been told, by the label, to expect a runtime control on a path where only an engineering-time one exists.

That is the pattern of this article arriving from an unusual direction. Elsewhere a control turns out to be enforced by the tool instead of the device. Here the device does enforce — just not on the door the label’s first word points at.

The full treatment — every attribute measured on every door, on both optimized and classic data blocks, across three controller generations and both authentication models — is in One Tag, Three Checkboxes, Two Answers: The S7 Per-Tag Access Attributes. This chapter is the summary; that article is the evidence, and it is the finding reported to Siemens ProductCERT.

Line those three case studies up and they tell one story — but it is a three-way split, not the two-way one it first looks like, and the middle category, which the chapter above has just been through, is the one that gets miscategorized.

Enforced by the controller, on every channel. Per-DB write protection above, and Complete protection plus a password. These are the controls that actually stop a native-channel client. The block upload/download surface belongs here too. The upload half I measured, as the know-how chapter describes: below Read access the controller hands out a block’s structure and withholds the compiled body. The download half I did not test, and there Siemens' position, that download is enforced by the PLC as well, is their account rather than my measurement. A compromised engineering station is still a standing reason to be careful with any control that such a station passes through. Either way it matters for the argument below: the global protection levels do gate something on the device side, so this article’s thesis stops short of swallowing them.

Enforced by the controller — but not on the native channel. The per-tag Accessible and Writable attributes are genuinely enforced, and not by tooling. The CPU’s own OPC UA server applies them against a plain third-party client with no Siemens software anywhere in the path — and so, measured separately and by an entirely different protocol, does the Web API, which refuses a write to a not-writable tag with 205 "Address is read-only" even for an account holding every right the controller offers. Calling these "tool-side" would be wrong twice over. They were simply never wired into the native protocol, so the same tag that two of the controller’s own servers refuse to write is freely writable over S7CommPlus.

The check that lives inside TIA Portal. Visible in HMI Engineering, and — for the enforcement that counts — know-how protection. Visible in HMI Engineering evaporates the moment a non-TIA client speaks the native protocol: it filters a tag picker at engineering time and has no presence on the wire at all. Know-how protection is the case the article’s title comes from, and it is the subtler one: the controller does store and serve the protected block, but in a transformed form only TIA can undo, against a password the controller never sees — so the enforcement that matters, the password check, lives in the tool even though the protected bytes themselves travel to the device. What it does not do is reach runtime tag data on the native channel.

Only the third group is "security that lived in the tool" in the strict sense. But from the native channel’s point of view the second behaves identically — a client on that channel walks through both — which is why the distinction is so easily lost.

And the second group is the one that actually catches people out, precisely because it is real enforcement. Come at these checkboxes from the S7Comm / S7CommPlus side — as an HMI integrator, a driver author, anyone whose world is the native channel — and everything about them says the PLC enforces this. They sit in the block interface editor next to the data type and the start value. They are downloaded to the controller. Two of the three are, in fact, enforced by the controller. Every signal points at a device-side control, and the conclusion "so my tags are protected" is not careless, it is the obvious reading. The part that is invisible from that vantage point is the word channel — that the enforcement is real but lives somewhere your client never goes. A control that does nothing anywhere is eventually noticed. A control that works perfectly on a channel you do not use is not.

That is why the distinction is worth holding onto: the second group is not a design that failed to be implemented, it is a design that was implemented for the surfaces that came later and never retrofitted onto the one underneath. One Tag, Three Checkboxes, Two Answers dissects all three attributes in detail.

That split is not an accident; it is the design decision from this article’s opening showing up in each individual setting. Because S7CommPlus access is HMI access, the native channel was always meant to serve its data freely, and the finer-grained restrictions were layered on for the surfaces that came later (OPC UA, the Web API) and for the engineering workflow itself — never retrofitted onto the native channel underneath. As long as TIA was the only client that could speak the protocol, that was enough. Once the native protocol was reverse-engineered, every tool-resident control fell out of the path and stopped being a security control for that channel at all.

And here is the trap the industry is now in: by the time that was clear, moving these controls down into the protocol and hardware had become almost impossible. You would be retrofitting enforcement onto an internal protocol that was never specified for a third-party adversary, across an enormous backward-compatible installed base, without breaking the HMIs and SCADA systems that depend on the channel staying open. So the answer this series arrives at from the operator side is the only one available: since the native channel cannot be sealed from within, the real boundary has to be the network — and the properly specified, properly enforced surfaces for third-party integration are OPC UA and the Web API, not the native protocol the tool-side controls always assumed nobody else could speak. It is worth naming both. They are the two doors where the attributes actually bind, they were measured independently and agreed, and only one of them carries a per-CPU license — so on a fleet where paying for OPC UA everywhere is not realistic, the free door is still an enforced one.

Criticism is cheap unless it comes with a suggestion, and most of what this article describes cannot be undone: you cannot retrofit enforcement into a decades-old protocol with a huge installed base without breaking the plants that depend on it. So here are two changes that would materially improve the security of these devices while — as far as I can see — costing almost nothing in backward compatibility. Neither requires changing a single byte of the existing wire protocol for existing clients.

1. Let the PLC authenticate its clients on the native channel. Today the TLS handshake on the PG/HMI channel is one-way: the CPU proves who it is, and then anything that can reach the port may try its luck with a password. The device already has every piece needed to do better — a certificate manager, a keystore, trusted-partner lists — and Siemens already ships exactly this on the same CPU for the OPC UA server. Adding a trusted-clients list for the PG/HMI channel, with an "accept any client" default so nothing existing breaks, would let operators who care opt into genuine mutual authentication. It would close the MITM hole that Encrypted, but Not Authenticated walks through, and it would mean a rogue host on the segment could not even open a session, let alone start guessing passwords. This is the single change I would most like to see.

2. Give the CPUs genuinely separate network interfaces. Several S7 devices — particularly in the S7-1500 family — appear to offer multiple Ethernet ports, but these are usually one interface behind a built-in switch: same IP stack, same services, same exposure on every socket. If those were real, independent interfaces, and the CPU let you bind services to them — native S7Comm / S7CommPlus on one, OPC UA and the web server on the other — then the natural deployment would fall out on its own. Put the engineering / HMI interface on the protected control segment and the OPC UA interface on the segment where the IT integrations live, and the channel this whole article is about stops being reachable from the side of the network you trust least, without a single extra firewall appliance. Operators who do not want the split just leave everything on one interface, as today.

Neither of these asks Siemens to break anything. The first is an opt-in feature on a protocol that already runs TLS; the second is a hardware and configuration choice that makes segmentation — the one control this article concludes actually works — something the device supports natively instead of something you have to bolt on in front of it.

The rest of the series is the case-by-case evidence for the pattern above.

ToddySoft Connect is an industrial connectivity library: a set of protocol drivers that let applications read, write, browse and subscribe to data on automation hardware. Everything measured in this series was measured with it — the S7 driver first, and later the S7 Web API driver, which began as a way to verify a single claim in these articles and turned into a second Siemens driver in its own right. The bench behind the numbers is real hardware: S7-1500, S7-1200 and S7-1200 G2 controllers, plus an S7-300 for the cases where the answer is "that generation does not do this at all".

Christofer Dutz has spent more than a decade on industrial protocols and IT/OT integration, much of it in open source. Questions, corrections and war stories are welcome — particularly corrections: several findings in this series were sharpened by people who knew more about a corner of it than he did.

On the writing: this series took shape over about seven weeks and was restructured, split and rewritten far more often than anyone would manage by hand — what began as one article ended up as six. An AI assistant did the heavy lifting on the prose. It decided nothing: every finding, every number and every conclusion here came off the bench first and was checked back against it afterward. Where the text and the hardware disagreed, the hardware won.