In 95% of all protections this is undesired.
One obvious behavior change is a performance loss. This is however under control of the engineer: Our tool gives precise control over the locations used for a protection, which can be used to limit performance costs.
Dangerous are programming errors where correct behavior erroneously depends on timing of the application instead on correct code synchronizations. This can lead to “bugs”; however such bugs really are already in the application before it is protected.
Another example is a simple bug in a protection: If the programmer uses “damage” and “repair” aspects. Just consider some code is “damaged”, but the engineer forgot to issue a “repair” before that code is executed.
Lastly, and very rarely: certain protection primitives CAN change the program semantics on purpose. This is very powerful, very advanced and highly unusual. In general we do NOT recommend doing this, and, and this will never happen by accident. Using such mechanisms has the high cost of not being debuggable before the protection is applied. As a simple example: it is possible to add tracing into a protection.