The specifications often specify the format of the correct Messages and are silent on what the implementation should do for Messages that deviate from the specification. Typically, the implementations continue to parse such packets, leading to vulnerabilities.

• The implementer should do strict checking of the Message format and should either drop the packets or send an error Message as described below.
• Error handling uses the error code, defined in OPC 10000-4, which most precisely fits the condition and only when returning an error code is appropriate. Error codes can be used as an attack vector; thus, their uses shall be limited as described in Part 4 Service Behaviours clause. Once the secure channel has been established then appropriate specific error codes are returned.
• Another attack vector that can be used is timing variations; this is minimized by the description in Part 4 that requires the closing of the socket for any errors when establishing a secure channel. Vendors should be careful in their implementation to ensure that all paths that result in the closure of the socket do not provide a timing hint indicating which failure path was encountered. This can be accomplished by having a random delay before closing the socket or before returning a generic error code.
• All array lengths, string lengths and recursion depth should be strictly enforced and processed.