S7 Know-How Protection: Block Security in STEP 7 and TIA Portal

Overview of S7 Block Protection Mechanisms

Siemens S7 controllers expose their program logic through compile blocks: Organization Blocks (OB), Function Blocks (FB), Functions (FC), Instance and Global Data Blocks (DB), System Function Blocks (SFB), System Functions (SFC), and User-Defined Types (UDT). Each block may be flagged with one of three protection levels that control how the block behaves inside the engineering tool and how it is read back from the controller:

Know-How Protection is the strongest of the three. It does not alter execution; the CPU still runs the compiled block identically. What it does change is what the engineer sees when the block is opened offline, when it is uploaded from the CPU, and when it is exported as a source file. This article dissects the mechanism across STEP 7 V5.x (SIMATIC Manager, S7-300/S7-400) and TIA Portal V13+ (S7-1200/S7-1500), explains why naive text removal in the source file does not defeat it, and presents the legitimate paths for working with protected blocks.

Know-How Protection vs Password Protection in STEP 7

STEP 7 V5.x separates two concepts that engineers frequently confuse:

• Password protection is a write protection. The block can be opened and viewed. Modifying and re-saving the block requires the password. Uploading the block from the CPU returns the full compiled content; the password is needed only to write the block back to the CPU.
• Know-How Protection removes the source code from the offline view entirely. The block opens as an empty container. The interface (IN, OUT, IN_OUT, STAT, TEMP) is visible if the Accessible option was set during protection. The compiled code is hidden. Uploading the block returns the protected block with no usable code.

Access during the protection dialog in SIMATIC Manager is at: Block > Know-How Protection > Set... The dialog prompts for a password and offers a check box Accessible. When checked, the block interface remains visible even without the password, which is essential for HMI tag generation and instance-DB creation. When unchecked, only the block's name, number, and author are visible.

How Know-How Protection Is Implemented (S7-300/400)

In the S7-300/400 architecture, a block consists of two companion objects in the offline S7 program:

1. Compiled block (.s7p / FC10, FB22, ...) in the Blocks container.
2. Source file in the Sources container, typically STL or SCL text.

The compiled block carries a flag in its block header that marks it as KHP-protected. When the engineering tool opens a KHP block, it does not load the code section of the compiled block; it shows an empty interface. The flag is also written into the source file as the directive KNOW_HOW_PROTECT at the top of the STL/SCL text, which is what users see when they export the source.

The STEP 7 V5.x protection scheme uses a Siemens-internal hash of the password combined with the CPU serial number (for blocks downloaded to a specific CPU). The algorithm is documented only inside the STEP 7 help file and is not part of the public S7 interface. The block will not be re-compiled with new code from the source file unless the password is supplied, because the compile operation requires opening the block to embed the user code.

The "Source Text" Removal Myth

A common attempt to defeat KHP in SIMATIC Manager follows this sequence:

1. Right-click the protected block in the Blocks container, choose Generate Source, and export a source file.
2. Open the source file in the Sources container. The file contains only a stub such as:
   FUNCTION FC 10 : VOID
// KNOW_HOW_PROTECT
END_FUNCTION
3. Delete the KNOW_HOW_PROTECT comment, paste in the original code obtained from a backup, and try to compile.

This fails for three reasons. First, the user does not have the original code. The compiled code section was replaced with a stub at protection time; the source file in the project already contains only the stub. Second, the compiled block in the Blocks container still carries the KHP flag in its header, so any recompile that targets the same block will restore the flag. Third, any code the engineer pastes back into the source file is a guess; the actual MC7 code in the compiled block is a translation of the original STL/SCL through several optimization passes (graph folding, constant propagation, jump optimization), so a hand-rewritten STL source is unlikely to produce identical MC7.

TIA Portal S7-1200/1500 Protection Architecture

From TIA Portal V13 onward, the protection model for S7-1200 and S7-1500 changed substantially. The protection is no longer a flag inside the block; it is an encrypted payload bound to the CPU's serial number and, for blocks compiled with newer TIA Portal versions, an additional cryptographic signature.

The encryption uses a key derived from the password and a salt. TIA Portal V15 SP1+ upgraded the key derivation to PBKDF2 with a high iteration count, and S7-1500 firmware version 2.6+ added a hardware-backed secure element on the CPU. The TIA Portal online help at Siemens KB 109751649 documents the algorithm change and the firmware requirements.

To protect a block in TIA Portal, right-click the block in the project tree, choose Properties > Protection, and tick Know-How Protection. The Accessible option exposes only the block's interface; Not accessible hides the interface as well. The password is stored only in the project on the engineering station; it is not transferred to the CPU.

Block Types and Their Protection Behavior

Not every block type accepts the same protection options. The following table summarizes the behavior across both environments:

When a protected FB is instantiated, the resulting Instance DB is independent of the FB's protection. The instance DB is fully readable. This is a deliberate design: the engineer needs the instance DB to wire HMI tags and to troubleshoot process state, but the logic of the FB is opaque.

Legitimate Workflows for Accessing Protected Code

When you encounter a KHP-protected block from a third party, a sister plant, or a vendor, the following workflows are the only supported paths to the code:

1. Ask the original author for the source. The original STL, SCL, LAD, or FBD file is the canonical form. Vendors often provide source under NDA, sometimes for a fee.
2. Request the uncompiled .s7src file. In TIA Portal, exporting a protected block from the project tree produces a binary source file. The author can export and send it, and the recipient can import it into a project that uses the same TIA Portal version and the same CPU family.
3. Use a copy-protection dongle or license file. Some vendors tie KHP-protected libraries to a CPU serial number. Provide the CPU serial number, and the vendor generates a CPU-bound source file that opens with the vendor's master password.
4. Re-implement the function from the visible interface. If the Accessible option was set, the engineer can see the block's IN/OUT/IN_OUT/STAT signatures, the HMI documentation if generated, and the instance DB layout. The implementation can be reverse-engineered from the I/O behavior using the instance DB and watch tables.
5. Use a TIA Portal library global to your organization. Internal blocks used across plants should be maintained in a versioned master-copy library with the source under change control, not as KHP-protected blocks on the CPU.

Protecting Your Own Blocks: Best Practices

If you are the block author, treat KHP as a last line of defense, not the primary one. The recommended layering is:

1. Store the project on a central server with access control. Most "cracks" are internal; they do not need an external attack.
2. Use a CPU-bound project for the final download. TIA Portal's Project Protection ties a compiled project to a specific CPU serial number, so even a stolen offline project cannot be downloaded to a different CPU.
3. Set KHP with Not accessible for sensitive FBs (machine tuning, recipe scaling, proprietary control loops). Use Accessible only when the interface must be visible to HMI.
4. Use unique passwords per block, stored in a corporate password manager. Reusing one master password across all blocks gives an attacker a single key.
5. Document the block externally in a PDF that describes purpose, I/O ranges, and expected runtime behavior. The PDF is not protected, so maintenance crews can troubleshoot without the source.

In STEP 7 V5.x, the protection is set from Block > Know-How Protection > Set... The block can be protected with a maximum 8-character password. In TIA Portal V17+, the password length is up to 32 characters and supports all printable ASCII. Always use the maximum length.

Source Files, Libraries, and Reuse Patterns

Siemens' block library concept is the correct way to distribute protected logic. A library master copy retains the source; when dragged into a project, the engineer can choose with Know-How Protection or without. The library vendor signs the master copy with a Siemens-internal signature; tampering with it invalidates the signature in TIA Portal V16+.

For S7-300/400, the equivalent is the S7 Library (.s7l) file. The library is a read-only project that the engineer browses and drags from. The source blocks in the library are uncompiled, and the KHP password is set on the master copy.

Hardware-Bound Protection and Security Considerations

From TIA Portal V17 onward, a project can be CPU-bound. The protection is implemented as follows:

• On download, the engineering tool signs the project with a hash of the target CPU's serial number and the CPU's hardware security chip (S7-1500 with FW 2.6+).
• The signed project is stored on the SIMATIC Memory Card. The card's CID (Card Identification) is also part of the signature.
• On startup, the CPU verifies the signature against its own hardware key. A block copied from one card to another fails to run.

This is the recommended protection for OEM machines shipped to a customer. The customer can monitor the program, but cannot copy it to another machine. The Siemens application note 109762387 describes the binding process in detail.

Note: CPU binding does not replace KHP. KHP hides the code from the engineer; CPU binding prevents the block from running on a different CPU. They are orthogonal mechanisms and should be combined for OEM shipments.

Commissioning and Verification Steps

When deploying a project that uses KHP-protected blocks, follow this verification sequence to confirm the protection is correctly applied:

1. In the project tree, right-click each protected block, choose Properties > Protection, and confirm the protection flag is on, the password field is populated, and the Accessible option matches the design intent.
2. Compile the project (Project > Compile all > Software (rebuild all)). The compile log should show Protection active for each protected block.
3. Download to the target CPU. In the Load preview dialog, every protected block should show a lock icon in the Action column.
4. After download, go online and open each protected block. Confirm the code section is empty and only the interface (if Accessible) is visible.
5. Upload the block from the CPU (Online > Upload from device). Confirm the uploaded block opens in the project as protected, with no source code.
6. Test instance DBs. Confirm instance DBs are readable; only the parent FB code is hidden.

Troubleshooting Matrix for Protection Issues

FAQ