Any system that contains routines which write or erase FLASH memory involves some risk that the FLASH write/erase routines will execute if the CPU is operating outside its defined operating range of VDD, temperature, or system clock frequency.

...

The most likely candidate for potential FLASH corruption is the CPU exiting reset prematurely (before VDD reaches 2.7V) on initial power-on. This is usually caused by a system VDD rise time that is slower than the 1 ms specification in the datasheet. One way to address this is to install an off-chip VDD brownout circuit on the /RST pin. Another way is to implement additional safeguards in code to ensure that the on-chip VDD monitor is always enabled whenever a write or erase to FLASH memory is attempted. Of course, it is also perfectly acceptable to implement both of these (hardware and software) schemes.

One other potential system parameter that can affect CPU code execution reliability is the system clock source. If the system clock is derived from an external crystal oscillator, then external EMI coupling can cause a runt pulse to be coupled into the system clock net which can lead to indeterminate operation. One way to lessen this risk is to enable the "divide by 2" option in the external crystal oscillator. Better ways are to use the internal oscillator or use an external CMOS can oscillator (one that is encased in a metallic shield to protect the sensitive crystal elements from external coupling effects).