The problem arises from an imprecise definition of Part 6. It occurred
with the HPSDK client and C++ SDK demo server. The later one uses the
legacy UA Stack, which causes the problem.

From the specification: Part 6 - 6.7.4

"The Client shall continue to accept the old SecurityToken until it
receives the OpenSecureChannel response. The Server has to accept
requests secured with the old SecurityToken until that SecurityToken
expires or until it receives a Message from the Client secured with
the new SecurityToken"

This defines only how long to accept old tokens, not when to use the
new token. This can lead to misinterpretations, which then lead to
buggy implementations. Obviously, the client should use the new token
as soon as possible, so after processing the OpenSecureChannel
response.

When the server assumes that after sending the OPN response, the
client "knows" it and so it can directly use the new token in any
response after the OPN response, this is wrong! The client may need
multiple seconds to process the OPN response. Meanwhile, the client is
still using the old token for other requests.

The server should only use the new token in any response, after it
receives the new token the first time from the client. This proves
that the client does actually know it.