S7-315-2DP: Troubleshooting Read/Write Protection Guide

Setting Protection level 3: write/read protection in the offline CPU properties does not prove that the running S7-315-2DP is protected. Load the updated hardware configuration and system data into the actual CPU, confirm the protection level online, cancel any authenticated access, and retest from a fresh programming session. Also distinguish between merely going online—which may not require a password—and performing a protected upload, download, or modification.

Why the CPU May Appear Unprotected

The protection selection is part of the configured CPU properties. Editing that selection changes the offline project first; the active controller behavior changes only after the corresponding system data reaches the intended CPU. If the download was omitted, failed, or targeted another station, the CPU continues using its previous protection configuration.

A missing password prompt is not by itself evidence of failure. An engineering station may establish an online connection and display limited diagnostic information without requesting the password. The decisive test is whether an unauthenticated user can upload protected program content, download changed blocks, or perform another operation restricted by level 3.

An already authenticated programming session can also make repeated access appear unrestricted. Test with the existing authorization explicitly canceled or with a newly started engineering session that has not received the password.

What Level 3 Protects

Protection level 3 applies CPU-level write/read restrictions to programming-device access. It is intended to stop unauthenticated reading and modification through supported online engineering operations. It is not equivalent to program encryption, network segmentation, or physical security.

The CPU protection password and block know-how protection solve different problems:

Use block protection only as an additional obstacle for selected intellectual-property blocks. It can be removed without the original password and therefore must not be treated as the primary control against program tampering.

Diagnostic Sequence

1. Identify the exact online CPU. Confirm that the programming station is connected to the intended rack and station. Compare the online station identity with the project before changing anything.
2. Open the offline CPU properties. Verify that the project shows Protection level 3: write/read protection and that a password was assigned.
3. Compare offline and online configuration. Check the CPU's online module information or diagnostic view for the active protection state. An offline setting alone is not a valid verification.
4. Review the previous load operation. Confirm that the hardware configuration and associated system data—not only user blocks—were loaded after protection was configured. Resolve any load errors before testing security.
5. Remove existing authorization. Cancel the current access rights if the engineering software provides that command, then close and restart the programming session.
6. Attempt protected operations without entering the password. Test an upload or read of protected program content and a harmless controlled write workflow. Do not infer protection status from the ability to connect or view diagnostics.
7. Inspect alternate change paths. Determine who can reach the programming network, connect locally, access engineering computers, or handle the CPU's load-memory media. CPU access protection cannot compensate for uncontrolled credentials or physical access.

Apply the Protection Correctly

1. Archive the known-good project and record an approved program signature or comparison baseline before making the security change.
2. In the correct S7-315-2DP object, select Protection level 3: write/read protection and assign the intended password.
3. Save and compile the hardware configuration so that updated system data is generated.
4. Connect directly to the intended CPU and load the hardware configuration and system data using the engineering software's normal CPU configuration procedure.
5. Follow the actual CPU and load-memory procedure required to retain the configuration across restart. Confirm retention by testing after a controlled restart when plant conditions permit.
6. Cancel authenticated access, close the engineering software, and reopen the project without supplying the password.
7. Perform separate negative tests for read and write access. Enter the password only after both unauthenticated tests have produced the expected restriction.
8. Restrict access to the programming connection, engineering project, password records, backups, and removable controller media.

Schedule the download and restart steps under the plant's change-control process. Loading system data can affect controller configuration beyond password protection if unrelated offline changes are present, so compare the complete offline and online configurations first.

Verify That the Fix Works

Verification requires both negative and positive tests. First prove that access is denied without authorization; then prove that the approved password restores the required engineering function.

After the tests, compare the online program with the archived known-good project. If tampering has already occurred, password protection alone does not identify which blocks changed. Use block comparisons, timestamps where available, system-data comparisons, and the CPU diagnostic information to establish the recovery scope.

Recurring Pitfalls

• Changing only the offline project: The CPU continues running the previously loaded system data.
• Testing only the online connection: Diagnostic access can be mistaken for unrestricted program read/write access.
• Retesting within an authorized session: Existing access rights hide the password challenge.
• Downloading only program blocks: CPU property changes reside in configuration/system data, not merely in FC or FB downloads.
• Using know-how protection as the main barrier: It obscures selected blocks but does not provide robust controller access control.
• Ignoring alternate access routes: Shared engineering computers, exposed programming networks, password disclosure, backups, and physical access can bypass the intended administrative boundary.
• Loading an unverified project: A protection update can unintentionally carry unrelated hardware-configuration differences into the plant.

FAQ