Can I enforce Server Message Block Signing on Wonderware Servers?

Hello Jeff,

I couldn't find any official documentation that indicates a direct incompatibility, AVEVA does not list SMB Signing as a requirement or restriction in its current guides. However, it looks like System Platform and its components implicitly use SMB for sharing files and libraries between nodes (IDE, GR, AOS), deployment and synchronization of objects, and access to shared resources such as Galaxy backups. This is confirmed because the manual lists ports 139 and 445 (NetBIOS/SMB) as required for the Bootstrap (Ports used by System Platform products). The presence of these ports could also be related to underlying Windows services rather than direct SMB functionality within System Platform itself.

If SMB Signing is enforced, the main consideration would be if these underlying Windows communications depend on SMB sessions. In modern Windows environments (Windows Server 2016 and later), enabling SMB Signing generally shouldn't break functionality, but it can introduce performance overhead. The risk is higher in legacy environments or where SMB1 is still present, as older systems may not support signing.

Best practices before enforcing SMB Signing include auditing SMB connections to ensure all nodes use SMB2 or SMB3, testing in a lab environment by enabling SMB Signing on a subset of nodes (GR and AOS) and validating object deployment, remote IDE access, and Historian store-and-forward functionality. It is also important to monitor performance, as SMB Signing can increase CPU usage and latency in OT networks with slow links, and to update legacy systems before enforcing SMB Signing.

Alena,

Thank you so much for taking the time to respond with a breadth of information that makes 100% sense to me. On our IT side of the house, we have tested everything you mentioned in your response, so I feel confident that we are on the same page with how to proceed forward. I will undoubtedly dedicate more focused time to the OT side, because we cannot afford to lose communication there.

The lowest OS in our environment ATM is Windows Server 2016, but most of our OT side is operating on Windows Server 2019. Our IT Side is almost exclusively Windows Server 2019. When enforcing SMB Signing, I encountered an issue with only one server, which was using a legacy application to write to our file server. Enforcing broke the file writing process.

Alena,

Thank you so much for taking the time to respond with a breadth of information that makes 100% sense to me. On our IT side of the house, we have tested everything you mentioned in your response, so I feel confident that we are on the same page with how to proceed forward. I will undoubtedly dedicate more focused time to the OT side, because we cannot afford to lose communication there.

The lowest OS in our environment ATM is Windows Server 2016, but most of our OT side is operating on Windows Server 2019. Our IT Side is almost exclusively Windows Server 2019. When enforcing SMB Signing, I encountered an issue with only one server, which was using a legacy application to write to our file server. Enforcing broke the file writing process.

Thanks for sharing those details. It sounds like you’ve got a solid approach and the right OS baseline in place. Glad to hear the testing confirmed the key points. Best of luck as you roll this out!