The following cases are distinguished when modifications are made to a certified system stack according to Volume 8/1 of the KNX Specifications:
| Cases | Registration required? | Certification tests required? | |
| A | The binary file of the compiled stack can be transferred 1:1 to another microcontroller platform (e.g. typically a microcontroller with extended features compared to the previous version) | Yes | No |
| B | The code of the system stack needs to be modified to be able to compile it to another microcontroller platform, without changing the code of the implemented KNX system stack as regards implemented KNX system features. | Yes | No, the correct functioning of the stack on this new controller lies in the responsibility of the manufacturer |
| C | The code of the implemented KNX system stack needs to be changed (e.g. adding new or correcting existing KNX system features), be it to compile it to the same or another controller platform. | Yes | Yes, based on the relevant declaration made by the manufacturer on which functionality was changed, the KNX accredited test lab may decide to only repeat some tests. |
| C1 | Extending an already certified KNX classic stack with KNX Secure | Yes | Yes, need for (at least) verification of the full added KNX Secure functionality as well as retest of the tests given in Volume 8/3/7 |
| C2 | Porting an already certified KNX classic stack for use with another KNX medium, e.g. originally certified for TP and adapted to RF | Yes | Yes, need for (at least) verification of the lower layers in accordance with Volume 8/2/5 and retest of the tests given in Volume 8/3/7 |
| C3 | Extending an already certified KNX classic stack with KNXnet/IP Tunneling | Yes | Yes, need for the verification of KNXnet/IP Core, Management, Tunneling next to random tests of the remaining stack |