Using the flash partition layout from OEM to illustrate:
[ 4.000000] Creating 10 MTD partitions on "MT7621-NAND":
[ 4.008000] 0x000000000000-0x000007f80000 : "ALL"
[ 4.020000] 0x000000000000-0x000000080000 : "Bootloader"
[ 4.032000] 0x000000080000-0x000000100000 : "Config"
[ 4.040000] 0x000000100000-0x000000140000 : "Factory"
[ 4.052000] 0x000000140000-0x000002000000 : "Kernel"
[ 4.064000] 0x000002140000-0x000004000000 : "Kernel2"
[ 4.076000] 0x000004000000-0x000004100000 : "wwan"
[ 4.084000] 0x000004100000-0x000005100000 : "data"
[ 4.096000] 0x000005100000-0x000005200000 : "rom-d"
[ 4.108000] 0x000005200000-0x000005280000 : "reserve"
Normal firmware upgrades will only write to the "Kernel" partition. All other partitions are left untouched on upgrades.
The bootloader will copy the image from "Kernel" to "Kernel2" if it decides this is required. Normally that won't happen, so you'll keep whatever initial firmware version the device had in "Kernel2" as a sort of backup. But don't trust this for anything. Booting from "Kernel2" is rarely considered by the bootloader, so it doesn't work as a generic failsafe solution.
nvram values are kept in the "Config" partition, so this is written whenever any of those variables are modified either by firmware or by bootloader. There isn't any device specific data here. There is a "serialnumber" variable, but the contents is not the real serial number (and it is the same for every device). This also goes for invalid "ethaddr" variable, which you'll have to work around to get tftp (or network at all) to work from the bootloader. Note: There are some variables here which are important to the bootloader. The DebugFlag is of special interest. If set to "0" (default), then the bootloader will not accept any input. I.e., you cannot upgrade firmware or boot from net or do anything else to fix a broken firmware. In other words: Any firmware failure while DebugFlag is set to "0" means a permanent BRICK!
To make this even worse: The OEM firmware will try to reset DebugFlag to default on every boot. So if you boot OEM once, then you have this dangerous setting. The idea is obviously to close down console access since these devices will be mounted outdoors without any physical access control. luckily for us, the OEM firmware tests DebugFlag against the string "1" before resetting it to "0". Writing "0x1" to the variable avoids the reset and is interpreted as "1" by the bootloader. But this hack depends on a bug in the OEM boot script, so it might stop working with any new OEM firmware version. Consider yourself warned: Always test that this hack still works (that you can type input to bootloader from the console) after any experiments with newer OEM firmwares. If it doesn't, then downgrade. If you can. But worst case is that they fix the bug and disable downgrades from OEM, while also disabling direct updates of the DebugFlag variable from OEM. But the latter will be very hard for them to do, so I don't think it is likely to happen.
The "data" partition has a UBIFS for userdata. The OEM firmware will mount it both under /data and every "<user home directory>/data". This partition is left untouched by firmware upgrades, so anything stored here is persistent over upgrades. The OEM firmware uses it for anything wanting persistent storage. I don't think there is ever anything critical here. Files will be created as required. But I suggest leaving this file system as is to allow smooth transitions between OEM and OpenWrt, or between different OEM versions.
The other partitions are never updated by anything, and I suggest you don't change any of them either. The "wwan", "rom-d" and "reserve" partitions are empty, so it probably doesn't matter much.
The real serialnumber and other device specific data like certificates etc are stored in the "Factory" partition. As long as you don't write to this partition (and DON'T do that) you should be able to restore the device to original. Note that there is no one who can help you recreate this partition. It is device specific and unique to your router. You should make a backup of if as soon as possible.
You''ll also have to make a backup copy of the original "Kernel" (and/or Kernel2") if you ever want to go back to the Telenor firmware. It isn't available for public download, and is required for Telenor to adopt the device it their management system. It's easiest not having to call Telenor to get a copy 
Last fun fact: Note the hole between "Kernel" and "Kernel2". You'd think it's empty. But it isn't (at least it wasn't on any of my devices). There's a jffs2 file system at 0x2100000 with lots of OpenWrt config files. That's where I found all the GPIO hints for this router. Needless to say, my suggestion is to leave this hole as-is too. Unless you know you'll never want to go back to the original
EDIT: One final warning: Remove any valid Telenor SIM while running the Telenor OEM firmware. Or the device might be captured by their management system. Using a Telenor SIM with OpenWrt is of course safe. And probably also with the generic ZyXEL OEM firmware.
EDIT2: Wasn't sure I should write this, but as required by personal integrity.... DISCLAIMER: I work for Telenor. All information provided above is based solely on a hobby project usiing a Telenor branded NR7101 I bought used on "finn" for my own money. But I do also have a Telenor provided NR7101 for work purposes. And I do use everything I learn from all my hobby projects in my daytime job. Just not the other way around.